Um cachorro contra a stack gráfica do Windows 3.1

• Ao tentar usar o Windows 3.11 em um Asus Eee PC 1000H de 2008 ajustado à tela de 1024x600, ficaram evidentes as limitações do VGA básico e do driver Super VGA de 256 cores da Microsoft
• O suporte a Super VGA do Windows 3.x não era baseado em um padrão comum, mas em uma estrutura voltada a extensões proprietárias de cada placa, e o Intel GMA 950 do Eee PC não era compatível
• O SVGAPatch altera o svga256.drv da Microsoft para usar chamadas VBE e permitir saída em alta resolução com 256 cores, mas ainda restava um problema em que a GUI ficava corrompida após alternar para a tela do DOS
• A engenharia reversa mostrou que a configuração inicial de modo passou a usar VBE, mas o caminho de reconfiguração durante a troca de tela ainda chamava o modo 30h do Tseng ET4000 e a configuração de scan line VBE em estado de text mode
• Um patch adicional reduziu a corrupção ao voltar de uma sessão DOS em tela cheia para a GUI, mas não resolveu completamente o estado de bank switching; no Eee PC real, a recuperação da GUI e do modo em janela ficou em um nível utilizável

---

Revivendo os gráficos do Windows 3.11 no Eee PC

• O dispositivo-alvo é um Asus Eee PC 1000H comprado em 2008, que hoje tem dificuldade para executar a maioria das distribuições Linux modernas por não ter suporte a x86_64
• O objetivo era executar Windows 3.11 for Workgroups nesse netbook com uma saída de vídeo melhor
• A saída padrão é VGA 640x480 em 16 cores, o que não fica bom em uma tela de 1024x600 e também não respeita a proporção da tela
• O instalador do Windows 3.11 inclui drivers para adaptadores de vídeo antigos, mas não oferece suporte ao Intel GMA 950 do Eee PC
• O driver Super VGA incluído parece oferecer suporte a até 1024x768 em 256 cores, mas nesse ambiente ele gera erro e o Windows não inicia

Diferenças entre VGA, SVGA e VBE

• VGA é um controlador de vídeo específico projetado pela IBM nos anos 1980, não simplesmente um conector analógico azul ou a resolução 640x480
• SVGA era mais um termo genérico para “algo mais avançado que o VGA básico” do que um padrão, e o software precisava dar suporte direto às extensões proprietárias de cada placa
• A lista de suporte do driver SVGA de 256 cores da Microsoft incluía as seguintes famílias
  • 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 tratar recursos fora do VGA por meio de uma interface comum, mas o Windows 3.x não incluía um driver VBE direto
• VBE9x e VBEMP, da BearWindows, permitem usar VBE no Windows 9x e no NT, respectivamente, mas não há versão para Windows 3.x

O que o SVGAPatch resolveu e o que deixou em aberto

• SVGAPatch aplica um patch ao driver Super VGA de 256 cores da Microsoft para fazê-lo usar VBE
• O driver com patch consegue exibir corretamente telas como 1024x600, mas há conflitos na compatibilidade com DOS
• O Windows 3.1 Enhanced Mode consegue executar aplicativos gráficos do Windows e aplicações DOS ao mesmo tempo, e também pode abrir o prompt do DOS em janela ou em tela cheia
• Depois de aplicar o SVGAPatch, os seguintes problemas foram reproduzidos
  • Ao entrar no modo DOS em tela cheia e voltar para a GUI do Windows, a tela fica corrompida
  • Em alguns casos, só abrir um prompt do DOS em modo janela já corrompe a tela
  • O problema é reproduzido no DOSBox, no 86Box e no Eee PC real, mas a forma da corrupção varia um pouco
• Um novo driver separado, PluMGMK/vbesvga.drv, oferece suporte até a modos true color, mas aqui a análise seguiu o caminho de corrigir o código da Microsoft e o SVGAPatch

Estrutura da stack gráfica do Windows 3.x

