Un chien contre la pile graphique de Windows 3.1

• En essayant d’utiliser Windows 3.11 sur un écran 1024x600 avec un Asus Eee PC 1000H de 2008, les limites du VGA de base et du pilote Microsoft Super VGA 256 couleurs sont apparues
• La prise en charge Super VGA de Windows 3.x n’était pas fondée sur un standard commun, mais sur des extensions propriétaires propres à chaque carte, et l’Intel GMA 950 de l’Eee PC n’était pas pris en charge
• SVGAPatch modifie svga256.drv de Microsoft pour le faire reposer sur des appels VBE et permettre un affichage 256 couleurs en haute résolution, mais un problème de corruption de l’interface après un passage par l’écran DOS persistait
• L’analyse inverse a montré que la configuration initiale du mode avait bien été basculée vers VBE, mais que le chemin de réinitialisation lors des changements d’écran appelait toujours le mode 30h pour Tseng ET4000 et le réglage VBE de la scan line alors que le système était en mode texte
• Un patch supplémentaire a réduit les corruptions au retour vers l’interface après une session DOS plein écran, mais sans résoudre complètement l’état du bank switching, si bien que sur l’Eee PC réel on arrive seulement à restaurer correctement l’interface et le mode fenêtré

---

Redonner vie aux graphismes de Windows 3.11 sur un Eee PC

• La machine visée est un Asus Eee PC 1000H acheté en 2008, aujourd’hui incapable d’exécuter facilement la plupart des distributions Linux récentes faute de prise en charge x86_64
• L’objectif était d’exécuter Windows 3.11 for Workgroups sur ce netbook avec une meilleure sortie vidéo
• L’affichage de base est en VGA 640x480 16 couleurs, ce qui rend mal sur un écran 1024x600 et ne respecte pas le bon ratio
• Le programme d’installation de Windows 3.11 inclut des pilotes pour d’anciens adaptateurs vidéo, mais pas pour l’Intel GMA 950 de l’Eee PC
• Le pilote Super VGA inclus semble prendre en charge jusqu’au 1024x768 en 256 couleurs, mais dans cet environnement il provoque une erreur et empêche Windows de démarrer

Différences entre VGA, SVGA et VBE

• Le VGA est un contrôleur vidéo précis conçu par IBM dans les années 1980, et ne désigne pas simplement un connecteur analogique bleu ou une résolution 640x480
• SVGA relevait moins d’un standard que d’un terme générique pour désigner ce qui allait « au-delà du VGA de base », ce qui obligeait les logiciels à gérer directement les extensions propriétaires de chaque carte
• La liste de prise en charge du pilote Microsoft SVGA 256 couleurs comprend notamment les familles suivantes
  • 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) fournit une interface commune pour les fonctions au-delà du VGA, mais Windows 3.x n’incluait pas de pilote VBE natif
• VBE9x et VBEMP de BearWindows permettent respectivement d’utiliser VBE sous Windows 9x et NT, mais il n’existe pas de version pour Windows 3.x

Ce que SVGAPatch résout, et ce qu’il laisse de côté

• SVGAPatch modifie le pilote Microsoft Super VGA 256 couleurs pour lui faire utiliser VBE
• Le pilote patché peut afficher correctement une résolution comme 1024x600, mais la compatibilité DOS pose problème
• Le mode étendu de Windows 3.1 permet d’exécuter simultanément des applications Windows graphiques et des applications DOS, et d’ouvrir une invite DOS en fenêtre ou en plein écran
• Après application de SVGAPatch, les problèmes suivants sont reproductibles
  • En entrant dans un mode DOS plein écran puis en revenant à l’interface Windows, l’affichage se corrompt
  • Dans certains cas, le simple fait d’ouvrir une invite DOS en mode fenêtré corrompt aussi l’écran
  • Le problème se reproduit dans DOSBox, 86Box et sur le véritable Eee PC, même si la corruption diffère légèrement selon les cas
• Un nouveau pilote séparé, PluMGMK/vbesvga.drv, prend même en charge le true color, mais ici l’analyse s’est concentrée sur la correction du code Microsoft et de SVGAPatch

Structure de la pile graphique de Windows 3.x

