.NET o no .NET, esa es la cuestión : vista, hardware

Cómo salta Windows entre anillos (Modo Kernel y modo Usuario)

Rafael Ontivero — Sat, 21 Nov 2009 13:37:03 GMT

Esta semana estamos de fiesta, y es que una de mis pasiones en el desarrollo siempre ha sido verle las tripas a Windows, y a ello vamos. Antes de nada, lo que voy a contar aquí es un resumen del punto System Service Dispatching del capítulo 3 de Windows Internals 5ª edición, pero es un resumen un poco especial porque voy a añadir cosas de mi cosecha, como siempre hago, ya que no es cosa de ir parafraseando lo que voy aprendiendo/recordando.

En entradas anteriores, y algunas veces en los foros, he comentado sobre saltos entre anillo 0 y anillo 3, y aquí voy a explicar de pasada lo que significa. Un microprocesador moderno (y no tan moderno), cuenta con un juego de instrucciones en cierta medida especiales, instrucciones que son necesarias para configurar el hardware y el propio funcionamiento del software. Hablamos aquí de las interrupciones y toda su parafernalia asociada, del control de la memoria virtual, del acceso directo a hardware (es decir, escribir o leer en una dirección de memoria o en un puerto en el que no hay tal, sino alguna electrónica que debe reaccionar en base a dicha lectura o escritura), etc.

Esas instrucciones son peligrosas de usar, y en general no deben estar disponibles para los programas normales, ya que entonces un error podría llevar a la caída total del sistema o incluso a la rotura de algún elemento electrónico.

Es decir, que podríamos dividir el juego de instrucciones de un microprocesador en dos grandes grupos: aquellas que no son necesarias para que un programa funcione normalmente y las que, si se usan de forma incorrecta, pueden terminar armando un buen pirifostio.

Pues básicamente eso son los anillos 0 y 3. En el 0 están las instrucciones peligrosas, en el 3 las que cualquier programa puede usar, y si un programa normal utiliza una del cero, generará una excepción (¿De qué me sonará esto?) que será capturada por el sistema operativo y manejada a su antojo. Aunque realmente no es del todo así, para nuestro propósito es suficiente.

(Si os dais cuenta, he hablado del 0 y del 3, pero también hay un 1 y un 2, que Windows no utiliza. Digamos que la separación de las instrucciones en estos distintos niveles permiten una serie de facilidades a la hora de construir software de sistemas, ya sean sistemas operativos o aplicaciones que vayan a correr en un microprocesador con estas características, lo que ocurre es que Windows aprovecha estos niveles únicamente de una sola forma, que llama modo usuario y modo kernel).

Pues bien, el kelmer, uis, perdón, el kernel, la mayoría de los drivers, y el motor gráfico (que fue ampliamente criticado en su momento pero que permitió que NT 4.0 pudiera ser usado en ordenadores no tan potentes) se ejecutan en el anillo 0, y los demás subsistemas (incluido Win32) en el 3. De esta forma un programador chapucero (o un compilador) sólo podrá tumbar su programa y nada más. Recordemos los días de Windows 3.x y DOS en los cuales tumbar por completo el sistema era tan fácil como ejecutar dos instrucciones de ensamblador seguidas: cli y luego sti, o al revés, ya no me acuerdo.

Una aplicación llama a una función, que debe terminar siendo ejecutada dentro del kernel (por ejemplo, abrir y leer de un fichero, cosa que necesita que los drivers de disco hagan trabajo de bajo nivel sobre la controladora y sobre el propio disco). Pongamos que nuestro programa llama a WriteFile(), y nos da igual que sea una aplicación .NET llamando a sus clases, ya que terminará en esa función. Esa función, que está en Kernel32.dll y pertenece al subsistema Win32, llamará a NtWriteFile(), que está en Ntdll.dll y no pertenece a ningún subsistema, sino que está disponible para cualquiera de ellos. Esta función llamará entonces a KiSystemService(), que está en Ntoskrnl.exe y se ejecuta en el anillo 0 en lugar del 3. Finalmente, esta última función hará lo que tenga que hacer llamando a otras funciones del kernel y de los drivers hasta que al final devolverá el resultado hacia atrás hasta nuestra aplicación.

