2008-09-29 12 views
15

En general, ¿qué hay que hacer para convertir un programa de Windows de 16 bits a Win32? Estoy seguro de que no soy la única persona que hereda una base de código y me sorprendería encontrar código de 16 bits al acecho en las esquinas.Conversión de código Win16 C a Win32

El código en cuestión es C

+0

¿qué tipo de aplicación es esta? –

+0

He encontrado varios en nuestra base de código; la mayoría son simuladores con GUI simples. El crítico es las comunicaciones en serie para hablar con dispositivos integrados.También tiene una GUI. – Zathrus

+0

Wow ... lo siento mucho por ti ... Siendo yo el que tengo que lidiar con el código de la API C pura de Win32 y tratando de llorar en el olvido, al menos, veo que podría ser mucho peor ...: - / – paercebal

Respuesta

15
  1. Los significados de wParam y lParam han cambiado en muchos lugares. I fuertemente lo invito a ser paranoico y convertir tanto como sea posible para usar message crackers. Ellos te salvarán de dolores de cabeza. Si solo hay un consejo que pueda darte, este sería.
  2. Siempre y cuando use mensajes de crackers, también habilite STRICT. Te ayudará a capturar la base de código Win16 usando int donde debería estar usando HWND, HANDLE, o alguna otra cosa. La conversión de estos será de gran ayuda con el # 9 en esta lista.
  3. hPrevInstance es inútil. Asegúrate de que no se use.
  4. Asegúrese de estar utilizando llamadas amigables para Unicode. Eso no significa que usted necesita para convertir todo para TCHAR s, pero significa que reemplace mejor OpenFile, _lopen y _lcreat con CreateFile, por mencionar lo obvio
  5. LibMain es ahora DllMain, y la totalidad de los convenios de formato de biblioteca y de exportación son diferentes
  6. Win16 no tenía VMM. GlobalAlloc, LocalAlloc, GlobalFree y LocalFree deben reemplazarse por equivalentes más modernos. Cuando termine, limpie las llamadas a LocalLock, LocalUnlock y amigos; ahora son inútiles. No es que imagine que tu aplicación está haciendo esto, pero asegúrate de no depender de WM_COMPACTING mientras estás allí.
  7. Win16 tampoco tenía protección de memoria. Asegúrese de no estar usando SendMessage o PostMessage para enviar punteros a ventanas fuera de proceso. Tendrá que cambiar a un mecanismo de IPC más moderno, como tuberías o archivos mapeados en la memoria.
  8. Win16 también carecía de multitarea preventiva. Si quería una respuesta rápida desde otra ventana, era genial llamar al SendMessage y esperar a que se procesara el mensaje. Esa puede ser una mala idea ahora. Considere si PostMessage no es una mejor opción.
  9. Cambian el tamaño del puntero y el número entero. Recuerde verificar cuidadosamente en cualquier lugar que esté leyendo o escribir datos en el disco —, especialmente si se trata de estructuras Win16. Tendrá que volver a hacerlos manualmente para manejar los valores más cortos. Una vez más, la forma menos dolorosa de lidiar con esto será usar crackers de mensaje cuando sea posible. De lo contrario, deberá buscar y convertir manualmente int en DWORD, y en su caso.
  10. Finalmente, cuando haya encontrado lo obvio, considere habilitar comprobaciones de compilación de 64 bits. Muchos de los problemas que se enfrentan al pasar de 16 a 32 bits son los mismos que pasar de 32 a 64, y Visual C++ en realidad es bastante inteligente en estos días. No solo detectará algunos problemas persistentes; también te prepararás para tu eventual migración de Win64.

EDITAR: Como @ChrisN señala, the official guide for porting Win16 apps to Win32 está todavía disponible, y tanto da cuerpo a y se suma a mis puntos anteriores.

1

el SDK de Win32 original tenía una herramienta que escanea el código fuente y marcado líneas que debían ser cambiado, pero no puedo recordar el nombre de la herramienta.

Cuando he tenido que hacer esto en el pasado, he usado una técnica de fuerza bruta - es decir: 1 - actualiza los archivos make o el entorno de compilación para usar el compilador de 32 bits y el enlazador. Opcionalmente, solo crea un nuevo proyecto en tu IDE (uso Visual Studio) y agrega los archivos manualmente.

2 - construir

3 - corregir los errores

4 - 2 repetir & 3 hasta que esté hecho

El dolor del proceso depende de la aplicación que está migrando. He convertido 10,000 programas de línea en una hora, y 75,000 programas de línea en menos de una semana. También he tenido algunas pequeñas utilidades de las que me di por vencido y reescribí (la mayoría) desde cero.

0

Estoy de acuerdo con Alan en que la prueba y error es probablemente la mejor manera.

Éstos son algunos buenos tips.

0

Estoy de acuerdo en que el compilador probablemente detectará la mayoría de los errores. Además, si usa punteros "cercanos" y "lejanos", puede eliminar esas designaciones; un puntero es solo un puntero en Win32.

6

Aparte de conseguir su entorno de compilación correcta, aquí hay pocos detalles que se necesitan para hacer frente a:

  1. estructuras que contienen enteros tendrá que cambiar a corto o ampliar de 16 a 32 bits. Si cambia el tamaño de la estructura y esta se carga/guarda en el disco, necesitará escribir el código de actualización del archivo de datos.

  2. Por ventana los datos suelen almacenarse con el identificador de ventana usando GWL_USERDATA. Si amplía algunos de los datos a 32 bits, sus desplazamientos cambiarán.

  3. PUNTO & Las estructuras de tamaño son 64 bits en Win32. En Win16 eran 32 bits y podían devolverse como DWORD (la persona que llama dividiría el valor de retorno en dos valores de 16 bits). Esto ya no funciona en Win32 (es decir, Win32 no devuelve resultados de 64 bits) y las funciones se cambiaron para aceptar un puntero para almacenar los valores devueltos. Deberá editar todos estos. Las API como GetTextExtent se ven afectadas por esto. Este mismo problema también se aplica a algunos mensajes de Windows.

  4. Se desaconseja el uso de archivos INI en Win32 a favor del registro. Si bien las funciones del archivo INI aún funcionan, deberá tener cuidado con los problemas de Vista. Los programas de 16 bits suelen almacenar su archivo INI en el directorio de sistema de Windows.

Estos son solo algunos de los problemas que puedo recordar. Ha pasado más de una década desde que hice cualquier migración de Win32. Una vez que lo entiendes, es bastante rápido. Cada base de código tendrá su propia "sensación" cuando se trata de portar a la que se acostumbrará.Probablemente incluso encuentres algunos errores en el camino.