Daniel Martín's blog : Curiosidades

Sobre el error "La operación solicitada requiere elevación" que puede devolver Runas.exe en Windows Vista/7

dmartin — Sun, 04 Oct 2009 01:32:00 GMT

En un foro que frecuento un usuario tenía el siguiente problema: Al intentar ejecutar como administrador un programa en Windows 7 usando el comando Runas.exe, le aparecía el siguiente mensaje de error:

740: La operación solicitada requiere elevación.

Ciertamente el usuario estaba proporcionando el nombre de usuario y la contraseña de un usuario con privilegios administrativos así que... ¿dónde estaría el problema?

En primer lugar, vamos a analizar con calma lo que quiere decir el mensaje de error. El mensaje de error "La operación solicitada requiere elevación" está recogido en el fichero de cabecera Ntstatus.h del SDK de Windows Vista y posteriores. Concretamente está definido con el nombre de macro ERROR_ELEVATION_REQUIRED.

¿Cuándo se devuelve ese código de error durante el funcionamiento de Windows?

En Windows los procesos se crean usando la API CreateProcess. Uno de los pasos que se siguen antes de crear un proceso en Windows Vista y posteriores es comprobar si el proceso en cuestión necesita elevar sus privilegios o no. A la hora de determinar este aspecto, entran en juego, entre otros, dos parámetros: El nivel de ejecución (runlevel) impuesto por el manifiesto de la propia aplicación, y el token del usuario que está lanzando ese programa. Existen tres posibles niveles de ejecución para una aplicación:

asInvoker: El nivel de ejecución es el mismo que el del proceso padre.
highestAvailable: El nivel de ejecución es el de mayores privilegios posibles, considerando el tipo de cuenta desde la cual se ejecuta el proceso.
requireAdministrator: El nivel de ejecución es administrativo, independientemente de las demás circunstancias.

Esta tabla recoge de forma básica las posibilidades:

Nivel de ejecución de la aplicación	Token del usuario	Requiere elevación o no
AsInvoker	Cualquiera	No
highestAvailable	Administrador "elevado"	No
highestAvailable	Administrador "estándar"	Sí
highestAvailable	Otro caso	No
requireAdministrator	Administrador "elevado"	No
requireAdministrator	Otro caso	Sí

Por administrador "elevado" me refiero a aquella cuenta con privilegios administrativos pero que, o bien ya ha elevado explícitamente sus privilegios (a través de un cuadro de UAC), o bien no tiene activada la característica Modo de aprobación del administrador (Admin Approval Mode). Esta característica se puede desactivar desde Directiva de grupo, pero yo personalmente lo desaconsejo. Un ejemplo de este tipo de cuentas es la cuenta "Administrador", creada durante la instalación del sistema operativo. Recuerde que el resto de cuentas con privilegios administrativos poseen dos tokens: uno limitado, con el que "actúan" por defecto, y otro "administrativo", que pueden aplicar si el usuario así lo indica a través de un cuadro de UAC.

Una vez que CreateProcess falla (devuelve un valor distinto de 1) y el último error se establece como ERROR_ELEVATION_REQUIRED (columna "Requiere elevación o no" de la tabla anterior), es asunto del proceso padre el tratar convenientemente este error. Si no lo hace, se registrará en Visor de sucesos, apartado dedicado a UAC, un evento informando de que el proceso padre no trató apropiadamente el error ERROR_ELEVATION_REQUIRED.

¿Qué ocurre cuando se lanza una aplicación desde la línea de comandos?

Imaginemos que el usuario intenta ejecutar el desfragmentador de disco de Windows 7 usando para ello una sintaxis de Runas.exe como esta:

runas /u:UsuarioAdministrador dfrgui.exe

Básicamente la línea de comandos detecta que no se trata de un comando interno, sino que se trata del programa Runas.exe, y por tanto se dispone a ejecutarlo usando CreateProcess. Como Runas.exe no es un programa que está marcado para requerir elevación de privilegios, CreateProcess retorna éxito.

Una vez que el planificador del sistema operativo cede el control al proceso Runas.exe recién creado, este se dispone a analizar su línea de comandos. Se encuentra con una petición de ejecutar Dfrgui.exe como si fuera el usuario administrador pasado como parámetro. Sin embargo, Runas.exe es poco más que un "envoltorio" de la API CreateProcessWithLogonW, que a su vez es poco más que un envoltorio de la API CreateProcess, pero pasando otro perfil de usuario distinto como parámetro.