• O Windows 3.x Enhanced Mode usa um Virtual Machine Manager em modo protegido de 32 bits para criar várias VMs, e dentro da primeira VM roda o Windows em Standard mode
• Ao escolher um adaptador de vídeo no Windows Setup, não é instalado um único driver, mas vários componentes em conjunto
  • Grabber: aparentemente responsável pela renderização de aplicativos DOS em modo janela
  • Display Driver: responsável pela inicialização do hardware e pela renderização da GUI dentro da VM principal do Windows; no Windows 3.x, também implementa internamente boa parte do GDI
  • Virtual Display Device(VDD): executado como parte do Virtual Machine Manager e multiplexa os aplicativos DOS e o hardware VGA real
• As entradas SVGA de 256 cores usam o mesmo driver e são diferenciadas pelas configurações de resolução e DPI no SYSTEM.INI
• O SVGAPatch modifica apenas o Display Driver e não altera o VDD de SVGA
• No fim, foi necessário entender em conjunto o Display Driver, o VDD e as mudanças privadas feitas pelo SVGAPatch para restringir a causa da corrupção da tela

Materiais e ferramentas usados na engenharia reversa

• Como referências, foram usados Windows 3.x VDDVGA e o Windows 3.1 DDK
• O Windows 3.1 DDK inclui os seguintes códigos-fonte
  • Fontes dos Display Drivers para VGA, IBM 8514, Video 7 e SVGA de 16 cores
  • Fontes dos VDDs para VGA, IBM 8514, Video 7 e SVGA de 16 cores
  • Quase todos os fontes dos Grabbers
  • Muito pouca documentação
• Justamente o necessário, o Display Driver SVGA de 256 cores e os fontes do VDD relacionado, não está incluído
• Para analisar svga256.drv e vddsvga.386, foram usados IDA e Ghidra
• O Ghidra conseguia ler .drv, mas o VDD era um VxD e exigia um loader LX separado; também havia limitações para lidar com arquivos que misturam código de 32 bits e de 16 bits

Análise interna de svga256.drv

• svga256.drv possui funções exportadas como GETCHARWIDTH, STRETCHBLT e VIDEOINIT_ATI, o que permitiu compará-lo com os fontes do DDK
• Algumas funções eram quase iguais às do driver VGA, mas havia diferenças, como a ausência da correção de largura para bold font em GETCHARWIDTH
• Em REALIZEOBJECT, apareceram diferenças que pareciam misturar código do driver VGA e do driver Video 7, e a lógica de tratamento de cores também era diferente
• Só as funções GDI não bastavam para explicar a interação com o adaptador de vídeo, então a análise seguiu para o caminho de inicialização, physical_enable

physical_enable e o modo de funcionamento do driver SVGA da Microsoft

• Ao selecionar “Super VGA (800x600, 256 colours, small fonts)” no Windows Setup, os seguintes valores são gravados em SYSTEM.INI
  • dpi=96
  • resolution=2
• Após a inicialização, o driver com patch registra ainda estes valores
  • svgamode=48
  • ChipSet=Tseng ET4000
  • LatchCapable=No
• physical_enable é a principal função de inicialização: ela define o modo de vídeo e percorre a lista de modos compatíveis para encontrar um modo específico de chipset que funcione
• A lógica original da Microsoft mantém uma tabela de modos compatíveis por resolução e testa cada modo com SetAndValidateMode
• Quando há sucesso, ela localiza e chama a função de inicialização específica do chipset, a função de configuração de bank e outras; depois prossegue com configuração de paleta, inicialização do framebuffer e configuração de endereços do VDD

As mudanças reais do SVGAPatch

• O SVGAPatch altera para 2000 o ID de função da primeira entrada de chipset nas listas de três resoluções, além de sobrescrever SetAndValidateMode e algumas funções específicas de chipset
• As mudanças principais são as seguintes
  • SetAndValidateMode: em vez da configuração de modo baseada no VGA BIOS antigo, solicita um modo de vídeo estendido via VBE 4F02h
  • SETBANK_TRIDENT: em vez de escrever em registradores específicos da Trident, move a janela de memória de vídeo via VBE 4F05h
  • VIDEOINIT_TRIDENT: em vez de escrever no VGA CRTC Offset Register, define o comprimento da scan line via VBE 4F06h
