Diskussion:DOS Protected Mode Interface

DOS-Extender vs. DPMI

Ein DOS-Extender stellt nicht automatisch ein DPMI zur Verfügung. Er kann auch noch VCPI oder ein eigenes, proprietäres Interface bereitstellen. Andersherum muss auch ein DPMI nicht zwangsläufig von einem DOS-Extender kommen. Wir sollten das daher lieber trennen, was meint ihr? --RokerHRO 17:32, 11. Sep. 2011 (CEST)

Die Frage von RokerHRO kann ich nicht beantworten - aber scheinbar interessiert diese Sache kaum noch jemanden.

Andererseits würde ich mir wünschen, daß man den/die Aufrufe noch etwas im Detail beschreibt und/oder die Funktionszusammenhänge etwas darstellt. --Guenni60 (Diskussion) 12:48, 7. Dez. 2018 (CET)

Wozu, wenn es kaum noch jemanden interessiert? ;-( --RokerHRO (Diskussion) 23:43, 9. Dez. 2018 (CET)

Ich würde mir das auch wünschen. Wozu ist nicht relevant, aber es ergibt sich daraus, dass sich keiner findet, der es macht.

Die Sache ist nicht so einfach. Windows 2.x/3.x verwendet DPMI, wenn es auf einem 386+ läuft. Das hat, so glaube ich, auch etwas mit der Multitasking-Fähigkeit zu tun. DR DOS 5.0 konnte das auch schon, in Version 6.x wurde es noch verbessert. Ob Microsoft mit Multitasking-MS-DOS 4.0 das auch schon per DPMI so gemacht hat weiß ich allerdings nicht.

Es ist jedenfalls nicht ganz so einfach und darum hat es vermutlich bisher keiner gemacht. :-(

‣Andreas•⚖ 17:33, 10. Dez. 2018 (CET)

Der Artikel war größtenteils falsch. Siehe dazu auch der andere Diskussionsabschnitt weiter unten. Ich habe den Artikel daher komplett überarbeitet und die zu beanstandenden Stellen umgeschrieben. --84.158.122.178 01:04, 22. Dez. 2021 (CET)

Die Aussage im Artikel ist falsch

Im Artikel steht
"Somit kann ein Real-Mode-Programm (etwa ein DOS-Programm) Funktionen des Protected Mode nutzen, indem es die entsprechenden DPMI-Funktionen aufruft. Der DOS-Extender schaltet daraufhin in den Protected Mode, führt die gewünschte Funktion aus, schaltet zurück in den Real Mode, und übergibt die Kontrolle wieder an das Anwendungsprogramm. "
Wenn wir hier von DOS-Extendern wie bspw. DOS/4GW sprechen, dann ist diese Aussage falsch, denn Programme die DOS-Extender verwenden sind selbst Protected Mode Programme und keine Real Mode Programme. Die können den Adressbereich also selbst linear bis zur 4 GiB Grenze ab dem 386er verwenden. Ein Umschalten in den Real Mode findet nur noch dann statt, wenn Funkionen aus dem DOS Betriebssystem oder dem BIOS abgerufen werden sollen. Der DOS-Extender ist sozusagen ein eigener OS Kernel der im Protected Mode läuft, dem Anwendungsprogramm das extra dafür geschrieben wird, eine abstrahierte Protected Mode Umgebung zur Verfügung stellt und dann, nach dem Beenden der Anwendung wieder zu DOS zurückkehrt und die CPU dazu in den Real Mode zurückschaltet. Es kann aber natürlich sein, dass DPMI und DOS Extender zwei völlig verschiedene Dinge sind, wie oben auch schon andiskutiert wurde, aber dann sollte man das auch entsprechend im Artikel erwähnen und ein DPMI dann nicht DOS-Extender nennen. --84.158.122.178 00:31, 22. Dez. 2021 (CET)

Ich habe mir jetzt zum Thema DPMI mal den englischen Artikel "DOS Protected Mode Interface" durchgelesen um mir Klarheit zu verschaffen, ob mit DPMI DOS-Extender gemeint sind. Und es scheint wohl so, dass das nur eine Spezifikation ist, die von DOS-Extendern dann umgestezt werden. Das bedeutet also, dass die obige Aussage im Artikel, dass es sich um Real Mode DOS Programme handeln würde, falsch ist. Ich werde das im Artikel daher korrigieren. --84.158.122.178 00:53, 22. Dez. 2021 (CET)

Bevor du das tust, wäre es gut, wenn du eine Quelle finden würdest, die WP:BLG entspricht. Nur weil es in der englischen Wikipedia steht, muss es nicht automatisch stimmen... ‣Andreas•⚖ 11:49, 22. Dez. 2021 (CET)

Ich bin Software Entwickler und weiß was ein DOS-Extender wie DOS/4GW ist und musste nur prüfen was es mit dem DPMI auf sich hat. Und das ist nun einmal, bei genauerer Betrachtung eine Spezifikation für eine bestimmte Form von DOS-Extendern. Als Quelle genügt ein Blick in die Spezifikation. Was ich also am Artikel geändert habe ich alles richtig. Es macht auch anders gar keinen Sinn, da ein reines Realmode Programm keinen DOS-Extender benötigt, schließlich läuft es allein im konventionellen Speicher (also unterhalb von 640 KiB) und Realmode Programme, die Speicher auslagern müssen, die verwenden Memory Extender wie bspw. XMS, dadurch werden die aber nicht zu einem Protected Mode Programm. Nur der Memory Extender läuft selbst im Protected Mode und kopiert die Daten dann in den für ein Realmode Programm sichtbaren Adressbereich. Ein Memory Extender ist aber kein DOS-Extender und auch kein DPMI konformes Programm. Denn DOS-Extender bilden eine Abstraktionsschicht für Programme, damit diese im Protected Mode laufen können und somit selbst ohne Umschichtung auf mehr Speicher zugreifen können. --84.158.122.178 17:36, 22. Dez. 2021 (CET)

Was du schreibst, klingt erstmal sehr logisch, ja. Auch ich hätte angenommen, dass das so sein müsste, dass man ein Protected-Mode-Programm hat, und deswegen einen DOS Extender benötigt, der die DPMI-Spezifikation umsetzt.

Aber... Annahmen sind eben keine Quellen.

Eine englische Quelle. Zitat: The document I had been handed [Anm.: DPMI pre-release spec] was nothing more or less than the functional specification of a protected-mode version of DOS! In retrospect, the fact that Microsoft was cooking up something like the DPMI should have been obvious. Every computer journalist in America, as well as thousands of beta testers, was well aware that the as-yet-unannounced Microsoft Windows 3.0 was somehow able to take advantage of extended memory by executing applications in protected mode, even though it ran on top of DOS and used the DOS file system. It was even fairly widely known that you could use a utility program to ‘mark’ the .EXE file headers of old (that is, Windows 2.03) applications, and that many such programs would then run (at least for a while) in protected mode, even though they hadn't been recompiled or relinked.

Auch nutzt scheinbar OS/2 2.0 dieselbe Technik wie Windows 3.0, um mehrere DOS-Programme (Real-Mode!) nebeneinander laufen zu lassen, ohne, dass sich diese gegenseitig konventionellen Speicher streitig machen müssten – dank DPMI.

Ich würde sagen, da zuerst einmal Quellen zu suchen und zu recherchieren, wäre eine gute Idee...

‣Andreas•⚖ 18:49, 22. Dez. 2021 (CET)

Äh Moment, du bringst da jetzt etwas durcheinander. OS/2 und Windows 3.0 setzten den DPMI selber um und natürlich müssen sie mit dem DOS Kernel und dem BIOS kommunizieren können, dass ist die Aufgabe eines DOS Extenders oder, OS/2 und Windows selbst, die den DPMI umsetzen. Die Programme, die auf OS/2 oder Windows 3.0 laufen, sind aber selber keine Real Mode Programme. Und das war eben der Fehler im Artikel, bevor ich ihn editiert und das korrigiert habe. Programme die auf OS/2 oder Windows 3.x aufsetzen, sind alles Protected Mode Programme. Aus dem Grund ist ein 286er auch eine Minimalanforderung. Auf einem 8086, der keinen Protected Mode kennt, läuft weder OS/2 noch Windows 3.x. --84.158.122.178 19:06, 22. Dez. 2021 (CET)

Noch etwas zu den Real Mode Programmen, die unter Windows oder OS/2 in einer DOS Umgebung laufen. Das ist erst ab dem 386er möglich, da der den sogenannten Virtual 8086 Mode kennt, in dem die Real Mode DOS Programme dann im Real Mode ausgeführt werden können. Das hat mit dem DPMI oder DOS Extender nichts zu tun. DOS Extender werden in einer Real Mode Umgebung (z.B. DOS) ausgeführt um dann in den Protected Mode zu schalten und dort dann einer dafür entwickelten Anwendung eine Protected Mode Umgebung zur Verfügung zu stellen, der umgekehte Weg, dass man von einer Protected Mode Umgebung kommt um dann im Virtual 8086 Mode zu laufen, ist etwas völlig anderes. --84.158.122.178 19:12, 22. Dez. 2021 (CET)

Moment mal... Windows 3.0 lief sehrwohl noch im Real Mode, und zwar auf 8086-PCs. Quelle. Windows 3.0 hatte einen Real-Mode- (für 8086/80186), Standard-Mode- (16-Bit-Protected-Mode, 80286) und einen Enhanced-Mode- (32-Bit-Protected-Mode) -Kernel. In Windows 3.1 fiel der Real-Mode-Modus weg, in Windows 3.11 der Standard-Mode.

Das heißt, es gibt Windows-Programme, die Real-Mode-Programme sind. Nicht nur das, Windows-Programme für z.B. Windows 2.03 sind eigentlich nur Real-Mode-Programme. Auch laufen 16-Bit-Windows-Programme, darunter auch solche für Windows 2.x, noch in 32-Bit-Windows-NT-basierten Versionen. Mithilfe der NTVDM sogar auch auf Windows 10 x64 (Quelle).

DPMI hingegen ist eine Spezifikation, die es ermöglichen soll, dass mehrere Programme – also parallel, in einer Multitasking-Umgebung – quasi gleichzeitig und ohne sich dabei in die Quere zu kommen, >1MB Speicher verwenden können, bei bestehender Kompatibilität zu DOS. Bei VCPI war ja genau das das Problem: es ging nur exklusiv, es hätten nicht mehrere Programme gleichzeitig laufen können. Darum war VCPI exklusiv für DOS, denn damals war Multitasking auf DOS noch nicht sehr verbreitet. DPMI hingegen wurde von Microsoft mit OS/2 2.0 und Windows 3.0 entwickelt, offen gelegt und somit von der Industrie gemeinsam weiterentwickelt, und als offene Spezifikation herausgebracht. DOS Extender können DPMI genauso umsetzen wie irgend etwas anderes, auch VCPI, aber um mit anderen Programmen kompatibel zu sein, war DPMI eigentlich ein guter Weg. Damit liefen dann 32-Bit-DOS-Programme auch unter OS/2 und Windows 3.x/9x.

Ein Teil eines DOS-Programms muss aber immer auch im Real Mode laufen, denn sonst könnte es nicht mit der von DOS zur Verfügung gestellten "Infrastruktur" (Treiber, Dateisystem, BIOS- und System-Calls) umgehen.

Was ich noch nicht weiß, mich aber brennend interessiert: wie liefen Win16-Programme sowohl auf 8086-Systemen als auch auf 80286-Systemen? Denn auf letzterem war Windows ja im 16-Bit-Protected-Mode. Und wie du treffend richtig festgestellt hast, fehlt dem 286er ja der V86-Mode...

‣Andreas•⚖ 19:42, 22. Dez. 2021 (CET)

Okay, Windows 3.0 lief noch im Real Mode. Die Auswahl an Software, die darunter lief, also Real Mode Programme sind, dürfte allerdings ziemlich klein sein. Unter folgendem Link hat jemand versucht eine Liste zu erstellen. Ich hatte damals nur Windows 3.1, das konnte kein Real Mode mehr. Da habe ich mich bezüglich Windows 3.0 dann wohl geirrt. Windows 2.x und früher sind zwar Real Mode Programme, spielten aber praktisch für 3rd Party Entwickler keine Rolle, man entwickelte zu der Zeit lieber weiterhin für DOS. Der Erfolg von Windows begann erst mit Windows 3.x. Die meisten 16 Bit Windows Programme, die für Windows 3.x entwickelt wurden, dürften reine Protected Mode Programme sein. Dazu muss Windows 3.0 selbst im Protected Mode, also Standard Mode oder Enhanced Mode laufen.

Und natürlich laufen 16 Bit Windows Real Mode Programme in einem 32 Bit Windows unter Ausnutzung des Virtual 8086 Mode. Das habe ich auch nie bestritten. Zu deiner Quelle bezüglich x64 liegst du aber falsch, denn wenn du dem dortigen Link folgst, dann wirst du erkennen, dass hier ein 16 Bit Emulator Namens Otya128 im Spiel ist. Selbstverständlich kann man jede Hardware in Software emulieren, das war noch nie ein Problem. Du kannst mit einem Emulator auch x86 Software auf einem ARM Prozessor, also einer völlig anderen Architektur laufen lassen, das ist eine der wesentlichen Aufgaben von Emulatoren. Die x64 Hardware kann selbst aber keine 16 Bit Realmode Programme in Hardware ausführen, wenn sie unter einem 64 Bit Betriebssystem läuft, das geben die x64 Betriebsmodi nämlich nicht her. Siehe dazu X64#Betriebsmodi. Der Virtual 8086 Mode für Real Mode Programme funktioniert darin nämlich nicht mehr.

Bei deinem Satz "DPMI hingegen ist eine Spezifikation, die es ermöglichen soll, dass mehrere Programme ... >1MB Speicher verwenden können" fehlt der Punkt "Protected Mode Programme", das ist nämlich das wesentliche von DPMI. Das mehrere DPMI fähige Protected Mode Programme miteinander funktionieren sollen ist richtig, allerdings kann es unter einem normalen Real Mode DOS nur einen DPMI Dos Extender gleichzeitg geben, der übernimmt nämlich die ganze Verwaltung. Da DPMI aber standardisiert ist, ist es möglich den DOS Extender gegen einen anderen auszutauschen. Wenn der DOS Extender im Programmbinary eingebettet ist, muss die EXE natürlich gepatched werden. DOS32 kann das bspw. bei Executables, die DOS/4GW verwenden.

Bei VCPI war das Problem, dass es in Ring 0 lief und somit der Protected Mode zwar genug Arbeitsspeicher im linearen Zugriff bot, aber der Hardwareschutz, der Programme untereinander abschottet, ein weiteres Feature des Protected Modus (daher übrigens auch dessen Name) war damit aber nicht möglich. Hätte man also ein VCPI Protected Mode Programm mit einem weiteren VCPI Protected Mode Programm "gleichzeitig" laufen lassen, dann hätte es im Addressbereich des anderen Programms nach belieben herumschreiben können. Bei DPMI ist das anders, da läuft der Anwendungsteil im Ring 3. Das andere Problem war, dass Windows 3.x DPMI verwendete, das zu VCPI inkompatibel war. VCPI lief daher unter Windows 3.0 ausschließlich nur dann, wenn es im Real Mode gestartet wurde, denn im Real Mode hat bekanntlich ein Prozess vollen Zugriff auf die Hardware und den gesamten Speicher. Windows 3.0 könnte im Real Mode die Ausführung von VCPI somit auch nicht verhindern, im Protected Mode ist das anders. Dass DPMI von Microsoft mit OS/2 2.0 und Windows 3.0 entwickelt und offen gelegt wurde, weiß ich.

Du verrennst dich jetzt aber völlig beim ursprünglichen Thema, denn im Artikel wurde ja behauptet, dass DPMI für Real Mode Programme da sei. Im Artikel wird nämlich behauptet:

"Somit kann ein Real-Mode-Programm (etwa ein DOS-Programm) Funktionen des Protected Mode nutzen, indem es die entsprechenden DPMI-Funktionen aufruft. Der DOS-Extender schaltet daraufhin in den Protected Mode, führt die gewünschte Funktion aus, schaltet zurück in den Real Mode, und übergibt die Kontrolle wieder an das Anwendungsprogramm. "

Das ergibt keinen Sinn, ein Real Mode Programm hat nämlich vollen Zugriff auf die Hardware. Das einzige was es nicht kann ist Speicher oberhalb der 1 MiB Grenze nutzen (HMA ist noch ne Sondergeschichte, damit geht noch ein bisschen mehr, soll hier aber nicht das Thema sein). Die Funktion, die da im zitierten Text beschrieben wird, passt eher zu einem Memory-Extender wie XMS, da wird das nämlich tatsächlich gemacht, damit ein Real Mode Programm etwas mehr Speicher nutzen kann. Der Memory-Extender XMS läuft im Protected Mode. Das Real Mode Programm fragt diesen an und ruft im Adressbereich, dass das Real Mode Programm erreichen kann, also im konventionellen Arbeitsspeicher unterhalb der 640 KiB, eine Funktion des XMS Memory Extenders auf. Dieser wird dann aufgerufen, schaltet die CPU in den Protected Mode und kopiert dann einfach, wie es die Real Mode Anwendung erbeten hat, Speicherinhalte oberhalb der 1 MiB Adresse in den konventionellen Speicher oder umgekehrt. Und wenn das erledigt ist, schaltet es die CPU in den Real Mode zurück und gibt die Kontrolle an das Real Mode Programm wieder ab. Dadurch kann das Real Mode Programm dann mehr Speicher nutzen, allerdings ist der "ausgelagerte" Speicher nur als Datenspeicher nutzbar, solange bspw. Programmcode darin ausgelagert ist. Und ich denke, genau daran hat damals, derjenige, der das in den Artikel eingebaut hat, gedacht und es dann schlichtweg mit DOS Extendern verwechselt. Mein Korrektur ist somit immer noch richtig, du könntest sie mal sichten und abnicken.

Dass ein DOS Extender sowohl die DPMI oder alternativ die VCPI Spezifikation umsetzen kann, weiß ich, auch kenne ich die Vorteile von DPMI gegenüber VCPI. Du erzählst mir da nichts neues. Das steht auch alles in der englischen Wikipedia DOS Extender, DPMI und VCPI und habe ich schon vor deinem Kommentar auch in der deutschen Wiki in Wikipedia:Redaktion Informatik/Fehlende Artikel#Überarbeitungswünsche als eingebettettes HTML Kommentar umfangreich erwähnt und deswegen als Überarbeitungswunsch eine Aufteilung der Artikel DPMI und DOS Extender empfohlen. Alternativ könnte man auch einfach als Oberbegriff den Artikel DOS Extender schaffen und dann darin, als Unterabschnitt sowohl DPMI als auch VCPI einzeln mitsamt Geschichte und technische Unterschiede erwähnen.

Zu deiner Aussage:

"Ein Teil eines DOS-Programms muss aber immer auch im Real Mode laufen, denn sonst könnte es nicht mit der von DOS zur Verfügung gestellten "Infrastruktur" (Treiber, Dateisystem, BIOS- und System-Calls) umgehen."

Dieser Teil ist der DOS Extender selbst! Er ist die Abstraktionsschicht. Man könnte auch sagen, so ne Art Mini Kernel.

Zu deiner letzten Frage. Da wären mehrere Möglichkeiten denkbar:

Möglichkeit 1: Windows 3.x setzt auf einem 286er für solche Real Mode Win 16 Programme die CPU in den Real Mode zurück und könnte vorher noch Real Mode Subroutinen von Windows, die es ja wegen dem Real Mode Windows 3.0 geben musste, in den konventionellen Speicher geladen haben. Dadurch könnte das Real Mode Win16 Programm Win3.x nutzen, als wäre es ein Real Mode Windows. Und wenn das Programm fertig war oder der Nutzer zu einem anderen Windows Programm wechseln sollte, dann wechselte Windows in den Protected Mode zurück. Der Hacken, es könnte zu Instabilitäten führen und die Treiber müssten damit klarkommen. Außerdem belegt diese Variante zu viel Platz im konventionellen Speicher. Der Vorteil wäre, dass es schnell wäre.

Möglichkeit 2: Ähnlicher Fall wie bei Möglichkeit eins, nur dass die Windows Subroutinen nicht vollständig als Real Mode Code vorlagen, sondern nur als stubs (Funktionsstumpf) im konventionellen Speicher vorliegen und dann gleich bei Aufruf dieser Funktionen die CPU in den Protected Mode zurückgeschaltet wird und dort dann die vollwertigen Protected Mode Funktionen zur Ausführung verwendet werden. Wenn die Aufgabe erledigt ist, springt man zurück in den stubs, wechselt dann dort in den Real Mode zurück und gibt die Kontrolle an das Real Mode Programm wieder ab. Diese Art war sogar, wie ich gestern irgendwo gelesen habe (Link leider entfallen), gängige Praxis bei diversen Protected Mode Programmen. Der Vorteil wäre, dass man den konventionellen Speicherplatz gut frei halten hätte können. Der Nachteil wäre, dass die ständigen Kontextwechsel zwischen Real Mode und Protected Mode viel Zeit gekostet hätten und was dann wiederum für Variante 1 sprechen könnte. Vor allem hat Intel beim 286 nie vorgesehen, dass man vom Protected Mode in den Real Mode zurückwechseln kann, denn das würde die Hardwareschutzfunktion des Protected Mode untergraben, wenn eine Anwendung in den Real Mode wechseln könnte. Microsoft wollte das aber aus naheliegenden Gründen dringend haben und findige Programmierer fanden dann einen Weg, diesen Kontextswitch zurück in den Real Mode in der CPU doch noch auszulösen. Diesen Trick haben dann sowohl die DOS Extender Entwickler, als auch die Entwickler von OS/2 und Windows 3.x verwendet.

Möglichkeit 3: Win 16 Compilate, also Binaries könnten Code für den Realmode als auch Protected Mode gleichermaßen enthalten, die dann der Compiler natürlich erzeugen muss. Vergleichbar also zu Fat Binaries, wie sie in der 32 und 64 Bit Zeit für ein ähnliches Problem vorgeschlagen wurden. Und am Anfang macht man nen Header, der auf die Codestelle verweist, wo der RealMode Code beginnt, also der Einsprungspunkt ist und wo der Protected Mode Code beginnt. Der Programmloader von Windows wertet diesen Header dann vorher aus und springt dann an die entsprechende Codezeile. Vorteil: Das Programm wird immer nativ in der eigentlichen Umgebung ausgeführt, also entweder einem Real Mode Windows 3.0 oder einem Windows 3.x das im Protected Mode läuft. Teure Kontextswitches fallen damit weg. Dagegen spricht allerdings, dass es ja Win16 Programme geben soll, die nicht mehr unter einem 64 Bit Windows Betriebssystem laufen. Würde deren Code im Protected Mode vorliegen, dann wäre die Ausführung ja kein Problem, denn die Ausführung von 16 Bit Protected Mode Binaries soll in den 64 Bit Betriebsmodi durchaus noch funktionieren. Ein weiterer Grund wäre ein größerer Speicherplatzbedarf auf den Datenträgern. Bezüglich dem Speicherplatz im Ram könnte der Loader nur das laden, was nötig ist. Das wäre dann weniger ein Problem.

Ich würde daher vermuten, dass man Variante 2 gewählt hat. Variante 3 kann man eigentlich wegen den Erfahrungen bezüglich 16 Bit unter 64 Bit ausschließen. Variante 1 könnte aber bei Windows 3.0 gut möglich sein, denn da war ja ohnehin schon Real Mode Code vorhanden und dann hat man später vielleicht gemerkt, dass Stubs völlig genügen würden, der Kontextswitch vielleicht doch nicht so gravierend ist, die meiste Zeit wartet die CPU bei Fensterprogrammen schließlich auf Eingaben des Menschen, das Speicherplatz spart, die Komplexität geringer ist und zu stabilerem Verhalten führt und dann hat man vielleicht damit einen weiteren Grund gehabt, auch das Real Mode Windows fallen zu lassen. Aber das ist jetzt Spekulation. So vom praktischen her wäre Variante 2 am sinnvollsten. Speicherplatz war knapp, unnötige Komplexität beim Programmieren wollte man vermeiden, Instabilitäten waren unerwünscht, auch wenn sie bei Win3.x durchaus vorkamen und dann ist die Ausführungsgeschwindigkeit durch häufige Kontextswitches vielleicht gar nicht so ausschlaggebend, falls diese sich in Grenzen halten oder aufgrund der Beschaffenheit der Anwendung in Grenzen halten sollten. --84.158.122.178 08:22, 23. Dez. 2021 (CET)

Danke. Ich habe inzwischen auch ein wenig recherchiert. Quelle. So wie es aussieht, lief Windows 2.x nie im Protected Mode des 80286... Windows/286 nutzte lediglich HMA, was Windows/86 nicht konnte. Das war aber auch die einzige Änderung, ansonsten war Windows/286 einfach bloß Windows 2.x und lief wie bisher im Real Mode. Erst Windows/386 nutzte den Protected Mode, allerdings den des 80386 inkl. V86-Mode, und um letzteren ging es: denn damit konnten mehrere Real-Mode-Instanzen von Windows- oder DOS-Programmen gleichzeitig laufen, was aber nur dank der Hardware des 386 möglich war. Windows war immer noch 16-Bit, aber der 16-Bit-Protected-Mode des 286 bot kein V86M, sodass dieser Modus mehr oder weniger nutzlos war für Windows.

Damit ist klar, dass es keine Windows-2.x-Programme gab, die den Protected Mode nutzten: das waren allesamt Real-Mode-Programme.

Windows 3.x hat wohl erstmals das Win16-API in den Protected-Mode gebracht, was aber nur auf einem 386-Prozessor gemeinsam mit Real-Mode-Programmen funktionieren konnte. Siehe dazu auch dieses Wiki, das aber keine zuverlässige Quelle ist. Jedenfalls liefen offenbar die Programme aus Windows 2.x auch unter Windows 3.x im Protected Mode, wenn sie die System-Aufrufe der Win16-API nutzten.

Genaueres konnte ich leider nicht finden.

‣Andreas•⚖ 15:39, 23. Dez. 2021 (CET)

Nachtrag: Protected mode#Real mode application compatibility in einer Wiki, aber mit Quellenangaben. Zitat: „Windows 3.0 and its successors can take advantage of the binary compatibility with real mode to run many Windows 2.x (Windows 2.0 and Windows 2.1x) applications in protected mode, which ran in real mode in Windows 2.x.“ Es scheint also doch zu stimmen, was ich anfangs gesagt habe.

‣Andreas•⚖ 16:09, 23. Dez. 2021 (CET)

Wie schon gesagt, Windows 2 war nie ein Thema und hat auch so gut wie niemand ernsthaft benutzt. Die meisten Softwarefirmen schrieben zu dieser Zeit lieber reine DOS Programme. Es war somit nicht wirklich mehr als eine Demo von Microsoft um zu zeigen, dass es auf einem IBM PC auch eine grafische GUI gibt. Und natürlich lief Windows 2.x nicht im Protected Mode, ich habe derartiges auch nicht behauptet, allerdings machte es Gebrauch von einem Expanded Memory Manager, der konnte XMS oder EMS Memory oberhalb des 1 MiB Bereichs zu Verfügung stellen, der musste im Protected Mode laufen, weil er sonst gar nicht auf das RAM oberhalb der 1 MiB Grenze auf einem 286er zugreifen hätten könnte, wenn dieser mit mehr RAM ausgelegt war. Eine Ausnahme bildeten Expander Memory Karten, die konnten sogar auf einem 8086 mehr RAM zur Verfügung stellen, welches sie dann einfach im UMB Block einblendeten. Natürlich brauchte man dafür ebenso einen XMS Expanded Memory Manager und die Real Mode Anwendung musste den nutzen können.

Aber zurück zu Windows. Das änderte sich alles erst mit Windows 3.x. und das wurde dann auch exzessiv von Softwareherstellern benutzt, unterstützt und Programme dafür geschrieben. Windows fing somit ernsthaft eigentlich erst mit Windows 3.x an, alles was davor erschien, spielte praktisch auf dem Markt keine Rolle. Da hatte OS/2 1.x eine weitaus größere Verbreitung. Bezüglich deiner Frage, wie DOS Anwendungen auf einem 286er ohne V86 Mode unter Windows ausgeführt werden konnte, gibt übrigens OS/2 einen interessanten Anhaltspunkt. Bei OS/2 war die Ausführung auf nur eine einzige DOS Anwendung limitiert, während das OS selbst im Protected Mode lief. Erst auf dem 386er mit V86 ändert sich das dann auch bei OS/2. Ob das unter Windows 3.x auf einem 286er auch so war, weiß ich nicht, es wäre aber eine Möglichkeit.

Zu deiner zweiten Quelle und dem 286, da steht:

The standard mode took advantage of the i286 CPU's protected mode. It allowed for MS-DOS sessions,

Klar, dazu muss aber die CPU in den Real Mode umgeschaltet werden und der gilt dann solange, solange die Real Mode Anwendung die Kontrolle über die CPU hat. In dem Moment, wo sie eine Windows Funktion aufruft, gibt sie die Kontrolle wieder ab und die Windows Funktion schaltet die CPU zurück in den Protected Mode, für Real Mode Win Anwendungen müssen hierfür Stümpfe der Win API im konventionellen Speicher erreichbar sein, so wie ich es oben erklärte. Und der Grund warum da folgendes steht:

It's worth noting that as long as your Windows program used the API for all of it's memory & disk (you had to for the GUI/screen) your realmode applications would just work in the protected mode environment

liegt einfach daran, weil die Möglichkeit besteht, dass es ansonsten knallt, wenn die Real Mode Anwendung im Real Mode CPU Modus auf Sachen zugreift, auf die es nicht zugreifen sollte und mit dem es Windows, sobald dieses wieder die Kontrolle hat und in den Protected Mode zurückkehrt, durcheinanderbringen könnte. Das war der Grund und deswegen steht das auch in der Quelle, dass sich die Real Mode Windows Anwendung an die API halten soll. Denn der Real Mode verhindert natürlich nicht, unzulässige Zugriffe an Windows vorbei durchzuführen. Im Protected Mode wäre das anders, da würde die Hardware den Zugriff dann verhindern können. Solange die Real Mode Anwendung aber nur die Windows Funktionen aufrief, wofür diese Stubs im konventionellen Speicherbereich benötigten, gab es da natürlich keine Probleme, denn wenn man sich strikt an die API hielt, wurde so ja nichts an Windows vorbei herumgepfuscht. Windows fand somit alles wieder so vor, wie es war, als es den Protected Mode verließ um die Kontrolle an die Real Mode Anwendung abzugeben und dann später wieder zurückbekam. Einer der wesentlichen Unterschiede beim i386 und dessen VR86 Mode bzw. dem Enhanced Mode ist also, dass der Enhanced Mode den Protected Mode für Real Mode Programme nie verlassen muss, der Standard Mode beim 286 aber schon.

Und natürlich war es auch immer möglich, die damals für 16 Bit Real Mode Windows geschriebenen Windows Programme einfach neu zu kompilieren, wenn sie sich auf die WinAPI beschränkten, um dann davon eine 16 Bit Protected Mode Windows Anwendung zu erhalten. Das konnte allerdings nur der Hersteller bzw. der, der den Code hatte. Sobald der Code etwas an der WinAPI vorbei machte, musste er für eine protected mode Version angepasst werden, denn im Protected Mode konnte er nicht mehr herumpfuschen, wie er wollte.

Wenn du es ganz genau wissen willst, dann müsstest du es schlichtweg ausprobieren. Also eine einfache 16 Bit Real Mode Windows Anwendung programmieren, die dann bspw. ein Windows Fenster anzeigt und im UMB oder in Bereichen, in denen Windows sich im Protected mode eigentlich schützen würde, aber die 16 Bit Real Mode Anwendung erreichen könnte, herumpfuscht und dann musst du Windows 3.x im Standard Mode, idealerweise auf einem emulierten 286er ausführen. Wenn es dann knallt, also Windows 3.x durcheinanderkommt, dann weißt du, dass der Protected Mode für die Real Mode Anwendung verlassen wurde. Wenn es nicht knallen sollte, dann hätte der Hardwareschutz des Protected Mode gegriffen und die CPU den Protected Mode somit nie verlassen. Aus Erfahrung mit Windows 3.x würde ich aber stark schätzen, dass es knallen wird, denn wirklich stabil lief Windows 3.x eigentlich nicht, obwohl es das hätte müssen, wenn es den Hardwareschutz immer durchgesetzt hätte. Das, also stabil, gescheite Treiber vorausgestezt, wurde es erst mit Windows NT und das lief ausschließlich nur im Protected Mode und nutzte daher auch immer dessen Hardware Schutzfunktionen. Außerdem war WinNT ein preemptives Multitasking OS, Windows 3.x hatte leider nur kooperatives Multitaskting. D.h. die Windows 3.x Anwendung konnte die CPU an sich reißen und auch einfach nie mehr abgeben. --84.158.122.178 21:20, 23. Dez. 2021 (CET)

Ergänzung: Oder noch einfacher. Schreib das 16 Bit Real Mode Windows Programm so, dass es ein Register in der CPU abfragt, dass der Anwendung dann mitteilt, in welchem Modus es sich befindet. Siehe dazu auch folgender Artikel https://lateblt.tripod.com/realmode.htm Das dürfte die einfachste Variante sein. --84.158.122.178 21:31, 23. Dez. 2021 (CET)

Ich bin kein Programmierer. Ich werde das vermutlich nicht hinbekommen.

Irgendwann einmal hab ich irgendwo gelesen (eine Computer-Zeitschrift? ein Fachartikel im Internet?), dass Windows 95 oder sogar Windows NT auch noch Win16-Anwendungen von Windows 2.03 ausführen könnte. Ich denke es war so etwas triviales wie reversi.exe oder etwas ähnliches.

Für mich interessant ist die Situation auf dem 286er. Ja, OS/2 nutze den 16-Bit-Protected-Mode des 286 wirklich voll aus, was ja auch die Hauptkritik an der OS/2-Entwicklung von Microsoft an IBM war, denn statt gleich auf dem 386er zu programmieren, war für IBM volle Kompatibilität mit dem 286er oberste Priorität. Aber das war für Microsoft nur ein unwesentlicher Zwischenschritt, und den hat man in Redmond gleich ganz übersprungen. Die Geschichte gibt Microsoft Recht, nicht IBM.

Zur Situation im Detail: OS/2 und Windows lässt sich auf dem 286 überhaupt nicht vergleichen. Was OS/2 macht, ist nicht, was Windows macht. Windows auf dem 286er lief immer im Real Mode, also wie auf einem 8086/8088er. Nur HIMEM.SYS erlaubte es, die vollen 1 MB und die HMA zu nutzen. Das war es aber auch schon.

Es ist verflixt, dass es sich nirgends nachlesen lässt, wie Windows auf einem 286 Programme ausgeführt hat. Und ich gehe davon aus, dass Windows 3.0/3.1 das auf einem 286 genau gleich gemacht hat. Erst mit Windows 3.11 fällt der 286er weg.

Und dann würde es mich noch interessieren, wie unter Windows 9x alte Win16-Real-Mode-Programme ausgeführt werden, was definitiv funktioniert hat. Unter Windows NT wäre es nochmals nachzurecherchieren, aber wie gesagt, ich bilde mir ein, das irgendwo gelesen zu haben...

‣Andreas•⚖ 11:41, 24. Dez. 2021 (CET)

Sowohl WinNT, als auch Windows 9x/ME setzen einen 386er voraus und nutzen dann natürlich für die Realmode Programme den Virtual 8086 Mode den die CPU bietet. Ich werde aber mal etwas recherchieren, vielleicht finde ich noch etwas dazu. --84.158.122.178 03:21, 25. Dez. 2021 (CET)

Zu deiner Aussage:

Windows auf dem 286er lief immer im Real Mode, also wie auf einem 8086/8088er.

Das gilt nur für die Windows Versionen vor Windows 3.0. Ab Windows 3.0 wird Windows auf einer 286 CPU im Standard Mode ausgeführt und das ist ein Protected Mode Betriebsmodus. Den Protected Mode gibt es nämlich ab dem 286-er, lediglich die Art der Speicheraddressierung ist noch nicht so weit fortgeschritten wie beim 386, Stichwort Paging, ebenso fehlt auf dem 286 der Virtual 8086 Modus.

Es ist allerdings mit Windows 3.0 unter DOS mit dem Befehlsaufruf win /r möglich, Windows im Real Mode zu starten und so auf einer 286 CPU und späteren Prozessoren den Betrieb von Windows 3.0 im Real Mode zu erzwingen. Erst ab späteren Windows Versionen geht dies nicht mehr, da diese den Real Mode nicht mehr unterstützen.

Wenn man versucht eine Windows Real Mode Anwendung unter Windows 3.0 im Standard Mode auszuführen, also wen Windows selbst im Protected Mode läuft, dann erhält man eine Warnung dass man den Ladevorgang abbrechen und Windows zuerst im Real Mode mit der Option win /r starten soll. Dort, in diesem Modus läuft die Anwendung dann ohne Probleme, sofern der konventionelle Arbeitsspeicher ausreicht.

Ignoriert man die Warnung und versucht die Real Mode Anwendung im Standard Mode (Protected Mode) von Windows 3.0 auf einem 286-er dennoch auszuführen, dann kann das zu Kompatibilitätsproblemen und unerwartetem Programmabbruch führen. Das geht in schweren Fällen sogar so weit, dass man den Rechner neu booten muss.

Im Falle eines Fehlers meldet dann Windows die Fehlermeldung "Unrecoverable Application Error" mit dem Text "Terminating current application".

Der Grund, warum man diese Option des "Warnung ignorieren und trotzdem ausprobieren" hat, liegt wohl daran, dass die Real Mode Anwendung funktionieren kann, wenn sie sich strikt an die Windows API Funktionen hält und nichts anders macht. Die 16 Bit Windows 3.0 eigenen Anwendungen, wie bspw. Notepad tun dies, deswegen laufen die auch auf allen späteren Windows 3.x und Win9x Versionen. Der ganze, für den Protected Mode notwendige Code läuft in dem Fall dann in den APIs von Windows, weswegen es der Anwendung egal sein kann, ob sie nun unter einem Windows 3.0, das im Real Mode ausgeführt wurde oder einem Windows 3.0, das im Protected Mode ausgeführt wurde, läuft.

Die großen Unterschieden liegen bei Windows 3.0 Real Mode vs. Standard Mode vs. Enhanced Mode im Wesentlichen im verwendeten Windows Kernel.

• C:\WINDOWS\SYSTEM\KERNEL.EXE = Real Mode Kernel (Nur Windows 3.0)
• C:\WINDOWS\SYSTEM\KRNL286.EXE = Standard Mode Kernel für 286er und spätere CPUs
• C:\WINDOWS\SYSTEM\KRNL386.EXE = Enhanced Mode für 386er und spätere CPUs

Anmerken kann man hier übrigens noch, dass Notepad von Windows 3.0 bis Windows 3.1 von dem mehr an Speicher, das der Protected Mode ermöglichen könnte, gar keinen Gebrauch macht, da es nur Dateien mit einer Dateigröße von maximal 54 KiB öffnen kann. Das liegt an der Speichergrenze eines 16 Bit Segments (small memory Model) womit innerhalb von diesem Segment nur (2^16)-1 = 64 KiB adressierbar sind. Die restlichen 10 KiB, also wenn man von 64 KiB die 54 KiB abzieht verwendet Notepad vermutlich für sich selbst. Erst ab Windows 95 können auch Dateien bis zu 64 KiB Größe geeöffnet werden. Ich tippe mal darauf dass der Programmcode hier in ein eigenes Segment ausgelagert wird und vom Paging des 386 Gebrauch gemacht wird. Möglicherweise ist das auch bereits schon unter Windows 3.x im Enhanced Mode der Fall, nur ausprobiert habe ich es noch nicht. --IT-Compiler (Diskussion) 21:21, 20. Jan. 2022 (CET)

Noch eine Ergänzung. Windows 9x/ME kann 16 Bit Windows REAL MODE Programme übrigens nicht ausführen. Es gibt dann eine Fehlermeldung und der Hinweis, dass man eine spätere Programmversion verwenden soll. --IT-Compiler (Diskussion) 22:21, 20. Jan. 2022 (CET)

Zur ursprünglichen Aussage dieser Diskussion: Ja, nach dem, was ich inzwischen alles darüber gelesen habe, sind DPMI-Programme (also solche, die einen DOS-Extender verwenden) keine Real-Mode- sondern Protected-Mode-Programme. Der DOS-Extender stellt lediglich die standardisierte Schnittstelle zur Verfügung, damit es keine Kompatiblitätsprobleme mit anderen Protected-Mode-Programmen gibt. (Ob nun ein anderes Anwendungsprogramm oder DOS-basiertes Windows...)

Warum mich die Situation von Windows/286 und OS/2 1.x so sehr interessiert, ist, weil diese auch den 16-Bit-Protected-Mode des 286 unterstützen, wie es auch DPMI tut. Das heißt, ein DPMI-DOS-Programm kann sowohl ein 16-Bit- als auch ein 32-Bit-Programm sein, denn den Protected Mode gibt es ja in diesen beiden Varianten. Damit kann ein 16-Bit-Programm per DPMI unter DOS die vollen 16 MB nutzen (abzüglich dem, was bereits belegt ist), und funktioniert auf einem 80286 wie auch auf späteren Prozessoren. Das ist unter DOS noch relativ einfach, aber unter OS/2 und Windows stellt sich dann doch die Frage, wie diese Systeme im 16-Bit-Protected-Mode – auf einem 80286 ohne Virtual 8086 Mode – mit Multi-Tasking und dem Real Mode umgehen. Heißt: wie läuft unter OS/2 1.x das Betriebssystem (16-Bit-Protected-Mode) gleichzeitig mit mehreren DOS-Programmen (im Real Mode)? Und wie macht das Windows bis Version 3.0 auf einem 80286? Das würde grundsätzlich dann auch DPMI treffen, wenn z.B. ein Programm per TSR den DOS-Extender nicht beendet, und dann ein anderes Programm ebenfalls DPMI nutzt.

Was ich mir schon erklären kann, ist, wie ein DPMI-Programm unter OS/2 oder Windows auf einem 286 läuft, denn dafür muss ja nicht in den Real Mode zurückgeschalten werden, und somit ist soetwas wie der Virtual 8086 Mode, der dem 80286 aber fehlt, auch nicht nötig. Bei Real-Mode-Programmen jedoch schon – aber wie funktioniert es bloß ohne VM86?

VCPI betrifft das alles nicht, denn das setzt ja einen 80386 voraus. Da VCPI von der Industrie – Dank Microsoft, das DPMI als freie Spezifikation an eine unabhängige Gemeinschaft vieler Firmen abgegeben hat – für DPMI fallen gelassen wurde, hatte auch zur Folge, dass sehr viele DPMI-Hosts (DOS-Extender) sowohl VCPI- als auch DPMI-Programme unterstützten. Nur eben dass nun auch (anfangs) der 80286 unterstützt wurde.

Ich habe z.B. über 386MAX gelesen, dass es DOS und Real-Mode-Programme selbst in den VM86 verfrachtet hat. Für Real-Mode-Programme ist ja kein Unterschied erkennbar, ob sie im (exklusiven) Real Mode oder im (Multitasking-fähigen) VM86 laufen. DOS lief also weiter wie bisher, nur dass der DOS-Extender damit weit flexibler war. 386MAX läuft natürlich nicht auf einem 80286, unterstützt aber klarerweise auch 16-Bit-DPMI-Programme (denen dan 16 MB Speicher zur Verfügung steht).

Es gibt aber auch DOS-Extender, die 80286-optimiert waren. Und um diesen Fall ging es mir. Da bin ich noch kein Stück weiter... *seufz*

‣Andreas•⚖ 14:40, 25. Jan. 2022 (CET)

Zu deiner Frage:

aber unter OS/2 und Windows stellt sich dann doch die Frage, wie diese Systeme im 16-Bit-Protected-Mode – auf einem 80286 ohne Virtual 8086 Mode – mit Multi-Tasking und dem Real Mode umgehen.

Ganz einfach, per en:LOADALL. Die Register werden gesichert und dann wird einfach per LOADALL in den Realmode zurückgewechselt. Deswegen ist auf dem 286 auch nur ein DOS Programm gleichzeitig möglich. Und das ist auch die Einschränkung, die OS/2 hatte und erst ab dem 386er in einer entsprechenden Version für den 386 beseitigt wurde, denn der 386 kann den Virtual Mode.

Heißt: wie läuft unter OS/2 1.x das Betriebssystem (16-Bit-Protected-Mode) gleichzeitig mit mehreren DOS-Programmen (im Real Mode)?

Das geht nicht. Es geht beim 286er der vom Protected Mode in den Real Mode geschaltet wird nur ein DOS Programm gleichzeitig. Und im Artikel zu OS/2 steht da auch etwas diesbezüglich drin, dass es diese Einschränkung hatte und die hatte es wegen dem 286er.

Aus dem gleichen Grund wird im Standard Mode von Windows 3.1 die Windowsoberfläche praktisch verlassen, im Speicher existiert sie natürlich weiter, aber die CPU und der Bildschirm wechselt zum Command Prompt. Eine DOS Eingabeaufforderung innerhalb der Windows Arbeitsfläche in einem Fenster geht erst ab dem erweiterten Modus (enhanced Mode) und dafür ist ein 386er notwendig. --IT-Compiler (Diskussion) 21:52, 25. Jan. 2022 (CET)

Okay, MS-DOS, Windows und OS/2 haben das auf dem 286 nicht unterstützt, es gab immer nur ein Real-Mode-Programm.

Aber unmöglich war es dennoch nicht, wie Concurrent DOS von Digital Research bewiesen hat. Die Zusammenarbeit mit Intel diesbezüglich soll dann ja auch letztendlich zum Virtual-8086-Mode des 80386 geführt haben...

• Multitasking MS-DOS 4.0, was dann Windows/286 und später OS/2 wurde: nur ein Real-Mode-Programm^{ref, ref}
• Mehrere Real-Mode-Programme parallel ausgeführt unter Concurrent DOS und FlexOS auf einem 286^ref

Der 286 hatte prinzipiell schon die Möglichkeit, aber der Performance-Overhead war größer.^{ref, GB}

‣Andreas•⚖ 19:05, 3. Feb. 2022 (CET)

DOS Extender und Virtual 8086 Mode des 386er

Die meisten Protected Mode Programme mit DOS Extender nutzen den Virtual 8086 Mode des 386er um so einfach DOS spezifische Zugriffe in der virtualisierten Umgebung durchzuführen ohne den Protected Mode verlassen zu müssen. Siehe Quelle. Das sollte man im Artikel vielleicht noch irgendwo einbauen. --IT-Compiler (Diskussion) 21:50, 24. Aug. 2022 (CEST)

DPMI unterstützt wohl auch VCPI Anwendungen

Das steht zumindest in folgendem Artikel. Wer die Zeit hat, kann das ja mal genauer überprüfen. --IT-Compiler (Diskussion) 21:56, 24. Aug. 2022 (CEST)

DPMI 1.0 ist nicht das gleiche wie True DPMI (welches Windows 3.0 verwendet)

Hier https://lists.gnu.org/archive/html/lynx-dev/1998-04/msg00773.html ist ein wichtiger Artikel, der darüber Aufschluss gibt. --93.229.164.202 09:22, 11. Nov. 2023 (CET)

Danke! Das war toll zu lesen.

Das Problem hier ist, dass DPMIONE^ref angibt, DPMI 1.0 umzusetzen: XMS driver (HIMEM.SYS or Memory Manager EMM386/QEMM/etc. -- 386MAX 7 and later versions already support DPMI 1.0) während dieses Dokument^ref schreibt: If you want the latter without running Windows, your current choices are (to my knowledge) 386Max and QEMM-386 with QDPMI. There also is the Borland DPMI host, but it's 16-bit only. Oh, and OS/2, Windows NT, and Novell DOS all implement True DPMI.

Was ergibt sich daraus? Eine Vermischung der Begriffe DPMI 1.0?

‣Andreas•⚖ 10:29, 11. Nov. 2023 (CET)

Ganz einfach, True DPMI und DPMI 1.0 sind nicht das selbe. Es gibt gemäß diesem Artikel 3 Versionen von DPMI:

• DPMI Version 0.9, die eine unvollständige Teilmenge von True DPMI ist, aber dafür eine öffentliche Spezifikation hat
• DPMI Version 1.0, die Version 0.9 umsetzt und noch etwas eigenes oben drauf setzt um 0.9 zu erweitern, aber inkompatibel zu True DPMI ist. Implementiert wurde 1.0 in bspw. CWSDPMI, das von GCC verwendet wird, weil man bei den DJ GCC Machern damals noch nichts über True DPMI wusste. Außerdem gibt es für DPMI Version 1.0 auch eine öffentliche Spezifikation.
• True DPMI, das am weitesten verbreitete DPMI, da es von Windows 3.0, 3.1, Windows 95, 98, OS/2, Windows NT und dem Borland C Compiler und Borland Turbo Pascal Compiler unterstützt bzw. verwendet wird, aber wofür nie eine öffentliche Spezifikation freigegeben wurde. Das haben also nur manche wenige Firmen, wie Microsoft und das ehemalige Borland. True DPMI war auch die Version, die zuerst da war.

Damit ergibt sich aus DPMI 1.0, dass es ein anderer Zweig ist, also eine Abspaltung. Beide setzen DPMI 0.9 um. Aber True DPMI war zuerst da, erst daraus wurde ein Teil entnommen um DPMI 0.9 zu erstellen. Und auf dieser Teilmenge von 0.9 hat man dann DPMI 1.0 gemacht, was aber nur wenige Produkte nutzen und schon gar nicht die wichtigen Produkte.

Ergänzung, man darf sich von der Version 1.0 also nicht täuschen lassen, es ist nicht die bessere Version im Sinne von neuer, sondern die inkompatible Version zum De-facto Standard True DPMI. True DPMI ist also die wichtigere maßgebende Version und DPMI 1.0 somit eher eine Fehlentwicklung, also eine Sackgasse. Dennoch bietet es, soweit ich das verstanden habe, eine API im Protected Mode für DOS Programme. Etwas, was DPMI 0.9 fehlt, aber True DPMI hat. --93.229.164.202 11:17, 11. Nov. 2023 (CET)

Ja, genau das sagt die Quelle. Das ist eine Quelle, und es ist "die Meinung" eines Entwicklers von lynx. Ich glaube ihm zwar, was er schreibt, aber es ist eine einzige Quelle, und dann eben "nur" eine E-Mail (Newsgroup). Siehe dazu auch WP:Q.

Worauf ich hinaus will: Welche Version von DPMI setzt z.B. 386Max oder QEMM um? Laut der einen Quelle (DPMIONE) wäre das DPMI 1.0, laut der anderen Quelle (lynx-Entwickler) wäre es "True DPMI", was übrigens nicht der Name ist, sondern soviel heißt wie "das wahre DPMI" (im Sinne "ursprüngliche, einzige, vollständige"). Die Quellen widersprechen sich also schon mal in diesem Bezug.

Erst, wenn das geklärt ist – und dazu braucht es eine zusätzliche Quelle gem. WP:Q, zu der dann das E-Mail durchaus als Zusatz dienen kann – erst dann kann man die ausgeführten Informationen in den Artikel eintragen. Momentan würde ich durchaus der offiziellen Spezifikation von DPMI 1.0 und dem GitHub-Repository von DPMIONE den Vorzug geben.

‣Andreas•⚖ 16:50, 12. Nov. 2023 (CET)

Übrigens, Nachtrag: https://virtuallyfun.com/2011/08/02/some-history-on-dpmi/ – "I seriously doubt that the above history is anywhere close to accurate" und "The “MS-DOS Extensions for DPMI Hosts” document only confirms what I said. It is not a complete 32-bit DOS environment; one of the biggest missing pieces is the ability to load a 32-bit protected-mode application. In other words, a DOS extender is still needed, even if it does not have to do the job of actually extending the DOS INT 21h API. And because this capability never became part of DOS itself, it’s completely moot — application writers still needed DOS extenders." von Michal Necasek, wer immer das ist. ‣Andreas•⚖ 18:27, 12. Nov. 2023 (CET)

CWSDPMI erlaubt es mit der Option -x ohne die DPMI 1.0 Funktionen als DPMI 0.9 Server zu starten. In der Dokumentationsdatei CWSDPMI.DOC zu CWSDPMI heißt es dazu:

You can disable the DPMI 1.0 extensions by starting the image with the "cwpsdpmi -x" syntax. This feature allows you to run programs developed under other DPMI providers which do not behave properly with these extensions enabled (typically use of NULL pointers).

Eine gleiche Umschaltoption wäre auch mit 386Max möglich und auch sehr wahrscheinlich, um die Produktkompatibilität zu erhöhen. Außerdem läuft 386Max mit Windows 3.x, was dafür spricht, dass es mit True DPMI kompatibel ist.

386MAX is a computer memory manager for DOS, and has two neat features: 1. 386MAX supports the Global EMM Import Specification (GEMMIS), which allows Windows 3.x to start in 386 Enhanced mode, even when the EMM manager is loaded.

Quelle: https://sourceforge.net/p/freedos/news/2022/07/the-386max-source-code-has-been-released/

Außerdem gilt, es kann nur ein DPMI Server zur gleichen Zeit Ring 0 des Protected Mode in Beschlag nehmen. D.h. wenn Windows 3.x mit seinem True DPMI Server aktiv ist, dann kann kein DPMI 1.0 Server gestartet werden. So steht es auch in der Dokumentationsdatei CWSDPMI.DOC zu CWSDPMI:

"Protected mode not accessible."

This message should only be displayed if running CWSDPMI in a protected environment with no access to protected mode. In this case, DPMI should already be available and CWSDPMI would not be needed. This might happen if a 16-bit DPMI client is loaded and a DJGPP image attempts to load CWSDPMI to provide 32-bit DPMI services under Windows."

Ein 16 Bit Programm, das CWSDPMI automatisch lädt, wenn kein DPMI Server geladen ist, ist bspw. der Texteditor FED, der bei FreeDOS mitgeliefert wird. Wenn ich den unter Windows in der MS-DOS Eingabeaufforderung starte, dann ist ein DPMI Server schon in Betrieb und FED verwendet dann diesen. CWSDPMI wird dann nicht gestartet. FED verwendet sehr wahrscheinlich nur DPMI 0.9 Funktionen, daher reicht der True DPMI Server, der mit Windows gestartet wird. FED bietet im Menü eine Möglichkeit, die Kommandozeile zu laden, während FED noch läuft. Da kann man dann mit MEM /C /P überprüfen, ob CWSDPMI geladen ist oder nicht.

Wenn man MS-DOS frisch bootet und kein HIMEM.SYS geladen ist und dann CWSDPMI lädt, um danach Windows 3.1 zu starten, dann meckert Windows, dass kein HIMEM.SYS gefunden wurde. Bootet man MS-DOS mit HIMEM.SYS und lädt CWSDPMI als TSR in das RAM, dann kann man Windows 3.1 starten, ABER, es bedeutet nicht, das CWSDPMI auch wirklich aktiv ist. Denn das ist dann nur nutzlos als TSR Programm geladen, es bedeutet nicht, dass es dann den Protected Mode auch schon in Beschlag genommen hat.

DOS zu booten, dann CWSDPMI mit FED zu starten, so dass CWSDPMI definitiv den Protected Mode für FED in beschlag nimmt und dann aus der Kommandozeilenoption von FED heraus Windows zu starten hat leider nicht funktioniert. Hier hat Windows zwar nur gemeldet, dass nicht genug konventionelles RAM zur Verfügung steht, aber es wäre auch denkbar, dass der aktive DPMI Server, hier also CWSDPMI inkompatibel ist oder ein anderer nicht geladen werden kann.

Was jetzt nötig wäre, wäre ein reiner DPMI 1.0 Server, den man aktiv machen kann, so dass er den PM in Beschlag nimmt, aber so, dass nur wenige konventioneller RAM benötigt wird und dann daraus versuchen Windows 3.1 im enhanced Mode zu starten. Erwartungsgemäß müsste dass dann fehlschlagen, da DPMI 1.0 kein True DPMI ist und der aktive DPMI 1.0 Server daher nicht für Windows geeignet ist. Leider ist mir kein DPMI Client mit geringem konventionellen RAM Verbrauch bekannt, der einem Zugriff auf eine Kommandozeile lässt, so dass man Windows 3.1 starten kann.

Ja, True DPMI ist nicht der offizielle Name, da es keinen offiziellen Namen für True DPMI gibt. Aber irgendwie muss man das hier nennen, wenn man sich darauf beruft. Und True DPMI ist eben schon als Begriff dafür etabliert.

Windows 3.x ist bis einschließlich Win9x/Me, übrigens selbst ein DPMI Client.

Dieser Michael Necasek disqualifiziert sich mit folgendem schon selbst:

And the bit about DOS extenders being bad because they’re built into every app is total nonsense. It completely ignores the history–early DOS extenders had to have everything built in because they simply had no other choice.

Denn er hat hier unrecht. Natürlich ist das schlecht, wenn ein DPMI Server fest mit einer DPMI Client EXE verbundelt wird. Es würde auch anders gehen, nämlich zur Laufzeit, wie es bspw. der obige FED Editor macht. Der lädt den DPMI Server nach, wenn FED keinen findet. Den DPMI Server hätte man also auch damals, wenn man die Geschichte von DOS berücksichtigt, mit der DOS Anwendung als eigenständiges Programm mitliefern können. So wie man es später unter Windows mit den VB und C++ Runtime Libs gemacht hat. Da spricht überhaupt nichts dagegen, die Anwendung wäre dann immer noch gelaufen, nur wäre es ein besseres Design, da der DPMI Server dann austauschbar wäre, wenn er der gleichen Spezifikation folgt.

Lediglich in einem Punkt hat er recht, dass Microsoft keine 32 Bit DOS API braucht, wenn die Windows durchboxen wollten. Deswegen ist DPMI 0.9 ja auch nur ein Subset von True DPMI, das Zugriffe vom PM Host aus auf die Real Mode DOSAPI erlaubt. Aber Michael Sokolov hat hier nichts Gegenteiliges behauptet. True DPMI ist öffentlich undokumentiert und es muss nicht alle Funktionen anbieten, die DPMI 1.0 bieten müsste, wenn man von Anfang an nicht vor hat, DOS 32 bit PM Anwendungen zu erlauben. Die angebotenen Funktionen von True DPMI im PM Bereich müssen nur für Windows und OS/2 reichen, sowie die Bibliotheken der Borland Compiler, die ja True DPMI nutzen, aber derartiges sagte auch Michael Sokolov.

Bei DPMI 1.0 ist das anders, das muss alles anbieten, was eine 32 Bit DOS Anwendung brauchen könnte. Inkompatibel können DPMI 1.0 und True DPMI dadurch trotzdem sein. Es reicht ja, das man das anders implementiert, die Funktionen anders heißen und somit anders aufgerufen werden und fertig ist die Inkompatibilität. Michael Necasek sagt also nichts, was die Aussagen Michael Sokolov's Artikel stichhaltig widerlegt. --93.229.164.202 03:34, 13. Nov. 2023 (CET)

Es gibt übrigens noch eine weitere Möglichkeit um die Inkompatibilität zwischen DPMI 1.0 und True DPMI aufzuzeigen. Nimm einen DPMI Client der alle Protected Mode Funktionen von DPMI 1.0 durchprobiert und dann versuche ihn unter Windows 3.x zu starten. Das wird nicht klappen. Wäre DPMI 1.0 und True DPMI identisch, dann würde es gehen. Unter Windows 3.x (oder Win95) laufen aber nur True DPMI und DPMI 0.9 Clients. Für echte DPMI 1.0 Clients müsste Windows 9x wie bei den DOS Extendern verlassen werden und in den reinen DOS Modus gestartet werden. --93.229.164.202 03:49, 13. Nov. 2023 (CET)

Ok, es ist bestätigt. Es gibt True DPMI und DPMI 1.0 und Windows nutzt True DPMI. Dazu lies mal dieses Dokument des Antitrustverfahrens gegen Microsoft durch:

https://web.archive.org/web/20180918054241/http://antitrust.slated.org/www.iowaconsumercase.org/011607/1000/PX01306.pdf

Die DPMI Version von Microsoft verfügte über DOS Extensions, die von Windows benutzt wurden, aber nicht in der DPMI 0.9 Spec enthalten sind und mit DPMI 1.0 auch nicht kompatibel sind. Den Link habe ich im englischen Artikel der WP zu DPMI im Abschnitt History gefunden. Da gibt es noch weitere Quellenbelege. Was Michael Sokolov sagte, stimmt also alles. --93.229.164.202 06:40, 13. Nov. 2023 (CET)

Das mag alles stimmen, aber der Begriff "True DPMI" existiert nicht offiziell. Es ist eine undokumentierte Implementierung, die keinen öffentlichen bzw. offiziellen Namen erhalten hat. Um dem Ding einen Namen zu geben wurde die Bezeichnung in der Hobby-Community erfunden. Der Begriff taucht aber in keinem Standard / MSDN / MS-KB-Artikel / Fachbuch / Google Scholar auf.

=> Wikipedia darf lt. WP:Belege nur gesichertes Wissen enthalten. => WP:KTF / WP:Begriffsfindung

PS: Er taucht auch nicht in den geleakten Dokumenten von Sokolov's FTP-Server und auch nicht in der gerade verlinkten E-Mail auf. Es wird das Verhalten beschrieben, aber nicht der exakte Term "True DPMI" genutzt.

Man kann (und sollte durchaus) im Artikel die wahre Natur beschreiben, aber der Begriff "True DPMI" muss entweder raus oder wie in der englischen Wikipedia in Anführungszeichen gesetzt werden mit dem Hinweis, dass diese Bezeichnung inoffiziell ist. (siehe hier) --Siegbert v2 (Diskussion) 11:31, 16. Nov. 2023 (CET)

…das gilt auch für die Anderen Artikel (HIMEM.SYS und Microsoft Windows 3.1), die Du in letzter Zeit mit dem Begriff True DPMI versehen hast. --Siegbert v2 (Diskussion) 11:40, 16. Nov. 2023 (CET)

Dann mach es so:

wie in der englischen Wikipedia in Anführungszeichen gesetzt werden mit dem Hinweis, dass diese Bezeichnung inoffiziell ist.

--84.158.122.223 22:50, 21. Nov. 2023 (CET)

Ich werde ganz sicher keine verwertbare Literatur zu inoffiziellen bzw. nicht öffentlichen Sachverhalten zusammensuchen! Wie ich geschrieben habe, taucht der Begriff in keinerlei akzeptabler Literatur auf! Ich weigere mich das zu sichten und habe aus den oben genannten Gründen erwogen, sämtliche Änderungen zurückzusetzen, da nicht hinreichend belegt! Das habe ich bisher nur noch nicht gemacht, weil ich dem Autor eine Chance geben wollte, das nachzureichen. Ewig kann das bei allen drei Artikeln nicht so stehen bleiben.

Zurück zum Thema: Der obere fettgedruckte Satz ist wichtiger als der untere. Das Verfahren muss sauber (im Artikel!) beschrieben und belegt werden. Erst danach kann man noch einen Satz in der Art "…dieses Verfahren wird inoffiziell auch als „True DPMI“ bezeichnet.^[x]" nachschieben. Auch in Deinen neuen Links auf Blogs taucht dieser Begriff nicht auf. Was sollen überhaupt diese Links auf Blogs ohne Bezug zum Artikel? Die Aussagen daraus müssten im Fließtext vorkommen und dort mit einem <ref>-Tag belegt werden (siehe: Hilfe:Einzelnachweise und Wikipedia:Belege). --Siegbert v2 (Diskussion) 02:37, 22. Nov. 2023 (CET)

Wenn du wüßtest, was du mir an positiven Änderungen, die viel Arbeit gekostet haben, in der WP alles verdankst, dann würdest du dich auf den Hosenboden setzen und deine Forderungen persönlich selber nachreichen und die entsprechenden Artikel um das, was deiner Meinung nach fehlt, selber ergänzen. Ich habe mit euch echt, wovon die meisten nur herummeckern aber NICHTS beitragen, echt keine Lust mehr und beschränke mich von nun ab auf absolute Sparflamme. --84.158.122.223 02:58, 22. Nov. 2023 (CET)

Ja, wenn wir wüssten... Aber wir wissen es nicht, wie auch?

Außerdem solltest du dir Argumentum ad hominem ansehen... Wenn wir wüssten... ‣Andreas•⚖ 07:34, 22. Nov. 2023 (CET)

Finde ich gut! Wenn Du wüsstest, was Du uns für Zeit und Arbeit kostest, Dir hinterherzulaufen und Deine unbelegten Aussagen zu verifizieren…

Du verstößt schlicht und einfach gegen die Richtlinien und Deine Pflicht, Deine eingebrachten Aussagen zu belegen (mit validen Quellen im Sinne der Richtlinien). Die Regeln habe nicht ich erfunden und sie gelten für alle! --Siegbert v2 (Diskussion) 09:39, 22. Nov. 2023 (CET)

Der Artikel https://lists.gnu.org/archive/html/lynx-dev/1998-04/msg00773.html ist eine valide Quelle. Ihr akzeptiert auch E-Mails von Linus Torvald und Bill Gates. --84.158.113.105 10:16, 7. Jun. 2024 (CEST)

Hier ist eine valide Quelle, dass der Windows DPMI Server noch eigene Funktionen hat, die nicht von DPMI 0.9 oder 1.0 abgedeckt werden, die Quelle steht übrigens auch schon im Artikel. Wichtig ist dieser Punkt:

This didn't come to pass, however, because one of the trade-offs Microsoft had to make to get the existing DOS extender vendors to support DPMI was to excise its DOS extender-like capabilites. In other words, Windows 3.0 still has its DOS extender, but thise facilities are no longer part of the DPMI specification, so the programmer cannot assume they will be present on DPMI servers other than Windows 3.0.

...

This is a bitter pill to swallow. I assume that the DOS extender documentation in the original Microsoft DPMI specification is still valid, since Windows 3.0 was very close to its final form at the time that document was printed, but unfortunately that document was supplied under a nondisclosure agreement and the information in this hasn't appeared publicly elsewhere. The only public documentation of Windows 3.0's DOS extender that I've stumbled on is a five-page leaflet that was given out at a recent Windows ISV seminar.

...

The first thing we learn from the document is that, although Windows 3.0 in 386 enhanced mode supports the full range of DPMI 0.9 functions, in standard mode Windows 3.0 supports only the subset of DPMI 0.9 functions that allow protected-mode programs to communicate with real-mode TSRs and device drivers.

• PC Mag Seite 390

Damit wäre das alles bewiesen und aus einer offiziellen Quelle. Ihr könnt euch jetzt natürlich am Namen TrueDPMI aufhängen, aber es das ist gar nicht so wichtig, denn wichtig ist allein nur, dass es ein DPMI 0.9, ein DPMI 1.0 und ein Windows DPMI gibt. --84.158.120.82 09:55, 13. Aug. 2024 (CEST)

Artikel ist Chaos

Die ganzen DOS Extender, die im Abschnitt DOS Protected Mode Interface#Implementierungen aufgelistet sind, gehören da nicht rein. Weil DOS Extender nichts mit DPMI zu tun hat. In diesem Implementierungsabschnitt sollten nur DPMI Server stehen und als DPMI Clients könnte man noch weitere Beispiele nennen. Z.B. ist Windows 3.x und Quake 1 ein DPMI Client. Auch wäre es bei den Servern und Clients sinnvoll hinzuschreiben um was für eine DPMI Version es sich handelt, True DPMI, DPMI 0.9 oder DPMI 1.0. --93.229.164.202 04:03, 13. Nov. 2023 (CET)

Ergänzung, außerdem ist das auch falsch, dass DPMI in Windows 3.x implementiert sei, denn Windows 3.x ist nur ein DPMI Client, kein DPMI Server. Der DPMI Server kommt in Form von HIMEM.SYS. Die Implementierung ist also HIMEM.SYS bzw. dessen ausführbare Alternative XMSMMGR.EXE. --93.229.164.202 05:11, 13. Nov. 2023 (CET)

Gundsätzliches: DOS-Extender haben sehr wohl was mit DPMI zu tun, weil durch die DOS-Extender VCPI entstand, und DPMI VCPI ersetzte. Ohne DOS-Extender hätte es die Notwendigkeit, das mehr oder weniger zu standardisieren (VCPI, DPMI) nicht gegeben. Natürlich, im Gegensatz zu VCPI geht DPMI weiter und normiert nicht nur die DOS-Extender, aber eben auch. ‣Andreas•⚖ 03:09, 17. Nov. 2023 (CET)

Grafik fehlt

Um mal Ordnung in die ganzen DPMI 0.9, DPMI 1.0, True DPMI, DOSExtender, VCPI, DOS-Multitasker Artikel zu schaffen wäre eine Grafik sinnvoll, die diese gerade genannten Einheiten als Schnittstelle zwischen dem DOS Real Mode und dem Protected Mode aufzeigt. Darin könnte man dann auch aufzeigen, dass ein DOS Extender bspw. nur einen Client bedient, DPMI aber mehrere bedienen kann. Während der Multitasker nur VM86 Maschinen aufmacht, in die dann Real Mode Anwendungen wiederum laufen können. Außerdem sollte in dieser Grafik noch deutlich gemacht sein, dass zur gleichen Zeit es nur eine Einheit von diesen Einheiten geben kann. Also entweder nur ein DPMI 1.0 Server oder ein True DPMI Server oder ein DOSExtender oder ein VCPI Server oder ein DOS-Multitasker. Da DPMI 0.9 eine Teilmenge von DPMI 1.0 und True DPMI ist, könnte man dies als Abzweigung darstellen. Die Grafik könnte man dann in allen entsprechenden Artikeln verlinken. Man könnte die Grafik so ähnlich machen wie bei folgendem Beispiel Datei:Linux API.svg --93.229.164.202 04:17, 13. Nov. 2023 (CET)

2 Links

• [1]
• [2]

--84.158.122.223 22:52, 21. Nov. 2023 (CET)

DOS4/GW und Windows 95

Das gehört noch in den Artikel: https://devblogs.microsoft.com/oldnewthing/20230829-00/?p=108661 --93.229.169.65 01:19, 26. Mär. 2024 (CET)