Fácil, ¿no? Pues no, porque si nuestra aplicación hubiera llamado a WriteFile() con algún parámetro mal que fuera crítico (y se me ocurre pasar un valor aleatorio diferente de cero al handle del fichero sobre el que queremos escribir), lo más seguro es que termináramos en una pantalla azul (como más o menos ocurría en Windows 3.x y a veces en Windows 9x). Además, es muy posible que durante el procesamiento de la función, se salte varias veces entre el modo kernel y el user por necesidades del guión.

Pero todavía hay más, ya que no hemos tenido en cuenta que el controlador de tiempos y de procesos puede cortar en cualquier momento esa llamada para atender otros procesos o incluso hilos de nuestra aplicación. Vamos, que no es fácil ni de lejos.

¿Cómo se produce el salto entre el anillo 3 y el 0, que hemos descrito más arriba? Pues depende del procesador que estemos usando. En la época de Windows 9x (y de la parte en modo protegido de Windows 3.x cuando la había), y para micros antiguos, NtWriteFile(), después de verificar que los parámetros recibidos son correctos, coloca en varios registros del procesador lo necesario, y ejecuta la instrucción int 0x2e, que genera una excepción si se hace desde el anillo 3. Esta excepción es recogida por el Kernel, que mediante los parámetros que hay en los registros determina si es una petición válida (y si no lo es protestará) y la procesará mediante la ejecución de la función correspondiente situada en un array de punteros a función que se llama System Service Dispatch Table, de las que creo que hay varias. Básicamente, lo que está haciendo es recibir un índice que se corresponde a una posición dentro del array de punteros, y como nos equivoquemos con esto la hemos cagado a base de bien, y es por eso por lo que antes del salto entre anillos se verifican los parámetros. El retorno al anillo 3 se produce con la ejecución de la instrucción iretd.

En micros Intel más modernos, el salto se hace mediante la instrucción sysenter y la vuelta mediante sysexit (o iret si estamos en modo depuración). En un AMD las instrucciones son syscall y sysret.

Y finalmente, en micros de 64 bits con la arquitectura x64 las instrucciones son las mismas que en el AMD (por que fueron los primeros en implementarla) y en la I64, epc.

Si os dais cuenta, dependiendo del microprocesador se hace de una u otra forma, lo que puede ser un serio quebradero de cabeza. Lo que hace Windows al arrancar un sistema de 32 bits es instalar la instrucción correcta en una posición de memoria y juego ejecutar sobre ella, con lo que a lo anterior añadimos un nuevo nivel de indirección.

La secuencia completa de paso del anillo 3 al 0 consiste, más o menos, en lo siguiente: primero se verifican los parámetros recibidos de la forma más completa posible, luego se ejecuta la instrucción que hay en cierta posición de memoria, que a su vez generará una excepción, que será controlada por el sistema operativo, que mirará si los parámetros son correctos, y si lo son volverá a saltar sobre un puntero a puntero a función, y finalmente lo que haya allí hará el trabajo.

Eso para un solo salto. Imaginaros cuántos son necesarios para que nuestro programa, y el sistema operativo funcione. Y no hemos hablado de que en cada una de esos pasos es necesario que la pila se guarde o se recupere, y que los datos deben ser copiados desde la pila de modo user a la de modo kernel para evitar que la aplicación pueda modificarlos en medio de una operación interna…

En un sistema x64 la operación es algo más sencilla porque la instrucción de salto es siempre la misma y no es necesaria la indirección extra sobre la instrucción ya que da igual que el microprocesador sea un Intel o un AMD.