• Depois do patch, a primeira entrada da lista de modos compatíveis tem sucesso e passam a ser usadas as funções reescritas associadas ao ID de função 2000
• O motivo de o valor Tseng ET4000 ser gravado em SYSTEM.INI é que, mesmo que o valor não seja usado de fato, o nome da primeira entrada da lista é salvo como está

VDD e DspDrvr_Addresses

• O VDD lida por virtualização com situações em que programas DOS esperam ter acesso exclusivo ao hardware real
• Cada VM possui uma instância da estrutura VDD_CB_Struc, que contém flags, espelhos do estado do controlador VGA e informações de alocação de memória de vídeo por VM
• O VDD contém código específico por fornecedor para detectar adaptadores VGA específicos e mudar a forma como determinados registradores são salvos, restaurados e simulados
• DspDrvr_Addresses é um serviço pelo qual o Display Driver passa informações de endereço ao VDD; pelos comentários, DX é um campo reservado e deveria ser 0, mas no código real do VDD VGA há comportamento especial quando DX não é 0
• No VDD SVGA existe um novo caminho para DX == 2, e SVGA256.DRV chama essa função com os seguintes valores
  • BX = 0xFFFF
  • DX = 2
  • DS:SI aponta para o byte de status da shadow memory

Delimitando a causa com DOSBox-X

• O Video debug overlay e o depurador do DOSBox-X foram usados para comparar o estado VGA antes e depois de alternar para o prompt do DOS em tela cheia
• As anotações de modo e o estado dos registradores exibidos eram diferentes entre GUI normal, DOS normal, GUI corrompida e DOS corrompido
• Para verificar se uma flag de VDD específica de fornecedor estava sendo ativada indevidamente, o DOSBox-X foi modificado para fazer dump da memória física, mas no DOSBox essa flag não estava ligada
• Ao comparar os registradores VGA, o valor interno scan_len do DOSBox era diferente entre os estados normais e corrompidos
  • Em DOS normal: 40
  • Em DOS corrompido: 296
  • Em GUI normal: 128
  • Em GUI corrompida: 256
• A implementação da API VESA Scan Line do DOSBox calculava scan_len de forma diferente dependendo do modo de vídeo atual, e esse ponto se tornou o principal suspeito

A pista decisiva: configuração de scan line VBE em text mode

• Ao adicionar logs da configuração de scan line VESA no DOSBox-X, a seguinte chamada apareceu
  • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
  • O modo atual era M_TEXT
• O Display Driver define o comprimento da scan line como 1024 bytes via VBE 4F06h, mas o DOSBox entende que o modo atual é text mode, então seu estado interno é calculado incorretamente
• Na inicialização do Windows, a configuração de scan line ocorre corretamente no estado SVGA 800x600 e M_LIN8
• Depois de abrir um prompt do DOS em tela cheia e voltar para a GUI com Alt+Enter, ocorre o seguinte fluxo
  • Algum código solicita a mudança para o modo 30h, ou seja, decimal 48
  • O patched display driver configura o comprimento da scan line em estado de text mode
  • O estado interno do DOSBox e o estado baseado nos registradores VGA ficam desalinhados
• O modo 30h era o valor de modo para 800x600 do Tseng ET4000 que o SVGAPatch havia sequestrado

O caminho de troca de tela que faltava

• O Display Driver do Windows 3.1 faz hook de INT 2Fh para receber comandos de troca de tela
• O driver VGA lida com os quatro comandos abaixo, mas o driver SVGA256 só oferece suporte a SCREEN_SWITCH_OUT e SCREEN_SWITCH_IN
  • SCREEN_SWITCH_OUT
  • SCREEN_SWITCH_IN
  • SAVE_DEV_REGS
  • RES_DEV_REGS