• En mode étendu, Windows 3.x s’appuie sur le Virtual Machine Manager 32 bits en mode protégé, qui crée plusieurs VM, la première exécutant Windows en mode standard
• Quand on choisit un adaptateur vidéo dans Windows Setup, ce n’est pas un seul pilote qui est installé, mais plusieurs composants
  • Grabber : apparemment chargé du rendu des applications DOS en mode fenêtré
  • Display Driver : chargé de l’initialisation matérielle et du rendu de l’interface dans la VM Windows principale, avec une bonne partie du GDI réimplémentée dans Windows 3.x
  • Virtual Display Device (VDD) : exécuté comme composant du Virtual Machine Manager, pour multiplexer l’accès entre les applis DOS et le vrai matériel VGA
• Les entrées SVGA 256 couleurs utilisent le même pilote et se distinguent par les réglages de résolution et de DPI dans SYSTEM.INI
• SVGAPatch ne modifie que le Display Driver et ne touche pas au VDD SVGA
• Il a donc fallu comprendre ensemble le Display Driver, le VDD et les modifications non documentées introduites par SVGAPatch pour remonter à l’origine de la corruption d’affichage

Documentation et outils utilisés pour l’analyse inverse

• Les références utilisées incluent Windows 3.x VDDVGA et le Windows 3.1 DDK
• Le Windows 3.1 DDK contient les sources suivantes
  • Sources des Display Drivers VGA, IBM 8514, Video 7 et SVGA 16 couleurs
  • Sources des VDD VGA, IBM 8514, Video 7 et SVGA 16 couleurs
  • Sources de presque tous les Grabbers
  • Très peu de documentation
• En revanche, les sources nécessaires du Display Driver SVGA 256 couleurs et du VDD associé n’y figurent pas
• L’analyse de svga256.drv et vddsvga.386 a été menée avec IDA et Ghidra
• Ghidra pouvait lire les .drv, mais le VDD étant un VxD, il nécessitait un chargeur LX séparé, avec des limites pour traiter un fichier mêlant code 32 bits et code 16 bits

Analyse interne de svga256.drv

• svga256.drv exporte des fonctions comme GETCHARWIDTH, STRETCHBLT et VIDEOINIT_ATI, ce qui a permis des comparaisons avec les sources du DDK
• Certaines fonctions étaient presque identiques à celles du pilote VGA, mais avec des différences comme l’absence, dans GETCHARWIDTH, de la correction de largeur pour les polices en gras
• Dans REALIZEOBJECT, on voyait des différences suggérant un mélange de code entre le pilote VGA et le pilote Video 7, ainsi qu’une logique de gestion des couleurs distincte
• Les seules fonctions GDI ne suffisaient pas à expliquer les interactions avec l’adaptateur vidéo, d’où une analyse du chemin d’initialisation physical_enable

physical_enable et la méthode du pilote Microsoft SVGA

• Si l’on choisit « Super VGA (800x600, 256 colours, small fonts) » dans Windows Setup, SYSTEM.INI reçoit les valeurs suivantes
  • dpi=96
  • resolution=2
• Après démarrage, le pilote patché ajoute aussi les valeurs suivantes
  • svgamode=48
  • ChipSet=Tseng ET4000
  • LatchCapable=No
• physical_enable est la fonction centrale d’initialisation qui règle le mode vidéo et parcourt une liste de modes pris en charge pour trouver un mode compatible selon le chipset
• La logique Microsoft d’origine maintient une table de modes pris en charge par résolution et teste chaque mode avec SetAndValidateMode
• En cas de succès, elle retrouve et appelle les fonctions d’initialisation propres au chipset ainsi que les fonctions de gestion des banks, puis configure la palette, initialise le frame buffer et renseigne les adresses destinées au VDD

Les modifications réelles de SVGAPatch

• SVGAPatch remplace par 2000 l’identifiant de fonction du premier chipset dans les trois listes de résolutions, puis écrase SetAndValidateMode et certaines fonctions spécifiques à des chipsets
• Les changements principaux sont les suivants
  • SetAndValidateMode : au lieu d’un réglage de mode via le BIOS VGA classique, demande un mode vidéo étendu via VBE 4F02h
  • SETBANK_TRIDENT : au lieu d’écrire dans des registres propres à Trident, déplace la fenêtre mémoire vidéo via VBE 4F05h
  • VIDEOINIT_TRIDENT : au lieu d’écrire dans le registre VGA CRTC Offset, règle la longueur de scan line via VBE 4F06h
