Un perro contra el stack gráfico de Windows 3.1

• Al intentar usar Windows 3.11 en una pantalla de 1024x600 en una Asus Eee PC 1000H de 2008, quedaron en evidencia las limitaciones del VGA básico y del controlador Super VGA de 256 colores de Microsoft
• El soporte Super VGA en Windows 3.x no estaba basado en un estándar común, sino en extensiones propietarias según cada tarjeta, y la Intel GMA 950 de la Eee PC no era una de las compatibles
• SVGAPatch modifica svga256.drv de Microsoft para usar llamadas VBE y permitir salida de 256 colores en alta resolución, pero seguía habiendo corrupción visual al volver de la pantalla de DOS a la GUI
• El análisis inverso mostró que la configuración inicial del modo sí se había cambiado a VBE, pero la ruta de reinicialización durante los cambios de pantalla seguía llamando al modo 30h para Tseng ET4000 y a la configuración VBE de scan line desde estado de text mode
• Con un parche adicional se redujo la corrupción al volver de sesiones DOS en pantalla completa a la GUI, aunque el estado de bank switching no quedó completamente resuelto, así que en la Eee PC real solo se logró una recuperación funcional de la GUI y del modo ventana

---

Reviviendo los gráficos de Windows 3.11 en una Eee PC

• El equipo objetivo es una Asus Eee PC 1000H comprada en 2008, que hoy tiene dificultades para ejecutar incluso distribuciones modernas de Linux por la falta de soporte x86_64
• El objetivo era ejecutar Windows 3.11 for Workgroups en esta netbook con una mejor salida de video
• La salida básica era VGA 640x480 de 16 colores, así que en una pantalla de 1024x600 no se veía bien y además no coincidía con la relación de aspecto
• El instalador de Windows 3.11 incluye controladores para adaptadores de video antiguos, pero no soporta la Intel GMA 950 de la Eee PC
• El controlador Super VGA incluido parece soportar hasta 1024x768 en 256 colores, pero en este entorno da error y Windows no inicia

Diferencias entre VGA, SVGA y VBE

• VGA es un controlador de video específico diseñado por IBM en los años 80; no significa simplemente un conector analógico azul ni una resolución de 640x480
• SVGA era menos un estándar y más una forma de agrupar “lo que va más allá del VGA básico”, por lo que el software tenía que soportar directamente las extensiones propietarias de cada tarjeta
• La lista de compatibilidad del controlador SVGA de 256 colores de Microsoft incluye estas familias
  • ATI VGA series
  • Cirrus Logic VGA
  • Oak Technology VGA
  • Paradise VGA
  • Trident VGA
  • Tseng VGA
  • Video Seven VGA
  • Western Digital VGA
• VBE (VESA BIOS Extensions) permite manejar funciones fuera de VGA mediante una interfaz común, pero Windows 3.x no incluía un controlador VBE directo
• VBE9x y VBEMP de BearWindows permiten usar VBE en Windows 9x y NT respectivamente, pero no existe una versión para Windows 3.x

Qué resolvió SVGAPatch y qué dejó pendiente

• SVGAPatch parchea el controlador Super VGA de 256 colores de Microsoft para que use VBE
• El controlador parcheado puede mostrar correctamente pantallas como 1024x600, pero aparecen conflictos de compatibilidad con DOS
• El modo Enhanced de Windows 3.1 puede ejecutar apps gráficas de Windows y aplicaciones DOS al mismo tiempo, y también abrir el símbolo de DOS en ventana o en pantalla completa
• Después de aplicar SVGAPatch se reproducen estos problemas
  • Al entrar al modo DOS en pantalla completa y volver a la GUI de Windows, la pantalla se corrompe
  • En algunos casos, basta con abrir un símbolo de DOS en ventana para que la pantalla se corrompa
  • Ocurre en DOSBox, 86Box y en una Eee PC real, aunque la forma de la corrupción varía un poco
