Daniel Martín's blog

Una de las novedades de Windows 7 con respecto a sistemas anteriores es su nuevo centro de dispositivos e impresoras, donde podemos visualizar rápidamente un listado de los dispositivos que tenemos conectados a nuestra máquina, así como información de utilidad sobre ellos (fabricante, descripción, página de soporte, etc.). Además, algunos dispositivos pueden acompañarse de un icono fotorrealista que hace que los identifiquemos mucho más rápidamente. Esta información sobre los dispositivos la genera el fabricante y la pone a disposición de los usuarios a través de Windows Metadata and Internet Services (WMIS). Windows 7 incorpora un componente cliente que contacta con este servicio y descarga información actualizada sobre los dispositivos conectados sin que el usuario tenga que hacer nada.

A pesar de que esta información está pensada para que la proporcione el fabricante, puede que nos apetezca cambiar alguno de los iconos por otro de más calidad, o bien más apropiado para el dispositivo en cuestión. En este artículo explicaré cómo usar una herramienta de Microsoft, Device and Printers Metadata Authoring Wizard, que permite crear paquetes de "metadatos” sobre cualquier dispositivo conectado a la máquina. Estos paquetes incluyen información sobre el dispositivo (modelo, fabricante, descripción, etc.), así como un icono fotorrealista que se mostrará en el centro de dispositivos e impresoras. Es la aplicación que usan los fabricantes de dispositivos para crear y probar localmente los paquetes de información e iconos, antes de publicarlos en los servicios web de Microsoft.

Podemos descargar este asistente desde la siguiente dirección: http://download.microsoft.com/download/F/5/4/F54F4AF9-737A-4EE6-B3F8-BEF68990CB62/Devices-and-Printers-Metadata-Authoring-Wizard.msi Una vez instalada la aplicación, abrimos Inicio, Dispositivos e impresoras y seleccionamos con el botón derecho el dispositivo en cuestión. Veremos una nueva opción en el menú contextual, Create metadata package, tal y como se muestra en la siguiente captura:

Esta opción abre un asistente como el que se muestra en la siguiente imagen:

El asistente tiene diversas pestañas para poder rellenar, entre otras cosas, el icono del dispositivo, su descripción, el ID de hardware asociado, la categoría a la que pertenece o los idiomas en los que mostrar la información. En este artículo vamos a centrarnos en cambiar el icono sin entrar en detalle sobre el resto de información; sin embargo, recomiendo que experimente con el resto de campos por su cuenta.

En la pestaña Icon podemos agregar el icono fotorrealista que hayamos creado para nuestro dispositivo. Para crear un icono fotorrealista hay que seguir ciertas pautas para que sea considerado válido (a este tipo de iconos se les conoce como iconos “estilo Windows Aero”). Estas pautas se citan en el propio asistente (formato .ico, número de formatos de imagen requeridos), así como de manera ampliada en esta dirección web: http://msdn.microsoft.com/en-us/library/aa511280.aspx En la documentación de prácticamente cualquier herramienta de diseño gráfico hay información paso a paso sobre cómo crear iconos con estilo Windows Aero. Por ejemplo, si se usa Axialis IconWorkShop se puede usar esta documentación para crear el icono fácilmente a partir de una imagen: http://www.axialis.com/docs/iw/Introducing_Vista_Icons.htm

En la pestaña Associations debemos seleccionar aquellos ID de hardware que queremos asociar con el paquete de “metadatos”. Puede ver los ID de hardware en Administrador de disposivos, haciendo doble clic sobre el dispositivo, pestaña Detalles, propiedad Id. de hardware. Otra pestaña importante es la pestaña Options, donde tendremos que seleccionar el idioma que queremos asociar con este paquete. Podemos crear varios paquetes de información, cada uno asociado con un idioma, y el sistema operativo decidirá automáticamente cuál utilizar en cada caso.

Para concluir, en la pestaña Finish deberemos seleccionar la casilla correspondiente para almacenar el paquete en el almacén de Windows:

Al pulsar sobre Finish, si todo ha ido bien, aparecerá un cuadro de Control de cuentas de usuario pidiéndonos confirmación o privilegios administrativos y el icono del dispositivo cambiará inmediatamente. Además de en el almacén de “metadatos” sobre dispositivos (%ProgramData%\Microsoft\Windows\DeviceMetadata\Idioma), se guarda también una copia del fichero .devicemetadata-ms en la carpeta que hayamos seleccionado en la pestaña Finish (por defecto, la carpeta Documentos). Conviene tener una copia de seguridad por si en algún momento un nuevo controlador o el propio servicio web WMIS “machacan” esta información que hemos personalizado localmente.

Un usuario del foro preguntaba si es posible cambiar a la opción de abrir archivos o carpetas con un simple clic, que está situada en Explorador de Windows, menú Organizar, Opciones de carpeta y búsqueda, pestaña General. El objetivo principal era incluir este automatismo como parte del proceso de instalación de un programa.

Cuando se plantean este tipo de preguntas, siempre pienso inmediatamente en el usuario de esa aplicación y en cómo tras instalarla considero que ha perdido parte del control de su máquina. No es buena idea que un programa tome la decisión unilateral de modificar configuraciones personales del usuario. En primer lugar habría que volver a pensar en por qué esa aplicación requiere un cambio en una configuración personal para funcionar correctamente. Si el cambio fuese estrictamente necesario y justificado, lo ideal sería indicarle esto al usuario a través de un mensaje y seguidamente dirigirle al panel de Opciones de carpeta (control.exe folders) para sea él personalmente el que cambie la configuración requerida. De esta manera, el usuario es consciente del cambio que ha realizado en su configuración personal, si es que finalmente decide llevarla a cabo.

Microsoft es consciente de que muchas aplicaciones interfieren con la configuración personal del usuario y por ello, especialmente desde Windows 7, ha ido restringiendo ciertas partes del sistema para que no dispongan de acceso a través de la interfaz de programación de Windows. Para el caso que nos ocupa, aún disponemos del acceso a una API que nos sirve para lo que estamos busando: SHGetSetSettings. Como se indica en la página de documentación, si la llamamos con el segundo parámetro establecido en SSF_DOUBLECLICKINWEBVIEW podremos cambiar esta configuración del explorador.

El resultado final de la llamada anterior es la modificación del valor binario ShellState de la clave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer. A simple vista este valor de registro tiene un aspecto un tanto críptico, pero voy a detallar a continuación su estructura para verlo todo más claro.

¿Cómo interpretar el valor de registro ShellState?

El primer parámetro de la función SHGetSetSettings es una estructura de nombre SHELLSTATE, documentada en MSDN, y presente en el fichero de cabecera Shlobj.h. Esta estructura está formada por un conjunto de flags binarios, cada uno de los cuales controla un determinado aspecto de la configuración del explorador. SHELLSTATE es una estructura bastante antigua, ciertos campos ya no se aplican a versiones recientes de Windows, y además es una estructura propensa a cambios (cada versión de Windows suele introducir un par de nuevos flags y algunos de sus valores se han transladado a otros sitios del registro, más fácilmente controlables mediante directivas). Por esta razón, tanto el valor de registro como su API asociada podrían dejar de funcionar en un futuro sin previo aviso.

Para que esta información persista en el tiempo, la estructura SHELLSTATE junto con su tamaño se almacenan en el valor de registro ShellState antes mencionado. Si lo abrimos en Editor del Registro veremos que comienza por 24 00 00 00. Estos primeros 4 bytes (un entero sin signo) indican el tamaño total, es decir, 36 bytes (nótese que el editor nos está mostrando el dato en hexadecimal). Después del tamaño, le sigue la estructura SHELLSTATE en sí, escrita en bloques de 1 byte de derecha a izquierda. Como vemos en la documentación de MSDN, el flag que nos interesa modificar es fDoubleClickInWebView, el sexto bit. Si lo establecemos en cero, activaremos la opción de abrir ítems con un simple clic; si lo establecemos en 1, los abriremos con un doble clic (comportamiento por defecto).

Por tanto, para respetar el resto de bits de la estructura ShellState lo que podemos hacer es anotar el valor hexadecimal del quinto byte del valor de registro (recuerde que los bytes del primero al cuarto inclusive expresan el tamaño del valor de registro). Con dicho valor anotado, abrimos la calculadora de Windows y la configuramos en modo “Programador” y “hexadecimal”. Introducimos el valor que hemos anotado en el paso anterior y pulsamos “And”, “20”, “Not”, “=”. (20 es el valor hexadecimal correspondiente a poner un 1 binario en la sexta posición). Si en vez de poner el correspondiente bit a 1, queremos ponerlo a 0, la operación que hay que hacer es “Or”, “20”, “=”. Hay más información sobre cómo hacer operaciones a nivel de bit en Wikipedia, por ejemplo.

Para terminar, dejo una posible implementación en lenguaje Visual Basic Script:

Pese a que Microsoft dedica bastante tiempo a probar sus actualizaciones en un enorme número de configuraciones diferentes, es posible que nos encontremos con un sistema al que le hemos intentado instalar una actualización pero el proceso falla por algún motivo, entrando el sistema en un bucle sin fín y por lo tanto no se puede arrancar el equipo.

Para solucionar este tipo de problemas, debemos tener en cuenta que lo más complicado no es conseguir arrancar el equipo, sino dejarlo en un estado consistente. Básicamente esto quiere decir que la información que mantiene el sistema operativo sobre cada uno de sus componentes se corresponda con lo que existe en realidad, números de versión incluidos. Así pues, lo primero que recomiendo si nos encontramos con un problema de este tipo es intentar restaurar el sistema. Para ello, arrancamos con el DVD de Windows 7 en la unidad y seleccionamos la opción “Reparar el equipo”. Cuando se nos presente el cuadro de diálogo con las opciones de reparación, seleccionamos Restaurar sistema y seleccionamos un punto anterior a la instalación de la actualización problemática. Este procedimiento deja el sistema en un estado consistente.

¿Qué hacer si Restaurar sistema no consigue solucionar el problema o bien no hay un punto de restauración disponible (Windows crea un punto de restauración automático antes de cada instalación de actualización)?

En esta situación mi consejo es que, debido al diseño actual y la arquitectura de componentes de Windows, pese a que consigamos arrancar el sistema va a ser tarea casi imposible dejarlo en un estado consistente. Este hecho probablemente causará problemas similares con actualizaciones futuras. Por tanto, debemos centrarnos en conseguir arrancar el sistema y salvaguardar los datos de importancia antes de proceder a reinstalar el sistema operativo.

Para conseguir iniciar el sistema, podemos probar a arrancar nuevamente con el DVD de Windows 7, seleccionamos “Reparar el equipo” y abrimos una ventana de comandos. En ella, teclearemos el siguiente comando:

