Ein Hund gegen den Windows-3.1-Grafik-Stack

 (wuffs.org)
2 Punkte von GN⁺ 2025-01-06 | 1 Kommentare | Auf WhatsApp teilen
  • Beim Versuch, Windows 3.11 auf einem Asus Eee PC 1000H von 2008 an den 1024x600-Bildschirm anzupassen, zeigten sich die Grenzen des Standard-VGA-Treibers und des Microsoft-Super-VGA-Treibers mit 256 Farben
  • Die Super-VGA-Unterstützung von Windows 3.x basierte nicht auf einem gemeinsamen Standard, sondern auf herstellerspezifischen Erweiterungen pro Grafikkarte; der Intel GMA 950 des Eee PC wurde daher nicht unterstützt
  • SVGAPatch modifiziert Microsofts svga256.drv so, dass es VBE-Aufrufe nutzt und damit hochauflösende 256-Farben-Ausgabe ermöglicht, ließ aber weiterhin ein Problem zurück, bei dem die GUI nach einem Wechsel zu einem DOS-Bildschirm beschädigt wurde
  • Die Reverse-Engineering-Analyse zeigte: Die anfängliche Moduseinstellung war zwar auf VBE umgestellt, aber der Neukonfigurationspfad beim Bildschirmwechsel rief weiterhin den Modus 30h für den Tseng ET4000 sowie die VBE-Scan-Line-Einstellung im Textmodus auf
  • Ein zusätzlicher Patch verringerte die Darstellungsfehler beim Zurückkehren aus einer DOS-Vollbildsitzung zur GUI, löste jedoch den Bank-Switching-Zustand nicht vollständig; auf dem echten Eee PC reichte es letztlich nur für die Wiederherstellung von GUI und Fenstermodus

Windows-3.11-Grafik auf dem Eee PC wiederbeleben

  • Das Zielgerät ist ein Asus Eee PC 1000H, gekauft im Jahr 2008; wegen fehlender x86_64-Unterstützung lassen sich die meisten aktuellen Linux-Distributionen kaum noch darauf ausführen
  • Ziel war es, auf diesem Netbook Windows 3.11 for Workgroups mit besserer Videoausgabe zu betreiben
  • Die Standardausgabe ist VGA 640x480 mit 16 Farben, was auf einem 1024x600-Display weder gut aussieht noch zum Seitenverhältnis passt
  • Das Installationsprogramm von Windows 3.11 enthält Treiber für ältere Videoadapter, aber den Intel GMA 950 des Eee PC unterstützt es nicht
  • Der enthaltene Super-VGA-Treiber scheint bis zu 1024x768 mit 256 Farben zu unterstützen, erzeugt in dieser Umgebung jedoch Fehler und verhindert den Start von Windows

Unterschiede zwischen VGA, SVGA und VBE

  • VGA ist ein konkreter Videocontroller, den IBM in den 1980er-Jahren entworfen hat, und bedeutet nicht einfach einen blauen analogen Anschluss oder die Auflösung 640x480
  • SVGA war weniger ein Standard als vielmehr ein Sammelbegriff für „mehr als normales VGA“, sodass Software die proprietären Erweiterungen jeder Karte direkt unterstützen musste
  • In Microsofts Unterstützungsliste für den 256-Farben-SVGA-Treiber stehen folgende Familien
    • 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) stellt eine gemeinsame Schnittstelle für Funktionen außerhalb von VGA bereit, aber Windows 3.x enthielt keinen direkten VBE-Treiber
  • BearWindows’ VBE9x und VBEMP ermöglichen die Nutzung von VBE unter Windows 9x beziehungsweise NT, aber es gibt keine Version für Windows 3.x

Was SVGAPatch löst — und was nicht

  • SVGAPatch patcht Microsofts 256-Farben-Super-VGA-Treiber, damit er VBE verwendet
  • Der gepatchte Treiber kann Bildschirme wie 1024x600 korrekt darstellen, verursacht aber Konflikte bei der DOS-Kompatibilität
  • Der Enhanced Mode von Windows 3.1 kann grafische Windows-Anwendungen und DOS-Programme gleichzeitig ausführen; auch eine DOS-Eingabeaufforderung lässt sich im Fenster oder im Vollbild öffnen
  • Nach Anwendung von SVGAPatch ließ sich Folgendes reproduzieren
    • Wechselt man in den DOS-Vollbildmodus und kehrt dann zur Windows-GUI zurück, wird die Anzeige beschädigt
    • In manchen Fällen reicht schon das Öffnen einer DOS-Eingabeaufforderung im Fenstermodus, um die Anzeige zu beschädigen
    • Das Problem tritt in DOSBox, 86Box und auf dem echten Eee PC auf, allerdings jeweils mit leicht unterschiedlichem Fehlerbild
  • Ein separater neuer Treiber, PluMGMK/vbesvga.drv, unterstützt sogar True-Color-Modi, doch hier konzentriert sich die Analyse darauf, den Microsoft-Code und SVGAPatch zu korrigieren