• Un controlador nuevo aparte, PluMGMK/vbesvga.drv, incluso soporta modos true color, pero aquí el análisis se enfocó en corregir el código de Microsoft y SVGAPatch

Estructura del stack gráfico de Windows 3.x

• El modo Enhanced de Windows 3.x usa un Virtual Machine Manager de 32 bits en modo protegido que crea varias VM, y dentro de la primera VM corre Windows en modo Standard
• Cuando se elige un adaptador de video en Windows Setup, no se instala un solo controlador sino varios componentes juntos
  • Grabber: aparentemente se encarga del renderizado de apps DOS en modo ventana
  • Display Driver: se encarga de la inicialización del hardware y del renderizado de la GUI dentro de la VM principal de Windows; en Windows 3.x también implementa buena parte del GDI por su cuenta
  • Virtual Display Device (VDD): corre como parte del Virtual Machine Manager y multiplexa el acceso entre las apps DOS y el hardware VGA real
• Las entradas SVGA de 256 colores usan el mismo controlador y se distinguen por la resolución y el DPI en SYSTEM.INI
• SVGAPatch solo modifica el Display Driver y no toca el VDD de SVGA
• Al final, para acotar la causa de la corrupción visual, fue necesario entender juntos el Display Driver, el VDD y los cambios privados que introduce SVGAPatch

Materiales y herramientas usados en el análisis inverso

• Como referencias se usaron Windows 3.x VDDVGA y Windows 3.1 DDK
• El Windows 3.1 DDK incluye el siguiente código fuente
  • código fuente de Display Driver para VGA, IBM 8514, Video 7 y SVGA de 16 colores
  • código fuente de VDD para VGA, IBM 8514, Video 7 y SVGA de 16 colores
  • código fuente de casi todos los Grabber
  • muy poca documentación
• Justamente el Display Driver SVGA de 256 colores y el código fuente del VDD relacionado no están incluidos
• Para analizar svga256.drv y vddsvga.386 se usaron IDA y Ghidra
• Ghidra podía leer .drv, pero para el VDD hacía falta un cargador LX aparte por tratarse de un VxD, y además tenía limitaciones para manejar archivos con código mixto de 32 y 16 bits

Análisis interno de svga256.drv

• svga256.drv exporta funciones como GETCHARWIDTH, STRETCHBLT y VIDEOINIT_ATI, lo que permitió compararlo con el código fuente del DDK
• Algunas funciones eran casi iguales al código del controlador VGA, aunque había diferencias como la ausencia de la corrección de ancho para bold font en GETCHARWIDTH
• En REALIZEOBJECT aparecían diferencias que parecían mezclar código del controlador VGA y del controlador Video 7, y también cambiaba la lógica de manejo de color
• Como solo con las funciones GDI no alcanzaba para explicar la interacción con el adaptador de video, el análisis continuó por la ruta de inicialización: physical_enable

physical_enable y el enfoque del controlador SVGA de Microsoft

• Si en Windows Setup se selecciona “Super VGA (800x600, 256 colours, small fonts)”, SYSTEM.INI recibe estos valores
  • dpi=96
  • resolution=2
• Después de arrancar, el controlador parcheado además escribe estos valores
  • svgamode=48
  • ChipSet=Tseng ET4000
  • LatchCapable=No
• physical_enable es la función clave de inicialización que configura el modo de video y recorre la lista de modos soportados hasta encontrar uno funcional para algún chipset
• La lógica original de Microsoft tiene tablas de modos soportados por resolución y prueba cada modo con SetAndValidateMode
• Cuando tiene éxito, busca y llama la función de inicialización específica del chipset, la función de cambio de bank y otras más; luego sigue con la configuración de la paleta, la inicialización del framebuffer y la configuración de direcciones para el VDD

Los cambios reales que hace SVGAPatch