Durante su ejecución, CreateProcess determina que Dfrgui.exe requiere privilegios administrativos (puesto que así se lo indica su manifiesto), y por ello devuelve falso y establace el último error como ERROR_ELEVATION_REQUIRED. Como Runas.exe es una herramienta que no está diseñada para tratar apropiadamente ese error, simplemente lo devuelve por pantalla de la forma "740: La operación solicitada requiere elevación".

Una vez desvelado el misterio, resta por comentar un aspecto que a estas alturas quizá ya se haya planteado:

¿Cómo es posible que ejecutando Dfrgui.exe desde la línea de comandos -sin usar Runas.exe- sí que aparezca un cuadro de UAC?

El secreto está en que la línea de comandos, antes de llamar a CreateProcess, informa al sistema de que va a tratar los posibles ERROR_ELEVATION_REQUIRED que puedan surgir. Esto lo consigue estableciendo unos atributos no documentados a la estructura STARTUPINFOEX, que se pasa como parámetro a la familia de API CreateProcess. Esto hace que no se registre el correspondiente error en el apartado UAC del Visor de sucesos. Seguidamente, la línea de comandos, sabiendo que se trata de un programa que debe elevar sus privilegios, lo intenta ejecutar mediante la API ShellExecuteEx. Esta API sí muestra el correspondiente cuadro de UAC, así que es la vía apropiada para ejecutar una aplicación que requiera privilegios administrativos.

En resumen, me gustaría resaltar estos puntos del tema del artículo:

En Windows Vista y Windows 7 la única forma de ejecutar algo con privilegios administrativos es mediante un cuadro de UAC. No vale con poner el nombre de usuario y la contraseña de un administrador en la línea de comandos.
Todo lo que se ejecute mediante la API CreateProcess, o alguna derivada de ella, no hará que aparezca un cuadro de UAC. Un ejemplo de ello es la utilidad Runas.exe.
Runas.exe, en Windows Vista/7, sirve para ejecutar una aplicación como si fuera otro usuario, pero no sirve para ejecutarla con mayores privilegios.
Si quiere que se ejecute una aplicación que requiere privilegios administrativos, use la API ShellExecuteEx, o alguna de sus derivadas. Esta API sí permite la aparición de un cuadro de UAC para que el usuario eleve sus privilegios.

¿Cuándo crea Windows un punto de restauración automático?

dmartin — Fri, 18 Sep 2009 02:31:00 GMT

Una de las dudas que más surgen entre los usuarios de Restaurar sistema es cada cuánto tiempo se creará un punto de restauración automático. Este artículo pretende dar una respuesta precisa a esta cuestión para así esclarecer aquellos casos en los que el sistema no haya creado un punto de restauración desde hace tiempo.

Windows XP

En Windows XP cada hora una tarea interna del Programador de tareas se encarga de analizar si el sistema está inactivo, es decir, si no está haciendo uso de la CPU ni del subsistema de E/S. Si se diera el caso, se realizan dos posibles comprobaciones para determinar si se debe crear un punto de restauración automático:

Si han pasado más de 24 horas desde el último punto de restauración, se crea uno automáticamente. Este parámetro (24 horas) es editable desde el Registro del sistema operativo, concretamente en la clave HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SystemRestore, valor RPGlobalInterval.
Si la sesión actual de trabajo con el PC está durando más de X horas y el último punto de restauración es más antiguo, se crea un punto de restauración automático. Por defecto, esta configuración no está establecida, pero puede hacerlo desde el Registro en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore, valor RPSessionInterval.

La comprobación de inactividad se realiza por defecto cada hora pero podría variar dependiendo de los valores de ciertas políticas de energía de su equipo. Eche un vistazo a los valores IdleTimeoutDc, IdleTimeoutAc de esta página de MSDN: http://msdn.microsoft.com/en-us/library/aa373239(VS.85).aspx. Aprovechando la inactividad, Restaurar sistema realiza otras tareas, tales como eliminar aquellos puntos de restauración cuyo tiempo de vida ya haya expirado, y de paso comprimir el almacén usando compresión NTFS. Estas tareas se realizan solo si el equipo está conectado a la corriente eléctrica, para evitar que se agote la batería en el caso de portátiles.