Esto quizás te presente una duda en el caso de equipos de 32 bits: ¿por qué no está cableada dicha instrucción y simplemente a la hora de instalar Windows o de arrancarlo, el cargador pone en memoria el juego de DLLs correcto? Pues realmente no tengo ni idea, lo que sí tengo claro es que en ese caso Windows debería contar con al menos 4 juegos completos de DLLs y o bien elegir el necesario durante la instalación o casi cuadriplicar el espacio ocupado en disco. Lo que sí es cierto es que si se hubiera hecho así, el Windows de 32 bits funcionaría sensiblemente más rápido… o no.

Sólo nos queda ver, por mor de completitud, cómo funciona internamente el kernel sobre sí mismo. Supongamos por un momento que el kernel necesita acceder a la funcionalidad que hay en WriteFile(), pero en lugar de llamar a esta función directamente, lo que hace es llamar directamente a la rutina a la que se está apuntando en la tabla SSDT y santas pascuas, ya que en principio no se necesita verificar los parámetros que se suponen son correctos, y aparte de eso ya estamos en el anillo 0. No obstante, un driver no puede hacerlo así porque Microsoft no se fía de ellos, y es por ello que existen unas funciones que tiene como prefijo Zw y que son las que llamarán a su homónimo apuntado por la SSDT después de realizar las verificaciones –menos que si se llamara desde el anillo 3- oportunas.

Eligiendo qué hacer cuando pete nuestra aplicación

Rafael Ontivero — Thu, 19 Nov 2009 17:53:00 GMT

En la entrada anterior expliqué qué ocurre cuando una aplicación peta y se genera una excepción no controlada (o controlada pero relanzada), y en esta voy a explicar cómo podemos, desde nuestro propio programa, configurar el modo en que eso ocurre. Pero antes una introducción.

En algunos lados he dicho que las excepciones son caras. Con eso no me refiero a que cuesten dinero, sino a que es un tipo de característica que resulta muy complicada de procesar y que a veces requiere de bastante tiempo de proceso. Cuando se dispara una interrupción en una aplicación, sobre todo si ocurre en el lado del kernel, éste tiene que entrar y salir varias veces entre su modo y el de usuario, operaciones que no son baratas (de nuevo no en dinero, aunque lo mismo en su servidor en producción sí) ya que significan saltar entre los anillos 0 y 3 del procesador. Aparte de eso, se debe recorrer la pila (a ambos lados de los anillos) para ir buscando el controlador adecuado, ejecutarlo y en la mayoría de casos continuar con la búsqueda.

Cuando ponemos un bloque try/catch, o __try/__except ó __try/__finally, el compilador deja “marcas” en la pila, “marcas” que serán leídas por el controlador de excepciones. Dependiendo de cómo lo hayamos hecho, y el número de bloques y de controladores, el sistema tendrá que salvar y restaurar el estado de la pila y de la aplicación para ir ejecutando los diferentes bloques de captura, y a veces incluso se necesita de cierta “inteligencia” para que la ejecución sea la correcta. El tema queda bastante claro una vez que se han leído los capítulos de los dos libros que mencioné, con una excepción: que esos recorridos requieren tiempo, sobre todo si hay saltos entre anillo 0 y 3, por lo que en general el uso de excepciones está para eso: para ser usadas cuando realmente se produzca una, y no alegremente como una mera característica de nuestro lenguaje.

Dicho esto, considero que el ejemplo que Jeffrey Ritcher pone al final del capítulo 25 no es muy correcto, no porque esté mal, sino porque realizar gestión de memoria mediante excepciones me parece que es matar moscas a cañonazos… aparte del desperdicio de la misma. Ritcher crea una hoja de cálculo de un tamaño predefinido pero sin asignar ningún tipo de memoria. Luego, ante cada requerimiento de que una celda sea llenada con algo, intenta escribir en la posición. Si ya hay memoria asignada todo irá bien, pero si no, se disparará una excepción que asignará un bloque a dicha celda. La barbaridad está en que cada asignación, aunque sea de un solo byte, asignará 4KB (que es el tamaño de página de RAM), y en que el gasto de la excepción y su control es enormemente más caro que simplemente comprobar si la memoria está asignada o no. A no ser que se me escape algo, como ejemplo sobre el funcionamiento de las excepciones, vale, pero como ejemplo de algoritmo genérico, no.