• A função problemática era dev_to_foreground, chamada ao voltar para a GUI do Windows
• O dev_to_foreground do SVGA256 opera no seguinte fluxo
  • Chama farsetmode
  • farsetmode configura o modo 48
  • Chama o VideoInit específico do chipset
  • Define enabled_flag como 0xFF
  • Chama a API SetPalette do Windows
• O SVGAPatch trocou o caminho de configuração de modo durante a inicialização para VBE, mas não trocou o caminho que reconfigura o modo durante a alternância de tela

Melhoria na recuperação da GUI com um patch adicional

• O código original de setmode tinha uma estrutura curta: colocava wGraphicsMode em ax, chamava INT 10h e depois chamava ptr_videoinit
• Um novo código foi inserido no espaço restante após o SetAndValidateMode encurtado pelo SVGAPatch
  • Coloca em cx o valor de CurrentHeight menos 1
  • Chama SetAndValidateMode
  • Chama ptr_videoinit
• A primeira instrução de setmode foi alterada para saltar para o novo código, fazendo com que a troca de tela também passasse pelo caminho de configuração de modo baseado em VBE
• Depois dessa correção, a tela deixou de ficar corrompida ao entrar em uma sessão DOS em tela cheia e voltar para a GUI
• Porém, o problema de os pontos reaparecerem ao passar do modo em janela para tela cheia permaneceu

O problema restante de bank switching

• Ao olhar a memória VGA em B8000 pelo depurador do DOSBox, o conteúdo de texto existia, mas não aparecia na tela
• O ponto suspeito era o bank switching, usado pelo driver para acessar uma quantidade maior de memória de vídeo
• Ao adicionar um comando no DOSBox-X para exibir o estado dos bancos SVGA, foi confirmado que o adaptador VGA permanecia no bank errado ao voltar para tela cheia
• Uma nova rotina para devolver o bank para 0 em dev_to_background foi inserida, mas o problema não foi corrigido
• A implementação de VBE 4F05h do DOSBox escrevia no registrador VGA CRTC 0x6A, e quando dev_to_background era chamado o VDD já estava em estado de interceptar as escritas, então era tarde demais

Resultados dos testes com o driver original e com o driver com patch

• Ao testar no 86Box o driver SVGA de 256 cores original da Microsoft com várias placas emuladas, os resultados variaram mesmo dentro da lista de suporte
  • Cirrus Logic GD5420 (ISA): funciona
  • Tseng Labs ET4000AX: funciona
  • Oak OTI-077: tela corrompida ao abrir o prompt do DOS em modo janela pela primeira vez; em tela cheia, surgem linhas verticais
  • Trident TVGA 8900D: tela corrompida no prompt do DOS em tela cheia; modo janela funciona normalmente
  • ATI VGA Wonder XL, Paradise PVGA1A, Video 7 VGA 1024i em algumas resoluções: o Windows não inicia
• Há a ressalva de que o 86Box não fornece exatamente as mesmas placas e que a precisão da emulação também não é garantida
• Os resultados do driver modificado baseado no SVGAPatch com placas mais novas também variaram por placa
  • Matrox Millennium II: muito lento; DOS em modo janela funciona, mas tela cheia fica corrompida
  • 3dfx Voodoo Banshee: abrir DOS em modo janela corrompe a GUI, mas a alternância para tela cheia funciona
  • S3 Trio3D/2X: aparece uma tela corrompida na inicialização do Windows, mas após o prompt do DOS e sair da tela cheia, 1024x768 aparece corretamente
  • 3dfx Voodoo3 3500 SI: parecido com a Banshee, mas a tela cheia funciona apenas uma vez

Estado final no Eee PC

