Ein wenig Geschichte hilft Ihnen zu verstehen, wie die Dinge in der Windows 9x-Welt funktionieren.
Seit dem Intel 80386 haben Prozessoren zwei "Betriebsmodi": den Real-Modus und den Protected-Modus. Wenn Sie Ihren Computer zum ersten Mal einschalten - selbst ein modernes Core i7-Gaming-Rig -, startet der Prozessor im Real-Modus. Der Real-Modus bietet keinen Speicherschutz, keine Multitasking-Unterstützung, keine Code-Privilegien - nichts. Jedes Programm hat direkten, uneingeschränkten Zugriff auf den Speicher. Die Kommunikation mit der Hardware wurde vom BIOS über Interrupt-Aufrufe bereitgestellt.
Ein Interrupt macht genau das, was sein Name bedeutet. Es stoppt die CPU in ihren Spuren. Programme würden eine Bitmap eines Bildes in den Bildspeicher laden. Es würde dann einen Zeiger auf diesen Speicher im niedrigen Byte des AX-CPU-Registers (bekannt als AL) und den BIOS-Befehl platzieren, um ihn im hohen Byte (AH) anzuzeigen. Es würde dann das BIOS-Interrupt 0x10h aufrufen und das BIOS übernehmen. Die CPU hat zu diesem Zeitpunkt keine Kontrolle mehr über Ihren Computer.
Das BIOS würde dann die Anweisung in AH lesen und den Zeiger in AL an die Videohardware übergeben. Die GPU kopiert dann den Inhalt des Frame-Puffers in seinen eigenen RAM und gibt dann die Steuerung an das BIOS zurück, das es an die CPU zurückgibt. Die CPU ist jetzt wieder auf dem Fahrersitz.
Es ist wichtig zu wissen, dass alle Versionen der Windows 9x-Familie im Wesentlichen DOS-Anwendungen waren. Als Win98 seinen Begrüßungsbildschirm zeigte, befand sich die CPU noch im Real-Modus und verwendete immer noch BIOS-Interrupts, um sie anzuzeigen. Die niedliche kleine Animation am unteren Rand war nur ein Trick fürs Radfahren. Es fand keine Zeichnung statt.
Beim Laden von Windows war es eine der ersten Aufgaben, die CPU in den geschützten 32-Bit-Modus zu schalten. Dies hat DOS im Grunde aus dem Speicher geworfen und dem BIOS mitgeteilt, was es mit sich selbst tun kann. Die meisten Funktionen, die vom BIOS ausgeführt wurden, werden jetzt durch die Windows-HAL und den Kernel ersetzt. In einer Windows-Welt kommunizieren Anwendungen über einen API-Aufruf mit der Hardware, und dieser API-Aufruf lief über den Anzeigetreiber, der eine erforderliche Komponente des Betriebssystems war.
Jetzt (endlich) hier, wo wir uns mit Ihrer Frage beschäftigen. Windows hat dann (wie bisher) die Video-Hardware über einen Bildschirmtreiber gesteuert. Wenn kein Treiber verfügbar war, wurde der Standard-Windows-Treiber verwendet, der den Framebuffer zum Zeichnen verwendete. Der einzige Unterschied besteht darin, dass die CPU immer über speicherzugeordnete E / A gesteuert wird und das BIOS nicht beteiligt ist. Wenn ein Treiber vorhanden ist, verwendet der Treiber immer noch das MMIO, aber um proprietäre Befehle an die GPU auszugeben, keine Bitmap-Frames. Die GPU hat direkten Zugriff auf den Speicher und könnte parallel zur CPU arbeiten, einschließlich der bidirektionalen Kommunikation über diese E / A-Bereiche.
Windows 98 hatte Treiber für die damalige Grafikhardware und konnte eine umfassende 2D- und 3D-Beschleunigung einschließlich OpenGL und DirectX bieten. Es benötigt jedoch noch einen Treiber, um diese Dinge an die GPU zu übermitteln, und kann dies nicht ohne.
Das Zeichnen von Fenstersteuerelementen (z. B. Schaltflächen, Titelleisten usw.) wurde über die Windows Graphics Device Interface (GDI) vorgenommen, die die Haupt-Windows-API für das Zeichnen von Bildschirmelementen war. Es bietet alle Arten von Funktionen, einschließlich Formen, Stiften, Füllfarben und Bitmaps. Die GDI würde diese Anweisungen in Treibercode umwandeln. Der Treiber (sei es der GPU-Treiber oder der Framebuffer-Treiber) war dafür verantwortlich, diese GDI-Anweisungen über die vom Programm programmierten Mittel auf den Bildschirm zu bringen.
Das ist viel zu verdauen und es ist nur ein kurzer Überblick darüber, wie Daten eingehen und Pixel herauskommen. Ich hoffe, es beantwortet einige Ihrer Fragen.