Con 32 bits es mucho mejor

Puesto que es un componente del sistema operativo el que decide cómo repartir la torta del tiempo de proceso (el Scheduler), se dice que la multitarea de Windows 95 es prioritaria. Se basa en prioridades y la asignación de estas prioridades no es responsabilidad de los programas y los hilos, sino del sistema operativo. Además, cada programa que se ajuste a esta norma -los de 32 bits, típicamente- pueden dividir su código en varios hilos.

Sin embargo, las aplicaciones de 16 bits no saben cómo realizar tales malabarismos y siguen funcionando según el método cooperativo.

La multitarea cooperativa tiene básicamente dos defectos: primero, deja en manos de los programas (o, más exactamente, en manos de quienes escriben los programas, que son humanos y pueden cometer errores) la tarea de delegar tiempo de proceso en otros programas actualmente en ejecución. No todas las aplicaciones son igual de civilizadas, sobre todo aquellas creadas en un mundo monolíticamente monotarea (como el DOS), y no es raro que tales programas acaparen tiempo de microprocesador incluso cuando no lo necesitan. Segundo, como no pueden expandirse en varios hilos, Win95 los ve como un solo hilo y no más de uno.

El tercer defecto, posiblemente el más serio desde el punto de vista del usuario, es que una sola aplicación de 16 bits que se haya quedado congelada puede, si no colgar el sistema, impedirle al usuario tener control de la interfaz. La versión light de esto es que las aplicaciones de 16 bits hacen que todo el sistema funcione más lento.

La punta del ovillo

¿Por qué un programa de 16 bits puede producir estos efectos adversos y uno de 32 no? Como suele ocurrir en informática, la cuestión es más bien que las aplicaciones de 32 bits son menos propensas a esta clase de comportamiento, mientras que el diseño de Windows 95 fomenta el que las de 16 bits puedan obstaculizar las operaciones con la interfaz. La razón de esto es que la arquitectura de Win95 combina código de 16 y 32 bits para dar compatibilidad a los programas escritos para Windows 3.1.

Sin duda, Microsoft hubiera querido olvidarse del código de 16 bits y, entre otras cosas, de su estilo cooperativo de hacer multitarea. El problema es que había cientos de miles de aplicaciones muy populares escritas en 16 bits para Win3.1. Lo que hicieron entonces fue una serie de concesiones de arquitectura a expensas de la robustez. Windows NT, en contraposición, es puro 32 bits y, a expensas de la compatibilidad, logra mayor robustez.

¿Qué tiene que ver el multithreading con la estabilidad y desempeño de un sistema operativo? Es fácil de entender si usted se plantea algunas preguntas: ¿cómo tratar a un módulo de 16 bits -como User o GDI- que no tienen en cuenta que podrían ser interrumpidos por el Scheduler cuando el Scheduler quiera? ¿Y qué hacemos con las llamadas a las direcciones de memoria? Caramba, los tipos de datos de 32 y 16 bits son bien diferentes. ¿Y las ventanas? ¿Cómo han de comportarse? Es de suponer que todo el sistema de visualización debería ser de 16 bits, para que le resulte comprensible a las aplicaciones de Windows 3.1. Sí, claro, ¿pero entonces las de 32 bits deberán rebajarse a usar ventanas de 16 bits?

Soluciones de compromiso

La forma en que Microsoft resolvió éstos y una docena de problemas más que aparecen toda vez que se combinan dos estilos tan diferentes de código escapa al horizonte de esta columna y, en verdad, excepto para los programadores y técnicos en general, no debe ser motivo de preocupación para el usuario. Pero daremos algunos titulares, simplemente para demostrar que, aunque signifique volver a invertir dinero en software, es una muy buena idea el correr sólo aplicaciones de 32 bits nativas bajo Windows 95.

Primer asunto, las interrupciones del código de sistema que continúa siendo de 16 bits, por ejemplo el manejo de las ventanas. Solución: el Win16Mutex . Suena a remedio, pero debe leerse como Windows 16 Mutual Exclusion , un objeto (se lo llama semáforo en la jerga) que sólo permite que se ejecute un hilo de 16 bits por vez. Se dice, también en la jerga, que al ejecutarse un hilo de 16 bits tiene el Win16Mutex. Lamentablemente, el código de 16 bits no sólo tiene, sino que también retiene el Win16Mutex mientras está ejecutándose.