• SVGAPatch cambia el ID de función del primer chipset en tres listas de resolución a 2000 y sobrescribe SetAndValidateMode junto con algunas funciones específicas por chipset
• Los cambios clave son estos
  • SetAndValidateMode: en vez de configurar el modo con el BIOS VGA tradicional, solicita un modo de video extendido mediante VBE 4F02h
  • SETBANK_TRIDENT: en vez de escribir registros propios de Trident, mueve la ventana de memoria de video mediante VBE 4F05h
  • VIDEOINIT_TRIDENT: en vez de escribir el VGA CRTC Offset Register, configura la longitud de scan line con VBE 4F06h
• Después del parche, el primer elemento de la lista de modos soportados es el que tiene éxito, y se usan las funciones reescritas ligadas al ID 2000
• La razón por la que SYSTEM.INI guarda valores de Tseng ET4000 es que el nombre del primer elemento de la lista se sigue almacenando aunque ese valor en realidad ya no se use

El VDD y DspDrvr_Addresses

• El VDD virtualiza situaciones en las que los programas DOS asumen que tienen acceso exclusivo al hardware real
• Cada VM tiene una instancia de la estructura VDD_CB_Struc, que contiene flags, espejos del estado del controlador VGA e información sobre la asignación de memoria de video por VM
• El VDD contiene código específico por fabricante para detectar ciertos adaptadores VGA y cambiar cómo se guardan, restauran o simulan determinados registros
• DspDrvr_Addresses es un servicio mediante el cual el Display Driver pasa información de direcciones al VDD; según los comentarios, DX es un campo reservado y debería ser 0, pero el código real del VDD VGA tiene un comportamiento especial cuando DX no es 0
• En el VDD SVGA hay una ruta nueva para DX == 2, y SVGA256.DRV llama esta función con estos valores
  • BX = 0xFFFF
  • DX = 2
  • DS:SI apunta a un byte de estado de shadow memory

Acotando la causa con DOSBox-X

• Se usaron el Video debug overlay y el depurador de DOSBox-X para comparar el estado VGA antes y después de cambiar hacia y desde el símbolo de DOS en pantalla completa
• El modo anotado y el estado de los registros diferían entre una GUI normal, un DOS normal, una GUI corrupta y un DOS corrupto
• Para verificar si algún flag específico del VDD por fabricante se activaba por error, se modificó DOSBox-X para volcar la memoria física, pero en DOSBox ese flag no estaba activado
• Al comparar registros VGA, el valor interno scan_len de DOSBox difería entre estados sanos y corruptos
  • en DOS normal: 40
  • en DOS corrupto: 296
  • en GUI normal: 128
  • en GUI corrupta: 256
• La implementación del API VESA Scan Line en DOSBox calcula scan_len de forma distinta según cómo interprete el modo de video actual, y ese punto quedó como principal sospechoso

La pista decisiva: configurar VBE scan line en text mode

• Al agregar registros de log para la configuración de VESA scan line en DOSBox-X, apareció esta llamada
  • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
  • el modo actual era M_TEXT
• El Display Driver configura la longitud de scan line en 1024 bytes mediante VBE 4F06h, pero DOSBox cree que sigue en text mode, así que su estado interno se calcula mal
• Durante el arranque de Windows, la configuración de scan line se hace correctamente con SVGA 800x600 y estado M_LIN8
• Al abrir un símbolo de DOS en pantalla completa y luego volver a la GUI con Alt+Enter, ocurre este flujo
  • algún código solicita cambiar al modo 30h, es decir, 48 decimal
  • el display driver parcheado configura la longitud de scan line mientras sigue en text mode
  • el estado interno de DOSBox deja de coincidir con el estado derivado de los registros VGA
• El modo 30h era el valor de modo 800x600 del Tseng ET4000 secuestrado por SVGAPatch

La ruta de cambio de pantalla que faltaba

• El Display Driver de Windows 3.1 hace hook de INT 2Fh para recibir comandos de cambio de pantalla
• El controlador VGA maneja estos cuatro comandos, pero el controlador SVGA256 solo soporta SCREEN_SWITCH_OUT y SCREEN_SWITCH_IN
  • SCREEN_SWITCH_OUT
  • SCREEN_SWITCH_IN
  • SAVE_DEV_REGS
  • RES_DEV_REGS