• Après le patch, la première entrée de la liste des modes pris en charge réussit, et les fonctions réécrites associées à l’identifiant 2000 sont utilisées
• Si SYSTEM.INI enregistre toujours Tseng ET4000, c’est simplement parce que le nom de la première entrée de la liste est conservé, même si la valeur n’est pas réellement utilisée

Le VDD et DspDrvr_Addresses

• Le VDD virtualise le cas où les programmes DOS s’attendent à avoir un accès exclusif au matériel réel
• Chaque VM possède une instance de la structure VDD_CB_Struc, qui contient des drapeaux, un miroir de l’état du contrôleur VGA et des informations d’allocation mémoire vidéo propres à cette VM
• Le VDD inclut du code spécifique à certains constructeurs pour détecter un adaptateur VGA donné et changer la manière de sauvegarder, restaurer ou simuler certains registres
• DspDrvr_Addresses est un service par lequel le Display Driver transmet des informations d’adressage au VDD ; d’après les commentaires, DX est un champ réservé qui devrait valoir 0, mais dans le code réel du VDD VGA, il existe un comportement spécial lorsque DX n’est pas nul
• Le VDD SVGA introduit un nouveau chemin pour DX == 2, et SVGA256.DRV appelle cette fonction avec les valeurs suivantes
  • BX = 0xFFFF
  • DX = 2
  • DS:SI pointe vers l’octet d’état de la shadow memory

Réduire la cause avec DOSBox-X

• L’overlay de débogage vidéo et le débogueur de DOSBox-X ont servi à comparer l’état VGA avant et après les transitions vers l’invite DOS plein écran
• Les annotations de mode affichées et l’état des registres différaient entre une interface normale, un DOS normal, une interface corrompue et un DOS corrompu
• Pour vérifier si des drapeaux VDD spécifiques à un constructeur s’activaient à tort, DOSBox-X a été modifié afin de dumper la mémoire physique, mais dans DOSBox ces drapeaux n’étaient pas activés
• En comparant les registres VGA, on a vu que la valeur interne scan_len de DOSBox différait entre les états sains et corrompus
  • DOS normal : 40
  • DOS corrompu : 296
  • Interface normale : 128
  • Interface corrompue : 256
• L’implémentation de l’API VESA Scan Line dans DOSBox calculait scan_len différemment selon son interprétation du mode vidéo courant, ce qui a resserré l’enquête autour de ce point

L’indice décisif : réglage VBE de scan line en mode texte

• Après ajout d’un journal des appels de réglage VESA Scan Line dans DOSBox-X, l’appel suivant a été observé
  • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
  • Le mode courant est M_TEXT
• Le Display Driver règle bien la longueur de scan line à 1024 octets via VBE 4F06h, mais DOSBox considère à ce moment qu’il est en mode texte, ce qui fausse son état interne
• Au démarrage de Windows, le réglage de scan line s’effectue correctement en mode SVGA 800x600 avec l’état M_LIN8
• Après ouverture d’une invite DOS plein écran puis retour à l’interface avec Alt+Enter, le flux suivant se produit
  • Un certain code demande le passage en mode 30h, soit 48 en décimal
  • Le display driver patché règle la longueur de scan line alors que le système est en mode texte
  • L’état interne de DOSBox diverge de l’état dérivé des registres VGA
• Le mode 30h correspondait justement à la valeur de mode 800x600 du Tseng ET4000 détournée par SVGAPatch

Le chemin de changement d’écran qui manquait

• Le Display Driver de Windows 3.1 intercepte INT 2Fh pour recevoir les commandes de changement d’écran
• Le pilote VGA gère les quatre commandes suivantes, mais le pilote SVGA256 ne prend en charge que SCREEN_SWITCH_OUT et SCREEN_SWITCH_IN
  • SCREEN_SWITCH_OUT
  • SCREEN_SWITCH_IN
  • SAVE_DEV_REGS
  • RES_DEV_REGS
• La fonction en cause était dev_to_foreground, appelée au retour vers l’interface Windows
• Dans SVGA256, dev_to_foreground suit le chemin suivant
  • Appel de farsetmode
  • farsetmode règle le mode 48
  • Appel de VideoInit spécifique au chipset
  • enabled_flag est mis à 0xFF
  • Appel de l’API Windows SetPalette