• No Eee PC real, a GUI funciona normalmente
• A alternância para o prompt do DOS em tela cheia ainda corrompe a tela, mas de uma forma diferente do DOSBox
• No DOSBox, aparecia um text mode com muitos caracteres corrompidos; no Eee PC, aparecia uma GUI corrompida com algumas cores faltando
• Ao voltar para o modo em janela, é possível recuperar
• O SVGAPatch original fazia a GUI inteira ficar corrompida só de abrir um prompt em modo janela, exigindo reiniciar o sistema operacional, mas o driver modificado melhorou bastante esse comportamento
• Como solução melhor, a opção foi continuar acompanhando o PluMGMK/vbesvga.drv, que segue em desenvolvimento ativo

[GN⁺]

Comentários do Hacker News

• Independentemente do suporte a SVGA, sempre me surpreende que, ao instalar Windows 3.x em um PC que suporta padrões modernos, o VGA básico funcione imediatamente, enquanto no Linux/BSD moderno muitas vezes nem mesmo um framebuffer VGA com aceleração por software básica em Xorg/Wayland é fácil de usar sem o driver certo e arquivos de configuração manuais
  O projeto XFree86, já morto, foi talvez a tentativa mais próxima desse tipo de “simplesmente funciona”, mas ainda estava longe disso, e essa abordagem aparentemente não foi preservada no fork do Xorg

  • O XFree86 também não fazia nada diferente do Xorg nesse ponto
    Ao iniciar um PC moderno com CSM, embora isso não seja algo recomendável, o Xorg precisa executar a BIOS de vídeo com x86emu para subir com o backend VBE; ao iniciar via EFI, o modesetting baseado em efifb precisa subir sobre o modo deixado pelo firmware e pelo bootloader
    Só que isso é mais fácil em sistemas operacionais de 16 ou 32 bits. Configurar modos VESA exige chamadas de 16 bits em modo real, e embora mais tarde o padrão tenha tido nominalmente um ponto de entrada de 32 bits, quase ninguém o implementou direito. Depois que se entra no modo de 64 bits, não dá para usar vm86 para chamar código de 16 bits no espaço do usuário, então é preciso usar o x86emu, que lê o código da BIOS de vídeo e o executa em um emulador x86, mas isso nem sempre funciona perfeitamente
  • O Linux tem vgafb/vesafb, então isso é possível se a distribuição estiver configurada adequadamente
    Só que geralmente a experiência tem desempenho e qualidade baixos, e o usuário talvez nem saiba por quê, então parece que algumas ou a maioria das distribuições não ativam isso por padrão. Hoje em dia quase todas as GPUs já têm suporte nativo, então provavelmente nunca houve motivação para criar um pop-up dizendo “você está usando VGA/VESA sem aceleração, corrija isso”
  • Faz muito tempo, mas lembro que havia um driver VGA genérico no X que “simplesmente funcionava”. Isso quer dizer que ele não existe mais?
  • O X11 já tinha um driver VESA há muito tempo, mas o número de pixels a processar cresce rapidamente com a resolução, então a escalabilidade de desempenho é ruim
    As distribuições Linux inicializáveis que uso no trabalho, principalmente GRML e Clonezilla, ajustam-se automaticamente durante o boot à resolução nativa da tela ou de um KVM virtual graças ao suporte a KMS, e funcionam bem. O Anaconda, isto é, o instalador da família RedHat, e o instalador do Debian também inicializam na resolução nativa
    Os instaladores GUI usam VESA diretamente sobre o X11
    O fork do Xorg também suporta há muito tempo “inicializar sem arquivo de configuração”. Faz muito tempo que não gerencio arquivos de configuração, e isso é muito mais satisfatório. Veja https://www.xkcd.com/963/
  • Vejo o Xorg como algo muito próximo do XFree86 com o sistema de build reorganizado

