| Artículos | 01 OCT 1995

¿Cómo migrar aplicaciones a Windows 95?

Tags: Histórico
Recompilar aplicaciones para 32 bits
Jaime Peña.

Con la llegada de Windows 95, muchos son los programadores que se decidirán por recompilar sus aplicaciones para 32 bits. Veremos algunas orientaciones para migrar lo más rápidamente posible nuestros códigos.

Una de las más importantes ventajas de Windows 95 desde el punto de vista del programador es su capacidades de direccionamiento de 32 bits. Se trata de un sistema operativo de 32 bits en su amplio sentido de la palabra. Hasta el presente, y dejando de lado la disponibilidad de Windows NT, no era posible ejecutar aplicaciones nativas de Win32 en Windows 3.x, ya que se trataba de un mero entorno sobre el sistema operativo DOS, de 16 bits.

Una especie de parche, que en cierto modo ha sido bastante aceptable, lo constituía el subconjunto del API Win32 denominado Win32s, que se podía instalar sobre Windows 3.x. Con todo, la ganancia en prestaciones no era lo digna que se desearía, ya que no se podía obviar el sistema operativo base.

Ahora es el momento de pensar, seriamente, en programar para Win32 y, para ello, nada mejor que partir de la migración de nuestras aplicaciones Win16. Veremos que nos será válido gran parte del código y casi todo el diseño de las aplicaciones; sólo hemos de tener en cuenta ciertos cambios en, fundamentalmente, el tamaño de tipo de datos int y cambios en algunos mensajes. Desde luego, hay ciertas utilidades que nos ayudan en la tarea, pero sólo sugieren cambios, no realizándose ningún tipo de migración automática.

Respecto al API Win32, es la usada por el nuevo sistema operativo Windows 95, pero hemos de tener muy presente que Microsoft la define como una especie de superconjunto de funciones, definiciones, mensajes y macros para toda la serie de sistemas operativos Windows de 32 bits, presentes (Windows NT y Windows 95) y futuros (Proyecto Cairo, implementación para PowerPC, etc.). Así que, sería inconsistente pretender recoger ejemplos de todas las funciones Win32 y tratar de trasladarlas a Windows 95.

En el presente artículo, no es nuestra intención dar un repaso completo a lo que habría que tener presente a la hora de migrar todo tipo de aplicaciones. Sería una labor demasiado ambiciosa para relativamente poco espacio. No consideraremos el uso de los Message Crackers, o de los restantes componentes del archivo de cabecera WINDOWSX.H, que mediante macros permite mantener código válido para 16 y 32 bits en un mismo archivo (al margen de que seamos poco favorables a ello y prefiramos, en la mayor parte de los casos, mantener archivos separados). Usaremos un ejemplo, bastante simple, para ver cuáles son los cambios fundamentales (sintácticos y semánticos) que hemos de tener presentes.

La utilidad PORTTOOL

Microsoft, ya desde hace tiempo, ha puesto a disposición de los programadores una utilidad de migración, denominada PORTTOOL.EXE, que repasa código fuente en Win16 y lo comenta para facilitar su migración a Win32. Funcionará, por tanto, sobre los archivos de código C y los archivos de cabecera (.H). Desde luego, es un aceptable punto de partida, aunque desafortunadamente tampoco es una solución final, ni demasiado explícita.

PORTTOOL puede encontrarse en las más recientes versiones de los compiladores de C/C++, como Borland, Microsoft o Symantec; nosotros hemos trabajado con la versión 2.2, que acompaña al CD-ROM de desarrollo de las últimas betas de Windows 95. Se trata de una aplicación Windows que carga código fuente en lenguaje C, para Win16, y nos da cómo salida un archivo comentado de los cambios sugeridos y advertencias acerca de variaciones en el tratamiento de funciones o mensajes estándar. PORTTOOL es un sistema personalizable, ya que se basa en un archivo de base de datos de entradas en modo texto, en el cual se recogen los cambios a sugerir. Tiene dos formas de realizar su labor, interactivamente, preguntando en cada caso, o en trasfondo, insertando automáticamente los comentarios preestablecidos en su base de datos.