Si quiere profundizar en el funcionamiento de la herramienta Restaurar sistema de Windows XP, eche un vistazo a esta serie de artículos de mi antiguo blog:

http://rinconwindows.blogspot.com/2007/02/cmo-funciona-restaurar-sistema-parte-i.html

http://rinconwindows.blogspot.com/2007/03/cmo-funciona-restaurar-sistema-parte-ii.html

Windows Vista/7

En Windows Vista/7 el nuevo Programador de tareas muestra información detallada acerca de la tarea programada que crea un punto de restauración automático. Abra Programador de tareas, apartado \Microsoft\Windows\SystemRestore. La tarea SR tiene como desencadenantes:

El inicio del sistema.
Diariamente a las 12 AM.

En esos instantes se ejecutará el comando %windir%\system32\rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation.

El modificador /d de Rundll32.exe ya lo traté ligeramente en mi antiguo blog: Se trata de un modificador que le dice a Rundll32.exe "ejecuta este comando y no captures las posibles excepciones que ocurran". La función ExecuteScheduledSPPCreation es la encargada de verificar si el punto de restauración más antiguo tiene más de 12 horas (la mitad que en el caso de XP) y, si así fuese, creará uno nuevo.

Hay que tener en cuenta otras condiciones adicionales que puede observar en la pestaña Condiciones: El sistema debe estar inactivo durante al menos 10 minutos y además, en el caso de portátiles, debe estar conectado a la red eléctrica.

Espero que este artículo haya aclarado sus dudas con respecto a la creación automática de puntos de restauración por parte de Windows. En resumen, si su sistema no genera periodicamente puntos de restauración puede deberse a:

El servicio Programador de tareas no está iniciado.
El sistema no está inactivo durante los periodos de tiempo impuestos por Windows, según lo explicado anteriormente.

Sobre la nueva sintaxis del Panel de control en Windows Vista/Windows 7

dmartin — Fri, 11 Sep 2009 23:42:00 GMT

Quizá ya se haya dado cuenta de que en Windows Vista/Windows 7 algunos módulos del Panel de control que anteriormente estaban implementados en la clásica forma de un fichero .cpl ahora lo están en la forma de un fichero ejecutable (.exe). El motivo de este cambio es que con la introducción de Control de cuentas de usuario (UAC), se da el caso de que algunos de estos módulos requieren privilegios administrativos para ejecutarse. Veámoslo con un ejemplo:

El ejecutable DPIScaling.exe del directorio \Windows\System32 implementa la opción del Panel de control que permite cambiar la escala DPI del sistema. Este módulo requiere privilegios administrativos para ejecutarse, como así indica su fichero de manifiesto. Para verlo prácticamente, descargue Strings desde http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx y abra una ventana de línea de comandos en el directorio donde la ha extraído. Introduzca este comando y pulse INTRO:

strings %SystemRoot%\System32\DPIScaling.exe | findstr /i requireAdministrator

La salida del comando, level="requireAdministrator", nos indica que el ejecutable en cuestión requerirá privilegios administrativos cuando lo invoquemos. Otros posibles valores para el atributo level son:

asInvoker: El ejecutable no requerirá privilegios administrativos.

highestAvailable: El ejecutable se ejecutará con los máximos privilegios que le permita la cuenta de usuario desde la que ha sido invocado.

Nombres canónicos en Windows Vista/Windows 7

Esta reestructuración de buena parte de los elementos del Panel de control trajo consigo una de las novedades que se introdujeron en Windows Vista y que se han mantenido en Windows 7: la posibilidad de abrir elementos del Panel de control usando un nombre canónico. Un nombre canónico es un nombre en inglés, no traducible, que describe de manera cercana al usuario el cometido de ese elemento del Panel de control. Esto evita que el usuario tenga que aprender el nombre de ficheros .cpl, muchas veces crípticos, y además permite separar el nombre del ítem de su implementación, ya sea en un clásico fichero .cpl o, ya sea en un fichero .dll o .exe.

Por ejemplo, para abrir el panel Agregar o quitar programas de Windows Vista/Windows 7, se puede usar esta sintaxis:

%windir%\system32\control.exe /name Microsoft.ProgramsAndFeatures

¿De dónde proviene ese nombre canónico, Microsoft.ProgramsAndFeatures?

Cuando el ejecutable Control.exe recibe el parámetro /name seguido de un nombre canónico, se invoca a la función IOpenControlPanel::Open, la cual en primer lugar busca el elemento correspondiente del Panel de control al que se está haciendo referencia. Cabe destacar que el Panel de control es un directorio virtual (no reside físicamente en el disco, sino que está implementado por el shell), situado en la clave de Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace. El valor (Predeterminado) de cada una de las subclaves de esa rama de Registro contiene el nombre con el que se mostrará en Panel de control (no el nombre canónico). Para encontrar la implementación de, digamos, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\{0DF44EAA-FF21-4412-828E-260A8728E7F1} (ítem de las propiedades de la barra de tareas y menú Inicio), se accede a la clave de registro HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}, en la cual existe un valor de registro de nombre System.ApplicationName y cuyo contenido es el nombre canónico: Microsoft.TaskbarAndStartMenu. Así pues, para abrir las propiedades de la barra de tareas y del menú Inicio ya sabemos que bastaría con ejecutar lo siguiente:

%windir%\system32\control.exe /name Microsoft.TaskbarAndStartMenu

Para ver qué es lo que realmente se ejecuta, eche un vistazo a la clave HKEY_CLASSES_ROOT\CLSID\{0DF44EAA-FF21-4412-828E-260A8728E7F1}\Shell\Open\Command.

Cada ítem del Panel de control puede implementar varias páginas

Podemos entender las páginas como subsecciones específicas del ítem del Panel de control. Para indicar una, debe usarse la sintaxis

%windir%\system32\control.exe /name Nombre_canónico /page Página

Veámoslo con un ejemplo:

Con los conocimientos que hemos adquirido, nos resulta sencillo determinar que el ítem Personalizar del Panel de control está implementado en la DLL Themecpl.dll. Es en esta DLL donde encontraremos información acerca de las posibles páginas de este ítem, en la forma, como no, de fichero XML.

Esta vez usaremos la aplicación gráfica Resource Hacker, que puede descargar gratuitamente desde http://www.angusj.com/resourcehacker/. Al abrir el fichero Themecpl.dll en esta aplicación, nos encontramos con dos ficheros XML adicionales al típico fichero de manifiesto (.manifest) que habíamos visto hasta ahora.

Este primer fichero XML especifica una serie de tareas que puede realizar el elemento del Panel de control "Personalizar". Estas tareas (cambiar los colores, el fondo de pantalla, etc.) se muestran como enlaces de texto justo debajo del elemento del Panel de control (suponiendo que esté configurado en la vista por categorías). Y lo que es más importante, estas tareas son indizables por el sistema de búsqueda de Windows Vista. Puede obtener más información en este artículo de MSDN: http://msdn.microsoft.com/en-us/library/bb776840(VS.85).aspx.

Esta segunda imagen hace referencia al segundo fichero XML, que es el que contiene la información acerca de cada una de las páginas que implementa este ítem del Panel de control. Entre las etiquetas <pagedefinition></pagedefinition> nos encontramos con una etiqueta <properties>, que hace referencia a cada una de las páginas. El atributo canonicalName nos ofrece su nombre canónico.

Como vemos, el ítem "Personalizar" del Panel de control admite como sintaxis:

%windir%\system32\control.exe /name Microsoft.Personalization /page pageColorization (para cambiar la configuración de color)

%windir%\system32\control.exe /name Microsoft.Personalization /page pageWallpaper (para cambiar el fondo de escritorio)

Ejercicio

Ahora que ya sabe cómo escudriñar en los ítems del Panel de control con el fin de construir accesos directos lo más directos posibles (valga la redundancia), le propongo como ejercicio que en un sistema Windows 7 averigüe la sintaxis para un acceso directo al Monitor de confiabilidad, que como sabe en Windows 7 está algo escondido dentro del Centro de actividades (Action Center).

Si se rinde, puede ver la solución seleccionando texto a partir de aquí: control.exe /name Microsoft.ActionCenter /page pageReliabilityView