• La función problemática era dev_to_foreground, llamada al volver a la GUI de Windows
• El flujo de dev_to_foreground en SVGA256 es el siguiente
  • llama a farsetmode
  • farsetmode configura el modo 48
  • llama al VideoInit específico del chipset
  • pone enabled_flag en 0xFF
  • llama a la API de Windows SetPalette
• SVGAPatch cambió la ruta de configuración de modo durante la inicialización, pero no cambió la ruta que vuelve a configurar el modo durante los cambios de pantalla

Mejoras en la recuperación de la GUI con un parche adicional

• El código original de setmode era una secuencia corta que cargaba wGraphicsMode en ax, llamaba a INT 10h y luego llamaba a ptr_videoinit
• En el espacio sobrante detrás de SetAndValidateMode, acortado por SVGAPatch, se insertó código nuevo
  • cargar en cx el valor de CurrentHeight menos 1
  • llamar a SetAndValidateMode
  • llamar a ptr_videoinit
• Luego se cambió la primera instrucción de setmode para que saltara al nuevo código, forzando que también durante los cambios de pantalla se use la ruta de configuración de modo basada en VBE
• Después de esta modificación, ya no se corrompía la pantalla al entrar a una sesión DOS en pantalla completa y volver a la GUI
• Aun así, seguía apareciendo el problema de puntos al pasar de modo ventana a pantalla completa

El problema restante de bank switching

• En el depurador de DOSBox, al mirar la memoria VGA B8000, el texto estaba presente, pero no se veía en pantalla
• La principal sospecha pasó a ser el bank switching que usa el controlador para acceder a más memoria de video
• Tras agregar a DOSBox-X un comando para mostrar el estado del bank SVGA, se confirmó que al volver a pantalla completa el adaptador VGA quedaba en el bank equivocado
• Se agregó una rutina nueva en dev_to_background para intentar restaurar el bank a 0, pero no solucionó el problema
• La implementación de VBE 4F05h en DOSBox escribe en el registro VGA CRTC 0x6A, y cuando se llama a dev_to_background, el VDD ya está atrapando las escrituras, así que era demasiado tarde

Resultados de pruebas con el controlador original y el parcheado

• En 86Box, al probar el controlador SVGA original de Microsoft de 256 colores con varias tarjetas emuladas, incluso entre las oficialmente soportadas los resultados fueron irregulares
  • Cirrus Logic GD5420 (ISA): funciona
  • Tseng Labs ET4000AX: funciona
  • Oak OTI-077: corrupción al abrir por primera vez un símbolo de DOS en ventana y líneas verticales en pantalla completa
  • Trident TVGA 8900D: corrupción en el símbolo de DOS en pantalla completa, pero modo ventana normal
  • ATI VGA Wonder XL, Paradise PVGA1A y algunas resoluciones de Video 7 VGA 1024i: Windows no inicia
• También hay que tener en cuenta que 86Box no ofrece exactamente las mismas tarjetas y la precisión de la emulación no está garantizada
• Al probar el controlador modificado basado en SVGAPatch con tarjetas más nuevas, los resultados también variaron según la tarjeta
  • Matrox Millennium II: muy lento; DOS en ventana funciona, pero pantalla completa se corrompe
  • 3dfx Voodoo Banshee: al abrir DOS en ventana se corrompe la GUI, pero el cambio a pantalla completa sí funciona
  • S3 Trio3D/2X: Windows arranca con la pantalla corrupta, pero después de abrir un símbolo de DOS y salir de pantalla completa, 1024x768 se muestra correctamente
  • 3dfx Voodoo3 3500 SI: similar a Banshee, pero la pantalla completa solo funciona una vez

Estado final en la Eee PC

