¿Qué hay detrás del mensaje "Win 16 Subsystem no tiene suficientes recursos…"?

Si usa Windows XP es posible que en alguna ocasión se haya encontrado con el siguiente mensaje de aviso:

Win 16 Subsystem no tiene suficientes recursos para que continúe ejecutándose. Haga clic en Aceptar, cierre sus aplicaciones y reinicie su equipo.

¿Qué quiere decir exactamente este mensaje? Básicamente, es la consecuencia de una desacertada decisión de diseño que Microsoft tomó hace décadas y que provocó una serie de fallos descubiertos poco tiempo antes de la salida al mercado de Windows XP. Este artículo indagará un poco en este tema tan curioso.

Un poco de historia

Windows incorpora desde sus comienzos una interfaz que permite a los programadores diseñar elementos gráficos para sus aplicaciones. Esta interfaz recibe el nombre de GDI (Graphics Device Interface). Ya desde Windows 3.1, Microsoft supuso que GDI solamente podría generar handles de tamaño menor de 16 K. En aquellos tiempos, los handles se implementaban en el montón (heap) de GDI y estaban limitados a 14 de los 16 bits posibles. Es decir, los dos últimos bits estaban reservados (el último bit siempre era cero porque las direcciones de memoria tenían que ser pares). Con la llegada de los 32 bits, llegó GDI32 y con él los handles pasaron a ocupar una palabra de longitud: La mitad inferior contenía el valor en sí y la mitad superior una serie de bits para dar unicidad al handle.

Como supongo que ya sabrá, los sistemas operativos Windows de 32 bits incorporan un subsistema de 16 bits encargado de hacer funcionar aplicaciones antiguas de 16 bits. Este subsistema recibe el nombre de WoW (Windows on Windows). Obviamente, dicho subsistema tiene que tener alguna manera de convertir un handle GDI de 32 bits a uno de 16 bits y viceversa. Hasta la llegada de Windows XP lo que se había venido haciendo es simplemente descartar la mitad superior, quedarse con la mitad inferior y desplazarla dos posiciones hacia la izquierda. Como los handles eran menores de 16 K, el desplazamiento no suponía pérdida de información y todo funcionaba a pedir de boca… hasta que llegó Windows XP.

Con Windows XP empezaron los problemas

Con la llegada de Windows XP, surgió la necesidad de tener handles GDI de tamaño superior a 16 K. Por este motivo, el equipo de GDI decidió utilizar completamente los 16 bits de la parte inferior del handle (recuerde que hasta entonces solo se usaban 14 bits). El problema, como puede empezar a vislumbrar, sucedía cuando un handle de tamaño mayor de 16 K tenía que ser convertido por la máquina virtual de 16 bits. Al hacer el desplazamiento de los bits, ya sí se perdía información, y los efectos negativos no tardaron en aparecer.

Este problema se descubrió en una fase muy tardía de la beta de XP, por lo que Microsoft no tuvo otra opción que implementar rápidamente una solución temporal: Concretamente decidió que, antes de convertir, se comprobara el tamaño del handle; si éste fuese superior a 16 K, se mostraría el mensaje de aviso del principio de este artículo y se finalizaría la ejecución de la máquina virtual de 16 bits. La solución adoptada en Windows Vista y Windows Server 2008, ya con tiempo suficiente para comprobarla exhaustivamente, consiste en una tabla de correspondencias entre handles de 32 bits y handles de 16 bits.

Es curioso ver que una solución válida durante un determinado contexto temporal (desplazamiento de bits para convertir handles de 32 bits a 16 bits, y viceversa) puede ser totalmente errónea en el momento que se introduzca algún tipo de “ampliación” con la que no se contaba en ese momento. La implementación desde un principio de la tabla de correspondencias habría ahorrado un buen número de usuarios disgustados por la solución temporal.

Ya como curiosidad final, y esto ya es más una opinión personal, si se da cuenta, la cadena de texto en español contiene la nomenclatura inglesa (“Win 16 Subsystem”), cuando el resto de cadenas de Wow32.dll que hacen referencia a este concepto usan su acertada traducción al español, “Subsistema Windows de 16 bits”. Ésta podría ser otra prueba más de que la implementación de esta solución temporal llegó muy, pero que muy tarde en el ciclo de desarrollo de Windows XP.