• A antiga GUI do Windows 3.1 parece muito mais intuitiva, eficiente e agradável de usar do que as de hoje
  https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
  Como será que o Win11 ficaria em uma tela de baixa resolução como a do texto principal? O menu Iniciar do Win11 está quase inutilizável, a não ser digitar palavras-chave e rezar para os circuitos
  Minha hipótese ingênua é que o ponto ótimo foi em Windows NT e 2000, e depois disso os gerentes de produto ficaram fazendo mágica. KDE e Gnome não mudaram tanto assim, mas com o tempo parecem cada vez mais atraentes :)

  • Considero Windows 7 a última versão “boa”. Era parecido com NT/2000, mas mais bonito graças à melhora do hardware gráfico, e o mesmo vale para o XP antes dele. O Vista também tinha uma UI decente; os defeitos estavam em outros lugares
    O Windows 8 estragou tudo, e o Windows nunca se recuperou. Acho que há dois motivos: a ascensão das plataformas móveis e a preguiça da Microsoft
    Agora existe um problema difícil de resolver: muitos aplicativos precisam ter uma versão desktop e uma versão móvel separadas. Uma é para tela grande com teclado e mouse; a outra, para tela pequena com toque, então um bom app de desktop e um bom app móvel precisam ser completamente diferentes. Mas você ainda quer que ambas as versões pareçam familiares para o usuário, então mesmo no melhor caso surgem concessões
    A Microsoft poderia ter feito isso de forma razoável, mas não fez. Basta olhar o Painel de Controle. O novo Painel de Controle, ou seja, Configurações, existe desde o Windows 8, ou seja, há 12 anos, e ainda assim não conseguiu migrar todas as funções do Painel de Controle antigo, então os dois continuam sendo necessários. Alguns meses atrás tentaram fazer a transição completa, mas não estava pronto, e não sei se um dia estará. Além disso, eles frequentemente removem opções populares de personalização, e nem o estilo entre os apps empacotados é consistente. Isso não é só controverso; é objetivamente ruim
    Há ainda outro fator pelo qual não dá para culpar apenas a Microsoft e o Windows: os desenvolvedores de aplicativos priorizam branding e consistência interna acima da integração com o sistema operacional. Muitas UIs modernas são apenas páginas web renderizadas por engines de navegador como Electron, não usam controles nativos do sistema, ignoram temas e até desenham a própria decoração de janela. O sistema operacional pode ser inconsistente, mas os desenvolvedores de apps também não ajudam
  • O flat design foi quase um desastre para a indústria. O skeuomorfismo também era, na prática, flat design com ilustrações coladas, então também era bem ruim
    O Windows Forms acertava muita coisa, e se eu tiver que citar um símbolo que fazia falta, seria algo como “ativo, mas não editável”
  • Pelo que se diz, o Windows 11 era originalmente o Windows 10X, que também estava sendo feito para celulares e tablets. O menu Iniciar parece ter bastante influência do Android, com aquela exibição plana de tudo que está instalado e um incentivo maior à busca
    Ainda assim, concordo. O beta do Win10 tinha uma mistura de tiles com a lista ao estilo do Windows 7, e como isso remontava até o Windows 2000, acho que aquele era o ponto alto. Poderia ter reunido o melhor dos dois mundos. A área de notificações sempre foi fraca, e o painel de Configurações é péssimo em comparação com o Painel de Controle. Claro, também dá para discutir se o Painel de Controle era realmente o ideal, já que era bagunçado e complexo

• O autor disse que a tela corrompia ao abrir o prompt do DOS em modo janela, e isso pode acontecer porque o prompt do DOS roda em uma VM separada, isto é, no modo V86, e chama o VGA ROM BIOS via INT 10h
  O VGA ROM BIOS desse dispositivo provavelmente é um wrapper sobre VBE, ou seja, deve incluir instruções IN/OUT que acessam as portas de I/O do VBE, 0x1CE e 0x1CF. Leituras e escritas desse tipo feitas na VM do DOS, se não forem virtualizadas pelo VMM, por padrão acabam chegando ao hardware real
  Esse era um problema comum que os autores de drivers de vídeo do Windows 3.x/9x precisavam tratar, mas os números das portas de I/O a virtualizar variavam conforme o adaptador gráfico. No Win95 DDK há um exemplo de como configurar traps de portas de I/O com os serviços do VMM Install_IO_Handler e Enable/Disable_Global_Trapping, e dentro do handler de trap usar VDD_Get_VM_Info para determinar qual VM possui o CRTC no momento. Com isso, o handler pode decidir se envia o I/O ao hardware ou de que forma deve virtualizá-lo. Uma boa política de virtualização para começar é simplesmente descartar as escritas das VMs que não forem donas do CRTC, e depois adicionar a complexidade necessária

