Una de las novedades más notables de Windows 7 es la nueva configuración de particiones que aplica por defecto. Cuando Windows 7 se instala en un disco recién formateado, automáticamente crea una partición de 200 MB, la marca como activa y no le asigna una letra de unidad. Esta captura de pantalla refleja esto:
Lo primero de todo aclarar un poco la nomenclatura, que resulta algo confusa: La primera partición de la imagen se denomina partición de sistema y contiene los archivos que sirven para que Windows 7 arranque correctamente. La otra partición se denomina partición de arranque y contiene el resto de archivos del sistema operativo.
¿Qué beneficios conlleva separar la partición de arranque de la partición de sistema?
Tener una partición separada para los ficheros de arranque es beneficioso puesto que facilita la instalación de múltiples sistemas operativos, sobre todo si unos son de la rama Windows NT (Windows NT, 2000, XP, Vista) y otros de la rama Windows 9x (Windows 95, 98, ME) ya que estos últimos no soportan el sistema de archivos NTFS. Otro motivo por el cual es beneficioso tener particiones separadas es que algunos virus y malware (aunque cada vez menos) suponen que el sistema operativo reside en la unidad C. Al tener los archivos del sistema operativo en otra partición, el código del virus fallará.
Sin embargo, el motivo principal por el cual Microsoft ha adoptado esta medida es que ciertas herramientas relacionadas con el almacenamiento requieren una configuración de particiones en la que la unidad de arranque esté separada de la unidad de sistema. Una de estas herramientas es Bitlocker, ya presente en las ediciones Ultimate y Enterprise de Windows Vista. Bitlocker requiere una partición de sistema separada de la partición de arranque para poder cifrar correctamente el contenido de un volumen.
¿Puedo configurar en algún sitio que esa reserva de 200 MB sea menor?
No es posible, pero Microsoft espera reducir el tamaño de la partición de sistema en posteriores versiones de Windows 7 (tenga en cuenta que aún no está ni en fase beta).
¿Se puede evitar la creación de dos particiones de alguna manera?
Si durante la instalación Windows 7 detecta que la partición donde se va a instalar es la partición activa, los ficheros de arranque y el resto de archivos del sistema operativo se almacenarán en una única partición. Sin embargo, por todo lo comentado más arriba, es altamente recomendable indicar que se instale en una partición no activa para que los archivos de arranque se instalen en otra partición separada (la partición activa).
Es importante comentar que la creación de dos particiones es una posibilidad que ya estaba presente en Windows Vista, con tres diferencias con respecto a Windows 7: No era la configuración por defecto, la partición de sistema sí recibía una letra de unidad y el tamaño de dicha partición era bastante elevado (1,5 GB). Por último comentar que si tiene Windows Vista y los archivos de arranque y de sistema residen en una misma partición, puede separarlos en dos particiones usando la herramienta Bitlocker Drive Preparation.
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.