De todos modos, el sistema de excepciones es my potente y versátil, y con la combinación del registro, podemos configurar a base de bien el comportamiento de las no controladas. Windows Internals lista 25 claves para cambiar el comportamiento, alguna de ellas tan radicales como hacer que ni siquiera se ejecute WerFault.exe y nuestra aplicación desaparezca de forma silenciosa.

Pero como diría el personaje de los dibujos animados, no se vayan todavía, que hay más. Aparte de poder instalar y controlar ciertas funciones de control de excepciones, podemos configurar el modo con que nuestra aplicación se comunica con el gestor de las mismas. Es decir, mediante ciertas llamadas a funciones de Win32, podemos decirle al sistema WER cómo debe comportarse, qué ficheros adjuntar, etc.

La mayoría de las funciones que voy a citar aquí de pasada, se encuentran dentro de kernel32.dll y para usarlas debemos incluir werapi.h.

WerSetFlags()/WerGetFlags(). Cambiamos o leemos si queremos que se incluya el heap (montículo) en el informe, si se suspenderán todos los hilos o sólo el que falló, si se añadirá el informe a la lista de errores, y si se enviará o no a Microsoft.
WerAddExcludedApplication()/WerRemoveExcludedApplication(). Añadir o eliminar una aplicación a la lista de aplicaciones excluidas de la generación de informes.
WerRegisterFile()/WerUnregisterFile(). Añadir o quitar el fichero indicado al informe.
WerRegisterMemoryBlock()/WerUnregisterMemoryBlock(). Añadir/Qutar un volcado de un área de la memoria de nuestro programa.

También podemos crear un informe desde nuestro programa cuando queramos. Los pasos a seguir son:

Llamar a WerReportCreate(), que inicia el informe.
Llamar tantas veces a WerReportSetParameter() como parámetros queramos cambiar.
Llamar tantas veces a WerReportAddDump() como bloques de memoria queramos incluir.
Llamar tantas veces a WerReportAddFile() como ficheros del tipo que sean queramos incluir.
Llamar a WerReportSetUIString() para añadir opciones a la pantalla de WerFault.exe.
Llamar a WerReportSubmit(), que dependiendo de la configuración para el programa y/o genéricas que se tengan, enviará o no, preguntará o no, etc. qué hacer con el informe.
Llamar a WerReportCloseHandle() para terminar con el tema.

Como podéis ver, la cosa es muy potente, y puede ser enormemente útil en determinadas situaciones. Imaginemos que nuestra aplicación esté petando en casa del cliente y no haya modo de ver qué puñetas pasa. La generación de informes a demanda podría ser la solución. Lo que no he visto es cómo recibir e interpretar esos informes.

También podemos usar estas funciones cuando sea nuestra aplicación la que esté controlando la excepción, pero debemos ser cuidadosos ya que ésta podría estar tan estropeada que el uso de todo esto volviera a genera nuevas excepciones que terminaran en el mismo código, que a su vez generara otras que…

Se supone que Windows es lo suficientemente inteligente como para detener la cadena, pero como yo ya he visto más de una vez petar de forma continua a una aplicación en Windows Vista hasta que la he matado desde el administrador de tareas, debemos ser cuidadosos con su uso.

De excepciones, del depurador, de Windows y de Visual Studio

Rafael Ontivero — Wed, 18 Nov 2009 16:54:09 GMT

Esto leyendo la quinta edición de Windows Internals, que cubre Windows Vista y Windows Server 2008 y es la última versión disponible del libro. Allá por los años del Windows 95 y del NT 4.0, un poco antes, un poco después, estaba yo muy interesado en las tripillas de los sistemas operativos, y aparte de empacharme con algún que otro mamotreto genérico sobre el tema, le di caña a los equivalentes, como Windows 95, al descubierto, o el Windows NT de Helen Custer, así como otros de similar temática. Vamos, que prácticamente me leí todo lo que pude conseguir sobre las interioridades de esos sistemas operativos.