• SVGAPatch avait remplacé le chemin de réglage du mode au démarrage par un chemin VBE, mais n’avait pas modifié le chemin qui reconfigure le mode lors d’un changement d’écran

Un patch supplémentaire améliore la restauration de l’interface

• Le code original de setmode était court : il chargeait wGraphicsMode dans ax, appelait INT 10h, puis appelait ptr_videoinit
• Un nouveau code a été inséré dans l’espace laissé libre derrière le SetAndValidateMode raccourci par SVGAPatch
  • Charge dans cx la valeur CurrentHeight - 1
  • Appelle SetAndValidateMode
  • Appelle ptr_videoinit
• La première instruction de setmode a été remplacée par un saut vers ce nouveau code, de sorte que les changements d’écran passent eux aussi par le chemin de réglage VBE
• Après cette modification, le retour à l’interface depuis une session DOS plein écran ne corrompt plus l’affichage
• En revanche, un problème subsiste avec la réapparition de points lors du passage du mode fenêtré au plein écran

Le problème restant de bank switching

• Dans le débogueur DOSBox, le contenu texte est bien présent dans la mémoire VGA B8000, mais n’apparaît pas à l’écran
• Le point suspect est devenu le bank switching utilisé par le pilote pour accéder à davantage de mémoire vidéo
• Après ajout dans DOSBox-X d’une commande affichant l’état des banks SVGA, il a été confirmé qu’au retour en plein écran, l’adaptateur VGA restait bloqué sur le mauvais bank
• Une nouvelle routine a été ajoutée dans dev_to_background pour remettre le bank à 0, mais cela n’a pas résolu le problème
• L’implémentation de VBE 4F05h dans DOSBox écrivait dans le registre VGA CRTC 0x6A, et lorsque dev_to_background était appelé, le VDD interceptait déjà les écritures, donc l’intervention arrivait trop tard

Résultats expérimentaux avec le pilote d’origine et le pilote patché

• Dans 86Box, des essais du pilote Microsoft SVGA 256 couleurs d’origine sur plusieurs cartes émulées ont donné des résultats irréguliers, y compris parmi les cartes officiellement prises en charge
  • Cirrus Logic GD5420 (ISA) : fonctionne
  • Tseng Labs ET4000AX : fonctionne
  • Oak OTI-077 : corruption à la première ouverture d’une invite DOS fenêtrée, barres verticales en plein écran
  • Trident TVGA 8900D : corruption en invite DOS plein écran, mode fenêtré normal
  • ATI VGA Wonder XL, Paradise PVGA1A et certaines résolutions de Video 7 VGA 1024i : échec du démarrage de Windows
• Il faut noter que 86Box ne propose pas exactement les mêmes cartes et que la fidélité de l’émulation n’est pas garantie
• Les essais du pilote basé sur SVGAPatch modifié, avec des cartes plus récentes, ont eux aussi varié selon le matériel
  • Matrox Millennium II : très lent, DOS fenêtré fonctionnel, plein écran corrompu
  • 3dfx Voodoo Banshee : l’ouverture d’un DOS fenêtré corrompt l’interface, mais le basculement plein écran fonctionne
  • S3 Trio3D/2X : écran corrompu au démarrage de Windows, mais après une invite DOS puis sortie du plein écran, le 1024x768 s’affiche correctement
  • 3dfx Voodoo3 3500 SI : proche de la Banshee, mais le plein écran ne fonctionne qu’une seule fois

État final sur l’Eee PC

• Sur le véritable Eee PC, l’interface graphique fonctionne normalement
• Le passage vers une invite DOS plein écran reste corrompu, mais d’une manière différente de DOSBox
• Dans DOSBox, on obtenait un mode texte rempli de caractères corrompus, tandis que sur l’Eee PC apparaissait plutôt une interface graphique corrompue avec certaines couleurs absentes
• Un retour en mode fenêtré permet de récupérer l’affichage
• Avec le SVGAPatch d’origine, le simple fait d’ouvrir une invite fenêtrée corrompait toute l’interface et imposait un redémarrage de l’OS ; le pilote modifié améliore nettement la situation
• Comme meilleure piste à l’avenir, le choix a été de suivre l’évolution de PluMGMK/vbesvga.drv, en développement actif

