Destierro de 32 Bits

C:\>RUN\DOS\RUN>

Esta es la continuación de la entrada anterior titulada “Revolución de 32 Bits”.

La última nota trató sobre el como las PC’s equipadas con procesadores 386 y superiores abandonaron lentamente la programación en 16 bits para dar paso a aplicaciones mas avanzadas de 32 bits. Y como el mundo tuvo que esperar casi 10 años para ver juegos que realmente aprovecharan el hardware de estos entonces poderosos equipos. En esta parte de la historia se cuentan unos años horribles en los que llegué a pensar que era el fin de la programación en Ensamblador para computadora personales.

Corrían los últimos años del siglo veinte, poco a poco las conexiones de tipo Dial Up se volvían inoperantes y los primeros monitores LCD (de esos que si uno no estaba parado directamente de frente a ellos no se veían) comenzaban a aparecer. Esa era una época maravillosa en la que el DOS y el Windows 95 cohabitaban en la misma computadora y existía la controversia de que tanto uno dependía del otro. Tiempos en que el Windows NT solo existía en equipos empresariales y aunque era muy estable no servía para jugar. En ese tiempo aún había juegos que para jugarlos adecuadamente había que salirse del Windows. Pues correrlos desde dentro de este sistema, aunque era posible disminuían severamente su desempeño. La razón de esto era el Modo Virtual 86

Modo Virtual 86

Las computadoras de 32 bits (no recuerdo de momento a partir de que CPU) tenían una modalidad interesante de operación llamada Virtual 86 Mode, en que podían imitar no solo uno, sino a una multitud de sistemas de 16 bits y ejecutarlos como una subtarea independiente. De este modo era posible correr al mismo tiempo varias instancias del DOS con sus respectivas aplicaciones sin por ello salirse del Modo Protegido. Esto le dio mucha vida artificial a estas viejas aplicaciones aún a pesar de que hacía mucho tiempo que los CPU’s 8086 habían dejado de fabricarse. Sin embargo, cuando una aplicación de Modo Real trataba de inicializar el Modo Protegido desde el Modo Virtual 86 pasaban errores muy feos, como el Famosísimo Fallo de protección General, Ejecución de instrucciones privilegiadas, fallos de página y otras cosas peores cuya única solución casi siempre era un reset de la computadora completa. Eso sin mencionar que aunque esto no ocurrirera, uno solo tenía acceso a una minúscula fracción del poder de procesamiento y memoria del sistema. Por lo que las aplicaciones de 16 bits ejecutadas en el Modo Virtual 86 rara vez daban buenos resultados. Aunque siempre estaba la opción de reiniciar la computadora en modo MS-DOS.

¿Qué estaba haciendo Bill Gates mientras tanto?

Resulta que en su diseño original, Windows no estaba preparado para suministrar lo necesario para hacer buenos juegos. Su GDI (Graphics Device Interface) estaba pensada con la seguridad en mente y no en el alto desempeño que los juegos requieren. Por lo que, y esto lo leí en viejos libros de historia, intentaron hacer una biblioteca de funciones de 32 bits desde al menos el windows 3.1. Dicha mejora era conocida como WinG pero no tuvo la aceptación esperada y los buenos juegos siguieron corriendo en Modo Protegido desde MS-DOS con ayuda de los Dos Extenders. Sin embargo, un poco mas adelante, Bill Gates finalmente aceptó que la única manera de lograr que los buenos juegos fueran desarrollados para Windows era dándo un acceso mucho mas DIRECT-o al hardware.

Inicios del DirectX.

Antes de entrar en detalle, hay que explicar primero el concepto de Overhead. Como en su origen las computadoras personales tenían muy pocos componentes realmente estandar aparte de un CPU Intel o compatible, era muy común crear capaz de delegación intermedia para facilitar la comunicación entre los dispositivos mas dispares sin cambiar los códigos originales. Por ejemplo, en tiempos del DOS, si uno quería escribir un pixel en pantalla primero tenía que llamar una función de la biblioteca de gráficos de C llamaba BGI(o cualquier otra biblioteca de gráficos) llamada putpixel(); que recibía las coordenadas X, Y y el color. Esta a su vez llamaba al sistema operativo para dar la órden de pintar el pixel, luego el sistema operativo llamaba al BIOS que ejecutaba la interrupción 10h y luego de hacer una complicada y tardada serie de validaciones al fin escribía el mentado puntito de color en la pantalla. Este proceso era tan lento que uno podía hacer un ciclo anidado para pintar la pantalla y podía ver como esta cambiaba de color lentamente. ¡Y pintar una pantalla completa de 320 por 200 tardaba casi un minuto!. Sin embargo, con ensamblador bastaba con conocer la posición de la RAM de Video y escribir un pixel era tan rápido como mover un byte a una posición de memoria. Eso sin contar que existían muchos recursos para manejar la tarjeta de video para hacer animaciones rápidas (de momento recuerdo por lo menos tres). El asunto era como dar acceso a los programadores a esta velocidad sin necesidad de salir del Windows. Y fue así como nació DirectX