Pero desde hace un tiempo me veo en la tesitura de que, conversando aquí y allí, me he dado cuenta de que me he quedado bastante obsoleto en el tema, con cosas que no sólo han sido mejoradas, sino que ahora funcionan de forma completamente diferente, así que me he puesto las pilas y le estoy dando un buen repaso al libro…

Bueno, pues como iba diciendo, el capítulo 3 del citado no es que sea nada del otro mundo. Bueno, sí, lo cierto es que como no sepas de programación de hardware y hayas hecho algo, te vas a quedar poco menos que a dos velas con muchas de las cosas que aparecen, ya que tienen que ver con la gestión de interrupciones, tanto de software como de hardware, así como las excepciones y demás intríngulis que todo sistema operativo ha de cumplir.

Personalmente yo he hecho un par de proyectos basados en un microprocesador, aunque generalmente, cuando lo hago, suelo trastear con microcontroladores más o menos potentes, y la verdad es que muchas de las cosas que aparecen ahí explicadas, con la evidente diferencia entre un sistema operativo como es Windows y lo que un mindundi como yo haya podido hacer, me las he encontrado en mis desarrollos. Tener en cuenta las prioridades y los niveles de las interrupciones, programarlos y cambiarlos en tiempo real, instalar y quitar vectores de interrupción, etc.

Por lo menos eso es de lo que trata la parte del capítulo 3 que he leído, que ciertamente me parece demasiado detallista en cosas que, la verdad, a no ser que vayas a meterte de lleno en la creación de drivers primarios para Windows, de poco te sirve. Y si sabes de sistemas operativos, lo único llamativo es que te enteras de que Windows no es mucho más diferente que otros sistemas.

Volviendo al tema (lo que me mola irme por las ramas), sobre la página ciento y pico (je je, me quedan todavía más de mil cien por leer, ¡qué emoción!) se pone a hablar del control de las excepciones del sistema operativo, y cómo son controladas en conjunción con el software de aplicación (ese que tu y yo hacemos) y el propio sistema. Y entonces te dice que si no tienes claro cómo funciona a nivel de programador, que mires los capítulos finales de Windows via C/C++. Y como resulta que tengo ese libro en la lista de pendientes (hace unos años leí y estudié la misma versión pero mucho más antigua, y encima en castellano), pues dejé uno y me puse con el otro, máxime recordando que fueron precisamente esos capítulos los que no leí en la edición anterior.

El sistema de excepciones de Windows es muy potente y versátil, y todos deberíamos saber lo básico sobre él. Pero no, no voy a entrar en detalles sobre el mismo, simplemente os diré que funciona muy parecido a las excepciones de un lenguaje de programación, con la salvedad de que es el sistema operativo el que las lanza y las gestiona si no lo has hecho tu.

En Windows Vista y siguientes existe una aplicación que se llama WerFault.exe y que seguro que habéis visto en ejecución. De hecho, cada vez que os peta un programa, es esa aplicación la que toma el control y saca la barra de progreso moviéndose y te permite unas u otras acciones una vez que ha hecho sus deberes.

Es decir, cuando una aplicación genera una excepción, o el sistema operativo dispara una causada por la aplicación (por ejemplo, una división entre cero o una escritura fuera de rango), se trastea con la pila de tu programa y se busca un controlador de excepción adecuado. Ojo, no estamos hablando de bloques try/catch, sino de bloques __try/__except… aunque a veces el control termina también en un catch, sobre todo si usamos C++ y hemos habilitado la compatibilidad de control de excepciones del sistema operativo (y esto no viene explicado así en el libro, que asume la compatibildad). En .NET no sé qué ocurrirá, pero no creo que haya mucha diferencia.

Si nuestro programa tiene un manejador para esa excepción, se ejecutará, y dependiendo de lo que devuelva, se reintentará la instrucción (de código máquina, así que ojo) que generó la excepción, se continuará como si nada hubiera pasado (y en este caso podríamos liarla todavía más gorda), o se seguirá buscando otro nuevo manejador. Es decir, independientemente de lo que quiera que hagamos en nuestro controlador, podemos decirle al sistema operativo que reintente, que ignore o que busque otro controlador más.