[GN⁺]

Avis sur Hacker News

• Indépendamment de la prise en charge SVGA, ce qui m’étonne toujours, c’est qu’en installant Windows 3.x sur un PC compatible avec les standards modernes, le VGA de base fonctionne immédiatement, alors que sur Linux/BSD modernes, sans le bon pilote ni fichier de configuration manuel, on ne peut même pas facilement utiliser un framebuffer VGA de base avec accélération logicielle dans Xorg/Wayland.
  Le défunt projet XFree86 a été la tentative la plus proche de ce « ça marche tout seul », mais il restait beaucoup de chemin à faire, et cette approche ne semble pas avoir été conservée dans le fork Xorg.

  • XFree86 ne faisait rien de différent de Xorg sur ce point.
    Si vous démarrez un PC moderne avec CSM, ce qui n’est pas recommandé, Xorg devrait exécuter le BIOS vidéo via x86emu et se lancer avec le backend VBE ; si vous démarrez en EFI, le modesetting basé sur efifb devrait se lancer sur le mode laissé par le firmware et le chargeur de démarrage.
    Mais c’est une tâche plus facile pour un système d’exploitation 16 ou 32 bits. Le paramétrage des modes VESA nécessite des appels 16 bits en mode réel et, même si un point d’entrée 32 bits existait nominalement dans les dernières versions du standard, presque personne ne l’a correctement implémenté. Une fois en mode 64 bits, vm86 n’est plus utilisable, donc on ne peut pas appeler du code 16 bits depuis l’espace utilisateur ; il faut alors x86emu, qui lit le code du BIOS vidéo et l’exécute dans un émulateur x86, mais ce n’est pas toujours parfait.
  • Linux dispose de vgafb/vesafb, donc c’est possible si la distribution est configurée correctement.
    Cela dit, l’expérience est généralement médiocre en performances et en qualité, et l’utilisateur peut ne pas en comprendre la cause ; c’est probablement pourquoi certaines distributions, voire la plupart, ne l’activent pas par défaut. Aujourd’hui, presque tous les GPU sont pris en charge nativement, donc il n’y avait sans doute pas non plus beaucoup de motivation à créer une pop-up disant « vous utilisez du VGA/VESA sans accélération, veuillez corriger cela ».
  • C’est lointain, mais je me souviens qu’il y avait pour X un pilote VGA générique qui « marchait tout seul ». Cela veut-il dire qu’il n’existe plus ?
  • X11 dispose depuis très longtemps d’un pilote VESA, mais le nombre de pixels à traiter augmente vite avec la résolution, donc les performances montent mal en charge.
    Les distributions Linux démarrables que j’utilise au travail, principalement GRML et Clonezilla, s’adaptent automatiquement pendant le démarrage à l’écran ou à la résolution native du KVM virtuel grâce à la prise en charge KMS, et fonctionnent assez bien. Anaconda, c’est-à-dire l’installateur des distributions de la famille RedHat, ainsi que l’installateur Debian, se règlent eux aussi sur la résolution native au démarrage.
    Les installateurs graphiques utilisent directement VESA au-dessus de X11.
    Le fork Xorg prend lui aussi en charge depuis longtemps le « démarrage sans fichier de configuration ». Cela fait très longtemps que je ne gère plus de fichier de configuration, et c’est bien plus satisfaisant. Voir https://www.xkcd.com/963/.
  • Je vois Xorg comme, en gros, XFree86 avec le système de build nettoyé.