Como el manejo de las ventanas sigue siendo en gran parte de 16 bits, una DLL escrita para Win3.1 (y hay miles) que no consiguiera soltar el Win16Mutex en tiempo y forma impediría operar con la interfaz; el código de 16 bits se interpone en el multithreading de las acciones relacionadas con ventanas. Dicho más simple: con aplicaciones de 16 bits, todo el control de la interfaz gráfica le resultará más lento y pesado, incluso con las aplicaciones de 32. También los programas de 32 deben convocar funciones de Gdi.exe y User.exe , que se ejecutan reteniendo el Win16Mutex . Este proceso de comunicación entre código de 32 y 16 bits, que involucra toda una serie de traducciones, se llama, en la jerga, thunking . (A propósito, no busque la palabra en el diccionario, no existe, es un invento de los desarrolladores de Win95.)

Pero, ¿por qué dejaron código de 16 bits en el manejo de ventanas precisamente en una interfaz gráfica? Bueno, primero, no todo el código es de 16. Las funciones gráficas y de usuario que tendían a devorar tiempo de proceso fueron reescritas en 32 (de allí las bibliotecas de vinculación dinámica User32.dll y Gdi32.dll ) para mejorar su rendimiento. En cuanto a las que quedaron de 16 bits, no sólo contienen partes en Assembler y marchan tan bien como las de 32, sino que además hubiera sido riesgoso volver a escribir todo ese código de nuevo; andaba bien, estaba probado y no había necesidad de hacerlo otra vez. El segundo motivo para dejar código de 16 en estos módulos es que los programas (y esto incluye una multitud de bibliotecas de vinculación dinámica) de Win3.1 no hubieran sabido cómo manejarse con ventanas de 32 bits. Además, recuerde: Windows 95 tenía la meta de funcionar en equipos modestos, al revés que NT. Y el código de 16 bits tiende a ser más conciso que el de 32.

Cooperando, o no tanto

El último de los problemas que mencionaremos es que la forma de acceder a la memoria a 16 bits es muy diferente de hacerlo a 32, y como el acceso a memoria de Windows 95 es siempre a 32 bits, las llamadas de aplicaciones de 16 bits deben ser traducidas a tipos de datos de 32 bits. Y viceversa.

Funciona bien, pero consume tiempo de proceso, lo que sumado a la multitarea cooperativa, el Win16Mutex y las funciones de interfaz gráfica y usuario en 16 bits dará como resultado que una sola aplicación de Windows 3.1 ejecutándose en Windows 95 afectará el desempeño general del sistema, incluidos los programas de 32 bits. Moraleja: conviene mudarse a 32 bits cuanto antes. Esto, en general. En lo particular, Windows 95 todavía tiene partes que se ejecutan en 16 bits, de modo que en realidad es imposible deshacerse por entero de los programas de esta clase (a menos que instale NT, por supuesto); sin embargo, el código de 16 bits de Win95 no afectará el desempeño del sistema y de los programas de 32 bits.

Además, y como queda dicho, el software está escrito por personas y, más frecuentemente, por equipos de personas; así que puede esperar algún que otro programa y DLL de 32 bits causando toda clase de problemas en su Windows 95. Multithreading a 32 bits no es, de ninguna manera, una solución mágica.

Debe quedar claro que Windows 95 no es estable o inestable de por sí, al revés que NT. NT está diseñado para aguantar golpes sobre el núcleo del sistema sin caerse. Es su misión. Por eso, las aplicaciones de 16 bits corren en su propio espacio de memoria, aisladas de las de 32 bits.

Win95 está hecho para consumir menos recursos y ser compatible con casi todos los programas para PC que existen. Los programas de 16 y 32 bits comparten el espacio de memoria y según lo que usted corra en este sistema, será más o menos propenso a colgarse.

Por Ariel Torres

---

Conforme a