Dism.exe /Image:X:\ /Cleanup-Image /RevertPendingActions

(Donde “X” es la unidad del sistema que no puede arrancar).

Este comando lo que hace es revertir todas las acciones pendientes que se hayan generado durante la instalación de la actualización. Estas acciones pendientes se ejecutan tras el reinicio de la máquina y los eventos relacionados quedan registrados en los ficheros %windir%\winsxs\poqexec.log, %windir%\winsxs\pending.xml y %windir%\winsxs\pending.xml.bad. Para que un paquete de actualización se instale correctamente, deben ejecutarse y finalizar con éxito todas las acciones que tenga pendientes, por lo que si alguna falla podemos encontrarnos en una situación de bucle infinito. En actualizaciones grandes como puede ser un service pack, hay un periodo de la instalación durante el cual no puede producirse ningún fallo o corte de energía. Si ocurriera, casi con total probabilidad el sistema entrará en un bucle infinito tras el reinicio. En Windows 7 esta “ventana fatídica” de tiempo se ha reducido bastante, lo que unido a la estabilidad del servicio de componentes y del instalador de actualizaciones han conseguido reducir enormemente este tipo de problemas. Si nos enfrentamos a un equipo con estos síntomas deberíamos sospechar siempre de alguna inconsistencia de base en el servicio de componentes de Windows, corrupción en el disco o algún otro tipo de fallo de hardware.

Actualización (15/6/2011): Si se quiere evitar reinstalar el sistema una vez recuperado el arranque correcto de la máquina, el Windows Server Core Team de Microsoft nos presenta un método para devolver el sistema a un estado consistente de nuevo, usando la herramienta Dism.exe para instalar y posteriormente desinstalar el paquete fallido. Aquí puede encontrar más información (en inglés): http://blogs.technet.com/b/askcore/archive/2011/05/10/supported-workaround-for-torn-state-installations-on-windows-7-sp1.aspx

Al hacer clic con el botón derecho del ratón sobre cualquier ítem del shell (ya sea un fichero o no), el sistema nos muestra un menú contextual formado por una serie de acciones (verbos) entre las que se incluyen un cierto número de acciones por defecto (cortar, copiar, pegar, renombrar, propiedades, etc.), así como ciertas acciones añadidas por programas de terceros. Puesto que un requisito para lograr una buena usabilidad podría ser un menú contextual simple y organizado, un usuario preguntaba cómo se pueden ocultar selectivamente estas acciones de la interfaz de usuario, pero sin eliminarlas del sistema.

Hay unas cuantas formas para lograr esto, agregando algunos valores al registro de Windows:

Valor de registro “Extended”

Si se agrega al registro, justo en la sección donde se define el verbo, un valor de tipo cadena de nombre “Extended” y contenido vacío, el sistema entiende que se trata de una acción que o bien raramente se usa, o bien solo suelen usarla los usuarios avanzados. De tal forma que para mostrarla es necesario mantener pulsada la tecla Mayúsculas mientras se abre el menú contextual. Un ejemplo de esto es la acción “Abrir consola de comandos aquí” del menú contextual de Windows 7 (HKEY_CLASSES_ROOT\Directory\shell\cmd).

Valor de registro “ProgrammaticAccessOnly”

Este valor es nuevo en Windows Vista. Sirve para indicar que dicha acción no está pensada para que la ejecuten los usuarios a través de la interfaz gráfica. Solamente se puede invocar mediante programación. Un ejemplo de ello es el verbo “explorar” (explore), que está presente en el registro, por ejemplo en la clave HKEY_CLASSES_ROOT\Folder\shell\explore, pero que no aparece en el menú contextual.

Valor de registro “LegacyDisable”

Este valor indica que la acción está presente simplemente por motivos de compatibilidad con algún programa antiguo y no debería usarse de ahora en adelante.

Valor de registro “SuppressionPolicy”

Esta opción oculta el verbo si se ha aplicado al sistema una determinada directiva. Las directivas pueden ser de dos tipos: una restricción de licencia o una directiva de grupo de toda la vida. Podemos ver una ejemplo de esto en la clave de registro HKEY_CLASSES_ROOT\CLSID\{20D04FE0-3AEA-1069-A2D8-08002B30309D}\shell\Manage. Ahí encontramos un valor de nombre “SuppressionPolicy” con contenido a 0x4000003c. ¿Qué quiere decir esto? El valor SuppressionPolicy contiene un valor de 32 bits que representa la restricción que, de estar aplicada, queremos que oculte el verbo del menú contextual. Es un valor del tipo enumerado RESTRICTIONS que se le pasa como parámetro a la API SHRestricted. Para ver la correspondencia entre restricciones y códigos hexadecimales, podemos abrir el fichero del SDK de Windows ShlObj.h y posicionarnos en la definición del tipo enumerado RESTRICTIONS (typedef enum RESTRICTIONS). Esta es la línea para el ejemplo que estamos desarrollando:

REST_NOMANAGEMYCOMPUTERVERB     = 0x4000003C,   // No Manage verb on My Computer

A partir de Windows Vista, Microsoft está usando un modelo distinto de restricciones. La primera diferencia la encontramos en la clave de registro donde se activan dichas restricciones. Anteriormente se agregaban a la clave de registro Software\Policies\Microsoft\Windows (ya sea dentro de HKCU o HKLM), pero recientemente toda nueva restricción se agrega a la clave Software\Microsoft\Windows\CurrentVersion\Policies. La segunda diferencia reside en el formato de representación de la restricción: En lugar de usar un valor de 32 bits, se da preferencia a un nuevo formato basado en un GUID de 128 bits. Para agregar una restricción a un verbo usando este nuevo formato debemos crear un valor de nombre “SuppressionPolicyEx” (nótese el “Ex” final) cuyo contenido sea el GUID correspondiente a la restricción. Podemos ver un ejemplo en la clave de registro HKEY_CLASSES_ROOT\batfile\shell\runasuser. Lamentablemente, Microsoft no ha documentado esta información, lo que hace pensar que pueda ser algo transitorio y propenso a cambios. Para el lector interesado, en esta página se recoge información adicional: http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shlwapi/api/winpolicy/policies.htm

De manera análoga podemos restringir la aparición de una acción en el menú contextual en función de una consulta al servicio de licencias de Windows. En este caso el valor de registro se denominaría “SuppressionSlapiPolicy” y el contenido sería la licencia a consultar, correspondiéndose con el primer parámetro de la función SLGetWindowsInformationDWORD. Si la directiva de licencia que se consulta no está disponible, se ocultará la acción del menú contextual.

Valor de registro “HideInSafeMode”

Si la acción que hemos agregado solamente tiene sentido si el sistema ha arrancado en modo seguro, podemos añadir este valor de cadena (con contenido vacío) para que Windows solo lo muestre en ese escenario.

Estas son las posibles formas de ocultar un verbo del menú contextual de Windows. La extensión del menú contextual y las asociaciones de archivos es un tema bastante amplio, en algunas ocasiones complejo y que generan bastantes dudas no solo entre desarrolladores de aplicaciones, también entre usuarios finales. Un buen punto de partida para comprender mejor el menú contextual es la documentación oficial de MSDN: http://msdn.microsoft.com/en-us/library/cc144169(v=vs.85).aspx

Es posible que en alguna ocasión le aparezca un mensaje de error bastante curioso que, sin motivo aparente, le advierte de que no hay disco en la unidad. Suele aparecer al trabajar con alguna aplicación, o bien al iniciar el sistema, y tiene un aspecto similar a la siguiente imagen:

¿Por qué ocurre este mensaje de error?

La representación de un proceso en Windows es una estructura de datos que internamente se denomina EPROCESS (que viene de executive process) y que reside en espacio de memoria de núcleo. Este bloque contiene numerosos campos y apuntadores a estructuras de datos auxiliares (entre otras, el PEB o bloque de entorno de proceso). Es uno de estos campos el que le dice a Windows si el proceso es quien va a manejar los errores graves de sistema, tales como errores de E/S, fallos de alineamiento, etc. y cómo va a hacerlo. Vemos esto de forma práctica usando Windbg como depurador, habiendo iniciado una sesión de depuración de núcleo y escribiendo este comando:

El campo “DefaultHardErrorProcessing” está marcado en negrita porque es el que nos interesa para este artículo. Cuando Windows crea un proceso, como podrá intuir, una de las fases de inicialización implica rellenar la estructura EPROCESS. Una vez que se rellena la estructura EPROCESS esta se inserta en la lista de procesos activos y en el espacio de nombres del administrador de objetos de Windows (Object Manager), el cual devuelve un handle único que permite que el proceso sea accesible tanto para el sistema como para el resto de aplicaciones. El valor inicial del campo “DefaultHardErrorProcessing” generalmente se hereda del proceso padre, y por defecto hace que el sistema muestre todos los errores graves de sistema que ocurran. La ventana de error aparece cuando ocurre un error grave y el proceso o hilo en cuestión no lo ha gestionado.

¿Cómo cambiar el contenido del atributo de proceso DefaultHardErrorProcessing para que en vez de mostrar una ventana de error se le envíe el error al proceso para que lo trate?

Se puede usar la API pública SetErrorMode, que admite diferentes parámetros según el tipo de error grave que queramos delegar al proceso en cuestión. De esta manera evitaremos que aparezcan crípticas ventanas de error (como la que aparece al comienzo del artículo), y que nuestra aplicación quede a la espera de que interactuemos con dicha ventana para proseguir con su funcionamiento. En Windows Vista se añadió al bloque de entorno de hilo (TEB) un nuevo campo de control de errores graves, como puede comprobar si ejecuta el comando !teb en una sesión de depuración de núcleo en Windbg (en Windows Vista o Windows 7):

Si bien este campo está presente desde Windows Vista, no fue hasta la llegada de Windows 7 cuando se creó una API pública para que los desarrolladores pudieran modificarlo en sus programas: SetThreadErrorMode. Esta API surgió de la necesidad por parte de las aplicaciones multi-hilo de cambiar este valor sin afectar al valor por proceso (que automáticamente es heredado por cada nuevo hilo).

Así pues, es recomendable que las aplicaciones hagan uso de la siguiente llamada a función para evitar que la experiencia de usuario sea poco agradable en caso de que ocurran errores graves:

o bien, en Windows 7:

Esta es la causa por la cual aparecen mensajes del tipo “No hay disco en la unidad” en los momentos más inoportunos. Por suerte Windows ofrece a los desarrolladores la posibilidad de manejar apropiadamente estas circunstancias excepcionales para así proporcionar una experiencia de usuario más agradable. Espero que este artículo haga más visibles estas posibilidades y todos disfrutemos de un mejor ecosistema.