Como su nombre lo indica, la idea original tras el DirectX era darle a los programadores el acceso mas directo posible al Hardware sin comprometer la protección de memoria del propio Windows. Mientras que intentaban ahogar los problemas de compatibilidad de hardware con capas de abstracción y emulación de hardware. Al principio DirectX fue un fracaso, pero no tanto porque fuera una mala idea, sino porque la mayor parte de los recursos del sistema estaban siendo usadas por el resto de las aplicaciones. No fue sino hasta la aparición del DirectX 5 que se empezaron a ver juegos para Windows mas o menos decentes. En ese entonces, los juegos de 32 bits soportados en los DOS Extenders ya comenzaban a oler a muerto.

C:\RUN\DOS\RUN>

Los vaqueros del viejo oeste solían decir que no había mejor indio que el indio muerto, y yo digo que el mejor de todos los Windows fue el Windows 98 SE, pues permitía explotar un sistema Pentium III a plena capacidad con todo y sus puertos USB en menos de 30 megas. Además de ser muy estable y ser el último que tenía la opción de reiniciar en Modo MS-DOS. Con un sistema como este fue que mi grupo de desarrolladores renegados aprendimos una buena cantidad de cosas sobre computación. Sin embargo. Sin embargo, con la llegada del temido Windows NT y sus derivados a las computadoras caseras, esta maravillosa era terminó. No mas juegos de 32 bits que tomaban el control absoluto del sistema. De hecho, en esa época, mientras jugaba el juego Hexen en una PC Pentium III con Windows ME apareció una pantalla sobre un error en algo llamado WinOldAp. De acuerdo con una poca de investigación, Winoldap era un servicio del sistema operativo que permitía correr aplicaciones de la época descrita en la entrada anterior “Revolución de 32 Bits” en este caso me enteré de que estaba muerto hasta que el mismo Windows me lo había informado.

…llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras…

Por cierto, y hablando del Windows ME, fue a partir de esta versión del sistema operativo de Micro$oft que la feliz armonía entre el Windows y los programadores de juegos que usaban Dos Extenders (o que entraban al modo protegido por su cuenta) se acabó. A partir del Windows 2000 y el ME ya no había manera de salirse del Windows y tomar el control absoluto del sistema como antes. Recuerdo que hubo una pequeña guerra entre mi grupo de amigos programadores por que sistema instalar en nuestras computadoras. Pues un sistema posterior al Windows 98 no nos permitía programar como lo habíamos hecho hasta entonces. Y la peor parte es que todas las herramientas para desarrollo en Windows eran inadmisibles dados nuestros métodos de trabajo. Llegó un momento en que llegamos a creer que ese era el fin de la programación en Ensamblador para computadoras caseras por lo que, como abandonar la programación en ASM no era una opción decidimos hacer lo mejor que se nos ocurrió: ¡Programar en Ensamblador para otras plataformas! Aunque eso significara crear la nuestra propia.

Y en ese entonces fue cuando se dio nuestro destierro de la programación en Ensamblador para computadoras caseras. Aunque en ese tiempo hicimos muchos avances en otras áreas relacionadas con el Ensamblador que se mencionarán en la siguiente entrada. Pero eso no nos salvó de experiencias terribles que poco a poco fueron debilitando al equipo aunque sin llegar a acabar con él por completo.

En la siguiente entrada se contará de que fue de la programación en Ensamblador (o al menos la parte que me tocó vivir) durante los primeros años del presente siglo y como gracias a los esfuerzos de grandes hackers como Iczelion y otros cuyos seudónimos no alcanzo a recordar los programadores de Ensamblador pudimos regresar a la escena de la computación casera de la que alguna vez nos sentimos desterrados. Pero entre ese tiempo, muchos de nosotros nos convertimos en poco menos que vagabundos y esos oscuros años son los que se narrarán mas adelante.