• L’ancienne interface graphique de Windows 3.1 semble bien plus intuitive, efficace et agréable à utiliser que celles d’aujourd’hui.
  https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
  À quoi pourrait bien ressembler Win11 sur un écran aussi basse résolution que dans l’article ? Le menu Démarrer de Win11 est quasiment inutilisable, à part taper un mot-clé puis prier les circuits.
  Mon hypothèse naïve est que Windows NT et 2000 représentaient le point optimal, puis que les chefs de produit ont fait leur magie. KDE et Gnome ont assez peu changé, mais paraissent de plus en plus séduisants avec le temps :)

  • À mon avis, la dernière « bonne » version a été Windows 7. C’était similaire à NT/2000, mais plus joli grâce aux progrès du matériel graphique, tout comme XP avant lui. Vista avait aussi une UI correcte en soi ; ses défauts étaient ailleurs.
    Windows 8 a tout cassé, et Windows ne s’en est jamais remis. J’y vois deux raisons : l’essor des plateformes mobiles et la paresse de Microsoft.
    On se retrouve maintenant avec un problème difficile à résoudre : beaucoup d’applications ont une version desktop et une version mobile séparées. L’une est faite pour un grand écran avec clavier et souris, l’autre pour un petit écran tactile ; une bonne application desktop et une bonne application mobile devraient donc être complètement différentes. Mais on veut que les deux versions paraissent familières aux utilisateurs, donc même en faisant de son mieux, on aboutit à des compromis.
    Microsoft aurait quand même pu faire quelque chose de correct, mais ne l’a pas fait. Le Panneau de configuration le montre clairement. Le nouveau panneau, Paramètres, existe depuis Windows 8, donc depuis 12 ans, et pourtant il n’a toujours pas repris toutes les fonctions de l’ancien Panneau de configuration : les deux restent nécessaires. Il y a quelques mois, ils ont voulu tenter une transition complète, mais ce n’était pas prêt, et je ne sais pas si ça le sera un jour. En plus, ils suppriment souvent des options de personnalisation populaires, et le style n’est même pas cohérent entre les applications incluses. Ce n’est pas seulement discutable, c’est objectivement mauvais.
    Un autre facteur, qu’on ne peut pas imputer uniquement à Microsoft et Windows, est que les développeurs d’applications privilégient le branding et la cohérence interne plutôt que l’intégration au système d’exploitation. Beaucoup d’UI modernes ne sont que des pages web rendues par un moteur de navigateur comme Electron ; elles n’utilisent pas les contrôles natifs du système, ignorent les thèmes et dessinent elles-mêmes les décorations de fenêtre. Le système d’exploitation peut manquer de cohérence, mais les développeurs d’applications n’aident pas non plus.
  • Le flat design a été quasiment une catastrophe pour l’industrie. Le skeuomorphisme aussi était assez mauvais, puisqu’en pratique ce n’était que du flat design avec des images collées dessus.
    Windows Forms faisait beaucoup de choses correctement, et s’il fallait citer un symbole manquant, ce serait quelque chose comme « actif mais non modifiable ».
  • D’après ce qui se dit, Windows 11 serait à l’origine Windows 10X, qui était aussi conçu pour les téléphones et tablettes. Le menu Démarrer semble assez influencé par Android : il affiche tout ce qui est installé de façon plate et pousse davantage à utiliser la recherche.
    Cela dit, je suis d’accord. Les bêtas de Win10 avaient une forme mêlant tuiles et liste à la Windows 7, une approche qui remontait jusqu’à Windows 2000, et je pense que c’était le sommet. On aurait pu avoir le meilleur des deux. La zone de notification a toujours été faible, et le panneau Paramètres est médiocre comparé au Panneau de configuration. Bien sûr, le Panneau de configuration lui-même était fouillis et complexe, donc on peut discuter du fait qu’il ait été la meilleure solution.

• L’auteur dit que l’affichage se corrompt quand il ouvre l’invite DOS en mode fenêtré ; cela peut venir du fait que l’invite DOS s’exécute dans une VM séparée, c’est-à-dire en mode V86, et appelle le VGA ROM BIOS via INT 10h.
  Le VGA ROM BIOS de cette machine est probablement un wrapper au-dessus de VBE, ce qui signifie qu’il devait contenir des instructions IN/OUT accédant aux ports d’E/S VBE 0x1CE et 0x1CF. Ces lectures et écritures déclenchées depuis la VM DOS atteignent par défaut le vrai matériel si le VMM ne les virtualise pas.
  C’était un problème courant que les auteurs de pilotes d’affichage Windows 3.x/9x devaient gérer, mais les numéros de ports d’E/S à virtualiser variaient selon l’adaptateur graphique. Le DDK Win95 contient un exemple qui configure des traps de ports d’E/S avec les services VMM Install_IO_Handler et Enable/Disable_Global_Trapping, puis utilise VDD_Get_VM_Info dans le gestionnaire de trap pour déterminer quelle VM possède actuellement le CRTC. Cela permet au gestionnaire de trap de décider s’il faut envoyer l’E/S au matériel, ou comment la virtualiser. Comme politique de virtualisation de départ, une bonne approche consiste à simplement ignorer les écritures provenant d’une VM qui ne possède pas le CRTC, puis à ajouter la complexité nécessaire ensuite.