• En la Eee PC real, la GUI funciona normalmente
• El cambio al símbolo de DOS en pantalla completa sigue corrompiéndose, aunque de una forma distinta a DOSBox
• En DOSBox aparecía un text mode con muchos caracteres corruptos, mientras que en la Eee PC aparecía una GUI corrupta con algunos colores ausentes
• Se puede recuperar al volver al modo ventana
• Con SVGAPatch original, bastaba abrir un símbolo en ventana para que se corrompiera toda la GUI y hubiera que reiniciar el sistema, pero el controlador modificado mejora mucho esa situación
• Como solución más prometedora, se optó por seguir de cerca el desarrollo activo de PluMGMK/vbesvga.drv

[GN⁺]

Opiniones de Hacker News

• Dejando aparte el soporte para SVGA, siempre me sorprende que si instalas Windows 3.x en una PC compatible con estándares modernos, el VGA básico funciona de inmediato, mientras que en Linux/BSD modernos, sin el driver correcto y archivos de configuración manuales, ni siquiera es fácil usar en Xorg/Wayland un framebuffer VGA básico con aceleración por software.
  El difunto proyecto XFree86 fue el intento que más se acercó a ese “simplemente funciona”, pero aún le faltaba mucho, y parece que ese enfoque no se conservó en el fork Xorg.

  • XFree86 tampoco hacía aquí nada distinto de Xorg.
    Si arrancas una PC moderna con CSM, aunque no sea recomendable, Xorg debería ejecutar el BIOS de video con x86emu y levantarse con el backend VBE; si arrancas con EFI, debería levantarse modesetting basado en efifb sobre el modo que dejaron el firmware y el bootloader.
    Pero esto es más fácil para sistemas operativos de 16 o 32 bits. La configuración de modos VESA requiere llamadas de 16 bits en modo real y, aunque hacia el final del estándar existía nominalmente un punto de entrada de 32 bits, casi nadie lo implementó bien. Cuando entras en modo de 64 bits no puedes usar vm86, así que no puedes llamar código de 16 bits desde el espacio de usuario; por eso se necesita x86emu, que lee el código del BIOS de video y lo ejecuta en un emulador x86, aunque no siempre es perfecto.
  • En Linux existen vgafb/vesafb, así que es posible si la distribución está configurada adecuadamente.
    Pero normalmente termina siendo una experiencia de bajo rendimiento y calidad, y el usuario puede no saber la causa, así que parece que algunas o la mayoría de las distribuciones no lo activan por defecto. Hoy casi todas las GPU tienen soporte nativo, así que probablemente tampoco hubo mucho incentivo para crear un popup que dijera “estás usando VGA/VESA sin aceleración, arréglalo”.
  • Es algo de hace mucho tiempo, pero recuerdo que en X había un driver VGA genérico que “simplemente funcionaba”. ¿Quieren decir que ya no existe?
  • X11 tuvo desde hace mucho un driver VESA, pero la cantidad de píxeles a procesar aumenta rápidamente con la resolución, así que escala mal en rendimiento.
    Las distribuciones Linux booteables que uso en el trabajo, principalmente GRML y Clonezilla, con soporte KMS se ajustan automáticamente durante el arranque a la pantalla o a la resolución nativa del KVM virtual, y funcionan bastante bien. Anaconda, es decir, el instalador de la familia RedHat, y el instalador de Debian también se ajustan a la resolución nativa al arrancar.
    Los instaladores con GUI usan VESA directamente sobre X11.
    El fork Xorg también soporta desde hace mucho el “arranque sin archivo de configuración”. Hace muchísimo que no administro archivos de configuración, y eso es mucho más satisfactorio. Ver https://www.xkcd.com/963/.
  • Veo a Xorg básicamente como XFree86 con el sistema de compilación ordenado.