Una pregunta que se hacen muchos usuarios de Windows es qué cuentas de usuario se muestran en la pantalla de bienvenida, puesto que no hay una relación de uno a uno entre las cuentas existentes en el sistema y las cuentas que aparecen al iniciar el equipo. Este artículo intentará aclarar esta duda.

Winlogon.exe, el proceso encargado del inicio de sesión en Windows, es quien realiza la enumeración y filtrado de las cuentas de usuario para mostrarlas en la pantalla de bienvenida ejecutando para ello, en Windows Vista y 7, un proceso auxiliar, LogonUI.exe. El hecho de separar esta tarea en dos procesos sirve para garantizar la estabilidad del sistema en caso de que código de autenticación de terceros (por ejemplo, el software de un lector de huellas) hiciera fallar a Winlogon.exe, un proceso que es crítico para el buen funcionamiento del sistema operativo. Al mostrar cuentas en la pantalla de bienvenida se examina antes una lista de cuentas “especiales” que, o bien siempre deben incluirse, o bien siempre deben ocultarse de dicha pantalla. La lista de cuentas “especiales” reside en el registro, concretamente en la clave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList. Allí, un valor de registro de tipo DWORD y con nombre igual al nombre de la cuenta de usuario “especial” decide si la cuenta siempre se incluye en la pantalla de bienvenida (contenido a 1), o bien siempre queda oculta (contenido a 0). Esta lista de cuentas especiales se almacena en una caché en memoria, así que si modificamos el registro es conveniente que reiniciemos el equipo para que los cambios surtan efecto.

Además del listado de cuentas “especiales” que el usuario puede editar desde el registro, Windows automáticamente excluye ciertas cuentas de usuario que no interesa que aparezcan en la pantalla de bienvenida, puesto que causarían bastante confusión al usuario. Se trata de cuentas de usuario que instalan entre otros Microsoft IIS (Internet Information Server) o Visual Studio y que no están pensadas para que el usuario inicie sesión con ellas. Concretamente, nunca aparecerán en la pantalla de bienvenida aquellas cuentas de usuario que empiecen con los prefijos “IWAM_”, “IUSR_”, “VUSR_”, entre otros posibles. Otro tipo de cuentas que obviamente siempre se ocultan son aquellas que están deshabilitadas o bloqueadas. Es importante comentar que en la pantalla de bienvenida solo aparecen las cuentas que pertenezcan a los grupos de usuarios creados durante la instalación de Windows, a saber, “administradores”, “usuarios avanzados”, “usuarios” e “invitados”. Por este motivo, por ejemplo la cuenta de usuario que crea VMWare Workstation dentro del grupo “__vmware__” no se muestra en la pantalla de bienvenida.

Pasamos a analizar en detalle lo que ocurre en la pantalla de bienvenida con un cuenta de usuario que, por recibir un tratamiento especial por parte del sistema, merece un apartado para ella sola: la cuenta “Administrador”.

La cuenta “Administrador"

Esta cuenta es especial en el sentido de que es la primera cuenta que se crea al instalar Windows. Es similar a la cuenta root de GNU/Linux y, como esta, solo debería usarse en casos de emergencia. Microsoft hace patente esto al deshabilitarla por defecto y no asignarle una contraseña. Lo que diferencia a esta cuenta del resto de cuentas con privilegios administrativos es que la cuenta “Administrador” tiene por defecto desactivado Control de cuentas de usuario, lo que quiere decir que si iniciamos sesión con ella gozaremos de verdaderos privilegios administrativos todo el rato. Ahí reside el principal peligro de esta cuenta y por lo cual yo siempre desaconsejo su manipulación, salvo en casos justificados.

El comportamiento de esta cuenta en la pantalla de bienvenida depende del sistema operativo en el que estemos trabajando. En Windows XP, la cuenta “Administrador” no aparece en la pantalla de bienvenida si ya se ha creado con anterioridad otra cuenta con privilegios administrativos. En Windows Vista y Windows 7, a diferencia de sistemas anteriores, la cuenta “Administrador” no se oculta nunca de la pantalla de bienvenida, siempre y cuando esté activada.

¿Qué ocurre con la cuenta “Administrador” en modo seguro?

En Windows XP al iniciar el equipo en modo seguro podremos tener acceso a la cuenta “Administrador”, de hecho tendremos acceso a todas las cuentas del equipo que pertenezcan al grupo de administradores (el resto de cuentas no serán mostradas).

En Windows Vista y Windows 7 el estado habilitado o deshabilitado de la cuenta “Administrador” (y por consiguiente, la capacidad para iniciar sesión con ella o no) puede variar en modo seguro. Esto se debe a que aunque Microsoft no quiere que los usuarios inicien sesión con el usuario “Administrador” sí quiere proporcionar un método de inicio de sesión “de emergencia” para cuando se han deshabilitado o borrado todas las cuentas administrativas del equipo. El hecho de que en modo seguro la cuenta “Administrador” se considere habilitada o deshabilitada depende de si el sistema operativo es cliente o servidor y de si está unido a un dominio. Resumo las posibilidades en esta tabla:

¿Cuándo está habilitada o deshabilitada la cuenta “Administrador” en modo seguro? (Windows Vista/7)

*: El caso de emergencia ocurre cuando no hay ninguna cuenta administrativa habilitada para el inicio de sesión.

En este artículo he descrito a grandes rasgos las cuentas de usuario que aparecen en la pantalla de bienvenida de Windows, aspecto que depende entre otras cosas del sistema operativo, del tipo de cuenta y de si se ha iniciado en modo seguro o no. Si desea ocultar cuentas de la pantalla de bienvenida puede usar mi herramienta HideUserAccounts7, que lo que hace es incluirlas dentro del grupo de cuentas “especiales”, ya comentado al principio, marcándolas como siempre ocultas. Debe tener especial cuidado a la hora de ocultarlas puesto que accidentalmente podría impedirse completamente el inicio de sesión en la máquina.