Una vez que se han recorrido todos los controladores adecuados, además de dos más extra que podemos instalar mediante AddVectoredExceptionHandler() y SetUnhandledExceptionFilter(), y siempre que se haya llegado al final de toda la cadena de excepciones (que es algo más larga y compleja de lo que aquí he expuesto) sin haber sido detenida, Windows lanzará el citado programa, y le pasará un manejador al proceso que está fallando, aparte de detener por completo la ejecución de todos sus hilos (en XP sólo se detenía el que fallaba) mediante unas APIs ALPC no documentadas.

Este programa, en base a algunas claves del registro, hará una cosa u otra. Como ha recibido los manejadores en modo heredado, tendrá control sobre el programa que está fallando. Aparte de añadir el evento correspondiente, podrá enviar el informe a Microsoft, o añadirlo a la lista de pendientes. Incluso existe la posibilidad de que ni siquiera aparezca, haciendo todas sus tareas de forma oculta, o incluso que no haga ninguna. Podemos incluso filtrar el comportamiento según qué aplicación haya fallado.

Después de que ha hecho sus tareas internas, si existe algún depurador registrado y si la configuración (o lo que hayamos elegido) lo permite, abrirá el programa vsjitdebugger.exe que mostrará los depuradores registrados. De nuevo este programa recibe los manejadores de forma heredada, y mientras, nuestra aplicación está completamente muerta, esperando. Una vez que hemos elegido un depurador, éste será ejecutado pasando, otra vez, la información necesaria para que sea capaz de buscar y localizar la aplicación que ha fallado.

Es entonces cuando ésta se abrirá dentro del depurador, y si están disponibles los símbolos y demás, podremos ver qué ha fallado y por qué.

Si os fijáis, el tema no es sencillo ni de lejos. En primer lugar, el programa fallante no puede hacer nada porque podría estar en un estado indeterminado, con la memoria o la pila completamente corruptas, así que es el sistema operativo el que debe tomar el control y lanzar una nueva aplicación que se encargue de todo el paripé, que a su vez lanzará un depurador que no es tal, sino un concentrador de depuradores, que al final sí, lanzará el depurador elegido, que tomará bajo su ala a nuestro programa petado.

¿Os dais cuenta lo complejo que es algo que asumimos de forma inconsciente como trivial? Pues no todo termina ahí, sino que es ahora el depurador el que debe meter las garras dentro de la aplicación defectuosa, insertándose en su espacio de direcciones de alguna manera.

Para finalizar, comentaros que esto no es más que un resumen de los capítulos 23, 24 y 25 de Windows via C/C++, quinta edición.

El loco de la colina y las colinas locas (Sobre el SP1 del Vista)

Rafael Ontivero — Sat, 01 Mar 2008 14:14:24 GMT

Ya sé que últimamente no abundan los contenidos técnicos por aquí, pero estoy laboralmente muy ocupado y el tiempo libre que tengo lo paso leyendo y relajándome, imagino que de aquí a un mes volveré a estar más libre… Eso o estaré en paro, ya que no me gusta absolutamente nada la dinámica que está tomando mi curro, con salidas a toda España a reparar máquinas de las que no entiendo ni quiero entender y que ya de por sí su comprensión suponen un oficio en sí mismo.

Pero hoy no voy a hablar de mí, sino de Microsoft y sus últimas pifias. Ahora como MVP tengo línea directa, pero a fin de cuentas es como si no la tuviera, ya que por lo menos a mi no me hacen ni p*to caso. Y a veces son cosas muy serias, como las del final de esta entrada.

Visual Studio 2008
Quien tenga una subscripción a la MSDN lo habrá podido descargar más o menos desde noviembre del año pasado, así que debe estar bastante familiarizado con él. En mi caso no le encuentro ninguna pega destacable. Aunque tampoco es que le haya dado mucha caña: una pequeña aplicación en C#, dos tonterías en MFC y sí una espuerta de DLLs en Win32. Y si fallara haciendo DLLs pues ya sería la rehostia…