• O Virtual Display Device (VDD) roda como parte do gerenciador de máquinas virtuais subjacente e funciona como um multiplexador para o hardware de vídeo. Se o app DOS estiver em tela cheia, os comandos vão direto para o adaptador VGA “real”; caso contrário, o VDD os emula
  É interessante ver outras pessoas redescobrindo essa estrutura. Pessoalmente, acho que era uma arquitetura bem à frente do seu tempo, até mais avançada do que hipervisores modernos com passthrough de hardware. A própria GUI do Windows 3.x, incluindo processos com multitarefa preemptiva, na prática roda como um processo DOS estendido em modo protegido dentro de uma VM onde o DOS está rodando, e o kernel hipervisor VMM32 faz a multiplexação entre ela e as VMs dos outros processos DOS. Assim, uma parte do driver de vídeo interage com o “hardware” sob o GDI, enquanto outra parte, em ring 0, virtualiza o hardware e o multiplexa com as outras VMs
  Isso até poderia ser corrigido no DOSBox, mas essa correção ficaria presa ao adaptador de vídeo específico que o DOSBox emula. O que se quer não é isso, e sim fazer um patch VBE genérico funcionar melhor
  Já escrevi um driver de framebuffer VESA para Win9x no Intel GMA950 e até adicionei aceleração básica, isto é, comandos de blitter e fill, e acabei enfrentando praticamente o mesmo problema, entendendo por que não existia um driver VESA genérico para Win9x. O VDD precisa saber como salvar e restaurar o estado da GPU, e esses detalhes são naturalmente dependentes do fornecedor. Também pensei em ideias que poderiam funcionar de forma genérica, como emular ou rastrear o VBIOS para ver que portas e MMIO ele toca a cada troca de modo, mas não cheguei a implementar
  No DOSBox aparece um modo texto com um monte de caracteres corrompidos, e no Eee PC surge uma GUI quebrada com algumas cores faltando
  Isso parece indicar que os registradores da paleta não estão sendo salvos e restaurados corretamente. Além disso, a corrupção na parte superior da tela poderia ser evitada movendo o plano de exibição em alta resolução para acima de 256K, deixando os primeiros 256K da VRAM para os planos VGA e para a emulação VGA. Felizmente, há bastante documentação pública sobre o Intel GMA. Não são os documentos do 900 e do 950, e sim do 810/815 e dos posteriores ao 965, mas como a maioria dos registradores e comandos não mudou, dá para usar os detalhes como referência