Realmente, no es un sistema infalible, por ejemplo, no comprueba tipos de datos de variables. Así, si usa un manejador de la instancia de la aplicación, no comprobará si se define como HANDLE genérico o como HINSTANCE, que es lo recomendado. Tampoco nos refiere algunos cambios en la estructura de llamadas a diálogos, liberación de memoria de los recursos (un proceso automático en Windows 95) y demás cuestiones que son compatibles con Win32, aunque innecesarias.

Hay varias posibilidades de definir en qué fijarse, por ejemplo: funciones, mensajes, estructuras, macros, constantes, tipos de variables de lenguaje C, funciones o comentarios definidos por el usuario y mayuscularización. En definitiva, una herramienta de entrada que nos orientará en el trabajo más mecánico de la migración de nuestros archivos de código.

Autoprotección del código fuente

Por nuestra parte, cabe un cierto nivel de autoprotección para obviar errores o malas costumbres, que pudieran tener escasa influencia en Win16, pero que podrían ser más serias en Win32. De entre ellas, destaca el recomendable hábito de incluir la directiva #define STRICT.

La directiva de compilación #define STRICT es un primer seguro para la correcta comprobación de tipos de datos. Ya sabemos que el lenguaje C nos permite un alto grado de libertad al respecto, no es fuertemente tipado, como el lenguaje Pascal, lo que tiene ciertas ventajas, pero también puede acarrear muchos errores difíciles de depurar. La directiva STRICT debe situarse antes de cualquier otra y desde luego siempre antes de los archivos incluidos (#include <...>). Su funcionalidad reside en que se fuerzan constantes avisos acerca de la no coincidencia de tipos, de manera que podremos revisar nuestro código para garantizar la portabilidad a Win32.

Por ejemplo, observe el fragmento del archivo de cabecera WINDOWS.H de la figura 1. Cuándo se ha definido STRICT en el código fuente, no se admiten tipos de HANDLE genéricos referenciando instancias (se debe usar HINSTANCE en su lugar). Bastará repasar WINDOWS.H para observar multitud de cambios en la declaración de tipos parametrizados en las funciones. De igual forma, se comprueban estrictamente otros tipos parametrizados.

Cambios en la función WinMain

La función de entrada, WinMain, es casi plenamente compatible, en su declaración y estructura, en Win16 y Win32. En su declaración y definición hemos de cambiar el tipo genérico HANDLE por HINSTANCE, en sus dos primeros parámetros, que apuntan a la instancia de la aplicación que queremos iniciar y a cualquier otra instancia previa que hubiéramos arrancado.

Al respecto se debe puntualizar que e parámetro de la instancia previa no tiene significado, ni interés, alguno en Win32. En Win16 (Windows 3.1) el sistema compartía parte del código que era común a diversas instancias de una misma aplicación (por ejemplo, la declaración y registro del tipo de ventana). En Win32 (Windows NT o Windows 95), las cosas ya no acontecen así, de manera que corrupciones del código de una aplicación no arrastren a otras.

Observe el listado de la figura 2, allí exponemos una maqueta de una aplicación Win32; no realiza grandes cosas, sólo abre una ventana y dispone de un sistema de menús que despliegan cajas de diálogos. Pero sí ilustra muchos de los cambios más importantes que hemos de tener presentes.

La declaración de WinMain cambia en varios aspectos. Primero, el tipo de función se debe declarar int WINAPI, en vez de int PASCAL; así se garantiza la portabilidad entre plataformas. En sus parámetros ahora se debe especificar claramente el tipo HINSTANCE para el primero y el segundo. Además, ya no hay necesidad de comprobar la existencia de una instancia previa de la aplicación, por las razones apuntadas acerca del mantenimiento aislado de cada aplicación en Win32. El código Win16 típico puede mantenerse:

if (!hPrevInstan

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información