• La antigua GUI de Windows 3.1 parece mucho más intuitiva, eficiente y agradable de usar que las actuales.
  https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
  ¿Cómo se verá Win11 en una pantalla de baja resolución como la del artículo? El menú Inicio de Win11 es casi inutilizable, salvo escribir una palabra clave y rezarle al circuito.
  Como hipótesis ingenua, Windows NT y 2000 fueron el punto óptimo, y después de eso los product managers han estado haciendo magia. KDE y Gnome no cambiaron demasiado, pero con el tiempo se ven cada vez más atractivos :)

  • Creo que la última versión “buena” fue Windows 7. Era parecido a NT/2000, pero más bonito gracias a las mejoras del hardware gráfico; y lo mismo aplicaba al XP anterior. Vista también tenía una UI decente; sus defectos estaban en otra parte.
    Windows 8 lo arruinó todo y Windows no logró recuperarse. Creo que las razones fueron dos: el auge de las plataformas móviles y la pereza de Microsoft.
    Ahora existe el problema difícil de resolver de que muchas apps tienen una versión de escritorio y otra móvil. Una es para pantalla grande con teclado y mouse; la otra, para una pantalla táctil pequeña, así que una buena app de escritorio y una buena app móvil deberían ser completamente distintas. Pero quieren que ambas versiones les resulten familiares a los usuarios, así que incluso haciendo el mejor esfuerzo aparecen compromisos.
    Microsoft podría haberlo hecho razonablemente bien, pero no lo hizo. El Panel de control lo deja claro. La nueva versión, Configuración, existe desde Windows 8, hace 12 años, y aun así todavía no logró trasladar todas las funciones del Panel de control antiguo, por lo que se necesitan ambos. Hace unos meses intentaron hacer la transición completa, pero no estaba lista, y no sé si algún día lo estará. Además, suelen eliminar opciones populares de personalización, y ni siquiera hay consistencia de estilo entre las apps incluidas. Esto no es solo discutible: es objetivamente malo.
    Otro factor que no se puede achacar solo a Microsoft y Windows es que los desarrolladores de apps priorizan el branding y la coherencia interna por encima de la integración con el sistema operativo. Muchas UI modernas no son más que páginas web renderizadas con motores de navegador como Electron; no usan controles nativos del sistema operativo, ignoran los temas y dibujan sus propias decoraciones de ventana. El sistema operativo puede ser inconsistente, pero los desarrolladores de apps tampoco ayudan.
  • El diseño plano fue casi un desastre para la industria. El esqueuomorfismo, en la práctica, también era diseño plano con dibujos pegados, así que también era bastante malo.
    Windows Forms hizo muchas cosas bien, y si tuviera que señalar un estado que faltaba, diría “activo pero no editable”.
  • Según se cuenta, Windows 11 era originalmente Windows 10X, que también se estaba haciendo para teléfonos y tablets. El menú Inicio parece tener bastante influencia de Android: muestra todo lo instalado de forma plana y empuja más al usuario a buscar.
    Aun así, estoy de acuerdo. En las betas de Win10 había una forma que mezclaba tiles con una lista al estilo Windows 7, y como ese enfoque venía desde Windows 2000, creo que ese fue el punto máximo. Podría haber tenido lo mejor de ambos mundos. El área de notificación siempre fue débil, y el panel de Configuración es pésimo comparado con el Panel de control. Claro que el Panel de control también era desordenado y complejo, así que se puede discutir si era lo mejor.

• El autor dijo que la pantalla se corrompía al abrir el prompt de DOS en modo ventana; esto puede ocurrir porque el prompt de DOS se ejecuta en una VM separada, es decir, en modo V86, y llama al BIOS ROM VGA mediante INT 10h.
  El BIOS ROM VGA de este equipo probablemente sea un wrapper sobre VBE, lo que significa que habría incluido instrucciones IN/OUT que acceden a los puertos de E/S de VBE, 0x1CE y 0x1CF. Si el VMM no virtualiza estas lecturas y escrituras originadas en la VM de DOS, por defecto llegan hasta el hardware real.
  Este era un problema común que debían manejar los autores de drivers de pantalla para Windows 3.x/9x, pero los números de puertos de E/S que había que virtualizar variaban según el adaptador gráfico. El DDK de Win95 incluye un ejemplo que configura trampas de puertos de E/S con los servicios de VMM Install_IO_Handler y Enable/Disable_Global_Trapping, y dentro del manejador de la trampa usa VDD_Get_VM_Info para determinar qué VM posee el CRTC actual. Con eso, el manejador de trampas puede decidir si enviar la E/S al hardware o cómo virtualizarla. Una buena política de virtualización como punto de partida es simplemente descartar las escrituras de las VM que no son dueñas del CRTC, y luego agregar la complejidad necesaria.