En mis foros estoy sorteando dos licencias de Diskeeper (http://www.diskeeper.com/), un partner de Microsoft dedicado a la desfragmentación de discos, y cuyos productos ofrecen un valor añadido al software de desfragmentación incluido en Windows. Aquí puede ver las características de este software: http://www.diskeeper.com/business/diskeeper/

Si le interesa, para participar solamente hay que publicar en el foro General de Wintecnico.com un pequeño artículo, truco o tip sobre Windows, cuanto más original mejor. Aquí hay más información sobre el concurso: http://www.wintecnico.com/foros/default.aspx?g=posts&t=77  Los ganadores los publicaré en dicho foro y serán contactados por correo electrónico.

¡Suerte!

Una forma sencilla de eliminar temporales en Internet Explorer consiste en abrir el menú Herramientas, Opciones de Internet y hacer clic sobre el botón Eliminar del apartado Historial de exploración. Sin embargo, a casi todo el mundo nos gusta automatizar ciertas tareas, y algo como eliminar la cache de navegación se realiza asiduamente así que bastante beneficio podríamos obtener si logramos automatizarla en la forma de un script o algo similar.

En Internet circulan scripts que eliminan temporales de Internet similares al siguiente:

Pese a que el script funciona correctamente, hay que tener en cuenta que en Windows Vista y Windows 7 está accediendo y borrando ficheros que tienen un nivel de integridad bajo (los temporales creados por IE con modo protegido activado) desde un proceso con un nivel de integridad medio (por defecto en Windows 7 y Windows Vista).

Una posible mejora consiste en crear un nuevo proceso que tenga un nivel de integridad bajo y ejecutar el comando RunDll32 InetCpl.cpl,ClearMyTracksByProcess en él. Para ejemplizar mi solución, he creado una pequeña utilidad que hace esto mismo. La puede descargar desde aquí. La herramienta admite una serie de parámetros de configuración para eliminar todo, solo temporales (-t), solo historial (-h), solo cookies (-c), o sin mostrar interfaz de usuario (-q). Básicamente el algoritmo que he seguido es: Duplicar el manejador del proceso que ejecuta la aplicación, usar la API SetTokenInformation para rebajar el nivel de integridad a “bajo” y finalmente usar CreateProcessAsUser para crear un nuevo proceso con este nuevo token de seguridad. Este proceso ejecuta el comando RunDll32 InetCpl.cpl,ClearMyTracksByProcess normalmente.

Como se hace uso de una función implementada en el sistema operativo, personalmente prefiero esta solución a eliminar manualmente los directorios de temporales. Eliminar temporales no es solamente limpiar una carpeta y es bueno que el equipo de producto de Microsoft nos abstraiga de esta tarea mediante una función. A pesar de todo, no podemos contar con que esta función siga en versiones sucesivas de Internet Explorer.

Para concluir, comprobamos en Process Explorer cómo mi herramienta ha creado dos procesos que ejecutan el comando de limpieza, uno con nivel de integridad bajo y otro con nivel de integridad medio, cada una ocupándose de su correspondiente caché:

¿Cuáles son los posibles flags de la función ClearMyTracksByProcess?

Ya tenemos una solución, ahora bien, es posible que necesitemos hacer uso de la función ClearMyTracksByProcess en algún otro momento, así que vendría bien tener a modo de referencia los posibles flags que se le pueden pasar. Según mis pruebas, esta es una lista más o menos detallada:

• Historial: 1
• Cookies: 2
• Temporales de Internet: 4
• Temporales incluyendo favoritos offline: 8
• Formularios: 16
• Contraseñas: 32
• Filtro de phising: 64
• Ejecutar sin ventana de progreso: 256

Los valores se pueden combinar mediante una simple OR. En una próxima actualización de mi herramienta iré incluyendo mejoras en la granularidad de limpieza.

Una vez instalado Windows 7 Service Pack 1 (en el momento de confeccionar este artículo, aún en versión RC), es posible que queramos ahorrar cierto espacio en disco quitando aquellas versiones antiguas de los componentes que hayan sido reemplazados por el service pack. Esto evita que se pueda desinstalar en un futuro, pero si tras un periodo de prueba todo funciona correctamente, raramente es necesario desinstalar un service pack. El hecho de impedir la desinstalación del service pack tiene todo el sentido del mundo cuando hemos procedido a integrarlo en una imagen original de Windows 7/Windows Server 2008 R2, tal y como explico en este artículo.

Hay tres formas de eliminar la información de desinstalación del SP1 de Windows 7:

Usando Liberador de espacio en disco

Al abrir la herramienta Liberador de espacio en disco (Cleanmgr.exe), si se selecciona la opción de Limpiar archivos de sistema (o lo que es lo mismo, ejecutándola con privilegios administrativos), nos dará la opción de eliminar los archivos de desinstalación del service pack, tal y como se ve en la captura siguiente:

Esta es quizá la opción más simple para la mayoría de usuarios.

Desde la línea de comandos, con el sistema arrancado

Si ejecutamos una ventana de línea de comandos (Cmd.exe) con privilegios administrativos y tecleamos lo siguiente podremos eliminar los archivos de desinstalación:

dism /online /Cleanup-Image /spsuperseded

Desde la línea de comandos, con el sistema no arrancado

Si el sistema no está arrancado, o bien si estamos integrando el service pack, podemos usar este comando desde otro sistema operativo que tengamos instalado en la misma máquina:

dism /Image:D: /Cleanup-Image /spsuperseded

(Donde D: es la unidad donde está instalado el sistema operativo con SP1).

Es indiferente la opción que usemos, el resultado es el mismo. Las dos últimas opciones tienen la ventaja de la automatización que se puede lograr usando baterías de comandos o similares.

En Internet es común encontrarnos con ficheros .reg que contienen datos que se pueden importar en el registro del sistema operativo. Si nos fijamos en la cabecera de estos ficheros .reg, nos podemos encontrar con dos tipos diferentes:

Existe un tercer tipo que quizá no haya visto nunca, REGEDIT, que se corresponde con ficheros de registro para Windows 3.1, sistema operativo en el que apareció la primera versión de lo que conocemos como registro. Que recuerde, en esa primera versión solamente existía la raíz HKEY_CLASSES_ROOT.

¿Cuál es la diferencia entre ambas cabeceras? La respuesta a esta pregunta da pie a un breve artículo sobre la historia de Windows, particularmente de Editor del Registro.

En los inicios de Windows, Editor del Registro no soportaba todos los tipos de valores que soporta hoy en día. Entre otros, no entendía de forma nativa valores de tipo cadena expandible (REG_EXPAND_SZ). Por este motivo, estos valores debían ser exportados a un fichero de texto de forma “cruda”, es decir, como una cadena ANSI de valores hexadecimales, terminada por un carácter nulo. He aquí un ejemplo. Al exportar una clave de registro que contiene un valor de tipo cadena expandible queda algo como esto:

Cuando nació Windows 2000, la compatibilidad con Unicode hizo que Editor del Registro exportara ficheros de registro de una forma un tanto diferente. Ahora los valores de cadena expandible no eran exportados como flujos hexadecimales en formato ANSI, sino Unicode, y la misma clave de registro quedaría exportada de la siguiente forma:

El caos que se formó fue importante, porque de pronto Editor del Registro podría dejar de importar correctamente millones de archivos de registro.

El primer intento de solución por parte de Microsoft fue el de crear una nueva cabecera para los archivos de registro, la versión 5, REGEDIT5. El problema que tiene esta cabecera es que tampoco era interpretada correctamente porque el parser de Editor del Registro no tenía en cuenta correctamente el número de versión. Si lo que viene después de “REGEDIT” es un número 4, entonces interpreta que se trata de un archivo de registro de tipo Windows 9x. Si no, interpreta que se trata de un fichero de registro de tipo Windows 3.1. ¡Desde Microsoft no pensaban que Editor del Registro fuese a necesitar una nueva versión!

Así pues, la única solución posible fue reescribir completamente la cabecera, y aprovechando la experiencia adquirida, hacerla más robusta ante futuras versiones de Editor del Registro. La nueva cabecera resultante quedó como “Windows Registry Editor Version 5.00” y ahora el parser sí interpreta correctamente que se trata de la versión 5.00. Si en un futuro Microsoft desarrollara una versión posterior, los editores antiguos descartarán adecuadamente el fichero en vez de importarlo. Las versiones recientes de Editor del Registro pueden importar archivos de registro de tipo Windows 9x y Windows 3.1. También ofrecen la posibilidad de exportar archivos de registro en formato de cadena ANSI para garantizar su compatibilidad con sistemas Windows 9x. Para ello basta con seleccionar la correspondiente opción Archivos de Registro de Win9x/NT4 (REGEDIT4) en la lista desplegable Tipo del cuadro de diálogo Exportar.

Ante la inminente llegada del primer service pack para Windows 7/Server 2008 R2, mucha gente aprovecha estos momentos para preparar sus sistemas para acoger la actualización. Si se requiere instalar una nueva copia del sistema operativo, es un buen momento para hacerlo usando una imagen que ya lo tenga integrado, para ahorrarnos el tiempo de acudir posteriormente a Windows Update y descargar la actualización.

La integración de service packs en Windows Vista y Windows 7 no es tan sencilla como lo era en Windows XP, por ejemplo. En los primeros no está soportada la integración de service packs en una imagen offline (es decir, no arrancada), por lo que tendremos que instalar el service pack en un sistema arrancado y “generalizarlo” (es decir, quitar todo aquello que lo hace dependiente de la máquina, tales como controladores instalados y demás). En este artículo voy a describir un posible método de integración sobre una edición de Windows 7. Vamos a necesitar lo siguiente:

• Un DVD o imagen ISO con Windows 7/Server 2008 R2
• Windows AIK para Windows 7, que se puede descargar gratuitamente desde http://www.microsoft.com/downloads/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=es.
• Guardar una copia de Service Pack 1 para Windows 7/Server 2008 R2 en un DVD o en un dispositivo de almacenamiento USB.
• Una máquina de laboratorio que disponga de al menos dos particiones (cada una de unos 20 GB de tamaño pues van a albergar un sistema operativo cada una y además la instalación de SP1 requiere de aproximadamente 5 GB libres.

Comenzamos la integración

El primer paso consiste en instalar en el sistema principal la aplicación Windows AIK, que contiene herramientas especializadas que nos servirán para manipular la imagen integrada del sistema operativo.

Una vez instalada esta aplicación, copie el contenido del DVD o ISO de Windows 7/Server 2008 R2 en una carpeta de este sistema principal, por ejemplo C:\DVD.

En la segunda partición que tiene libre, instale del modo habitual una edición de Windows 7/Server 2008 R2. Este será el sistema que actúe como base para la integración del service pack, así que le recomiendo que instale la edición que use más a menudo.

Cuando finalice la instalación, le aparecerá un asistente para crear usuarios, configurar la zona horaria, etc. Este asistente recibe el nombre de OOBE (Out Of the Box Experience). En esta imagen puede ver qué aspecto tiene:

En este momento, sin rellenar nada, pulse la combinación de teclas Ctrl+Mayúsculas+F3. El sistema se reiniciará en modo auditoría. El modo auditoría lo suelen usar los OEM para personalizar las imágenes de Windows 7 e instalar todos los programas de serie que suelen incluir (antivirus, Office, etc.). Puede informarse más sobre el modo auditoría en este artículo: http://technet.microsoft.com/en-us/library/dd744337(WS.10).aspx

Una vez se haya reiniciado el sistema en modo auditoría, introduzca el DVD o dispositivo de almacenamiento USB que contiene Service Pack 1 y proceda a instalarlo. Es recomendable que seleccione la casilla para reiniciar el sistema automáticamente cuando finalice la instalación. Dicho proceso de instalación puede llevar bastante tiempo, dependiendo de la configuración hardware de la máquina.

Una vez se haya instalado el service pack, el sistema se reiniciará automáticamente. Cuando arranque de nuevo el sistema, en la ventana de título Herramienta de preparación del sistema (SysPrep), seleccione la opción Iniciar la configuración rápida (OOBE) del sistema, marque la casilla Generalizar, y seleccione la opción Reiniciar.

Inicie ahora el sistema operativo principal, donde ha instalado Windows AIK.

Abra Inicio, Todos los programas, seleccione Microsoft Windows AIK, seleccione con el botón derecho Línea de comandos de las herramientas de implementación y pulse sobre Ejecutar como administrador.

Teclee este comando y pulse INTRO:

dism /Image:D: /Cleanup-Image /spsuperseded

(donde D: es la unidad que contiene al sistema operativo que tiene SP1 instalado)

Este comando eliminará archivos antiguos que quedan tras la instalación del service pack, evitando también que el usuario pueda desinstalarlo (lo cual carece de sentido en una instalación integrada).

A continuación vamos a crear una imagen WIM a partir del sistema operativo generalizado. Teclee este comando:

imagex /capture D: C:\Install.wim “Windows 7 Ultimate” “Windows 7 Ultimate SP1 (x86)” /compress maximum /flags “Ultimate”

El proceso puede tardar más de media hora, dependiendo del hardware del equipo.

Cuando finalice, tendrá una imagen de instalación (Install.wim) que contiene la edición de Windows 7 que haya elegido, así como SP1 integrado.

Ya solo falta sustituir el fichero C:\DVD\sources\install.wim por el nuevo fichero C:\install.wim que se acaba de crear y generar una ISO de Windows 7, mediante la herramienta Oscdimg.exe:

oscdimg –bC:\DVD\boot\etfsboot.com –u2 –h –m –lWindows7_SP1_x86_ES C:\DVD C:\Windows7_SP1_x86_ES.iso

Recuerde que si la imagen tiene un tamaño superior a 4,5 GB, debe crear un fichero Bootorder.txt para que los ficheros de arranque se sitúen correctamente, tal y como describo en los pasos finales de este otro artículo.

Probamos nuestro DVD integrado

Procedemos a instalar nuestro DVD con Windows 7/Server 2008 R2 SP1 y al finalizar la instalación abrimos Inicio, hacemos clic con el botón derecho sobre Equipo, Propiedades, y observamos que todo ha ido bien:

Nota: La imagen representa los números de versión de la versión RC del SP1, no de la versión final.

Hay otras formas de integrar Windows 7 SP1 en un único DVD, usando otras herramientas de instalación desatendida de Microsoft. También existe la posibilidad de integrar varias ediciones, arquitecturas e idiomas, usando los conceptos que explico en mi otro artículo sobre integración de Windows 7. Tenga en cuenta que siempre se deben instalar las actualizaciones después de los paquetes de idiomas. De lo contrario la instalación del paquete de idiomas “macharía” los archivos dependientes del idioma que pudiera contener la actualización, y por lo tanto tendría que reinstalarla.

Esto lo dejo como ejercicio al lector interesado, con posibilidad de discutirlo en la sección de comentarios de este artículo o bien en mis foros: http://www.wintecnico.com/foros

Otro año que llega, y, aunque parece que fue ayer cuando comenzó este blog, ya han pasado dos años y medio desde su nacimiento. En él he intentado ofrecer información interesante y útil sobre Windows y a la vez derribar algunos “mitos” o “inexactitudes” que han acompañado a este sistema operativo. Siempre lo he pretendido hacer desde una perspectiva neutral y nunca desde una perspectiva “fanboy”, ya que pienso que Windows no es la solución universal para cualquier necesidad. El futuro cercano va a deparar muchas novedades en lo que a los sistemas operativos respecta y Microsoft no debería dormirse en los laureles si quiere que Windows siga siendo un sistema operativo competitivo. Estoy seguro de que las mentes brillantes de Microsoft tendrán la capacidad de innovación y la creatividad necesarias para que así sea.

Además, 2010 fue el año de nacimiento oficial de www.wintecnico.com, un portal que pretende recoger soluciones a problemas con Windows (especialmente con Windows 7). La comunidad de www.wintecnico.com/foros cada vez es mayor (ya hay 42 miembros registrados), y en ella se han analizado y discutido problemas muy interesantes con Windows.

En 2010 habrá novedades, seguro, y espero que sean novedades útiles tanto para las personas que quieren ver a Windows desde una perspectiva diferente, como para aquellas que simplemente quieren una solución para su problema y que tras perder horas buscando en Internet no han conseguido solucionar.

¡Feliz año!

Windows 7 es el primer sistema operativo de Microsoft que permite a los OEM establecer una imagen cualquiera como fondo de la pantalla de bienvenida. Sin embargo, como la pantalla de bienvenida de Windows 7 solo soporta imágenes de ciertas resoluciones, es posible que estas tengan que ser escaladas para que ocupen toda la pantalla, con el consiguiente efecto estético negativo y, por qué no, con la consiguiente degradación en el tiempo de arranque del sistema. Este artículo dará las pautas para lograr la imagen de fondo perfecta.

¿Qué resoluciones soporta Windows 7 para la imagen de fondo de la pantalla de bienvenida?

Windows 7 soporta las siguientes resoluciones:

• 1280x1024
• 1024x768
• 1280x960
• 1600x1200
• 1440x900
• 1920x1200
• 1280x768
• 1360x768

Además también se soportan las resoluciones análogas en estilo de orientación vertical, donde se intercambian ancho y alto, es decir: 1024x1280, 768x1024, etc.

La clave es la relación de aspecto de la pantalla

Lo principal a la hora de elegir una resolución para la imagen de fondo de la pantalla de bienvenida es la relación de aspecto que tenga, entendiendo esta como el cociente entre ancho y alto (en píxeles). Aunque existen multitud de posibles resoluciones de pantalla, si contamos las más frecuentes y calculamos sus relaciones de aspecto, nos quedaremos con muchas menos. En el caso de las resoluciones de pantalla soportadas por Windows 7 para la imagen de fondo de la pantalla de bienvenida (que son las más frecuentes entre los usuarios), estas quedan agrupadas en 5 clases:

A la hora de seleccionar una imagen para la pantalla de bienvenida, Windows buscará aquella cuya relación de aspecto coincida exacta o aproximadamente con alguna de las categorías anteriores. Una vez encontrada, el sistema busca entre las resoluciones de pantalla alguna que coincida exactamente con la resolución de pantalla del usuario. Esto se hace con el objetivo de evitar escalar la imagen, puesto que se trata de un procedimiento complejo computacionalmente. En caso de que no haya ninguna coincidencia, el sistema elegirá cualquiera de las resoluciones posibles (para la relación de aspecto hallada) y escalará la imagen convenientemente.

Como conclusión, si su resolución de pantalla coincide exactamente con alguna de las soportadas por Windows 7, lo ideal es que cree una imagen con esa misma resolución. De no ser así, calcule la relación de aspecto de su pantalla (ancho / alto, si se trata de una orientación horizontal) y examine en la tabla anterior las resoluciones soportadas. En caso de que solo haya una alternativa, cree una imagen con esa misma resolución; en caso de que haya varias, pruebe con imágenes de esas resoluciones y elija la que mejor resultados le ofrezca.

Por supuesto, si le gusta exprimir hasta la última gota el rendimiento de su sistema, puede cambiar la resolución de trabajo de la pantalla para que coincida con alguna de las soportadas, y evitar así que se tenga que escalar la imagen.

Un usuario preguntaba qué representan exactamente los rangos de fecha de modificación que aparecen en el cuadro de búsqueda de Windows 7 (hace mucho tiempo, al principio de este mes, etc.). A modo de referencia, esta es la explicación de los correspondientes rangos:

• Hace mucho tiempo: En algún año anterior al actual.
• Al principio de este año: Desde que comenzó el año actual hasta el final del mes pasado.
• Al principio de este mes: Desde que comenzó el mes hasta la semana antepasada.
• La semana pasada: No requiere explicación.
• Al principio de esta semana: Desde que comenzó la semana hasta anteayer.
• Ayer: No requiere explicación.

Espero que esto aclare un poco más las búsquedas por fecha de modificación en Windows 7, para que se sepa exactamente qué se puede esperar encontrar y qué no.

Con este artículo inicio una temática que apenas había tratado hasta ahora en el blog y es la de programación para Windows y los fallos más comunes e interesantes que he ido viendo en Internet. Hoy vamos a ver un error no poco frecuente entre la gente que empieza a adentrarse en la programación para Windows.

El caso de hoy es el de un usuario que quería cambiar el fondo de escritorio de su máquina de manera inmediata mediante un programa que hiciera uso de la API de programación de Windows. La función que nos proporciona la API para cambiar el fondo de escritorio es SystemParametersInfo, con el primer parámetro establecido a la constante SPI_SETDESKWALLPAPER. El programa que había escrito el usuario era, de manera simplificada, el siguiente:

Si examinamos la documentación de la función SystemParametersInfo, el programa tiene buen aspecto: El primer parámetro, SPI_SETDESKWALLPAPER, le indica al sistema que lo que se va a cambiar es el fondo de escritorio; el segundo parámetro está establecido en 0, ya que no es aplicable cuando el primer parámetro está establecido en SPI_SETDESKWALLPAPER; el tercer parámetro es la cadena correspondiente al fondo de escritorio; y el último parámetro le indica al Windows que debe notificar del cambio de fondo a todas las ventanas de primer nivel del sistema, de forma que el cambio se vea inmediatamente.

Sorprendentemente para el usuario, el código no funciona, aunque en otros sistemas antiguos lo había hecho perfectamente. ¿Cuál sería el problema?

Vamos a fijarnos bien en la variable local “wallString”. Está declarada como un vector de tipo “char”. En C/C++, el tipo de datos “char” representa por defecto a un entero con signo entre –128 y 127 y, por lo tanto, ocupa un byte. La documentación de la función SystemParametersInfo dice que el tercer parámetro debe recibir una variable de tipo PVOID, que es un “alias” de un puntero a una dirección de memoria que contenga cualquier tipo de datos, es decir, lo que en C++ se expresa como void*.

Aunque SystemParametersInfo venga documentada como función en MSDN, en realidad es una macro de C que “delega” el trabajo a la verdadera función, dependiendo de si el programa está compilado como Unicode (SystemParametersInfoW) o no (SystemParametersInfoA). Así que hoy en día es más que probable que internamente el programa esté llamando a SystemParametersInfoW. La clave está en la interpretación de la cadena de caracteres que se pasa como tercer parámetro. El usuario estaba pasando una cadena ANSI (1 byte por caracter), mientras que el sistema la estaba interpretando como Unicode (2 bytes por caracter). Este es un esquema gráfico de lo que ocurre por lo bajo:

Los números hexadecimales representan cada carácter (un dígito hexadecimal es medio byte). Al interpretar la cadena con caracteres anchos (de 2 bytes) como unidad básica, se traduce en una ristra de caracteres “extraños” y por consiguiente el fondo de escritorio no se cambia correctamente.

Lo ideal hoy en día es usar Unicode en todo lugar. Si se usa el formato de carácter de Windows TCHAR, éste se convertirá en un carácter normal (char) en sistemas antiguos que no soportan Unicode y en un carácter ancho (wchar) en sistemas Unicode. La “T” que precede a “CHAR en “TCHAR” indica que se trata de un tipo de datos general que se convertirá apropiadamente en la versión ANSI o Unicode dependiendo de los parámetros de compilación. Si necesitamos un puntero en lugar de un único carácter, podemos usar el tipo LPTSTR (Long Pointer to String). Este sería el programa resultante:

La moraleja del artículo es que siempre hay que tener en cuenta el tipo de cadena que empleemos. La API de Windows ofrece muchos nuevos tipos de datos de caracteres que conviene interiorizar para evitar este tipo de fallos y ser más productivos mientras se aprende programación usando la API de Windows. Otro punto destacado de la programación con cadenas es la posibilidad de incluir vulnerabilidades de seguridad con cierta facilidad. Trataremos este punto en un próximo artículo.

En el futuro iré tratando otros problemas más complejos que pueden surgir al programar usando la API de Windows, especialmente casos en los que la documentación oficial no ofrece información, o bien la que ofrece es ambigua, o bien inexacta.

En este artículo voy a resumir las posibilidades existentes de actualización a Windows 7, tanto desde sistemas anteriores como desde versiones menos completas de este sistema operativo. También explicaré en detalle en qué consiste Windows Anytime Upgrade, y por qué es técnicamente diferente a lo habitualmente conocemos como una actualización de sistema operativo.

Posibilidades de actualización

Existen tres posibilidades de actualización a Windows 7 dependiendo del sistema operativo y de la edición de la que partamos:

• Actualización no disponible: Típicamente estamos intentando actualizar desde Windows XP o sistemas anteriores. La única opción sería realizar una instalación limpia, salvaguardando antes los datos de valor, o usando Windows Easy Transfer.
• Actualización disponible: Si partimos de ciertas ediciones de Windows Vista (SP1 o superiores) existe la posibilidad de actualizar a Windows 7 sin perder datos mediante la típica opción de actualización del programa de instalación. Si podemos permitirnos el tiempo necesario para realizar una instalación limpia, personalmente lo recomiendo a este tipo de actualización, pues herederá los problemas que tuviéramos en Windows Vista (y podría añadir nuevos). La instalación limpia siempre que sea posible es la manera mejor de hacer llegar Windows 7 a nuestro equipo “por la puerta grande”.
• WAU (Windows Anytime Upgrade): Esta opción permite actualizar desde una edición de Windows 7 a otra más completa. Técnicamente el proceso de instalación no tiene que ver con una actualización desde un sistema anterior y además podemos usar cualquier tipo de clave de Windows 7 que tengamos, no solamente las que adquiramos desde la web de Microsoft.

Tabla resumen

Una vez descritas las tres posibilidades de actualización, detallo en esta tabla todas las posibilidades de actualización a Windows 7:

Nota: Las versiones de Windows Vista deben tener instalado como mínimo Service Pack 1.

Leyenda: “No” – No está disponible la actualización. “Sí” – Actualización disponible. “Rep.” – Reparación del sistema operativo. “WAU” – Windows Anytime Upgrade.

Para facilitar la lectura, he marcado en la tabla en negrita las combinaciones posibles.

Windows Anytime Upgrade ¿en qué consiste realmente?

Windows Anytime Upgrade (WAU en adelante) es una característica incorporada a Windows 7 que permite actualizar el sistema operativo a una edición superior, si existe un camino de actualización (ver tabla anterior). Al iniciar WAU el sistema nos invitará a comprar una clave de producto en el sitio web de Microsoft o bien proporcionar una clave (ya sea comprada en la tienda de Microsoft, de actualización o versión completa, perteneciente a una suscripción técnica MSDN/Technet, etc.). Cualquier clave “retail” o de actualización de esa edición superior de Windows 7 será admitida por WAU, siempre y cuando exista un camino soportado de actualización.

WindowsAnytimeUpgrade.exe es el ejecutable principal. Al ejecutarlo, el sistema comprueba si la edición es actualizable mediante WAU y si no hay aplicada una directiva de grupo (claves de registro Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\WAU, bajo las ramas HKCU y HKLM, valor Disabled con contenido 1).

Cabe destacar que podemos ejecutar WindowsAnyTimeUpgrade.exe desde la línea de comandos y que admite como parámetro la clave de la edición de Windows 7 a la que queremos pasar. Por tanto, podemos utilizar este ejecutable en baterías de scripts que automaticen todo el procedimiento. El sistema seguidamente procede a validar la clave de producto que le hemos pasado, así como comprobar que el sistema esté activado correctamente. De no ser así, el sistema nos ofrecerá la opción de activarlo en este momento.

Antes de comenzar con la actualización propiamente dicha, Windows 7 crea un punto de restauración por si algo fuera mal. La actualización se realiza mediante el ejecutable DISM.exe, que activa y configura los componentes correspondientes a la versión de Windows 7 a la que queremos actualizar. No necesitaremos disponer de un DVD de Windows 7 con esa edición, puesto que al instalar cualquier edición de Windows 7 está presente en nuestro disco todo el contenido completo del sistema operativo en su edición Ultimate. El proceso de actualización de WAU es similar a lo que ocurre cuando añadimos características de Windows (como IIS o Telnet) desde Panel de control, Programas.

Una vez acabada la actualización de WAU, se instalarán actualizaciones de Windows Update para que el sistema resultante quede completamente al día. Este paso se realiza si la configuración del usuario con respecto a las actualizaciones automáticas de Windows Update no lo impide. Algunas actualizaciones no se instalarán, y son aquellas que requieren intervención por parte del usuario, por ejemplo para aceptar un EULA (para que la experiencia de usuario no sea mala). Si fallara por algún motivo la instalación de las actualizaciones, no se detendrá ni fallará el proceso de actualización de WAU.

Una vez finalizada la actualización, se añade una entrada de registro a la clave RunOnce del registro para que se ejecute WindowsAnytimeUpgradeResults.exe nada más volver a iniciar sesión. Esto sirve para informar al usuario de si el proceso de actualización concluyó con éxito o no.

¿Qué hacer en caso de fallo?

Si WAU no ha podido actualizar nuestra edición de Windows 7, hay que examinar los ficheros de reporte. Estos son los ficheros de reporte que deberemos examinar en primer lugar en busca de información precisa sobre lo que ha ocurrido:

• %UserProfile%\AppData\Local\Microsoft\Windows\Windows Anytime Upgrade\*.log
• %SystemRoot%\Logs\CBS\CBS.log.

Algunas soluciones generales que quizá solucionen el problema son reiniciar el sistema por si hubiera operaciones pendientes que estuvieran interfiriendo en la actualización, analizar el disco con la herramienta Chkdsk, o usar esta herramienta de Microsoft.

Si tuviera problemas con WAU que no ha podido solucionar, lo mejor es que abra un nuevo tema en mis foros, http://www.wintecnico.com/foros, para facilitar su seguimiento.

En otros artículos expliqué cómo integrar varias arquitecturas de Windows 7 en un mismo DVD, así como varios idiomas de Windows 7. En este artículo vamos a combinar las técnicas de ambos artículos para explicar, con todo detalle, cómo crear un DVD de Windows 7 Ultimate que contenga las ediciones de 32 y de 64 bits, así como 3 idiomas: inglés (Estados Unidos), español, portugués (Portugal) y portugués (Brasil). Debido a la extensión del artículo, es recomendable que lo imprima y guarde como referencia para consultarlo con más comodidad.

Preliminares

Antes de comenzar, deberá disponer de una licencia de Windows 7 Ultimate así como acceso tanto a la versión de 32 bits como a la de 64 bits (en formato DVD o ISO). También podría seguir este tutorial con Windows 7 Enterprise, pues es la otra edición de Windows 7 que permite instalar varios idiomas en un mismo equipo. Sin pérdida de generalidad, en este tutorial supondremos que el idioma de Windows 7 Ultimate 32 bits y 64 bits sobre el que se realizará la integración tiene como idioma base el inglés (Estados Unidos).

Para realizar la integración, vamos a usar las herramientas incluidas en el Windows AIK, que se puede descargar gratuitamente desde http://www.microsoft.com/downloads/details.aspx?FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34&displayLang=es. Instálelas en una máquina destinada a realizar la integración. Esta máquina deberá disponer de un mínimo de 15 GB de espacio libre en disco, aproximadamente. Quizá los requerimientos exactos en su caso sean menos exigentes, pero es recomendable que haya suficiente espacio en disco en todo momento para evitar corromper la imagen resultante.

Por supuesto, deberá descargar los paquetes de idiomas español, portugués (Portugal) y portugués (Brasil), tanto en sus versiones de 32 bits, como sus versiones en 64 bits. Para ahorrarle trabajo, aquí dejo los correspondientes enlaces al sitio de Windows Update:

Español (32 bits): windows6.1-kb972813-x86-es-es_1943a073d8f00e387301deb22cd177bf77319ee8.exe

Español (64 bits): windows6.1-kb972813-x64-es-es_2e593c26d9e23ad8176224a53c68a04f996ee014.exe

Portugués (Portugal) (32 bits): windows6.1-kb972813-x86-pt-pt_4165bd9cd083abd8ddd81986e18b1fd86aab5ce9.exe

Portugués (Portugal) (64 bits): windows6.1-kb972813-x64-pt-pt_f8310aa4a73841aec29b3f4e74ecaece56b695e9.exe

Portugués (Brasil) (32 bits): windows6.1-kb972813-x86-pt-br_0a3fe79820d6d199dd43495d4efa5c40f270e45a.exe

Portugués (Brasil) (64 bits): windows6.1-kb972813-x64-pt-br_276b65f3b6b2657c8fe936f9841dc1243e02dc7b.exe

Estructura de directorios inicial

Para comenzar, cree los siguientes directorios dentro de alguna carpeta vacía dedicada a este procedimiento de integración:

• \Distribution
• \Offline
• \ScratchDir
• \Boot

Copie en el directorio \Distribution el contenido del DVD o ISO de Windows 7 Ultimate de 32 bits. Cree dentro de este directorio un subdirectorio de nombre \langpacks que dentro contenga los subdirectorios \es-es, \pt-pt y \pt-br. Deje dentro de cada uno de estos subdirectorios el paquete de idiomas en formato .cab correspondiente a cada idioma. Los paquetes de 32 bits denomínelos "Lp.cab” y los de 64 bits “Lp64.cab”. Para extraer el fichero lp.cab a partir del .exe, haga doble clic sobre el .exe y en el momento que aparezca el fichero .cab en el mismo directorio que el fichero .exe, cámbielo momentáneamente de nombre (para evitar que Windows lo elimine a los pocos segundos). Cancele la instalación del paquete de idiomas.

Cree aparte unas carpetas temporales, por ejemplo

C:\LPs\es-es\expanded

C:\LPs\pt-pt\expanded

C:\LPs\pt-br\expanded

A continuación abra una ventana de línea de comandos (Inicio, Todos los programas, Accesorios, Símbolo de sistema) y teclee estos comandos:

expand.exe -f:* <Ruta Distribution>\langpacks\es-es\lp.cab C:\LPs\es-es\expanded

expand.exe -f:* <Ruta Distribution>\langpacks\pt-pt\lp.cab C:\LPs\pt-pt\expanded

expand.exe -f:* <Ruta Distribution>\langpacks\pt-br\lp.cab C:\LPs\pt-br\expanded

xcopy C:\LPs\es-es\expanded\sources\license\* <Ruta Distribution>\sources\license\ /cherkyi

xcopy C:\LPs\es-es\expanded\setup\sources\* <Ruta Distribution>\sources\ /cherkyi

xcopy C:\LPs\pt-pt\expanded\sources\license\* <Ruta Distribution>\sources\license\ /cherkyi

xcopy C:\LPs\pt-pt\expanded\setup\sources\* <Ruta Distribution>\sources\ /cherkyi

xcopy C:\LPs\pt-br\expanded\sources\license\* <Ruta Distribution>\sources\license\ /cherkyi

xcopy C:\LPs\pt-br\expanded\setup\sources\* <Ruta Distribution>\sources\ /cherkyi

Este debería ser el aspecto final del directorio \Distribution:

Y este sería parte del contenido del subdirectorio \sources:

En este punto ya disponemos de un directorio \Distribution con todo preparado para un albergar varios idiomas. El resto del artículo tratará sobre la integración de los paquetes de idiomas en cada edición de Windows 7, juntar ambas en una misma imagen Install.wim, e integrar los paquetes de idiomas en la imagen de instalación (Boot.wim).

Montaje de la imagen de 32 bits e integración de los paquetes de idiomas

Abra Inicio, Todos los programas, Microsoft Windows AIK, seleccione Deployment Tools Command Prompt con el botón derecho del ratón y escoja Ejecutar como administrador.

En este artículo la edición de Windows 7 copiada en el directorio Distribution contiene varias ediciones de Windows 7 32 bits. Concretamente, la imagen con índice 5 es la correspondiente a Windows 7 Ultimate, y es la que se va a montar. Para ver el listado de imágenes contenidas en un fichero .wim, teclee este comando y pulse INTRO:

Imagex /info <Ruta Distribucion>\sources\install.wim

Fíjese en el atributo “index” de las etiquetas “image” para identificar la imagen de Windows 7 Ultimate.

En la ventana de línea de comandos teclee el siguiente comando y pulse INTRO:

Dism /Mount-WIM /WimFile:<Ruta Distribution>\sources\install.wim /index:5 /MountDir:<Ruta Offline>

A continuación vamos a instalar los 3 paquetes de idiomas de 32 bits en la imagen que acabamos de montar:

Dism /Image:<Ruta Offline> /ScratchDir:<Ruta ScratchDir> /Add-Package /PackagePath:<Ruta Distribution>\langpacks\e
s-es\lp.cab /PackagePath:<Ruta Distribution>\langpacks\pt-pt\lp.cab /PackagePath:<Ruta Distribution>\langpacks\pt-br\lp.cab

Tenga en cuenta que esta operación podría tardar bastantes miinutos, pues se están instalando 3 paquetes de idiomas en la imagen offline.

A continuación se debe volver a generar el fichero Lang.ini contenido en el directorio \Distribution\sources. Para ello, introduzca este comando:

Dism /image:<Ruta Offline> /Gen-LangINI /distribution:<Ruta Distribution> /Set-AllIntl:en-us

Seguidamente, capture el contenido de la imagen de Windows 7 Ultimate montada con los paquetes de idiomas integrados para generar un nuevo fichero .wim. Antes de nada, cree un directorio C:\W7, que contendrá la imagen resultante.

Imagex /capture <Ruta Offline> C:\W7\install.wim "Windows 7 Ultimate (x86)" "Windows 7 Ultimate (x86)" /flags "Ultimate" /verify /compress maximum

Este procedimiento podría tardar bastante tiempo, así como consumir un alto porcentaje de CPU, pues se están aplicando algoritmos complejos de compresión para que la imagen ocupe lo mínimo posible.

Una vez finalizada la integración, debe desmontar la imagen para liberar el directorio \Offline:

Dism /unmount-WIM /MountDir:<Ruta Offline> /Commit

Hacemos lo mismo con la edición de 64 bits

Ya tenemos la mitad de lo que queremos conseguir, nos falta integrar la edición de 64 bits, con sus correspondientes paquetes de idiomas. Copie en un directorio temporal el fichero \sources\install.wim de su DVD o ISO de Windows 7 64 bits. A continuación siga los mismos pasos anteriores de montaje de la imagen en el directorio /Offline, integre los paquetes de idiomas siguiendo el mismo comando que el ya citado (Ojo, tenga en cuenta que debe integrar los ficheros Lp64.cab) y capture la imagen de modo que se agregue a la imagen que ya tiene creada, con este comando:

Imagex /append <Ruta Offline>  C:\W7\install.wim  “Windows 7 Ultimate (x64)” /verify

Ya solo queda desmontar la imagen de 64 bits mediante el comando

Dism /unmount-WIM /MountDir:<Ruta Offline> /Commit

Sustituya el fichero \Distribution\sources\install.wim por el nuevo fichero C:\W7\install.wim.

Modificación de la imagen Boot.wim

Resta por agregar los paquetes de idiomas a la imagen de instalación y preinstalación (Windows PE) de Windows 7.

En primer lugar, extraiga en unas carpetas temporales el contenido del directorio \WinPE_LangPacks\x86 de la ISO de Windows AIK; puede quedarse solamente con las subcarpetas es-es, pt-pt y pt-br y eliminar el resto, por ejemplo:

C:\WinPE_LPs\es-es

C:\WinPE_LPs\pt-pt

C:\WinPE_LPs\pt-br

En la ventana de línea de comandos que está abierta, teclee lo siguiente para montar la imagen de Windows PE en el directorio \Boot que creó al principio del artículo:

Dism /Mount-WIM /WimFile:<Ruta Distribution>\sources\boot.wim /index:1 /MountDir:<Ruta Boot>

Teclee este comando para instalar los paquetes de idiomas:

Dism /Image:<Ruta Boot> /Add-Package /PackagePath:C:\WinPE_LPs\es-es\lp.cab /PackagePath:C:\WinPE_LPs\pt-pt\lp.cab /PackagePath:C:\WinPE_LPs\pt-br\lp.cab

Cuando finalice la instalación, teclee este comando para guardar y desmontar la imagen:

Dism /unmount-WIM /MountDir:<Ruta Boot> /Commit

A continuación debe montarse la imagen de Windows Setup (imagen número 2) de Boot.wim:

Dism /Mount-WIM /WimFile:<Ruta Distribution>\sources\boot.wim /index:2 /MountDir:<Ruta Boot>

Instalamos los paquetes de idiomas:

Dism /Mount:<Ruta Boot> /Add-Package /PackagePath:C:\WinPE_LPs\es-es\lp.cab /PackagePath:C:\WinPE_LPs\es-es\winpe-setup_es-es.cab /PackagePath:C:\WinPE_LPs\es-es\winpe-setup-client_es-es.cab /PackagePath:C:\WinPE_LPs\pt-pt\lp.cab /PackagePath:C:\WinPE_LPs\pt-pt\winpe-setup_pt-pt.cab /PackagePath:C:\WinPE_LPs\pt-pt\winpe-setup-client_pt-pt.cab /PackagePath:C:\WinPE_LPs\pt-br\lp.cab /PackagePath:C:\WinPE_LPs\pt-br\winpe-setup_pt-br.cab /PackagePath:C:\WinPE_LPs\pt-br\winpe-setup-client_pt-br.cab

Salve los cambios:

Dism /unmount-WIM /MountDir:<Ruta Boot> /Commit

Creación de una imagen ISO y grabación en un DVD

Ya tenemos nuestro Windows 7 Ultimate x86/x64 con cuatro idiomas integrados. Solo nos queda generar una imagen ISO con Oscdimg.exe (incluido también en el Windows AIK) y grabarla en un DVD.

Como la imagen tiene un tamaño superior a 4,5 GB, es necesario indicarle a Oscdimg.exe el orden de los archivos de arranque para asegurar que estos se sitúen al principio de la imagen. Para ello, abra Bloc de notas, copie y pegue este texto y guárdelo como C:\Docs\Bootorder.txt, por ejemplo:

boot\bcd
boot\boot.sdi
boot\bootfix.bin
boot\bootsect.exe
boot\etfsboot.com
boot\memtest.efi
boot\memtest.exe
boot\en-us\bootsect.exe.mui
boot\fonts\chs_boot.ttf
boot\fonts\cht_boot.ttf
boot\fonts\jpn_boot.ttf
boot\fonts\kor_boot.ttf
boot\fonts\wgl4_boot.ttf
sources\boot.wim

A continuación ejecute este comando en la línea de comandos que tiene abierta (respete al pie de la letra los espacios):

oscdimg -m -n -yoC:\Docs\bootorder.txt –l”Windows7_x86_x64_MultiLanguage” –b<Ruta Distribution>\boot\etfsboot.com <Ruta Distribution> <Ruta ISO>\Windows7_x86_x64_en-us_es-es_pt-pt_pt-br.iso

Cuando finalice la creación de la imagen ISO, grábela en un DVD usando por ejemplo la herramienta de grabación de imágenes de Windows 7 (simplemente haga doble clic sobre la imagen para arrancar esta herramienta). Cuando arranque desde el DVD y proceda a instalar el sistema operativo, el programa de instalación le invitará a seleccionar su idioma nada más comenzar:

Conclusión

Este artículo ha explicado paso a paso y detalladamente cómo crear un DVD de Windows 7 Ultimate que contenga ambas arquitecturas (32 bits y 64 bits), así como cuatro idiomas. Los idiomas están disponibles tanto externamente a la imagen (en la carpeta \langpacks de la nueva ISO) como integrados en las imágenes Install.wim y Boot.wim. Con el primer Service Pack de Windows 7 a la vuelta de la esquina, explicaré próximamente cómo crear un DVD de Windows 7 con SP1 integrado, partiendo de este artículo.

En la quinta parte de este tutorial introductorio de depuración de aplicaciones vimos algunos comandos de Windbg que nos permiten mostrar información sobre la pila de ejecución en un determinado momento, una tarea bastante cotidiana en el ámbito de la depuración. En esta parte veremos algunas otras tareas relacionadas con la pila de ejecución y los correspondientes comandos de Windbg que nos permite llevarlas a cabo.

Puede darse el caso de que necesitemos saber el espacio que ocupa cada marco de pila de una traza de pila concreta. Para ello podemos obtenerlo de dos formas: Aplicando la teoría que vimos en la parte anterior, el tamaño de cada marco de pila se podría obtener restando la dirección del puntero base (registro ebp) del marco de pila anterior a la del marco de pila actual. Recuerde que las direcciones de los punteros base aparecen bajo la columna "ChildEBP” en la salida de la familia de comandos k* de Windbg. Alternativamente, se puede hacer uso del comando kf, que hace todo este cálculo por nosotros. La salida de este comando nos mostrará el espacio ocupado por cada marco de pila, exceptuando el actual. Esta es una salida de ejemplo del comando kf de Windbg:

A modo de ejemplo, vamos a calcular el tamaño del segundo marco de pila. Tenemos que restar las direcciones 0020f9c4 y 0020f868, que coincide con el contenido actual del registro ebp. Windbg incorpora un comando muy práctico que nos permite evaluar este tipo de expresiones, ?:

Como vemos, el resultado hexadecimal obtenido es 15c, que coincide con lo que nos muestra el comando kf.

Otro comando relacionado que nos permite evaluar y convertir expresiones a diferentes formatos es .formats. Veamos un ejemplo de la salida de este comando:

A veces hay que ayudar a Windbg para que muestre una buena traza de pila

En determinados ambientes de servidores es bastante común que tengamos que depurar un sistema que haya recibido una carga de trabajo bastante elevada. Una consecuencia de esto es que la información correspondiente a la pila no reside en memoria principal. Técnicamente, se dice que las páginas correspondientes a la pila han paginado a disco. Otro escenario común es que estemos depurando un software cuya ejecución haya corrompido la pila. Para que Windbg pueda construir una buena traza de pila, es necesario que ciertas estructuras de la misma estén en estado intacto. De no ser así, con total seguridad no podemos confiar en la traza de pila resultante que obtengamos mediante la familia de comandos k*. Un ejemplo de traza de pila sospechosa sería aquella en la que el marco de pila actual (es decir, el que está el primero en la traza) se le haya hecho corresponder con una dirección de memoria hexadecimal en lugar de el símbolo de una función. ¿Por qué motivo Windbg no ha podido hacer corresponder esa dirección de memoria con un módulo? Posiblemente porque con anterioridad se haya sobreescrito partes importantes de la pila (como la dirección de retorno) y el flujo de ejecución haya acabado ahí por error. Es más que probable que la dirección ni siquiera sea código ejecutable, con la correspondiente excepción que surgirá cuando el procesador se disponga a ejecutar a partir de ella.

En estos casos de la vida real, no nos queda otra opción que ayudar a Windbg aplicando nuestros conocimientos para reconstruir una buena traza de pila. Lo primero es hacer uso del comando dd (display memory, double-word) para mostrar el contenido de la pila (almacenado en la dirección de memoria contenida en el registro puntero de pila, esp):

dd esp

De la salida de este comando hay que identificar aquellas direcciones que se correspondan con funciones. Para ver los rangos de direcciones de los símbolos de todos los módulos cargados en memoria, podemos hacer uso del comando

x *!

Buscamos en la salida del comando dd esp aquellas direcciones que podrían corresponderse con direcciones de funciones. Para ello comparamos cada dirección con los rangos de direcciones que nos muestra el comando x *!. Una vez que hayamos identificado alguna dirección de memoria que sea potencialmente candidata de ckrrresponderse con una función, podemos comprobar si estamos en lo cierto haciendo uso del comando

ln <Dirección>

El comando ln (list nearest symbols) nos muestra los símbolos más cercanos a la dirección de memoria pasada como argumento.

Una vez identificadas las posibles funciones que conformarían nuestra traza de pila reconstruida, debemos tener en cuenta las direcciones de retorno que se almacenan en la pila previamente a una llamada a subrutina (como vimos en el artículo anterior). Desensamblando unas cuantas instrucciones alrededor de esa dirección de retorno mediante el comando u podemos confirmar nuestra teoría viendo si hay una llamada a subrutina (call, en ensamblador) y en cuyo caso, a qué dirección de función está llamando. Si nuestras averiguaciones han sido correctas, dicha llamada debería ser a la función que esté justo encima en nuestra hipotética traza de pila. Una vez identificado el flujo de ejecución de la aplicación, podemos dar visto bueno a nuestra traza de pila y proseguir con la depuración.

En el próximo artículo vamos a ver un ejemplo práctico donde reconstruyo una traza de pila para poner en práctica y afianzar totalmente los pasos anteriormente comentados. Seguiremos tratando el tema de la pila de ejecución con otros casos del mundo real con los que me he encontrado en los que ha sido necesario comprobar que una traza de pila es correcta para seguidamente analizarla y determinar por qué ha ocurrido cierto problema.

Uno de los temas que más se han comentado en Internet con respecto a Windows 7 es si en este sistema es posible deshabilitar las vistas en miniatura que aparecen al posar el puntero del ratón sobre un icono de aplicación abierta de la barra de tareas. En algunas páginas en Internet se muestran algunos pasos, y algunos usuarios comentan que funcionan, otros que no, etc. Este artículo aclarará qué es lo que realmente sirve aproximadamente, qué no sirve, y todo lo que se puede hacer con las vistas en miniatura de la barra de tareas en Windows 7.

TaskbarNoThumbnail: Una directiva que se aplicaba a Windows Vista pero que ya no sirve en Windows 7

Si busca en Internet sobre cómo desactivar las vistas en miniatura de la barra de tareas en Windows 7, es probable que se encuentre con artículos que indican cómo aplicar una directiva de grupo que aparentemente consigue esto mismo. En concreto se trata del valor de tipo DWORD “TaskbarNoThumbnail” que se puede agregar a la clave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer. Lamentablemente esta directiva solo es aplicable a Windows Vista. De hecho, en Windows Vista se pueden activar/desactivar las vistas en miniatura desde las propiedades de la barra de tareas. En Windows 7 se ha eliminado completamente esta opción de la interfaz de usuario. Por lo tanto, esta alternativa no consigue lo que queremos.

DisablePreviewWindow: Cómo desactivar Live Preview. Pero Live Preview no es la vista en miniatura de la barra de tareas

Otras páginas tratan una cuestión parecida e invitan al usuario a crear un valor de registro de nombre DisablePreviewWindow con contenido 1 en la clave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced. Este valor de registro desactiva lo que se conoce como Live Preview, que no es exactamente lo que está buscando. Live Preview es el efecto que surge cuando el usuario posa el cursor del ratón sobre una miniatura de la barra de tareas: La ventana en cuestión aparece visible y “aislada” del resto, para echar un vistazo rápido. Similarmente, el valor de registro DisablePreviewDesktop, de esa misma clave de registro, desactiva Aero Peek.

ExtendedUIHoverTime: Una forma de desactivarlas “aproximadamente”

Si añade a la clave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced un valor de tipo DWORD y nombre ExtendedUIHoverTime que contenga el tiempo (en milisegundos) que quiere que pase hasta que se muestre la vista en miniatura, efectivamente si establece un valor alto conseguirá el efecto de que la vista no se muestre nada más posar el puntero sobre un elemento de la barra de tareas. El problema es que mucha gente quiere que al posar el puntero sobre un elemento de la barra de tareas se muestre una lista clásica de todas las ventanas que hay abiertas de ese elemento. Para ello una opción es activar un tema clásico de Windows, o desactivar la composición de escritorio (con la consecuente pérdida de efectos visuales), o bien manipular un valor del registro, comentado a continuación.

NumThumbnails: Probablemente casi lo que está buscando

Si añade a la clave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Taskband un valor de tipo DWORD y nombre NumThumbnails, podrá controlar el número de vistas en miniatura máximo para que el sistema pase a mostrar una lista vertical de ventanas. Por defecto Windows muestra hasta un máximo de 16 vistas en miniatura en la barra de tareas. Los límites superior e inferior para el valor NumThumbnails es 32 y 1. Como ve, el límite inferior es 1, por lo que las ventanas individuales siempre mostrarán una vista en miniatura.

Por último, una aplicación denominada Taskbar Tweaker (http://rammichael.com/7-taskbar-tweaker) es capaz de eliminar las vistas en miniatura de la barra de tareas, sin modificar el registro (es una aplicación que se inyecta en Explorer.exe). La pega de esta opción es que tampoco es capaz de mostrar una lista de ventanas en lugar de la lista de vistas en miniatura.

Como observa, no hay una opción de registro perfecta que consiga pasar a modo lista la visualización de ventanas abiertas en la barra de tareas de Windows 7, sin tener que desactivar Windows Aero. Lo más cercano quizá sea la opción cuarta (NumThumbnails) estableciendo como contenido para este valor de registro un 1.

Existen bastantes dudas entre la gente que no se dedica a programar (en especial en .NET)sobre las versiones de .NET Framework. Desde el punto de vista de un usuario final o de un profesional de las TI que no desarrolla software, ¿qué versiones instalar y cuáles no? ¿Se actualizan las versiones anteriores o se instalan de forma paralela? Este artículo dará respuesta a estas preguntas.

¿De qué se compone .NET?

El punto de partida para aclarar el caos que existe con las versiones de .NET es comprender exactamente cuáles son los dos componentes principales de .NET: Por un lado está el CLR (Common Language Runtime) y por otro el Framework, o conjunto de librerías que proporcionan funcionalidades a los programadores de aplicaciones. Existe un tercer componente, el lenguaje de programación (C# o VB.NET), que no vamos a tratar en este artículo.

El núcleo de .NET Framework es el CLR, y es el componente que se encarga entre otras cosas de traducir el código gestionado (IL), generado por el compilador, en código adaptado a la máquina de destino (por ejemplo, x86). La clave está en el número de versión del CLR es independiente de la versión de .NET Framework; o dicho de otra manera, una nueva versión de .NET Framework no necesariamente incorpora una nueva versión del CLR. Este punto es el que confunde a mucha gente. Históricamente, las versiones de .NET (sin contar Service Packs intermedios) han sido la 1.0, 1.1, 2.0, 3.0, 3.5 y 4.0, disponible desde hace poco tiempo. Hasta la versión 2.0, cada nueva versión de .NET Framework ha incorporado una nueva versión del CLR. Sin embargo, las versiones 3.0 y 3.5 siguen usando la versión 2.0 del CLR. Estas dos versiones solo han consistido en la adición de nuevas librerías, manteniéndose el mismo núcleo de .NET. ¿Por qué ha elegido Microsoft denominarlas con un nuevo número de versión? Realmente lo desconozco, quizá sea un aspecto de marketing.

.NET Framework en su versión 4.0 introdujo la versión 4.0 de las librerías y además incorporó una nueva versión del CLR, la 4.0. Esta tabla resume toda esta información:

* Incorpora la versión 2.0 SP2 como requisito de la versión 3.0.

** Incorpora la versión 3.5 SP1.

(No ha habido una versión 3.0 del CLR).

Las versiones instaladas de .NET están en el directorio C:\Windows\Microsoft.NET\Framework, dentro de la subcarpeta correspondiente a su número de versión. Podrá comprobar que algunas versiones, como la 3.0 o 3.5, no incorporan una nueva versión del fichero Mscorlib.dll, que implementa el núcleo de .NET.

¿Se pueden instalar varias versiones en un mismo equipo? ¿Se actualizan automáticamente las versiones anteriores?

Podemos tener instaladas varias versiones de .NET Framework. La versión 3.0, por ejemplo, requiere tener instalada la versión 2.0 para añadirle unas cuantas librerías más. Lo mismo ocurre con la versión 3.5. No es necesario instalarlas gradualmente, cada instalación incorpora todos los componentes necesarios. Por lo general, si un programa requiere una versión específica de .NET, la instalará automáticamente, o bien le indicará al usuario de dónde tiene que bajarla e instalarla. No hay ningún problema por tener instaladas varias versiones de .NET en un mismo equipo, estas se ejecutan “side-by-side”, impidiendo que ocurran conflictos. La práctica totalidad de aplicaciones diseñadas para .NET Framework 1.0, 1.1, 2.0, 3.0 ó 3.5 van a funcionar sin problemas en .NET Framework 4.0.

Este es un resumen del “caos” de versiones de .NET Framework, que trae de cabeza a muchos usuarios finales que no saben exáctamente qué versión instalar. Si el sistema operativo es superior a Windows XP, el usuario probablemente no va a tener que preocuparse de instalar nada, pues estos sistemas ya incorporan de serie una versión de .NET Framework. En estos casos, lo único que hay que hacer es mantenerla actualizada. En el caso de que aparezca una nueva versión del motor CLR de .NET, al instalarla se mantendrán las versiones anteriores que pudiera haber en el equipo; no es necesario desinstalarlas. En casos como las versiones 3.0 y 3.5 esto incluso no es posible hacerlo puesto que dependen del motor de la versión 2.0 para funcionar. Otro caso en el que no es posible la desinstalación es si la versión de .NET venía incorporada de serie con el sistema operativo (tercera columna de la tabla anterior).