Aufbau des Windows-3.x-Grafik-Stacks

  • Im Enhanced Mode von Windows 3.x erstellt der 32-Bit-Virtual Machine Manager mehrere VMs; innerhalb der ersten VM läuft dann Windows im Standard Mode
  • Wenn man im Windows Setup einen Videoadapter auswählt, wird nicht nur ein einzelner Treiber installiert, sondern mehrere Komponenten zusammen
    • Grabber: vermutlich zuständig für das Rendering von DOS-Anwendungen im Fenstermodus
    • Display Driver: zuständig für Hardwareinitialisierung und GUI-Rendering in der Haupt-Windows-VM; unter Windows 3.x implementiert er auch einen großen Teil der GDI selbst
    • Virtual Display Device (VDD): läuft als Teil des Virtual Machine Manager und multiplexiert zwischen DOS-Anwendungen und der echten VGA-Hardware
  • Die 256-Farben-SVGA-Einträge verwenden denselben Treiber und unterscheiden sich über Auflösungs- und DPI-Einstellungen in SYSTEM.INI
  • SVGAPatch ändert nur den Display Driver und lässt das SVGA-VDD unangetastet
  • Um die Ursache der Darstellungsfehler einzugrenzen, musste letztlich das Zusammenspiel von Display Driver, VDD und den inoffiziellen Änderungen durch SVGAPatch gemeinsam verstanden werden

Verwendete Quellen und Werkzeuge für das Reverse Engineering

  • Als Referenzen dienten Windows 3.x VDDVGA und das Windows 3.1 DDK
  • Das Windows 3.1 DDK enthält folgende Quellen
    • VGA-, IBM-8514-, Video-7- und 16-Farben-SVGA-Display-Driver-Quellen
    • VGA-, IBM-8514-, Video-7- und 16-Farben-SVGA-VDD-Quellen
    • Quellcode für fast alle Grabber
    • sehr wenig Dokumentation
  • Ausgerechnet die benötigten Quellen für den 256-Farben-SVGA-Display-Driver und das zugehörige VDD fehlen jedoch
  • Für die Analyse von svga256.drv und vddsvga.386 kamen IDA und Ghidra zum Einsatz
  • Ghidra konnte .drv lesen, für das VDD als VxD war jedoch ein separater LX-Loader nötig; außerdem gab es Einschränkungen beim Umgang mit Dateien, die 32-Bit- und 16-Bit-Code mischen

Analyse des Inneren von svga256.drv

  • svga256.drv exportiert Funktionen wie GETCHARWIDTH, STRETCHBLT und VIDEOINIT_ATI, wodurch sich Vergleiche mit den DDK-Quellen anstellen ließen
  • Einige Funktionen waren fast identisch zum VGA-Treiber-Quellcode, bei anderen fehlten Unterschiede wie etwa die Korrektur der Breite fetter Schrift in GETCHARWIDTH
  • In REALIZEOBJECT zeigten sich Abweichungen, als sei Code aus dem VGA-Treiber und dem Video-7-Treiber vermischt worden; auch die Farbverarbeitung unterschied sich
  • Da sich die Interaktion mit dem Videoadapter nicht allein durch GDI-Funktionen erklären ließ, führte die Analyse weiter zum Initialisierungspfad physical_enable

physical_enable und die Arbeitsweise des Microsoft-SVGA-Treibers

  • Wählt man in Windows Setup „Super VGA (800x600, 256 colours, small fonts)“, werden in SYSTEM.INI folgende Werte eingetragen
    • dpi=96
    • resolution=2
  • Der gepatchte Treiber schreibt nach dem Booten zusätzlich diese Werte
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable ist die zentrale Initialisierungsfunktion, die den Videomodus setzt und eine Liste unterstützter Modi durchsucht, um einen funktionierenden chipsatzspezifischen Modus zu finden
  • Die ursprüngliche Microsoft-Logik hält pro Auflösung Tabellen unterstützter Modi vor und testet jeden Modus mit SetAndValidateMode
  • Bei Erfolg sucht und ruft sie chipsatzspezifische Initialisierungsfunktionen sowie Bank-Setz-Funktionen auf und führt anschließend Palettenkonfiguration, Framebuffer-Initialisierung und das Setzen von VDD-Adressen durch