Descubrir valores de Registro no documentados usando Process Monitor

dmartin — Sun, 16 Aug 2009 23:01:00 GMT

A mucha gente le gusta personalizar su sistema de escritorio al máximo posible. Por ello, Microsoft acostumbra a incorporar en sus sistemas operativos bastantes menús y cuadros de diálogo capaces de personalizar muchos de los detalles de funcionamiento de Windows. Sin embargo, hay ciertos detalles que no son modificables desde la interfaz gráfica, solamente desde el Registro; siempre siguiendo los pasos de algún artículo de la documentación oficial de Microsoft (KB, MSDN LIbrary, Technet Library, etc.). También hay detalles que no están documentados pero que pueden "descubrirse" utilizando herramientas de monitoreo del Registro, como Process Monitor, tal y como se explica en este artículo.

En el caso que nos ocupa, el usuario quería modificar el tiempo de aparición de la vista en miniatura de una aplicación en la barra de tareas de Windows Vista. En Windows Vista, la funcionalidad Windows Aero permite ver, a golpe de ratón, el contenido de todas y cada una de las ventanas minimizadas en la barra de tareas. El usuario intentaba buscar una forma de acortar ese tiempo de aparición de la vista en miniatura, pues le parecía excesivo. En Internet la alternativa que es más popular es la de modificar el valor de Registro MouseHoverTime de la clave de Registro HKEY_CURRENT_USER\Control Panel\Mouse. Sin embargo, este valor influye en el tiempo que tarda en reconocerse un posicionamiento del cursor del ratón, en cualquier parte de la interfaz gráfica de Windows. Era necesario buscar algún valor de Registro más específico, y para ello iba a recurrir a Process Monitor.

Antes de nada hay que comentar que no tenía la garantía de que existiera un valor de Registro que controlara ese aspecto tan específico de la interfaz gráfica de Windows. De existir, suelen ser parámetros que solo se tienen en cuenta en las versiones de depuración (checked) del sistema operativo. De todas formas, abrí Process Monitor y establecí un filtro de aquellos eventos de Registro que contuvieran en su ruta la palabra "Thumbnail". Inicié Explorer.exe y rápidamente me encontré con tres eventos bastante interesantes:

El primer evento indica el momento en que Explorer.exe examina una directiva, TaskbarNoThumbnail, configurable desde Directiva de grupo, encargada de desactivar las vistas en miniatura de la barra de tareas. La lectura de este valor me hizo pensar que los dos valores siguientes podrían estar relacionados con lo que buscaba.

Esos dos eventos siguientes hacen referencia a una búsqueda de cierta rama en el Registro (ExplorerThumbnails), tanto en la rama HKEY_CURRENT_USER como en la rama HKEY_LOCAL_MACHINE. El primer evento hace referencia al SID de mi usuario dentro de la rama HKEY_USERS (HKU) simplemente porque ejecuté Process Monitor desde una cuenta limitada, proporcionando obviamente el nombre de usuario y contraseña del administrador.

¿Qué sería esa rama ExplorerThumbnails? La verdad es que no encontré nada documentado en Internet, pero su nombre era lo suficientemente atractivo como para seguir indagando. Una de las cosas que suelo hacer en casos como este es crear la clave que busca en este caso Explorer.exe y ver qué valores o subclaves de Registro busca a continuación. Eso hice: Abrí Editor del Registro y creé la clave de Registro ExplorerThumbnails. Volví a capturar una traza con Process Monitor y el resultado ofreció otros tres valores tan interesantes como desconocidos:

Los valores InitialThumbnail, InitialTooltip y AutoPopTooltip me hacían pensar que efectivamente estaban relacionados con lo que realmente buscaba: Modificar el tiempo de aparición de la vista en miniatura. En este caso podría haber experimentado introduciendo algunos valores aleatorios para esos valores de Registro y observar los resultados, aunque en este caso recurrí a una lectura del código fuente de Explorer.

Al parecer, el valor InitialThumbnail tiene que ver con el tiempo en milisegundos que tarda en aparecer la vista en miniatura desde que se sitúa el cursor del ratón en la aplicación minimizada en la barra de tareas; InitialTooltip influye en el tiempo de aparición del texto emergente que siempre aparece encima de la vista en miniatura, un tiempo después. Por último, AutoPopTooltip influye en el tiempo que tarda en desaparecer el texto emergente. Por defecto, si no se encuentran esos valores en el Registro, el sistema supone, respectivamente, 500, 1000 y 5000 milisegundos.

