DOS-Extender
Als DOS-Extender bezeichnet man Programme für MS-DOS bzw. dazu kompatibles DOS (wie PC DOS oder DR-DOS), die den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) verwenden. Dieser steht bei der x86-Architektur ab dem Intel 80286 (16-Bit-{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)) und 80386 (zusätzlich 32-Bit-{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)) neben dem bisherigen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) zur Verfügung. Da PC-kompatibles DOS ein {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-Betriebssystem ist, sind DOS-Programme grundsätzlich ebenfalls auf diesen Modus beschränkt, und damit auch auf den konventionellen Speicher von 640 KiB. Mithilfe eines DOS-Extenders allerdings können DOS-Programme nicht nur im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) laufen, sondern vor allem haben sie direkten Zugriff auf den erweiterten Speicher, womit diese Limitierung wegfällt.<ref name="CW_1989_Extender-appeal"></ref>
Die bekanntesten Standards für DOS-Extender sind VCPI und DPMI. Anfang der 1990er Jahre etablierte sich durchwegs DPMI, weil es mit den DOS-basierten Windows-Versionen ab Windows 3.x und mit OS/2 voll kompatibel ist.
Geschichte
In 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, vertrieben und für kompatible PCs als MS-DOS vermarktet wurde, steht nur 1 MiB Adressraum zur Verfügung. Dieses Limit ist auf den im IBM PC verwendeten 8088-Prozessor zurückzuführen, einer 16-Bit-Architektur mit 8-Bit-Daten- und 20-Bit-Adressbus, wo dieser als Arbeitsspeicher auf 640 KiB für Betriebssystem und Programme und 384 KiB für den Zugriff auf Geräte wie das BIOS oder den Grafikspeicher aufgeteilt wurde. Dadurch steht auf IBM-PC-Kompatiblen unter DOS nur 640 KiB „Konventioneller Speicher“ zur Verfügung.<ref>Guido Weckwerth: Der Dornröschenschlaf des 80286/80386 – Grundlagen zum Protected Mode. In: DOS International. Nr. 5/1990. DMV-Verlag, Mai 1990, ISSN 0933-1557, S. 52 ff. „Bestimmt haben Sie schon einmal davon gehört, daß die 80286- und 80386-Prozessoren mehr als 1 MByte Speicher adressieren können. MS-DOS bietet dagegen höchstens 640 KByte Platz für Daten und Programme. … Als der IBM-PC vor ungefähr zehn Jahren auf den Markt kam, war Speicher noch sehr teuer. Gerätekonfigurationen mit 1 MByte RAM oder mehr waren aus preislichen Gründen nicht denkbar. Da der ursprünglich verfügbare Prozessor Intel 8088 oder 8086 ohnehin den für damalige Verhältnisse riesigen Adreßraum von 1 MByte besaß, wurde das Betriebssystem MS-DOS nicht für größere Adreßräume ausgelegt. Heutige Versionen können diese Grenze aus Kompatibilitätsgründen nicht oder, wie Sie später noch sehen werden, nur sehr schwer überwinden.“</ref>
Mit dem IBM PC/AT verwendete IBM Ende 1984 erstmals einen 80286-Prozessor, bei dem Intel mit dem {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) einen zusätzlichen Betriebsmodus hinzugefügt hatte. Da DOS jedoch für den 8086/8088 geschrieben worden war, lief es auch auf dem PC/AT im retronym mit {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) bezeichneten Modus des 8086 und machte vom neuen Betriebsmodus keinen Gebrauch. Im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) kann der gesamte Speicher adressiert werden, beim 80286 sind dies 16 MiB, allerdings ist die Adressierung immer noch segmentiert.<ref>https://www.xtof.info/inside-windows3.html#h-protected-mode</ref> Bereits im darauffolgenden Jahr, 1985, stellte Intel mit dem 80386 den ersten 32-Bit-x86-Prozessor vor, dessen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) im 32-Bit-Modus theoretisch bis zu 4 GiB Arbeitsspeicher linear adressieren kann.
Da der {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) und der „Erweiterte Speicher“ ({{Modul:Vorlage:lang}} Modul:Vorlage:lang:103: attempt to index field 'wikibase' (a nil value)) für Anwendungsprogramme unter DOS brach lag, wurden Ende der 1980er Jahre die ersten „MS-DOS-Extender“ angeboten, die einzelnen dafür programmierten DOS-Programmen den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) exklusiv zugänglich machten.<ref>Guido Weckwerth: Der Dornröschenschlaf des 80286/80386 – Grundlagen zum Protected Mode. In: DOS International. Nr. 5/1990. DMV-Verlag, Mai 1990, ISSN 0933-1557, S. 56, Multitasking-Betriebssysteme entfalten die volle Leistung des Prozessors: „Seit einiger Zeit drängen Programme auf den Markt, die als ›MS-DOS-Extender‹ geläufig sind. Dabei wird unter MS-DOS der Protected Mode des Prozessors genutzt. Die auszuführen den Routinen müssen lediglich für den Protected Mode compiliert werden. Diese Aufgabe übernehmen einige handelsübliche Compiler, die wahlweise den Code für den Real Mode oder den Protected Mode erzeugen können.“</ref>
Technik
DOS-Extender ermöglichen Programme, die mehr Speicher nutzen können, als PC-kompatibles DOS eigentlich bereitstellen kann. Nur ein {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-DOS-Programm ist von der Beschränkung auf den konventionelle Speicher befreit und kann im erweiterten Speicher Programmcode und Daten verarbeiten. Dazu stellen DOS-Extender Mechanismen bereit, kontrolliert zwischen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) und {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) zu wechseln. Die Notwendigkeit dafür entstammt der Architektur von MS-DOS: als 16-Bit-Betriebssystem nutzt es auf dem IBM PC viele Funktionen dessen Systemfirmware, des BIOS. Sowohl die BIOS-Routinen als auch die DOS-Funktionen sind nur im Betriebsmodus des 8086 (bzw. 8088) – dem {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) – verfügbar. DOS-Programme müssen also grundsätzlich, um diese System-Funktionen ansprechen zu können, im selben Modus laufen. Ein Programm, das im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) läuft, muss daher für die BIOS- und DOS-Funktionen in den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) zurück wechseln – oder alle Funktionen, die eigentlich vom Betriebssystem (im Falle von DOS beinhaltet dies auch die BIOS-Funktionen) zur Verfügung gestellt werden, selbst implementieren.
Bei der Verwendung von DOS-Extendern soll sich der Aufwand für die Entwickler und Programmierer möglichst gering halten, denn für das DOS-Programm, das im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) laufen soll, ändert sich vorerst nichts: es ruft wie gewohnt die Funktionen von DOS und dem BIOS auf – der DOS-Extender kümmert sich um den kontrollierten Wechsel in den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), und anschließend zurück in den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), wo die Ausführung des eigentlichen Programms stattfindet.<ref></ref>
DOS-Extender haben gegenüber größeren Betriebssystemen wie PC-Unix oder OS/2, die von sich aus den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) bieten, den Vorteil, dass sie insgesamt, mit dem Betriebssystem und dem eigentlichen Anwendungsprogramm, mit weniger Arbeitsspeicher auskommen.<ref></ref> Auf IBM-PC-kompatiblen Computern mit 80386 profitieren DOS-Programme zusätzlich von der neuen 32-Bit-Architektur IA-32, was der Performance zugutekommt, solange sie im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) verbleiben. Die allgemeine Verbesserung der Performance wurde insbesondere mit der Einführung eines linearen Speicherzugriffs aus dem {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) bei den VESA BIOS Extension (VBE) der Version 2.0 auf den VRAM der Grafikkarte deutlich, was beispielsweise einige Computerspiele beschleunigte. Sobald jedoch DOS- und BIOS-Funktionsaufrufe erforderlich sind, ist meist ein Kontextswitch (ein Wechsel des Betriebsmodus) in den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) erforderlich, was vergleichsweise viele Prozessorzyklen in Anspruch nimmt und daher Zeit kostet. Um derartige Wechsel zu minimieren, reimplementieren manche DOS-Extender ausgesuchte BIOS- und DOS-Funktionen im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value). DOS-Extender werden daher manchmal auch mit einer Art Mini-Betriebssystem verglichen, denn auch alle 32-Bit-PC-Betriebssysteme haben keinen Zugriff auf die BIOS-Funktionen und müssen deren Funktionalität im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) neu implementieren.
Diverse Compiler für DOS der späteren 1990er Jahre bieten die Option, {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-Programme zu erzeugen. Damit diese unter DOS ausführbar sind, muss ein DOS-Extender mitgeliefert werden.<ref>dm: Gesprengte Ketten – Metaware High C 386. In: DOS International. Nr. 10/1990. DMV-Verlag, Oktober 1990, ISSN 0933-1557, S. 66 ff. „Bisher kränkelte die Leistungsfähigkeit von MS-DOS-Programmen am mit 640 KByte knapp bemessenen Arbeitsspeicher. Auch wenn im System mehrere MByte installiert sind, läßt sich dieser Zusatzspeicher nur sehr unvollkommen nutzen. Eine Lösung dieses Problems sind leistungsfähige Compiler wie der speziell für 80386-Prozessoren entwickelte High-C-Compiler sowie DOS-Extender, die die Speichergrenzen aufheben.“</ref> Anfangs machten vor allem Business-Programme vom {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) Gebrauch, beispielsweise AutoCAD und Lotus 1-2-3. In den 1990er Jahren stach der Watcom C/C++ Compiler besonders hervor, da er mit DOS/4GW einen günstigen DOS-Extender mitlieferte, der für kommerzielle Programme lizenzfrei verwendet werden durfte und somit schnell, insbesondere in der Computerspielbranche, Verbreitung fand. Eines der ersten und bekanntesten DOS-Spiele, das den 32-Bit-DOS-Extender DOS/4GW nutzt, ist DOOM.<ref>https://www.xtof.info/inside-windows3.html#h-dpmi--dos-extender</ref>
Standardisierung
In der zweiten Hälfte der 1980er Jahre entstanden unterschiedliche, zueinander nicht kompatible DOS-Extender. Ein erster erfolgreicher Versuch einer Standardisierung ist das {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), kurz VCPI, das von Phar Lap und Quarterdeck ab 1987 entwickelt wurde. VCPI setzt jedoch einen i386 voraus und ist mit dem 80286 nicht kompatibel.
Beispiele für DOS-Extender vor VCPI:
- 286|DOS-Extender und 386|DOS-Extender von Phar Lap Software<ref name="CW_1989_Extender-appeal" /><ref name="PCMag_386-DOS-Extenders" />
- DOS/16M von Rational Systems<ref name="CW_1989_Extender-appeal" /><ref name="PCMag_386-DOS-Extenders" /> (später Tenberry Software; weiterentwickelt zu DOS/4G und die Version für den Watcom C/C++ Compiler DOS/4GW)<ref>Unofficial DOS/4G(W) documentation. In: rgmroman.narod.ru. 2005, abgerufen am 29. Dezember 2025 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „DOS/4G, DOS/4GW, DOS/4GW Professional and DOS/16M are dos extenders from Tenberry Software (old name Rational Systems). … DOS/16M is a 16-bit dos extender, DOS/4G(W) based on it.“</ref>
- OS/286 und OS/386 von A. I. Architects<ref name="CW_1989_Extender-appeal" />
- X-AM von Intelligent Graphics Corp. (IGC)<ref name="PCMag_386-DOS-Extenders"></ref>
Die DOS-Extender zu dieser Zeit liefen exklusiv und waren mit (kooperativen) Multitasking-Erweiterungen wie DESQview und Windows 3.x nur eingeschränkt kompatibel.<ref></ref> Die Zusammenarbeit von Quarterdeck mit Phar Lap schuf zwar den VCPI-Standard, mit dem DESQview voll kompatibel war, aber in Windows 3.0 wurde für den 80386 ein neuer Betriebsmodus eingeführt: der „386 Erweiterte Modus“ bzw. „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“. Anders als beim 80286 bietet der 80386 einen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value), in dem Windows DOS-Programme parallel und mit eigenem Adressraum zur Ausführung bringen kann. Das erlaubt transparentes Multitasking für DOS-Programme. Gleichzeitig gab es zu dieser Zeit bereits zahlreiche {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-DOS-Programme, die in diesem Modus nicht funktionieren.
Obwohl Windows 3.0 im 8086-kompatiblen „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“ und im 80286-kompatiblen „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“, die beide auch weiterhin auf dem 80386 funktionieren, mit den bisherigen DOS-Extendern kompatibel bleibt, war Microsoft klar, dass ein neuer und auch mit dem „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“ kompatibler DOS-Extender entwickelt werden müsste, damit der Vorteil des 80386 – dessen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) – in der Realität nicht zu einem Nachteil werden würde. Das {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (DPMI) wurde daher nicht nur in Windows 3.0 und OS/2 2.0 integriert, sondern auch als freie Spezifikation veröffentlicht. Da die Hersteller der DOS-Extender DPMI übernahmen, konnten die Entwickler existierender {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)-DOS-Programme, die diese DOS-Extender nutzten, ihre Produkte von VCPI- in DPMI-kompatible Programme weiterentwickeln, die somit auch unter Windows und OS/2 die volle Stärke des 80386 und nachfolgender IA-32-Prozessoren wie dem 80486 nutzen konnten.
DPMI wurde der bekanntesten Standard für DOS-Extender und in den 1990er Jahren zum Industriestandard. Da zur gleichen Zeit immer nur ein DOS-Extender aktiv sein kann, schließlich verwaltet er sowohl den Speicher als auch die Kontextwechsel vom {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) in den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) und zurück, sind DOS-Extender nach DPMI- und VCPI- und frühe proprietäre Spezifikationen zueinander inkompatibel. Wenn ein DPMI-fähiger DOS-Extender läuft, können somit nur DPMI-Clientprogramme ausgeführt werden. Soll ein Programm gestartet werden, dass der VCPI-Spezifikation folgt, so muss der DPMI-DOS-Extender beendet und ein VCPI-fähiger DOS-Extender gestartet werden. Viele DOS-Extender nutzen daher jene Umgebung, die beim Start bereits vorhanden ist; am Beispiel PMODE:<ref>Thomas Pytel alias „Tran“: PMODE 3.07 documentation. (Textdatei) 5. Dezember 1994, abgerufen am 24. Januar 2026 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>
- findet der DOS-Extender PMODE einen DPMI-Host, so reicht er alle Aufrufe durch; das 32-Bit-DOS-Programm, das PMODE als DOS-Extender nutzt, läuft denn in Wirklichkeit auf dem bereits vorhandenen DPMI-DOS-Extender (wie z. B. Windows 3.x)
- bei vorhandenem Speichermanager, neben Vorlage:Monospace auch etwa QEMM oder 386Max, startet PMODE im VCPI-Modus, weil die Ausführung im Ring 0 schneller ist als im Ring 3 von DPMI
- läuft DOS ohne einen DPMI-Host oder VCPI-Server, ist aber ein Speichermanager für {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (XMS) geladen – wie z. B. Vorlage:Monospace – so nutzt PMODE diesen für die Verwaltung von Erweitertem Speicher; PMODE läuft in diesem Fall in seinem eigenen Modus (weder VCPI, noch DPMI), um einem 32-Bit-DOS-Programm den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) zu bieten.
- fehlt ein XMS-Speichermanager (Vorlage:Monospace), so läuft PMODE im „Vorlage:Monospace“: in diesem Fall übernimmt der DOS-Extender auch die Speicherverwaltung für den Erweiterten Speicher (XMS) selbst
Bekannte DOS-Extender
DOS-Extender finden sich oft in integrierten Entwicklungsumgebungen für DOS, OS/2 und Windows, aber auch als {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value):
- der „{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)“ verschiedener Borland-Compiler, u. a. Borland Pascal 7.0 (Vorlage:Monospace, 16-Bit, und Vorlage:Monospace, 32-Bit, nur noch in Turbo C)
- DOS/4GW (bei Watcom C/C++ mitgeliefert, sehr beliebt bis 1995, danach Entwicklung eingestellt)
- PMODE/W (als Alternative zu DOS/4GW bei Watcom C/C++)
- CauseWay
- DOS/32 Advanced (DOS/32A; kompatibel zu DOS/4GW, letzte Version 9.12 von 2006)
- HX DOS Extender – HDPMI16 (16-Bit) und HDPMI32 (32-Bit)
- CWSDPMI (unter der Bezeichnung GO32 Bestandteil von DJGPP)
- PMODE/DJ
- Wuschel’s DOS eXtender (WDOSX)
- TNT DOS-Extender SDK von Phar Lap
- 386|DOS-Extender SDK von Phar Lap
- emx von Eberhard Mattes
- Zortech C++
- Zurenava DOS extender (ZRDX)
Die meisten Implementierungen können sowohl VCPI als auch DPMI als Client verwenden, wenn diese als Server (VCPI) bzw. Host (DPMI) bereits geladen sind. Ansonsten nutzen DOS-Extender meist eine eigene Programmierschnittstelle, die nicht zwingend mit anderen DOS-Extendern kompatibel ist – normalerweise lässt sich ein Protected-Mode-Programm für DOS daher nicht mit einem beliebigen anderen DOS-Extender nutzen.
Einzelnachweise
<references />