Die tatsächlichen Änderungen durch SVGAPatch

  • SVGAPatch ändert in den drei Auflösungslisten die Funktions-ID des ersten Chipsatz-Eintrags auf 2000 und überschreibt SetAndValidateMode sowie einige chipsatzspezifische Funktionen
  • Die Kernänderungen sind
    • SetAndValidateMode: Anstelle der bisherigen modussetzenden VGA-BIOS-Logik wird über VBE 4F02h ein erweiterter Videomodus angefordert
    • SETBANK_TRIDENT: Statt in Trident-spezifische Register zu schreiben, wird über VBE 4F05h das Video-Speicherfenster umgeschaltet
    • VIDEOINIT_TRIDENT: Statt den VGA-CRTC-Offset-Register zu beschreiben, wird über VBE 4F06h die Scan-Line-Länge gesetzt
  • Nach dem Patch ist der erste Eintrag der Unterstützungsliste erfolgreich, und die umgeschriebenen Funktionen, die an Funktions-ID 2000 hängen, werden verwendet
  • Dass in SYSTEM.INI Tseng-ET4000-Werte eingetragen werden, liegt daran, dass der Name des ersten Listeneintrags unverändert gespeichert wird, auch wenn der Wert tatsächlich nicht benutzt wird

VDD und DspDrvr_Addresses

  • Das VDD virtualisiert Situationen, in denen DOS-Programme erwarten, exklusiven Zugriff auf die echte Hardware zu haben
  • Jede VM besitzt eine Instanz der Struktur VDD_CB_Struc, die Flags, gespiegelten VGA-Controller-Zustand und Informationen über die pro VM zugewiesene Videospeicherbelegung enthält
  • Im VDD gibt es herstellerspezifischen Code, der bestimmte VGA-Adapter erkennt und die Art des Speicherns, Wiederherstellens oder Simulierens bestimmter Register verändert
  • DspDrvr_Addresses ist ein Dienst, mit dem der Display Driver Adressinformationen an das VDD übergibt; laut Kommentar ist DX ein reserviertes Feld und sollte 0 sein, aber der echte VGA-VDD-Code enthält Spezialverhalten für den Fall, dass DX ungleich 0 ist
  • Im SVGA-VDD gibt es einen neuen Pfad für DX == 2, und SVGA256.DRV ruft diese Funktion mit folgenden Werten auf
    • BX = 0xFFFF
    • DX = 2
    • DS:SI zeigt auf ein Status-Byte für Shadow Memory

Eingrenzung der Ursache mit DOSBox-X

  • Mithilfe des Video-Debug-Overlays und des Debuggers von DOSBox-X wurden die VGA-Zustände vor und nach dem Wechsel in eine DOS-Vollbild-Eingabeaufforderung verglichen
  • Die angezeigten Moduskommentare und Registerzustände unterschieden sich zwischen intakter GUI, intaktem DOS, beschädigter GUI und beschädigtem DOS
  • Um zu prüfen, ob herstellerspezifische VDD-Flags fälschlich gesetzt wurden, wurde DOSBox-X so modifiziert, dass physischer Speicher gedumpt werden konnte; in DOSBox waren diese Flags jedoch nicht gesetzt
  • Beim Vergleich der VGA-Register zeigte sich, dass sich der interne scan_len-Wert von DOSBox zwischen intakten und beschädigten Zuständen unterschied
    • In intaktem DOS: 40
    • In beschädigtem DOS: 296
    • In intakter GUI: 128
    • In beschädigter GUI: 256
  • Die Implementierung der VESA-Scan-Line-API in DOSBox berechnete scan_len je nach Einschätzung des aktuellen Videomodus unterschiedlich; genau dieser Punkt rückte dadurch in den Mittelpunkt des Verdachts

Der entscheidende Hinweis: VBE-Scan-Line-Setzung im Textmodus

  • Nachdem DOSBox-X um ein Logging der VESA-Scan-Line-Setzung erweitert wurde, tauchte folgender Aufruf auf
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • Der aktuelle Modus war M_TEXT
  • Der Display Driver setzt die Scan-Line-Länge über VBE 4F06h auf 1024 Byte, aber DOSBox betrachtet den aktuellen Zustand weiterhin als Textmodus und berechnet dadurch seinen internen Zustand falsch
  • Beim Windows-Start wird die Scan-Line-Einstellung im Zustand 800x600 SVGA und M_LIN8 korrekt ausgeführt
  • Öffnet man eine DOS-Vollbild-Eingabeaufforderung und kehrt dann mit Alt+Enter zur GUI zurück, läuft folgender Ablauf ab
    • Irgendein Code fordert einen Wechsel in Modus 30h, also dezimal 48, an
    • Der gepatchte Display Driver setzt im Textmodus die Scan-Line-Länge
    • Der interne DOSBox-Zustand und der aus den VGA-Registern abgeleitete Zustand laufen auseinander
  • Modus 30h war genau der 800x600-Modus des Tseng ET4000, den SVGAPatch kapert

