Mucho se está hablando del nuevo sistema operativo Windows 8 de Microsoft, sobre todo del cambio de modelo que implica, tanto para usuarios como para desarrolladores, el protagonismo de la nueva interfaz gráfica “Metro” y su entorno de ejecución subyacente. Pero hay un detalle novedoso en relación con el escritorio clásico en el que poca gente suele reparar porque pertenece a una funcionalidad muy antigua, cada vez menos usada y condenada a desaparecer.
Nota: las funcionalidades que se van a describir corresponden a un sistema en fase de desarrollo, por lo tanto podrán sufrir variaciones importantes con respecto a la versión final o incluso desaparecer por el camino. Tómese la información aquí expuesta con la máxima prudencia.
Microsoft presentó hace unas dos semanas la versión preliminar Developer Preview, un anticipo para desarrolladores. Su intención es que los creadores de aplicaciones se familiaricen ya con la filosofía de desarrollo de “Metro”, de forma que el lanzamiento oficial del sistema operativo vaya acompañado de suficientes aplicaciones “Metro” compatibles y de calidad. Esta versión no incluye algunas de las características previstas en la versión final del producto ni tiene calidad de “beta”, por lo que a veces puede exhibir algún comportamiento extraño.
Jugando un poco con la edición x86 de 32 bits de Developer Preview probé a abrir el viejo editor de MS-DOS, Edit.com. También podría haber usado Command.com, Mem, Debug, el denostado Edlin que tiene más años que un servidor (¿lo echará en falta alguien cuando ya no esté?), o incluso, como aplicación Windows de 16 bits, el vetusto y actualmente inservible editor de archivos de configuración Sysedit.exe que apareció primero en Windows 3.0. Me llevé una sorpresa.
La capacidad de ejecutar aplicaciones antiguas basadas en MS-DOS y Windows de 16 bits está presente exclusivamente en las ediciones x86 de Windows, a través de los subsistemas NTVDM (NT Virtual DOS Machine) y WOW respectivamente. No confundir este WOW, en ocasiones también llamado WOW32 o Windows on Win32, con WOW64, que en los sistemas de 64 bits constituye la capa de compatibilidad con aplicaciones Windows de 32 bits, ni con —nota friki superflua— el videojuego World of Warcraft.
NTVDM y WOW dependen casi completamente del modo 8086 virtual exclusivo de la arquitectura x86 de 32 bits. Su traslado a otras arquitecturas, como x64 o Itanium, habría supuesto reescribir estos componentes como emuladores completos del modo real y de un subconjunto del modo protegido de los procesadores x86. Solamente merece la pena dedicar recursos a añadir o mejorar una característica del sistema si se estima que el uso o el beneficio superará con creces el esfuerzo empleado. Por tanto, Microsoft abandonó esta posibilidad en todas las ediciones de 64 bits de Windows.
En la ventana de la imagen anterior, la opción “Enable” permite el uso de aplicaciones de 16 bits de aquí en adelante.
Por el contrario, si se selecciona “Disable”, se anula la compatibilidad y aparece el consiguiente mensaje de error cada vez que se intenta usar un programa de 16 bits.
La configuración actual no cambia si se cierra la ventana de confirmación sin haber elegido “Enable” o “Disable”. En caso de no tener un valor definido, Windows decide como opción más segura (secure by default) no ejecutar tampoco la aplicación. La próxima vez se volverá a mostrar la ventana.
¿Qué ha influido supuestamente en esta decisión? A lo largo de la historia de Windows NT, la familia de la que procede Windows 8, se han descubierto varias vulnerabilidades en el subsistema NTVDM y la sección del núcleo de Windows que le sirve de apoyo. Un usuario limitado local podría obtener de forma directa privilegios de administrador o sistema local, incluso eludiendo el control de cuentas de usuario de Windows Vista y sus sucesores, ejecutando de forma intencionada o fortuita un programa de 16 bits especialmente preparado en un Windows vulnerable. Algunos de estos fallos de seguridad han permanecido latentes durante mucho tiempo, posiblemente desde el origen mismo de Windows NT (versión 3.1, año 1993). El más grave o quizá más mediático fue el que divulgó el investigador Tavis Ormandy a principios de 2010, seis meses después de comunicar el informe a Microsoft de forma privada y esperar una solución. Finalmente, Microsoft publicó la corrección del problema unas pocas semanas más tarde en el ciclo de febrero de 2010 con la actualización KB977165, que describió en el boletín de seguridad MS10-015. Las ediciones de 64 bits, salvo Windows 7 y Windows Server 2008 R2, no están afectadas por esta vulnerabilidad pero sí por otra resuelta en la misma actualización.
La configuración de la compatibilidad con aplicaciones de 16 bits está contenida en el archivo Ntvdmcpl.cpl, un elemento clásico del panel de control. El equipo de desarrollo de Windows habrá tenido sus motivos para presentarlo de este modo, tal vez disimularlo un poco, en lugar de empaquetarlo en un archivo EXE tal como se recomienda a partir de Windows Vista. La navegación habitual del panel de control no muestra este elemento, así que para encontrarlo hay que cambiar a una vista de iconos (todos los elementos) o usar la función de búsqueda. También se puede invocar explícitamente mediante la ventana Ejecutar con la combinación Windows+R.
Dos valores del registro determinan si si la ejecución de programas de 16 bits está permitida. El primero es el valor DisallowedPolicyDefault de la clave HKLM\System\CurrentControlSet\Control\WOW. El segundo, que se puede hallar en HKLM\Software\Policies\Microsoft\Windows\AppCompat y se denomina VDMDisallowed, forma parte de la directiva de grupo “Impedir el acceso a aplicaciones de 16 bits” (Configuración del equipo, Plantillas administrativas, Componentes de Windows, Compatibilidad de aplicaciones) y tiene preferencia sobre el anterior.
La siguiente tabla muestra las combinaciones de ambos valores y su efecto sobre la ejecución:
| VDMDisallowed (directiva de grupo) | DPD no definido | DPD = 0 | DPD <> 0 |
| No configurado | Preguntar al usuario* | Permitido | Acceso denegado |
| Cero (directiva deshabilitada) | Permitido | Permitido | Permitido |
| Distinto de cero (directiva habilitada) | Acceso denegado | Acceso denegado | Acceso denegado |
* En versiones anteriores a Windows 8, ejecución permitida.
La elección de “Enable” o “Disable” en la ventana de configuración vuelve a llamar a Ntvdmcpl.cpl con un parámetro especial. La operación necesita privilegios administrativos para escribir en la rama HKEY_LOCAL_MACHINE.
Cuando se opta por “Disable”, Ntvdmcpl recibe el parámetro /setdpd:1 para establecer DisallowedPolicyDefault a 1.
Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:1
Análogamente con “Enable”: en este caso el parámetro es /setdpd:2. DisallowedPolicyDefault se pone a cero.
Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:2
¿Por qué se utiliza /setdpd:2 para establecer a cero el valor DisallowedPolicyDefault? Resulta que /setdpd:0 está reservado para otra finalidad.
¿Qué hace “Rundll32 Shell32.dll,Control_RunDLLAsUser Ntvdmcpl.cpl,,/setdpd:0”? Si abrimos Ntvdmcpl.cpl a continuación o ejecutamos un programa de 16 bits, y además la directiva VDMDisallowed no está definida, veremos que los dos botones “Enable” y “Disable” vuelven a estar activos. ¿Y si usamos /setdpd:0 dos veces seguidas?
El mensaje de error es confuso: el sistema no puede hallar el archivo especificado. La explicación es muy sencilla. El parámetro /setdpd:0 indica que se borre el valor DisallowedPolicyDefault, sea cual sea su contenido. Windows no contempla códigos de error específicos para las operaciones relacionadas con el registro, de modo que sus funciones devuelven errores coherentes con la idea de que el registro se organiza en directorios (claves) y ficheros (valores). Ntvdmcpl.cpl no comprueba si el valor DisallowedPolicyDefault existe antes de eliminarlo, así que la segunda vez la función de borrado fracasa con el error “fichero no encontrado”.
Ntvdmcpl.cpl admite otro parámetro, /originalapp, seguido de dos puntos y un texto entrecomillado, que se muestra en la ventana de configuración a continuación de “You are attempting to run”. Windows usa este parámetro para indicar qué programa de 16 bits se ha intentado ejecutar cuando no están definidos los valores VDMDisallowed y DisallowedPolicyDefault. Una demostración:
Rundll32 Shell32.dll,Control_RunDLL Ntvdmcpl.cpl,,/originalapp:"c:\windows\system32\command.com"
Para terminar, diversos rumores señalan que Microsoft podría no publicar una edición x86 del sucesor de Windows 8, por tanto éste constituiría la última versión de 32 bits capaz de ejecutar programas de 16 bits de forma nativa e integrada sin tener que emplear máquinas virtuales o emuladores como DOSBox.
Por cierto, ¿sabías que la versión de DOS emulada en la familia Windows NT es MS-DOS 5.0? La información de copyright de los archivos ejecutables y la función 30h de la INT 21h (AX=0005h) así lo atestiguan.