• Virtual Display Device (VDD) s’exécute comme une partie du gestionnaire de machines virtuelles sous-jacent et agit comme un multiplexeur pour le matériel vidéo. Si une application DOS est en plein écran, ses commandes sont transmises directement au « vrai » adaptateur VGA ; sinon, le VDD les émule.
  C’est intéressant de voir d’autres personnes redécouvrir cette architecture. Personnellement, je la trouve assez en avance sur son temps, antérieure aux hyperviseurs modernes avec passthrough matériel. L’interface graphique Windows 3.x elle-même, avec ses processus multitâches préemptifs, s’exécute en fait comme un processus DOS en mode protégé étendu dans une VM où tourne DOS, tandis que le noyau hyperviseur VMM32 multiplexe cette VM et les autres VM de processus DOS. Ainsi, une partie du pilote d’affichage interagit avec le « matériel » sous GDI, et une autre partie virtualise le matériel en ring 0 pour le multiplexer avec les autres VM.
  Cela pourrait être corrigé dans DOSBox, mais le correctif serait lié à l’adaptateur vidéo particulier que DOSBox émule. Ce qu’on veut, ce n’est pas ça, mais rendre le patch VBE générique plus fiable.
  J’ai déjà écrit un pilote de framebuffer VESA Win9x pour Intel GMA950 et ajouté une accélération de base, c’est-à-dire des commandes de blit et de remplissage ; je me suis retrouvé face au même problème et j’ai compris pourquoi Win9x n’avait pas de pilote VESA générique. Le VDD doit savoir comment sauvegarder et restaurer l’état du GPU, et ces détails dépendent évidemment du fournisseur. J’avais aussi réfléchi à des idées génériques, par exemple émuler ou tracer le VBIOS pour voir quels ports et MMIO il touche à chaque changement de mode, mais je ne suis pas allé jusqu’à l’implémentation.
  Dans DOSBox, on obtient un mode texte rempli de caractères cassés ; sur l’Eee PC, une interface graphique abîmée où certaines couleurs disparaissent.
  Cela ressemble à des registres de palette qui ne sont pas correctement sauvegardés/restaurés. Par ailleurs, la corruption en haut de l’écran peut être évitée en déplaçant le plan d’affichage haute résolution au-delà de 256 K, afin de laisser les premiers 256 K de VRAM aux plans VGA et à l’émulation VGA. Heureusement, Intel GMA dispose d’une documentation publique assez fournie. Ce ne sont pas les documents des 900 et 950, mais ceux des 810/815 et des modèles à partir du 965 ; toutefois, la plupart des registres et commandes n’ont pas changé, donc on peut s’y référer pour les détails.