• Virtual Display Device(VDD) se ejecuta como parte del administrador de máquinas virtuales subyacente y actúa como un multiplexor para el hardware de video. Si una app de DOS está en pantalla completa, los comandos se pasan directamente al adaptador VGA “real”; si no, el VDD los emula.
  Es interesante ver que otras personas redescubran esta estructura. Personalmente, creo que era una arquitectura bastante adelantada a su época, anterior a los hipervisores modernos con passthrough de hardware. La propia GUI de Windows 3.x, incluidos los procesos con multitarea preventiva, se ejecuta básicamente como un proceso DOS en modo protegido extendido dentro de una VM donde corre DOS, y el kernel hipervisor VMM32 multiplexa entre esa VM y otras VM de procesos DOS. Por eso una parte del driver de pantalla interactúa con el “hardware” debajo de GDI, y otra parte virtualiza el hardware en ring 0 y lo multiplexa con otras VM.
  Esto podría arreglarse en DOSBox, pero esa corrección quedaría atada al adaptador de video específico que DOSBox emula. Lo que se quiere no es eso, sino hacer que el parche VBE genérico funcione mejor.
  Una vez escribí un driver de framebuffer VESA para Win9x para Intel GMA950 e incluso le agregué aceleración básica, es decir, comandos de blitter y relleno, y al pasar por prácticamente el mismo problema entendí por qué Win9x no tenía un driver VESA genérico. El VDD tiene que saber cómo guardar y restaurar el estado de la GPU, y esos detalles son, por supuesto, dependientes del proveedor. También pensé en ideas que podrían funcionar de forma genérica. Por ejemplo, emular o rastrear el VBIOS para ver qué puertos y MMIO toca en cada cambio de modo, pero no llegué a implementarlo.
  En DOSBox aparece un modo texto lleno de caracteres corruptos, y en la Eee PC aparece una GUI dañada en la que faltan algunos colores.
  Esto parece indicar que los registros de la paleta no se guardan y restauran correctamente. Además, la corrupción en la parte superior de la pantalla puede evitarse moviendo el plano de visualización de alta resolución por encima de los 256K, dejando los primeros 256K de VRAM para los planos VGA y la emulación VGA. Por suerte, Intel GMA tiene bastante documentación pública. No la de 900 y 950, sino la de 810/815 y la de 965 en adelante, pero la mayoría de los registros y comandos no cambiaron, así que sirve para consultar los detalles.