Estooooo… ¿Digo que no falla? Pues sí que falla, o mejor dicho fallaba. Y no sé cómo lo han actualizado, pero lo han hecho. Si uno crea un proyecto con una DLL nativa, y usa esa DLL nativa en otro proyecto dentro de la misma solución, el linker revienta a la hora de enlazar. Es muy curioso, porque solo revienta justo después de reiniciar Windows, y sólo en Vista. O en otras palabras: la primera compilación parcial tras un reinicio hace que el linker genere un error interno. Curioso, ¿no?

Pues tras informar del error (yo fui el primero, luego comenzó a pasarle a más gente), lo han solucionado. ¿Cómo? Pues no lo sé. El Visual Studio no lo han actualizado, así que ha debido ser una actualización secreta de esas que no te dicen nada o junto a alguna actualización del propio Windows.

Decir que está actualizado es mucho afirmar, más bien el problema queda minimizado y sólo ocurre con muy poca frecuencia, tan poca que apenas es molesto.

Más Visual Studio 2008 y el SDK 6.1
Otra, esta algo más grande. Hay dos nuevos Windows SDK, ambos con la versión 6.1. Uno para Vista SP1 y otro para Windows Server 2008. El que trae el Visual Studio es la versión 6.0A.

¿Los ha instalado alguien? ¿En Vista x64, con o sin SP1? No hace falta que lo hagáis, ya que si bien se instalan perfectamente, cuando utilizamos el nuevo “Windows SDK Configuration Tool” para cambiarle al VS2008 el SDK activo, lo rompe y lo deja incapaz de compilar; en el caso del SDK de Vista, ya no es posible crear aplicaciones en C++/CLI, y en el caso del de Windows Server, nativas. Tras comprobar que la instalación del SDK del Server falló, y un par de cuelgues duros de Vista durante la reinstalación, al final el problema que presenta el SDK del Server es el mismo que el del Vista.

Tampoco vale la pena que utilices dicha herramienta para volver al status anterior: El Visual Studio 2008 ya no te volverá a funcionar a no ser que desinstales los SDK (menos mal).

¿Solución? Ninguna. Silencio administrativo.

Windows Vista SP1
Antes de la salida pública del SP1 los suscriptores a la MSDN también tienen acceso a dicho Service Pack. Ciertamente pagar una suscripción a la MSDN cada vez tiene menos sentido, sobre todo las caras, ya que MS va liberando poco a poco casi todo lo que antes costaba dinero o tenías que ser un Partner para obtenerlo. Como consecuencia de ello, los subscriptores pusieron el grito en el cielo y al poco se permitió la descarga del SP1. Decir que tampoco a los MVP que no fueran betatester del propio SP1 nos dieron acceso a él…

Pues bien, tras estar un par de semanas con él instalado de forma limpia, es decir, instalas el Vista, luego el SP1 y sigues con todo lo demás, ya que los chicos de las altas esferas han decidido que no se pueda crear un CD integrado, mis conclusiones no podrían ser más pésimas. Vamos allá.

Windows Mail. Si antes del SP1 era pésimo, después de él sigue siéndolo. Es decir, los parpadeos continúan, los autismos también, y en general los problemas de que adolece se siguen presentando de igual forma, aunque con un, digamos, 10% menos de frecuencia.

Arranque y apagado. Ninguna mejora. Tarda la misma eternidad en arrancar y parar, y durante el arranque sigues dejando de tener todo funcional hasta pasado un buen rato después del que te muestre el escritorio.

Autismos varios. Es decir, esas congelaciones que se producen en ciertas aplicaciones se vienen produciendo con algo menos de frecuencia, pero siguen pasando.

Otros. Parece ser que sí que han mejorado algo la I/O por prioridades, y ahora copia y mueve archivos mucho más rápido, pero siguen los autismos en cuanto a arrastrar y soltar. El IE se sigue cayendo solo igual que antes, el explorador sigue sin recordar posiciones ni ciertas configuraciones y en general, salvo la copia, la gestión de archivos sigue siendo tan mala que antes, lo que me lleva al siguiente punto.