Der fehlende Bildschirmwechselpfad

  • Der Windows-3.1-Display-Driver hookt INT 2Fh, um Befehle zum Bildschirmwechsel entgegenzunehmen
  • Der VGA-Treiber behandelt alle vier folgenden Befehle, aber der SVGA256-Treiber unterstützt nur SCREEN_SWITCH_OUT und SCREEN_SWITCH_IN
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • Die problematische Funktion war dev_to_foreground, die beim Zurückkehren zur Windows-GUI aufgerufen wird
  • In SVGA256 arbeitet dev_to_foreground nach folgendem Ablauf
    • Aufruf von farsetmode
    • farsetmode setzt Modus 48
    • Aufruf des chipsatzspezifischen VideoInit
    • Setzen von enabled_flag auf 0xFF
    • Aufruf der Windows-API SetPalette
  • SVGAPatch hat zwar beim Initialisierungspfad die Modussetzung auf VBE umgestellt, aber den Pfad, der beim Bildschirmwechsel den Modus erneut setzt, nicht angepasst

Verbesserte GUI-Wiederherstellung durch zusätzlichen Patch

  • Der ursprüngliche setmode-Code war kurz aufgebaut: wGraphicsMode in ax laden, INT 10h aufrufen und danach ptr_videoinit aufrufen
  • In den nach der Verkürzung von SetAndValidateMode freien Platz fügte SVGAPatch neuen Code ein
    • Den um 1 verringerten Wert von CurrentHeight in cx laden
    • SetAndValidateMode aufrufen
    • ptr_videoinit aufrufen
  • Der erste Befehl von setmode wurde so geändert, dass er in den neuen Code springt, damit auch beim Bildschirmwechsel der VBE-basierte Modussetzungspfad verwendet wird
  • Nach dieser Änderung wurde die Anzeige nicht mehr beschädigt, wenn man eine DOS-Vollbildsitzung öffnete und anschließend zur GUI zurückkehrte
  • Allerdings blieb das Problem bestehen, dass beim Wechsel vom Fenster- in den Vollbildmodus wieder Artefakte erschienen

Das verbleibende Bank-Switching-Problem

  • Im DOSBox-Debugger war beim Blick auf den VGA-Speicher B8000 zu sehen, dass der Textinhalt vorhanden war, auf dem Bildschirm jedoch nicht sichtbar wurde
  • Der Verdacht richtete sich auf Bank Switching, das der Treiber verwendet, um auf mehr Videospeicher zuzugreifen
  • Nachdem DOSBox-X um einen Befehl zur Ausgabe des SVGA-Bankzustands erweitert wurde, zeigte sich, dass der VGA-Adapter beim Zurückkehren ins Vollbild auf der falschen Bank stehen blieb
  • In dev_to_background wurde zwar eine neue Routine eingefügt, die die Bank auf 0 zurücksetzen sollte, doch das Problem ließ sich damit nicht beheben
  • Die Implementierung von VBE 4F05h in DOSBox schrieb in das VGA-CRTC-Register 0x6A; wenn dev_to_background aufgerufen wurde, befand sich das VDD jedoch bereits in einem Zustand, in dem es Schreibzugriffe abfing — zu spät also

Versuchsergebnisse mit Original- und Patch-Treiber

  • Tests des originalen Microsoft-SVGA-Treibers mit 256 Farben in 86Box auf mehreren emulierten Karten ergaben selbst innerhalb der Unterstützungsliste uneinheitliche Resultate
    • Cirrus Logic GD5420 (ISA): funktioniert
    • Tseng Labs ET4000AX: funktioniert
    • Oak OTI-077: Beim ersten Öffnen einer DOS-Eingabeaufforderung im Fenstermodus wird die Anzeige beschädigt, im Vollbild erscheinen vertikale Linien
    • Trident TVGA 8900D: Anzeige im DOS-Vollbild beschädigt, Fenstermodus normal
    • ATI VGA Wonder XL, Paradise PVGA1A und manche Auflösungen der Video 7 VGA 1024i: Windows startet nicht
  • Es gibt Hinweise darauf, dass 86Box nicht exakt dieselben Karten anbietet und die Emulationsgenauigkeit nicht gesichert ist
  • Auch Tests des modifizierten, auf SVGAPatch basierenden Treibers mit neueren Karten lieferten je nach Karte unterschiedliche Ergebnisse
    • Matrox Millennium II: sehr langsam; DOS im Fenstermodus funktioniert, Vollbild ist beschädigt
    • 3dfx Voodoo Banshee: Beim Öffnen von DOS im Fenstermodus wird die GUI beschädigt, Vollbildwechsel funktioniert jedoch
    • S3 Trio3D/2X: Beim Windows-Start erscheint eine beschädigte Anzeige, aber nach einer DOS-Eingabeaufforderung und dem Verlassen des Vollbilds wird 1024x768 korrekt dargestellt
    • 3dfx Voodoo3 3500 SI: ähnlich wie die Banshee, aber Vollbild funktioniert nur einmal