• « La plupart des distributions Linux modernes ne tournent pas non plus dessus faute de prise en charge x86_64 », mais mon Eee tient très bien avec Debian 32 bits.
  Firefox est trop lourd et rame presque inutilisablement, mais le streaming vidéo avec mpv fonctionne suffisamment bien. Je m’en sers surtout comme machine à écrire avec peu de distractions, capable de lancer pandoc quand j’ai du retard sur du travail de livre.

  • Je suis totalement d’accord sur l’intérêt d’un ordinateur avec un minimum de distractions pour écrire. Pour cet usage, j’utilise WordPerfect 5.1 sur un PS/2 386SX.
    J’aimais beaucoup l’EEE pour son excellente portabilité, mais je trouve son clavier trop petit pour taper sérieusement.
  • Si c’est pour s’en servir sans web ni applications modernes, quelque chose comme Haiku OS pourrait être un cas d’usage intéressant.
    Je l’ai essayé sur PC ; il manque clairement de logiciels disponibles pour devenir un véritable OS du quotidien, mais pour des usages à faible connectivité comme machine à écrire et mail, il m’a semblé très agréable.
    J’ai aimé la cohérence de l’UI, des logiciels de base et même du système de fichiers. Si j’ai bien compris, le système de fichiers est la représentation de toutes les données, les « fichiers » peuvent avoir des métadonnées arbitraires, et on peut presque tout faire depuis le gestionnaire de fichiers. Tout le système de fichiers ressemble à une base de données NoSQL, et les applications l’adoptent naturellement. Les contacts sont des « fichiers » dans un dossier, les mails aussi, etc.
    Je n’avais jamais touché à BeOS à l’époque, mais dans les années 90, quand la connectivité était faible, ce paradigme devait plutôt bien fonctionner. Le fait de rédiger un « fichier » mail hors ligne, de le glisser-déposer vers un lecteur de disquette, puis de l’envoyer depuis un autre ordinateur connecté à Internet, le tout uniquement via le gestionnaire de fichiers, était étonnamment cohérent.
    Malheureusement, dès qu’il faut interopérer avec d’autres ordinateurs non compatibles avec le système de fichiers BeOS/Haiku, l’utilité de ce paradigme diminue. Statistiquement, c’est le cas de presque tous les ordinateurs.
    Mais pour une machine dédiée à l’écriture, cela pourrait être intéressant.
  • À ma connaissance, Debian va supprimer la prise en charge du x86 32 bits dans sa prochaine version.
  • J’avais un 1215B, mais il est mort l’an dernier, et maintenant une tablette Android l’a remplacé.
    Les tablettes semblent avoir balayé le segment de marché des netbooks. Les ultraportables et les 2-en-1 existent encore, mais ils sont plutôt à l’opposé en termes de gamme de prix.

• Le titre m’a un peu embrouillé.
  Cela dit, chaque fois que je lis comment les anciens Windows basés sur DOS fonctionnaient en interne, je suis toujours impressionné. Tout semble tenu avec du ruban adhésif logiciel, et pourtant, d’une manière ou d’une autre, ça marche.

  • Écoutez Casey Muratori là-dessus. L’idée, c’est qu’on a construit un énorme tas d’abstractions qui ne sont pas vraiment nécessaires et ne font que dégrader les performances.

• Quand l’ET4000H est sorti, je me souviens qu’il n’était pas pris en charge par Windows 3.1 à l’époque. J’ai appelé le support technique de MS, ils m’ont envoyé une disquette de pilotes, et elle est arrivée 8 heures plus tard
  C’est le meilleur support que j’aie jamais reçu pour un produit piraté

  • Pour être précis, l’ET4000H était identique à l’ET4000ax, déjà pris en charge par Windows 3.0 et 3.1, mais il embarquait un HiDAC au lieu d’un DAC 256 couleurs, c’est-à-dire du true color 15/16 bits
    Mes souvenirs sont flous, mais je crois que le mode 16 couleurs fonctionnait avec le pilote de base, tandis que le 256 couleurs et au-delà ne marchait pas, et le choix des résolutions était peut-être aussi limité
    D’après MS, le pilote prenant en charge le HiDAC est sorti la troisième semaine d’avril 1992, soit une à deux semaines après la date dont je me souviens, donc ça semble globalement cohérent

• C’est amusant. J’ai le petit modèle, un EEEPC 701, et il fonctionne encore, mais je n’avais jamais pensé à m’en servir pour du rétrogaming
  Le mien prend juste la poussière, mais ce serait sans doute amusant d’essayer ce genre de choses

  • Il parle sans doute du 701. 207g n’est pas un nom de modèle d’Eee PC

• En comparant distraitement les petites annotations, on voit le changement d’état suivant, après l’avoir probablement fixé jusqu’à saturation sémantique
  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
  Dans le motif, le DOS cassé et le GUI cassé sont à 200 ou 250, tandis que les états fonctionnels sont à 100 ou 050. Qu’est-ce que c’est que cette adresse ?
  Le GUI cassé est en quelque sorte en mode M_VGA, pas en LIN8. Comment et pourquoi est-ce arrivé, et est-ce lié au fait qu’il soit passé à 400x600, soit la moitié de la largeur de 800x600 ? Le vrai « mode texte », comme on le voit dans les deux modes DOS, est en 720x400

• Je ne sais pas si l’auteur verra ceci, mais j’ai signalé cet article à l’auteur du patch
  https://www.bttr-software.de/forum/board_entry.php?id=22124#...