Dieses Projekt ist ein DOS-Emulator, der die Windows Hypervisor Platform (WHP) -API zum Erstellen einer virtuellen CPU nutzt und die Ausführung von DOS-Programmen in einer virtualisierten 16-Bit-Real-Mode-Umgebung auf modernen Windows-Systemen ermöglicht.
In meinem vorherigen Windows 3.1 -Emulator wurde die 80286 -CPU in der Software vollständig emuliert. Für dieses Projekt habe ich mich jedoch entschlossen, einen anderen Ansatz durch die Hardware -Virtualisierung für die CPU zu verfolgen und gleichzeitig die DOS -Schicht in der Software zu emulieren.
Dieser Emulator dient hauptsächlich als Demonstration der WHP -API und soll nicht als vollständiger Dos -Emulator fungieren. Es wurde eine minimale DOS -Funktionalität implementiert und nur ausreichend, um einige Beispielprogramme durchzuführen, obwohl das Framework so ausgelegt ist, dass sie leicht erweiterbar sind.
Der Emulator initialisiert eine virtuelle CPU mit der WHP-API und konfiguriert sie so, dass sie in Real-Mode ausgeführt werden, indem sichergestellt wird, dass der PE (geschützte Modus enable) und PG (Paging) im CR0-Register deaktiviert sind.
Die ausführbare DOS -Datei wird in den Emulator -Host zugeordnet und an die entsprechende physische Adresse mit dem Gast geteilt, wodurch das Speicherlayout eines echten DOS -Systems simuliert wird.
Die meisten DOS -Funktionen erfolgen über Interrupts, z. B. 0x21 für Systemdienste und 0x10 für Videooperationen, die in Software manuell emuliert werden müssen. Interrupts auslösen nicht von Natur aus VM -Ausgänge und erfordern zusätzliche Tricks, um sie zu erfassen. Dies kann leicht durch die Implementierung einer benutzerdefinierten Interrupt -Vektortabelle (IVT) angegangen werden, in der jeder Interrupt auf eine CPUID -Anweisung verweist. Diese Konfiguration stellt sicher, dass ein VM -Ausgang beim Auftreten eines Interrupts ausgelöst wird, sodass der Emulator den Interrupt abfängt und verarbeitet.
DOS -Programme verwenden häufig E/A -Ports, wie z. B. für PC -Lautsprecher, CMOs und Hardware -Timer. E/A -Anfragen können leicht erfasst werden, da die in und out -Anweisungen einen VM -Ausgang auslösen, sodass die Funktionalität emuliert werden kann. Derzeit werden nur ein sehr kleiner Satz gemeinsamer E/A -Anfragen unterstützt.
DOS -Programme verwendeten verschiedene Methoden zur Aufrechterhaltung des Timings. Dieser Emulator enthält Unterstützung für einige ausgewählte dieser Mechanismen:
0000:046C zurück, eine Alternative zum direkten Zugriff auf den Speicher.Der 8253 Pit -Timer ist derzeit nicht vollständig implementiert.
Der Emulator überwacht den Tastaturzustand und führt einen einfachen Schlüsselpuffer bei, über die Informationen über Tastaturinterrupte (0x16) an das DOS -Programm weitergegeben werden.
Grundlegende Terminalbefehle werden unterstützt, sodass der Emulator einfache textbasierte Spiele und andere grundlegende Programme ausführen kann.
Der Emulator verteilt derzeit Platz für Systemfelder wie BIOS -Datenbereiche und das Programmsegmentpräfix (PSP). Diese Felder sind jedoch derzeit nicht besiedelt, mit Ausnahme des BIOS -Zählerwerts. Zusätzliche Felder können bei Bedarf besiedelt werden.
Das Testen wurde unter Verwendung eines einfachen DOS -Spiels von Flareon 2023 (FLARESAY.EXE, Challenge #6) durchgeführt, vor allem, weil es zu dieser Zeit die einzige ausführbare DOS -Datei war.
Zusätzlich zu diesem DOS-Emulator hatte ich einige Erfolge mit einem ähnlichen Konzept, das darauf abzielt, 64-Bit/32-Bit-Windows-Benutzer-Mode-Programme zu emulieren. Durch den Aufbau einer simulierten CPL3 -Umgebung und das Haken des MSR_LSTAR -Registers ist es möglich, eine ausführbare Datei zu emulieren und einen VM -Ausgang auf Systemaufrufen zu erzwingen. Auf diese Weise kann der Emulator die Systemanforderung an das Host -Betriebssystem erfassen und entweder weiterleiten oder abfangen. Diese Technik ist mit vielen Komplikationen ausgestattet, aber es kann gültige Anwendungsfälle geben, in denen ein leichtgewichtiger Emulator nützlich sein kann.