• Dizem que “não tem suporte a x86_64, então nem roda a maioria das distribuições Linux modernas”, mas o meu Eee segue firme com Debian 32 bits
  O Firefox é pesado demais e quase engasga, mas streaming de vídeo com mpv funciona bem o suficiente. Eu o uso principalmente como uma máquina de escrever com poucas distrações, quando preciso rodar pandoc e estou atrasado com algum trabalho de livro

  • Concordo totalmente que é bom ter um computador com o mínimo possível de distrações na hora de escrever. Para esse uso, eu uso WordPerfect 5.1 num PS/2 386SX
    Eu gostava do EEE por ser extremamente portátil, mas acho o teclado pequeno demais para digitar seriamente
  • Se a ideia é usar sem web nem apps modernos, isso pode ser um caso de uso interessante para algo como Haiku OS
    Usei no PC e, embora claramente falte software disponível para ele ser um sistema operacional realmente cotidiano, para usos de baixa conectividade, como máquina de escrever e e-mail, pareceu um sistema muito agradável
    Gostei da sensação de consistência entre a UI, o software básico e até o sistema de arquivos. Se entendi direito, o sistema de arquivos é a representação de todos os dados, e os “arquivos” podem ter metadados arbitrários, de modo que quase tudo pode ser feito no gerenciador de arquivos. O sistema de arquivos inteiro parece um banco de dados NoSQL, e os apps adotam isso de forma natural. Contatos são “arquivos” dentro de pastas, e e-mails também são “arquivos” dentro de pastas
    Nunca usei BeOS na época, mas nos anos 90, com pouca conectividade, esse paradigma provavelmente combinava muito bem. Sem internet, era surpreendentemente consistente fazer tudo só no gerenciador de arquivos: escrever um “arquivo” de e-mail, arrastá-lo para um disquete e depois enviá-lo pela internet em outro computador
    Infelizmente, no momento em que você precisa interoperar com outros computadores que não são compatíveis com o sistema de arquivos do BeOS/Haiku, a utilidade desse paradigma diminui. Estatisticamente, isso vale para quase todos os computadores
    Mas para um dispositivo de uso como máquina de escrever, pode ser interessante
  • Pelo que sei, o Debian deve remover o suporte a x86 de 32 bits na próxima versão
  • Eu tinha um 1215B, mas ele morreu no ano passado, e agora um tablet Android ocupa o lugar
    Parece que os tablets varreram a faixa de mercado dos netbooks. Ainda existem ultraportáteis e 2-em-1, mas isso já fica mais para o extremo oposto da faixa de preço

• O título me confundiu um pouco
  Mesmo assim, sempre fico impressionado quando leio sobre como o antigo Windows baseado em DOS funcionava por dentro. Parece que tudo está preso com fita adesiva de software, mas somehow funciona

  • É só ouvir o que o Casey Muratori diz. Criaram um enorme monte de abstrações, mas na prática elas não são necessárias e só fazem o desempenho piorar

• Quando a ET4000H saiu, lembro que ela não era suportada pelo Windows 3.1 na época. Liguei para o suporte técnico da MS, e eles me enviaram um disco de driver que chegou 8 horas depois
  Foi o melhor suporte que já recebi por um produto pirateado

  • Para ser mais preciso, a ET4000H era igual à ET4000ax, que já era suportada no Windows 3.0 e 3.1, mas vinha com um HiDAC em vez de um DAC de 256 cores, ou seja, true color de 15/16 bits
    Minha memória está vaga, mas acho que o modo de 16 cores funcionava com o driver padrão, enquanto 256 cores ou mais não funcionavam, e a seleção de resolução também podia ser limitada
    Segundo a MS, o driver com suporte a HiDAC saiu na terceira semana de abril de 1992, o que é 1 ou 2 semanas depois do momento de que eu me lembro, então no geral parece bater

• Interessante. Tenho um modelo pequeno, o EEEPC 701, e ele ainda funciona, mas nunca tinha pensado nele para jogos retrô
  O meu só está pegando poeira, então talvez seja divertido tentar essas coisas

  • Acho que ele está falando do 701. 207g não é um nome de modelo do Eee PC

• Comparando casualmente as pequenas anotações, dá para ver a próxima mudança de estado, provavelmente depois de encarar isso por tempo suficiente para chegar à saciedade 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
  Pelo padrão, o DOS quebrado e a GUI quebrada são 200 ou 250, e os estados normais são 100 ou 050. O que seria esse endereço?
  A GUI quebrada está somehow em modo M_VGA em vez de LIN8. Como e por que isso aconteceu, e isso teria relação com o fato de ter virado 400x600, metade da largura de 800x600? O verdadeiro “modo texto” é 720x400, como aparece nos dois modos DOS

• Não sei se o autor vai ver isto, mas informei este post ao autor do patch
  https://www.bttr-software.de/forum/board_entry.php?id=22124#...