• “Como no tiene soporte x86_64, tampoco puede ejecutar la mayoría de las distribuciones Linux modernas”, pero mi Eee se mantiene bien con Debian de 32 bits.
  Firefox es demasiado pesado y casi se arrastra, pero alcanza perfectamente para hacer streaming de video con mpv. Lo uso sobre todo como una máquina de escribir con pocas distracciones, donde puedo correr pandoc cuando se me acumula trabajo con libros.

  • Estoy totalmente de acuerdo en que para escribir conviene una computadora con el mínimo de distracciones. Para eso uso WordPerfect 5.1 en una PS/2 386SX.
    Me gustaba mucho la EEE porque era muy portable, pero creo que el teclado es demasiado pequeño para tipear en serio.
  • Si se usa prácticamente sin web ni apps modernas, podría ser un caso de uso interesante para algo como Haiku OS.
    Lo probé en PC y, aunque claramente le faltaba software disponible para convertirse en un sistema operativo real de uso diario, para usos de baja conectividad como máquina de escribir y correo se sentía como un sistema operativo muy agradable.
    Me gustó la sensación de coherencia entre la UI, el software base y el sistema de archivos. Si lo entendí bien, el sistema de archivos es la representación de todos los datos, los “archivos” pueden tener metadatos arbitrarios y casi todo se puede hacer desde el administrador de archivos. Todo el sistema de archivos parece una base de datos NoSQL, y las apps adoptan esa idea de forma natural. Los contactos son “archivos” dentro de una carpeta, los correos también son “archivos” dentro de una carpeta, y así.
    En esa época nunca usé BeOS, pero en los 90, cuando había poca conectividad, creo que este paradigma habría encajado bastante bien. Era sorprendentemente coherente poder redactar un “archivo” de correo sin internet, arrastrarlo a una disquetera y luego enviarlo por internet desde otra computadora, todo usando solo el administrador de archivos.
    Lamentablemente, en cuanto hay que interoperar con otra computadora que no es compatible con el sistema de archivos de BeOS/Haiku, la utilidad de este paradigma disminuye. Estadísticamente, eso incluye a casi todas las computadoras.
    Pero para un dispositivo usado como máquina de escribir podría ser interesante.
  • Tengo entendido que Debian eliminará el soporte para x86 de 32 bits en la próxima versión.
  • Tenía una 1215B, pero murió el año pasado, y ahora una tablet Android la reemplaza.
    Parece que las tablets arrasaron con el segmento de mercado de las netbooks. Todavía existen ultraportátiles y 2-en-1, pero están más bien en el extremo opuesto de precios.

• El título me resultó un poco confuso.
  Aun así, cada vez que leo cómo funcionaban por dentro los viejos Windows basados en DOS, siempre me da una sensación de asombro. Parece que todo estuviera pegado con cinta adhesiva de software, pero somehow funciona.

  • Escuchen lo que dice Casey Muratori. La idea es que se construyó una enorme pila de abstracciones que en realidad no hace falta y que solo empeora el rendimiento.

• Recuerdo que cuando salió ET4000H, Windows 3.1 no lo soportaba en ese momento. Llamé al soporte técnico de MS, me mandaron un disquete con el driver y llegó 8 horas después
  Fue el mejor soporte que recibí para un producto pirateado

  • Para ser exactos, el ET4000H era igual al ET4000ax, que ya era compatible con Windows 3.0 y 3.1, pero traía HiDAC, es decir, true color de 15/16 bits, en vez de un DAC de 256 colores
    Mi memoria es borrosa, pero creo que con el driver básico funcionaba el modo de 16 colores y no los de 256 colores o más, y tal vez la selección de resoluciones también era limitada
    Según MS, el driver compatible con HiDAC salió en la tercera semana de abril de 1992, una o dos semanas después de la fecha que recuerdo, así que en general parece coincidir

• Interesante. Tengo el modelo pequeño, el EEEPC 701, y todavía funciona, pero nunca lo había pensado para juegos retro
  El mío solo está juntando polvo, pero probar cosas así podría ser divertido

  • Parece que se refiere al 701. 207g no es un modelo de Eee PC

• Comparando de pasada las pequeñas anotaciones, se ven los siguientes cambios de estado, que probablemente miré hasta llegar a la saturación semántica
  Functional GUI: M_LIN8 G800x600 > 800x600 @00000+100+Dch4
  Functional DOS: M_TEXT T80x25 > 720x400 @00000+050-W
  Broken GUI: M_VGA G400x600 > 400x600 @00000+200-Dch4
  Broken DOS: M_TEXT T80x25 > 720x400 @00000+250-W
  Por el patrón, el DOS roto y la GUI rota son 200 o 250, y los normales son 100 o 050. ¿Qué será esa dirección?
  La GUI rota, somehow, está en modo M_VGA, no en LIN8. ¿Cómo y por qué terminó así, y tendrá relación con que quedara en 400x600, la mitad horizontal de 800x600? El “modo texto” real es 720x400, como se ve en los dos modos DOS

• No sé si el autor lo verá, pero le avisé de este artículo al autor del parche
  https://www.bttr-software.de/forum/board_entry.php?id=22124#...