Endzustand auf dem Eee PC

  • Auf dem echten Eee PC funktioniert die GUI normal
  • Der Wechsel in eine DOS-Vollbild-Eingabeaufforderung bleibt weiterhin fehlerhaft, zeigt sich aber anders als in DOSBox
  • In DOSBox erschien ein Textmodus mit vielen beschädigten Zeichen, auf dem Eee PC dagegen eine beschädigte GUI mit teils fehlenden Farben
  • Ein Zurückwechseln in den Fenstermodus stellt die Anzeige wieder her
  • Mit dem ursprünglichen SVGAPatch reichte schon das Öffnen einer Eingabeaufforderung im Fenstermodus, um die gesamte GUI zu beschädigen und einen Neustart des OS nötig zu machen; der modifizierte Treiber stellt hier eine deutliche Verbesserung dar
  • Als bessere langfristige Lösung fiel die Entscheidung, die aktiv weiterentwickelte PluMGMK/vbesvga.drv weiter im Blick zu behalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-06
Hacker-News-Kommentare

  • Unabhängig von der SVGA-Unterstützung ist es immer wieder erstaunlich, dass auf einem PC mit Unterstützung für aktuelle Standards beim Installieren von Windows 3.x sofort das grundlegende VGA funktioniert, während man unter modernem Linux/BSD ohne passenden Treiber und manuelle Konfigurationsdatei in Xorg/Wayland oft nicht einmal den einfachen softwarebeschleunigten VGA-Framebuffer leicht nutzen kann
    Das eingestellte Projekt XFree86 war wohl der Versuch, der diesem „einfach funktioniert“ am nächsten kam, hatte aber noch einen langen Weg vor sich, und dieser Ansatz scheint im Xorg-Fork nicht erhalten geblieben zu sein

    • Auch XFree86 hat hier nichts anders gemacht als Xorg
      Wenn auf einem modernen PC mit CSM gebootet wird, sollte Xorg zwar nicht unbedingt empfohlen werden, aber es muss das Video-BIOS mit x86emu ausführen und mit dem VBE-Backend starten; bei einem EFI-Boot muss ein efifb-basiertes Modesetting auf dem Modus aufsetzen, den Firmware und Bootloader hinterlassen haben
      Das ist allerdings für 16-Bit- oder 32-Bit-Betriebssysteme einfacher. Das Setzen von VESA-Modi erfordert 16-Bit-Aufrufe im Real Mode, und obwohl es gegen Ende des Standards nominell einen 32-Bit-Einstiegspunkt gab, wurde dieser fast nirgends korrekt implementiert. Sobald man in den 64-Bit-Modus wechselt, kann man vm86 nicht mehr verwenden und deshalb aus dem Userspace keinen 16-Bit-Code aufrufen. Daher braucht man x86emu, das den Video-BIOS-Code liest und in einem x86-Emulator ausführt, was aber nicht immer perfekt funktioniert
    • Unter Linux gibt es vgafb/vesafb, daher ist das möglich, wenn die Distribution passend konfiguriert ist
      Allerdings ist die Erfahrung meist leistungsschwach und qualitativ schlecht, und Nutzer wissen womöglich nicht, woran es liegt. Deshalb aktivieren manche oder die meisten Distributionen das wohl nicht standardmäßig. Heute werden fast alle GPUs nativ unterstützt, daher gab es vermutlich auch keinen Anreiz, ein Popup zu bauen mit dem Hinweis „Sie verwenden unge­beschleunigtes VGA/VESA, bitte beheben“
    • Es ist lange her, aber ich erinnere mich, dass es für X einen allgemeinen VGA-Treiber gab, der „einfach funktionierte“. Heißt das, den gibt es jetzt nicht mehr?
    • X11 hatte schon vor langer Zeit einen VESA-Treiber, aber die Zahl der zu verarbeitenden Pixel steigt mit der Auflösung schnell an, daher skaliert die Leistung schlecht
      Die bootfähigen Linux-Distributionen, die ich beruflich nutze, vor allem GRML und Clonezilla, passen sich dank KMS während des Bootens automatisch an die native Auflösung des Bildschirms oder eines virtuellen KVM an und funktionieren ziemlich gut. Auch Anaconda, also das Installationsprogramm der RedHat-Familie, und das Debian-Installationsprogramm stellen beim Booten auf die native Auflösung um
      GUI-Installer verwenden VESA direkt über X11
      Der Xorg-Fork unterstützt ebenfalls schon lange „Booten ohne Konfigurationsdatei“. Ich verwalte schon sehr lange keine Konfigurationsdateien mehr, und das ist viel zufriedenstellender. Siehe https://www.xkcd.com/963/
    • Ich würde Xorg als XFree86 mit aufgeräumtem Build-System betrachten

  • Die frühere Windows-3.1-GUI wirkt viel intuitiver, effizienter und angenehmer zu benutzen als heutige Oberflächen
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    Wie würde Win11 auf einem Bildschirm mit so niedriger Auflösung wie im Artikel überhaupt aussehen? Das Startmenü von Win11 ist kaum zu gebrauchen, außer man tippt Schlüsselwörter ein und betet zur Schaltung
    Meine naive Hypothese ist, dass Windows NT und 2000 das Optimum waren und danach Produktmanager Magie betrieben haben. KDE und Gnome haben sich nicht besonders verändert, wirken aber mit der Zeit immer attraktiver :)

    • Ich würde sagen, die letzte „gute“ Version war Windows 7. Ähnlich wie NT/2000, aber dank besserer Grafikhardware schöner, und das galt auch schon für XP davor. Auch Vista war als UI an sich in Ordnung; die Probleme lagen woanders
      Windows 8 hat alles ruiniert, und Windows hat sich davon nicht erholt. Ich denke, das hat zwei Gründe: den Aufstieg mobiler Plattformen und Microsofts Trägheit
      Jetzt gibt es das schwer lösbare Problem, dass viele Apps eine Desktop-Version und eine mobile Version getrennt haben. Das eine ist für große Bildschirme und Tastatur/Maus, das andere für kleine Touchscreens, also müssen gute Desktop-Apps und gute mobile Apps eigentlich völlig verschieden sein. Gleichzeitig will man aber, dass sich beide Versionen für Nutzer vertraut anfühlen, sodass selbst im besten Fall Kompromisse entstehen
      Microsoft hätte das trotzdem ordentlich hinbekommen können, hat es aber nicht getan. Man sieht es am Control Panel. Die neue Systemsteuerung, also Einstellungen, gibt es seit Windows 8, also seit 12 Jahren, und trotzdem wurden bis heute nicht alle Funktionen der alten Systemsteuerung dorthin übertragen, sodass man immer noch beide braucht. Vor ein paar Monaten wollte Microsoft offenbar den vollständigen Umstieg versuchen, war aber nicht bereit, und ob das jemals gelingt, ist fraglich. Dazu kommt, dass oft beliebte Anpassungsoptionen entfernt werden und der Stil zwischen den mitgelieferten Apps uneinheitlich ist. Das ist nicht nur umstritten, sondern objektiv schlecht
      Ein weiterer Faktor, für den nicht nur Microsoft und Windows verantwortlich sind, ist, dass App-Entwickler Branding und interne Konsistenz höher gewichten als die Integration ins Betriebssystem. Viele moderne UIs sind nur noch Webseiten, die von Browser-Engines wie Electron gerendert werden, nutzen keine nativen Betriebssystem-Steuerelemente, ignorieren Themes und zeichnen sogar die Fensterdekoration selbst. Das Betriebssystem mag uneinheitlich sein, aber die App-Entwickler helfen auch nicht gerade
    • Flat Design war für die Branche fast ein Desaster. Skeuomorphismus war im Grunde auch nur Flat Design mit aufgeklebten Bildern und daher ziemlich schlecht
      Windows Forms hat vieles richtig gemacht, und wenn ich ein fehlendes Symbol nennen müsste, dann vielleicht „aktiv, aber nicht bearbeitbar“
    • Soweit man hört, war Windows 11 ursprünglich Windows 10X, das auch für Smartphones und Tablets gedacht war. Das Startmenü scheint stark von Android beeinflusst zu sein, indem es alles Installierte flach anzeigt und stärker zur Suche lenkt
      Dem stimme ich aber zu. In der Win10-Beta gab es eine Mischform aus Kacheln und einer Liste im Stil von Windows 7, und das war der Ansatz, der bis Windows 2000 zurückreichte; meiner Meinung nach war das der Höhepunkt. Man hätte die Vorteile beider Welten haben können. Der Infobereich war schon immer schwach, und das Einstellungsfenster ist im Vergleich zur Systemsteuerung miserabel. Natürlich ist auch die Systemsteuerung unübersichtlich und komplex, sodass man streiten kann, ob sie wirklich das Beste war

  • Der Autor schrieb, dass der Bildschirm beschädigt wird, wenn er die DOS-Eingabeaufforderung im Fenstermodus öffnet; das kann daran liegen, dass die DOS-Eingabeaufforderung in einer separaten VM, also im V86-Modus, läuft und über INT 10h das VGA-ROM-BIOS aufruft.
    Das VGA-ROM-BIOS dieses Geräts ist vermutlich ein Wrapper über VBE und enthielt also wahrscheinlich IN/OUT-Befehle für den Zugriff auf die VBE-I/O-Ports 0x1CE und 0x1CF. Solche Lese- und Schreibzugriffe aus der DOS-VM erreichen standardmäßig die echte Hardware, wenn der VMM sie nicht virtualisiert.
    Das war ein häufiges Problem, mit dem Autoren von Display-Treibern für Windows 3.x/9x umgehen mussten, aber welche I/O-Portnummern zu virtualisieren waren, hing vom jeweiligen Grafikadapter ab. Im Win95 DDK gibt es ein Beispiel, das mit den VMM-Services Install_IO_Handler und Enable/Disable_Global_Trapping I/O-Port-Traps einrichtet und im Trap-Handler mit VDD_Get_VM_Info bestimmt, welche VM aktuell die CRTC besitzt. Dadurch kann der Trap-Handler entscheiden, ob er I/O an die Hardware weiterleitet oder auf welche Weise virtualisiert wird. Eine gute Virtualisierungsstrategie als Ausgangspunkt ist, Schreibzugriffe von VMs zu verwerfen, die nicht der CRTC-Besitzer sind; die nötige zusätzliche Komplexität kann später ergänzt werden.

  • Das Virtual Display Device (VDD) läuft als Teil des zugrunde liegenden Virtual Machine Managers und verhält sich wie ein Multiplexer für die Video-Hardware. Wenn eine DOS-App im Vollbild läuft, werden Befehle direkt an den „echten“ VGA-Adapter durchgereicht, andernfalls emuliert das VDD sie.
    Es ist interessant, dass andere diese Struktur wiederentdecken. Ich persönlich halte sie für ein ziemlich fortschrittliches Design, seiner Zeit voraus gegenüber modernen Hypervisoren mit Hardware-Passthrough. Die Windows-3.x-GUI selbst, einschließlich präemptiv multitaskender Prozesse, lief faktisch als erweiterter Protected-Mode-DOS-Prozess innerhalb einer VM, in der DOS lief, und der Hypervisor-Kernel VMM32 multiplexte zwischen ihr und den VMs anderer DOS-Prozesse. Deshalb interagiert ein Teil des Display-Treibers unterhalb von GDI mit der „Hardware“, während ein anderer Teil in Ring 0 die Hardware virtualisiert und zwischen anderen VMs multiplexte.
    In DOSBox ließe sich das wohl beheben, aber diese Korrektur wäre an den spezifischen Video-Adapter gebunden, den DOSBox emuliert. Gewünscht ist stattdessen, einen generischen VBE-Patch besser zum Laufen zu bringen.
    Ich habe einmal einen Win9x-VESA-Framebuffer-Treiber für Intel GMA950 geschrieben und sogar grundlegende Beschleunigung ergänzt, also Blitter- und Füllbefehle. Dabei bin ich praktisch auf dasselbe Problem gestoßen und habe verstanden, warum es für Win9x keinen generischen VESA-Treiber gab. Das VDD muss wissen, wie der GPU-Zustand gespeichert und wiederhergestellt wird, und diese Details sind naturgemäß herstellerspezifisch. Ich habe auch über Ideen nachgedacht, wie man das generisch lösen könnte, zum Beispiel das VBIOS zu emulieren oder nachzuverfolgen, um zu sehen, welche Ports und MMIO-Bereiche bei jedem Moduswechsel angefasst werden, aber zur Umsetzung kam es nie.
    In DOSBox erscheint ein Textmodus mit massenhaft beschädigten Zeichen, und auf dem Eee PC erscheint eine kaputte GUI, in der einige Farben fehlen.
    Das sieht so aus, als würden die Palettenregister nicht korrekt gespeichert und wiederhergestellt. Außerdem lässt sich die Beschädigung am oberen Bildschirmrand vermeiden, indem man die hochauflösende Display-Ebene oberhalb von 256K platziert und die ersten 256K des VRAMs für die VGA-Ebene und die VGA-Emulation freilässt. Glücklicherweise gibt es für Intel GMA ziemlich viel öffentliche Dokumentation. Nicht für 900 und 950, sondern für 810/815 und ab 965, aber die meisten Register und Befehle haben sich nicht geändert, sodass man die Details als Referenz heranziehen kann.

  • Es heißt zwar, „wegen fehlender x86_64-Unterstützung kann man auch die meisten aktuellen Linux-Distributionen nicht ausführen“, aber mein Eee hält sich mit 32-Bit-Debian ganz gut.
    Firefox ist zu schwergewichtig und ruckelt fast nur, aber Videostreaming mit mpv funktioniert völlig ausreichend. Ich nutze es hauptsächlich wie eine Schreibmaschine mit wenigen Ablenkungen, auf der ich auch mal pandoc laufen lassen kann, wenn ich bei der Bucharbeit in Verzug bin.

    • Ich stimme voll zu, dass ein Computer mit minimalen Ablenkungen zum Schreiben ideal ist. Für genau diesen Zweck nutze ich WordPerfect 5.1 auf einem PS/2 386SX.
      Den EEE mochte ich wegen seiner hohen Portabilität, aber für ernsthaftes Tippen ist die Tastatur meiner Meinung nach zu klein.
    • Wenn man ihn ohnehin ohne Web oder moderne Apps verwendet, wäre so etwas wie Haiku OS ein interessanter Anwendungsfall.
      Ich habe es auf einem PC ausprobiert, und als echtes Alltagsbetriebssystem fehlte ihm eindeutig benutzbare Software, aber für Zwecke mit geringer Konnektivität wie Schreibmaschine und E-Mail fühlte es sich wie ein sehr angenehmes Betriebssystem an.
      Mir gefiel das konsistente Gefühl von UI, Basissoftware und Dateisystem. Wenn ich es richtig verstanden habe, ist das Dateisystem die Repräsentation aller Daten, und „Dateien“ können beliebige Metadaten haben, während man fast alles im Dateimanager erledigen kann. Das gesamte Dateisystem wirkt wie eine NoSQL-Datenbank, und die Apps übernehmen dieses Modell ganz selbstverständlich. Kontakte sind „Dateien“ in einem Ordner, E-Mails sind ebenfalls „Dateien“ in einem Ordner und so weiter.
      Ich habe BeOS damals nie benutzt, aber in den wenig vernetzten 90ern dürfte dieses Paradigma ziemlich gut gepasst haben. Es war erstaunlich konsistent, den gesamten Ablauf allein im Dateimanager zu erledigen: eine E-Mail-„Datei“ ohne Internet verfassen, sie auf ein Diskettenlaufwerk ziehen und auf einem anderen Computer per Internet versenden.
      Leider verliert dieses Paradigma an Nutzen, sobald man mit anderen Computern interoperieren muss, die nicht mit dem BeOS-/Haiku-Dateisystem kompatibel sind. Statistisch gesehen gilt das für fast alle Computer.
      Aber für ein Gerät im Schreibmaschinen-Stil könnte es interessant sein.
    • Soweit ich weiß, wird Debian in der nächsten Release die Unterstützung für 32-Bit-x86 entfernen.
    • Ich hatte ein 1215B, aber es ist letztes Jahr gestorben, und jetzt hat ein Android-Tablet seinen Platz eingenommen.
      Es sieht so aus, als hätten Tablets das Marktsegment der Netbooks weggefegt. Ultraportables oder 2-in-1s gibt es zwar noch, aber die liegen eher am anderen Ende der Preisskala.

  • Der Titel war etwas verwirrend.
    Trotzdem erfüllt es mich jedes Mal mit Ehrfurcht, wenn ich lese, wie altes DOS-basiertes Windows intern funktionierte. Alles wirkt, als wäre es mit Software-Klebeband zusammengehalten, und somehow funktioniert es.

    • Hör dir einfach Casey Muratori an. Sie haben einen riesigen Haufen Abstraktionen gebaut, den man in Wirklichkeit nicht braucht und der nur die Performance verschlechtert.

  • Ich erinnere mich, dass der ET4000H damals unter Windows 3.1 nicht unterstützt wurde, als er herauskam. Ich rief beim technischen Support von MS an, und man schickte mir eine Treiberdiskette, die 8 Stunden später ankam
    Das war der beste Support, den ich je für ein Raubkopie-Produkt bekommen habe

    • Genauer gesagt war der ET4000H derselbe wie der ET4000ax, der unter Windows 3.0 und 3.1 bereits unterstützt wurde, aber statt eines 256-Farben-DAC mit einem HiDAC ausgestattet, also mit 15/16-Bit-True-Color
      Meine Erinnerung ist unscharf, aber ich glaube, der 16-Farben-Modus funktionierte mit dem Standardtreiber, während 256 Farben und mehr nicht gingen, und möglicherweise war auch die Auswahl der Auflösungen eingeschränkt
      Laut MS erschien ein Treiber mit HiDAC-Unterstützung in der dritten Aprilwoche 1992, also 1–2 Wochen später als der Zeitpunkt, an den ich mich erinnere, was insgesamt plausibel wirkt

  • Lustig. Ich habe ein kleines EEEPC 701, und es funktioniert noch, aber ich habe nie daran gedacht, es für Retro-Games zu verwenden
    Meins setzt nur Staub an, aber solche Dinge auszuprobieren könnte Spaß machen

    • Gemeint ist wohl das 701. 207g ist keine Eee-PC-Modellbezeichnung

  • Beim beiläufigen Vergleichen der kleinen Anmerkungen sieht man einen weiteren Zustandswechsel, den man wohl erst nach so langem Anstarren bemerkt, bis eine Bedeutungssättigung einsetzt
    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
    Dem Muster nach stehen kaputtes DOS und kaputte GUI bei 200 bzw. 250, während die funktionierenden Zustände 100 bzw. 050 haben. Was ist diese Adresse?
    Die kaputte GUI befindet sich irgendwie im M_VGA-Modus statt in LIN8. Wie und warum ist das passiert, und hängt das damit zusammen, dass 400x600 genau die halbe Breite von 800x600 ist? Der eigentliche „Textmodus“ ist, wie die beiden DOS-Modi zeigen, 720x400

  • Ich weiß nicht, ob der Autor das hier sehen wird, aber ich habe diesen Beitrag dem Patch-Autor gemeldet
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...