No se copian ni mueven todos los ficheros
Pues lo dicho. Así que ojito con copiar y luego borrar el original sin comprobar la copia. Me da igual que se deba a los hooks de terceros o a lo que sea. Es completamente inaceptable. Ni siquiera Linux en sus peores días hacía eso.

Antes del SP1 experimenté el problema de dos formas distintas. En la primera, al mover ficheros, en el origen quedaban restos que si bien se habían copiado, no se habían borrado. En la segunda, al borrar ficheros, me pasaba lo mismo, pues supuse que se debía a que alguien bloqueaba el fichero y se olvidaba de liberarlo, ya que la única forma de poderlos borrar era saliendo y volviendo a entrar en la sesión. Como eran ficheros que no se habían visto en ningún momento, el candidato que generaba el problema debía ser el propio Vista.

Después de eso otro MVP comentó que le parecía que le había fallado la copia, pero no estaba seguro de ello.

Y yo me quedé con la mosca detrás de la oreja… Después instalé el SP1, y observé el problema que cuento en la sección siguiente (que ya es el súmmum de todo), por lo que procedí a limpiar la unidad…

¿Imaginan? Pues se quedaron ficheros sin mover. Bien es cierto que eran ficheros ocultos y de sólo lectura, pero otros ocultos y de sólo lectura se movieron, así que ese no era el motivo. Un arrastrar y soltar los copió, pero el problema está ahí.

Y vayamos al apoteósico final.

Particiones sucia
Tengo una partición con la que trabajo todos los días, donde está el código fuente de la empresa, almacenes de correo y demás. El System Restore está deshabilitado globalmente. La unidad es NTFS formateada desde la misma instalación. Pues bien, de 11 GB de datos que hay (datos en disco, teniendo en cuenta el tamaño del cluster), en el disco hay realmente más de 20 GB. Tras borrar todo lo del disco, me seguían quedando esos 10 GB ocupados, o sea, que son basuras que deja el Vista, ya que a nivel de usuario no queda nada. Activando mostrar ficheros ocultos por el sistema operativo, tomo posesión de "System Volume Information" y veo un montón de archivos con nombres de GUIID con tamaños de entre varios cientos de megas y gigas... Y de repente, antes de que me dé tiempo de mirarlos, ¡desaparecen! y la unidad se queda como debería haber estado en un primer momento.

¿Qué se oculta ahí? ¿Por qué desaparecen esos ficheros nada más verlos? ¿Qué son esos restos (el system restore no puede ser ya que está desactivado) que Vista no quiere que tengamos acceso a ellos?

Me hubiera gustado haber recibido una respuesta oficial, creíble y documentada. Pero no fue así. Silencio administrativo.

¿Por qué roba Vista ese espacio en disco?

Podría ser un resto del shadow copy de la copia de seguridad del propio Vista: en ese caso, chapuzas dobles y triples. Nunca los programas de copia de seguridad que han acompañado al sistema operativo han sido buenos, pero llegar hasta ese punto... Es decir, tengo programado el Backup del Vista para que haga copia de esa unidad sobre otra, si son los restos de la preparación del shadow, lo dicho.

Podría ser que aunque se ha desactivado globalmente el System Restore, Vista pasara olímpicamente de nosotros e hiciera copias... en una unidad que nunca lo ha tenido activado. Aquí entraríamos en cuestiones de otro tipo, como las actualizaciones ocultas que se instalan de forma oculta aunque las tengas desactivadas... lo que me parece un punto de soberbia, prepotencia y abuso de poder completamente intolerable...

No se me ocurren otras posibles causas, y las que se me ocurren mejor no mencionarlas (qué casualidad que sólo pase en la única partición en la que hay código fuente...) etc.

El tema es que han pasado unos días y ya tengo otra vez la partición con 5 gigas de basura… Pero esta vez no se me escapan…

Eso será después de que instale XP.