Para concluir, codifiqué una aplicación gráfica que facilitara la modificación de estos valores en el Registro: http://winvista.mvps.org/Ficheros/TweakThumbnails.zip

Ya conoce otro posible uso de Process Monitor: Intentar descubrir valores de Registro (o ficheros) no documentados pero que pueden permitirnos configurar aspectos más o menos interesantes del sistema operativo.

Nota: Como indico en el margen izquierdo de este blog, toda la información que no está documentada por Microsoft es muy susceptible de cambiar e incluso de desaparecer en versiones posteriores de Windows. Este es el caso particular de esta rama del Registro, pues no es tenida en cuenta en Windows 7. Adicionalmente, deberá tomar las medidas oportunas si aplica este tip en un entorno de producción, pues de seguro se trata de un parámetro que no está tan probado como el resto de personalizaciones conocidas en el sistema operativo.

¿/Savecred, /Savedcred, /Savedcreds...? Es lo mismo

dmartin — Thu, 02 Jul 2009 18:57:00 GMT

Como quizá sepa, el comando Runas.exe de Windows XP y Windows Server 2003 sirve para ejecutar procesos en el contexto de otra cuenta de usuario. Los usuarios domésticos normalmente lo usan para ejecutar un proceso como administrador desde una cuenta limitada. Echando un vistazo al listado de parámetros de Runas.exe nos encontramos con uno que suele llamar la atención de bastante gente. Sirve para almacenar temporalmente en el administrador de credenciales (Credential Manager) el usuario y contraseña que va a ejecutar el programa. El atractivo de este parámetro es que no tendremos que introducir el nombre de usuario y contraseña para ese programa durante la sesión en curso. Sin embargo, no hay unanimidad con respecto al nombre del parámetro (incluso la propia documentación del sistema operativo creo que presenta alguna inconsistencia al respecto): Unos lo llaman /savecred, otros /savedcred, otros /savedcreds... Incluso en algunos sitios se indica que tienen semántica diferente.

Nada más lejos de la realidad. Runas.exe solo entiende el parámetro /sa (que contiene el mínimo número de letras que diferencian /savecred de los parámetros /smartcard y /showtrustlevels); lo que venga después le es indiferente. Del mismo modo, en cuanto se encuentra con /p supone el parámetro /profile; si se encuentra con /e supone /env, y así sucesivamente.

Nota: Por limitaciones del administrador de credenciales de XP Home Edition, el parámetro /savecred no es tenido en cuenta en esta versión de Windows. Este artículo no es aplicable tampoco a Windows Vista, pues el comando Runas.exe en Windows Vista es bastante diferente del de XP y será tema de un próximo artículo.

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

dmartin — Thu, 06 Nov 2008 20:16:00 GMT

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.

Cerrar Explorer sin cerrar la sesión

dmartin — Mon, 11 Aug 2008 13:50:00 GMT

Completando la información del artículo anterior sobre Explorer, dejo por aquí un "truco" que quizá no conozca: En Windows Vista, al abrir el menú Inicio, pulsar simultáneamente las teclas Ctrl y Shift (Mayúsculas) y hacer clic con el botón derecho sobre una región libre del menú, nos aparecerá una opción adicional a la ya clásica "Propiedades": "Salir de Explorer". Esta opción es especialmente útil cuando haya realizado algún cambio en la configuración que requiera de un reinicio del explorador para que surta efecto. Hasta ahora quizá lo que haya hecho es "matar" al proceso Explorer.exe usando Process Explorer, con todos los riesgos que conlleva el "matar" a un proceso. La opción "Salir de Explorer" realiza los pasos correctos de cierre del explorador, que incluyen, entre otras cosas, el almacenar en el Registro del sistema ciertas configuraciones residentes en memoria. Al "matar" al proceso estas configuraciones se pierden irremediablemente.

Lamentablemente, esta opción no está presente en Windows XP y anteriores, por lo que tendrá que, como mínimo, reiniciar la sesión para lograr un efecto similar en esos sistemas.