Diskussion:Windows 3.x

Real Mode vs. Standard Mode vs. 386 Enh Mode

@IT-Compiler: Wieso sollte der Kernel "Real Mode" heißen? Der Real Mode ist ein Betriebsmodus des 80286-Prozessors, der diesen kompatibel zum 8086/8088 macht. So ist bei x86-CPUs seit dem 286er der Modus des 8086 benannt. Der zweite Betriebsmodus des 80286, der jedoch damals inkompatibel zu DOS und Windows war, ist der Protected Mode. Windows 3.0 hat nun drei Kernel: einen für den 8086, der jedoch nicht Real Mode heißt, denn so heißt der Betriebsmodus, nicht der Kernel. Es ist annähernd der gleiche Kernel wie der von Windows 2.0 für den 8086. Dann gibt es noch den Kernel für den 80286 - Windows, das mit diesem Kernel gestartet wurde, nennt Microsoft zur Unterscheidung "Standard Mode". Und dann gibt es den Kernel für den 80386, der im 386-Protected-Mode läuft (der einen Virtual 8086 Mode bietet, der dem Protected Mode des 80286 fehlt) und der sowohl im "Standard Mode" als auch im "386 Enhanced Mode" laufen kann.

Aus dieser englischen Quelle:

The 16-bit Windows kernel was actually three kernels. One if you were using an 8086 processor, another if you were using an 80286 processor, and a third if you were using an 80386 processor. The 8086 kernel was a completely separate beast, but the 80286 and 80386 kernels shared a lot of code in common. The major difference between the 80286 and 80386 kernels was in how they managed memory, because the descriptor tables on the 80386 were a different format from the descriptor tables on the 80286. The 80386 memory manager could also take advantage of the new 32-bit registers.

But the difference between the 80286 and 80386 kernels were not based on whether you were running Standard or Enhanced mode. If you’re running on an 80386 processor, then you get the 80386 kernel, regardless of whether you’re using Standard or Enhanced mode Windows. And since Enhanced mode Windows required an 80386 processor, the behavioral changes between Standard and Enhanced mode were restricted to the 80386 kernel.

The 80386 kernel was designed to run as a DPMI client. It asked the DPMI host to take it into protected mode, then used the DPMI interface to do things like allocate selectors and allocate memory. If you ran Windows in Standard mode, then the DPMI host was a custom-built DOS extender that was created just for Standard mode Windows. If you ran Windows in Enhanced mode, then the DPMI host was the 32-bit virtual machine manager. Abstracting to the DPMI interface allowed a single 80386 kernel to run in both Standard and Enhanced modes.

And in fact if you ran Enhanced mode Windows with paging disabled, then the code running in the 80386 kernel was pretty much the same code that ran if you had run the 80386 kernel under Standard mode Windows.

Die Quelle MS Document WW0335 ist durchwegs in englisch gehalten. Dort heißt es etwa The requirements for WIN.COM to automatically start up in real mode... – heißt also, dass der Kernel im Real Mode startet, nicht dass der Windows-Betriebsmodus so hieße. Operating modes are real mode (similar to Windows/286 2.x), which is only available in Windows 3.0; 286 standard mode (also known as 286 protected mode); and 386 enhanced mode (also known as 386 protected mode). – das Dokument vermischt das leider durchwegs.

Wie dem auch sei, ich würde die Modi eher nach den "sichtbaren" Benennungen in Windows selbst im Artikel wissen. Dass es drei verschiedene Kernel gibt, ist amtlich. Dass diese je nach Bedingungen geladen werden (oder per win.com /r, /s bzw. /2 oder /3), ist auch bereits im Artikel beschrieben ("Je nachdem, welcher Prozessor im PC vorhanden war, startete Windows automatisch mit dem entsprechenden Kernel.").

Wenn wir hier zu sehr ins Detail gehen, wird es eigentlich immer komplizierter, denn es gibt sehr viel dazu zu sagen. Das trifft aber im Kern eigentlich nur Windows 3.0 – und sollte daher in die entsprechenden Artikel, und nicht hier her. Unter Windows 3.1/3.11 gibt es nur noch den Standard Mode und den 386 Enh Mode, die sehr viel ähnlicher sind als der Kernel für den 8086 ("Real Mode").

‣Andreas•⚖ 18:53, 29. Mär. 2022 (CEST)

Nachtrag:

Bitte vermische nicht x86-Betriebsmodi, Windows-Kernel und Windows-Betriebsmodus.

8086/8088 → "Real Mode" → 8086-Kernel von Windows 3.0 (jener von Windows 2.0/286) → keine Bezeichnung für den Betriebsmodus.

80286 → "Protected Mode" (286, 16-Bit, kein V86Mode) → 80286-Kernel von Windows 3.x → Standard Mode

80386 → "Protected Mode" des 386 (16- und 32-Bit, mit V86Mode) → 80386-Kernel von Windows 3.x → Standard Mode oder 386 Enhanced Mode

3 Kernel

Windows selbst hat unterschiedliche Betriebsmodi, wovon jener für den 8086 (Windows 2.0/286) keine Bezeichnung hat. Diese hängen aber NICHT vom Kernel ab: der 80386-Kernel von Windows kann sowohl im Standard Mode als auch im 386 Enhanced Mode laufen.

Das ist nun vermischt. Ob HIMEM.SYS und wie DPMI einen Teil des Speichermanagements bereitstellen ist dabei nebensächlich, denn es ging in diesem Absatz um die 3 Kernel. Auch unter Windows 2.0/286 hat man mit HIMEM.SYS Zugriff auf den UMB und die HMA (also auf die 1 MB, die ein 8086 adressieren kann, nicht bloß auf die 640 kB konventionellen Speicher).

Aber das alles geht zu sehr ins Detail für diesen Artikel, findest du nicht? Denn natürlich kann auf einem 286er und 386er auch ein 8086-Programm ausgeführt werden, sodass der 8086-Kernel auch auf einem 286er und 386er laufen kann (win.com /r). Theoretisch müsste es auch möglich sein, den 286er-Kernel auf einem 386er laufen zu lassen, denn der Protected Mode des 386 sollte eigentlich zu jenem des 286 kompatibel sein, allerdings führt win.com /s auf einem 386er den 386er-Kernel im Standard Mode aus, nicht den 286er-Kernel. Wie sehr sollten wir da ins Detail gehen? WP:OMA

‣Andreas•⚖ 19:04, 29. Mär. 2022 (CEST)

Ich habe nirgends behauptet, dass der Kernel Real Mode heißen würde. Die Kernel sollten hier zudem auch nicht im Vordergrund stehen, sondern die Betriebsmodi, denn das ist das, mit dem der Nutzer es zu tun hat. Die Betriebsmodi bestimmen wesentlich, was der Nutzer tun kann und wie sich Windows verhält. Man kann sie im About Dialog anzeigen lassen und per Parameter beim Starten von Windows erzwingen, sofern die CPU das unterstützt.

Zum Nächsten Punkt, der Real Mode ist bei Windows auch der Name des Betriebsmodus, in dem Windows 3.0 auf einem 8086 gestartet wird. Einen anderen Namen hat dieser Modus nämlich auch nicht und ja, der Modus des Prozessors lautet ganz genauso. Wobei der 8086 ohnehin keine Wahl des Modus hat, das gibt's erst bei den späteren CPUs.

Zu "ich würde die Modi eher nach den "sichtbaren" Benennungen in Windows selbst im Artikel wissen."

Und deswegen muss man die Betriebsmodi hervorheben und nicht die gewählten Kernel. Der Artikel ist sowieso unschön, weswegen ich beabsichtige ihn zu überarbeiten. Das kann man besser machen, z.b. in dem man die einzelnen Betriebsmodi separat aufführt und dann dazu etwas schreibt. Als Ergänzung wäre noch eine Tabelle möglich, in der drin steht, was in welchem Betriebsmodis möglich ist. So in etwa würde ich das gerne machen. Ob ich dazu heute noch komme, weiß ich nicht.

Doch, der Betriebmodus von Windows 3.0 für den 8086 Prozessor hat einen Namen. Starte mal Windows 3.0 im Real Mode, also mit dem Befehl und Parameter "win /r" und dann klicke im Programm Manager auf "Help" und dann auf "About Program Manager". Dann poppt ein Info Fenster auf und in dem steht dann "Real Mode" dran. Startest du Windows dagegen im Standard Mode, dann wird da "Standard Mode" stehen und im Enhanced Mode steht "Enhanced Mode". Bzw. "Erweiteter Modus" in einer eingedeutschen Windows Version. Den Modus "Real Mode" gibt es also und er hat die gleiche Bezeichnung wie die des Prozessors.

Das ist nicht nebensächlich. HIMEM.SYS ist der Speichermanager und der stellt XMS Speicher zur Verfügung und den gibt es, anders als der Artikel fälschlicherweise zuvor behauptet hat, schon in MS-DOS ab ca. MS-DOS 5.0. DPMI ist die Spezifikation und die Art und Weise, wie Programme die DPMI Clients sind, zwischen den CPU Modi Protected Mode und Real Mode zwischen sich und dem DOS Betriebssystem kommunzieren können. Das die Speicherreservierung via HIMEM.SYS erfolgt, steht auch im bereits erwähnten WW0335.TXT Artikel.

Zu Windows 2.0. Das ist nicht Bestandteil dieses Artikels und Windows 2.0 hat ziemlich wenig mit Windows 3.0 gemeinsam. Bei Windows 2.0 läuft der Prozessor im Real Mode und daher können die Programme alles machen was sie wollen. D.h. sie können anstatt über den Speichermanager HIMEM.SYS, den es damals in Zeiten von Win 2.0 noch nicht gab, ihren Speicher auch einfach selber reservieren. Es gibt im Real Mode nichts, was sie daran hindern könnte. Und Windows 2.0 verwaltet den Speicher auch nicht selber. Bei Windows 3.0 ist das anders. Da rufen die Programme, wenn sie ordentlich programmiert wurden, Windows Funktionen auf, um Speicher reservieren zu können. Das passiert auch im Real Mode, obwohl die Programme das in diesem Modus auch selber machen könnten, aber wenn das kompatibel zum Standard Mode und Enhanced Mode programmiert sein soll, dann muss das über Windows Funktionen erfolgen und die leiten es dann an HIMEM.SYS weiter.

Der 8086 kann den HMA nicht adressieren, das kann erst der 286er. Beim 8086 gibt's da kein RAM, auf das er zugreifen könnte und beim 286 muss das A20 Gate so geschaltet sein, dass er auf den oberen RAM Bereich zugreifen kann, dann kann er RAM daraus für HMA nutzen. HMA ergibt sich durch die Art und Weise, wie die Segmente angesprochen werden können. Durch ein Verschieben der Segmentadresse nach ganz oben ist es so beim 286er möglich, auf den Bereich oberhalb von 1 MiB zuzugreifen, wenn das A20 Gate entsprechend geschaltet ist. Beim 8086 geht das nicht, der bricht dann um auf den unteren Speicher, also ganz unten bei 0x0000.

Der Punkt mit den 640 KiB ergibt sich aus dem WW0355.TXT Dokument, darin heißt es, dass im UMB eigentlich kein RAM ist, dass man nutzen könnte, das ist also eine Definition. Darin heißt es:

84K Upper Memory Area (UMA)

----------------------------

Between the top of conventional memory at 640K and the start of

extended memory at 1024K lies the 384K UMA. This area does not contain

physical memory. Mapped into the 384K UMA are the system BIOS (basic

input/output system) ROM chips and the display adapter memory. When

you install other accessory cards, such as network adapters, they may

also occupy space within the 384K UMA. It is important to remember

that the 384K UMA is always located in the same area of the IBM-

compatible computer's address space: from 640K to 1024K (A000 to FFFF

hexadecimal). There are no exceptions to this rule.

This means that a standard IBM-compatible machine with 640K of

conventional memory installed really has 1 MB of address space. The

system memory occupies the first 640K, and the 384K UMA occupies the

area from 640K to 1 MB (1024K). This does not mean that the machine

has 1 MB of memory. A machine with 1 MB of physical memory has an

address space of 1408K. This consists of the 640K of conventional

memory, the 384K UMA, and the 384K of extended memory starting at

1024K.

Zu allerdings führt win.com /s auf einem 386er den 386er-Kernel im Standard Mode aus, nicht den 286er-Kernel.

Der Aufruf von win.com /s auf einem 386er müsste auch den 286 Kernel aufrufen. Die verschiedenen Kernel gibt es ja deswegen, weil der 386er eine andere Speicheradressierung hat und Paging verwendet. Da er aber auch abwärtskompatibel zum 286er ist, muss er auch in der Lage sein Binärcode, der für den 286er programmiert wurde, auszuführen und damit kann er auch die Segmentierte Speicheradresssierung des 286er. Und was die Windows Kernel betrifft, so verwendet der Kernel für den Standard Mode diese Segmentierte Speicheradressierung und der 386 Kernel für den Enhanced Mode die Paging Speicheradressierungsweise. Das ist der wesentliche Unterschied und der Grund, warum das unterschiedliche Kernel sind. Du kannst den 386er Kernel ja mal im Dateisystem umbenenen und dann auf einem 386er Windows im Standard Mode, also "win /s" starten. Wenn dann Windows läuft, obwohl der Kernel für den Enhanced Mode umbenannt wurde, dann weißt du sicher, dass der Kernel für den Standard Mode verwendet wurde. So kriegt man das am einfachsten raus.

Zu deiner Frage wie sehr wir ins Detail gehen sollen. Wir sollten das einfach anders strukturieren. Mein Vorschlag wäre für jeden Betiebsmodi einen Abschnitt zu machen und dort kann man dann genauer ins Detail gehen. So wird das dann auch übersichtlicher. Momentan ist alles in einem einzigen Technik Abschnitt zusammengeklatscht, was dazu führt, dass man immer dazu schreiben muss, was in welchem Modus nun gilt. Mit 3 Abschnitten für jeden einzelnen Betriebsmodus wird das übersichtlicher. --IT-Compiler (Diskussion) 21:34, 29. Mär. 2022 (CEST)

@Y2kbug So, ich habe den Abschnitt jetzt überarbeitet. Schau es dir mal an und wenn du noch Fehler findest oder dir noch weitere Punkte einfallen, wie man das noch besser machen könnte, dann kannst du die natürlich verbessern bzw. um weitere Punkte ergänzen. --IT-Compiler (Diskussion) 23:05, 29. Mär. 2022 (CEST)

Noch etwas. Die gleiche Quelle habe ich im Artikel zweimal referenziert um die entsprechenden Punkte einzeln zu belegen. Ich weiß allerdings nicht, wie ich das so machen kann, dass die Quelle dann unten bei den Referenzen nur einmal erwähnt wird. Das müsste man also noch anpassen, nur weiß ich nicht wie. --IT-Compiler (Diskussion) 23:21, 29. Mär. 2022 (CEST)

Die referenzierte Quelle WW0335.TXT findet man übrigens, wie ich gerade herausgefunden habe, auch als Internetlink. Falls das als Link besser sein sollte, dann könnte man diesen verwenden: https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/66420 --IT-Compiler (Diskussion) 23:24, 29. Mär. 2022 (CEST)

Okay, erstmal danke für deine Arbeit. Ich habe jedoch ein paar Probleme damit. Das ist erstmal nicht schlecht, wir müssen das ganze nur so hinbringen, dass wir beide damit zufrieden sind. (Oder es kommt noch jemand dazu, der sich einarbeiten will...)

1. Zu Mehr als nur ein GUI-Aufsatz:

Durch die Verwendung des Protected Mode für die Betriebsmodi Standard Mode und Enhanced Mode war Windows bereits mehr als ein grafischer Aufsatz für das Betriebssystem MS-DOS, wenn es auf einem Prozessor lief, der den Protected Mode ermöglichte.

Das Geschriebene stellt Windows gegenüber anderer Software für DOS heraus, weil der Protected Mode verwendet wird, doch es nutzen doch auch viele DOS-Anwendungen den Protected Mode. Lotus 1-2-3 beispielsweise. Es ist also erstmal gerade nicht besonders, dass Windows das tut. Das Besondere ist eher, dass Windows das kann, ohne die anderen Protected-Mode-Anwendungen zu behindern, denn unter DOS kann ursprünglich nur eine Anwendung exklusiv laufen. VCPI war ein Protect-Mode-Standard, der mit Multitaskting nicht zurecht kam. Es gab aber vielleicht auch andere Anwendungen, die einen ganz selbst entwickelten eigenen "Standard" für den Protected Mode nutzten.

Das Besondere an Windows 3.0 ist in diesem Bezug "nur" (es war ja objektiv gesehen eine ganz große Sache!) DPMI, denn damit war es möglich, dass mehrere Anwendungen den Protected Mode nutzen konnten, ohne sich gegenseitung zu behindern. Das inkludiert Windows selbst. Somit kann Windows den Protected Mode nutzen, DOS-Programme aber auch - und sogar mehrere DOS-Programme (und Windows-Programme) gleichzeitig. Dass Windows-Programme gleichzeitig laufen, war ja nichts besonderes, wegen dem API - dieses sieht ja vor, dass Windows-Programme gleichzeitig (Multi-Tasking) laufen können. Das ganze inklusive DOS zustande zu bringen, macht Windows 3.0 besonders: DPMI.

2. Expanded Memory

Auch das hat nichts mit Windows selbst zu tun, sondern mit der Umstellung vom 8086/88 und 80286 hin zum 80386 und dessen Virtual 8086 Mode. Während EMS noch 8086-kompatibel war und durch Bank-Switching immer innerhalb der 1 MiB verblieb, sodass durch EMS-Speichererweiterungskarten auf 8086 und 80286 mehr als 1 MB im Real Mode ermöglicht wurde, war XMS als die neuere Technik bereits auf den Protected Mode angewiesen. Damit funktioniert XMS auch auf einem 80286, der Zugriff auf 16 MB erlaubt. Ab dem 80386 wurde diese Granze dann starkt angehoben (64 MB anfangs, später mehr). Viele Real-Mode-DOS-Programme (und Windows 2.x) konnte jedoch nur mit EMS umgehen, da die Software noch 8086-kompatibel war.

Von daher ist es keine Windows-eigene Entwicklung oder etwas, das speziell oder besonderns und Windows-spezifisch wäre, sondern es ist auch in anderer Software (auch vielen DOS-Programmen) zu finden. Zur Kompatibilität kann XMS ja auch immer EMS emulieren, damit Legacy-Software weiterhin läuft.

3. HIMEM.SYS

Unter Windows 2.x (Windows 2.1?) war HIMEM.SYS enthalten. Der Treiber kommt also ursprünglich von Windows 2, nicht von MS-DOS. In MS-DOS 5.0 ist HIMEM.SYS dann (gemeinsam mit EMM386.EXE) in das Betriebssystem übersiedelt, auf dem Windows läuft.

Nun kann man gerade bei Windows 3.x aber nicht davon reden, dass es sich auf HIMEM.SYS abstützen würde, weil Windows auch auf anderen DOS-Betriebssystemen auf dem PC läuft. Unter DR DOS hieß der kompatible Treiber dann HIDOS.SYS, und die Funktionen dieses Treibers nutzt Windows 3.x dann für die Speicherverwaltung.

Alles andere würde ich als Microsoft-zentriert bezeichnen: als könnte man Windows 3.x nur mit MS-DOS (und PC DOS), nicht aber mit z.B. DR DOS, Multiuser DOS, FreeDOS, PTS-DOS etc. nutzen.

4. 32-Bit-Windows-Software

(Enhanced Mode (Erweiterter Modus)) In diesem Modus ist die Ausführung von sowohl 16-Bit- als auch erstmals 32-Bit-Windows-Programmen möglich.

Als der 386 Enhanced Mode eingeführt wurde, gab es keine 32-Bit-Windows-Software. Soweit mir bekannt ist, kam Win32s erst später zu Windows. Sehr wohl aber gab es 32-Bit-DOS-Software (DPMI und dem Protected Mode sei Dank).

Man sollte erwähnen, dass Windows nur optional, durch manuelles Nachinstallieren von Win32s (das NICHT Teil der Windows-Installation ist!) auch 32-Bit-Windows-Software ausführen kann. Sonst entseht der falsche Eindruck.

(Der Satz ist nicht falsch, aber die Informationen sind selektiv und unvollständig.)

5. Standard Mode

Wie beim Real Mode können im Standard Mode nur 16-Bit-Programme ausgeführt werden. Im Standard Mode ist die Verwendung von mehr als 640 KiB Arbeitsspeicher für DOS-Anwendungen mit der Ausnahme von EMS Memory nicht möglich.

Was ist denn bitte mit 32-Bit-DOS-Programmen? Auf einem 386 läuft Windows im Standard Mode als DPMI-Client. Damit kann man unter DOS 32-Bit-Programme, die ebenfalls DPMI verwenden ausführen. Die Aussage "nur 16-Bit-Programme" ist daher falsch, es sei denn, es sind 16-Bit-Windows-Programme gemeint. Aber auch Windows 3.11 für Workgroups kann nach der Installation und im Enhanced Mode nur 16-Bit-Windows-Programme ausführen, weil das Win32s-API fehlt. Das muss (optional) manuell nachinstalliert werden, sonst geht da gar nichts... Oder, Windows-Programme könnten (eigenmächtig, ohne Win32-API) DPMI nutzen und in Teilen als 32-Bit-DPMI-Client laufen. Dann wären sie nicht anders als (32-Bit-)DOS-Programme. Das ginge aber auch im Standard Mode – auf einem 386 wohlgemerkt.

6. DPMI-Host

Im Enhanced Mode fungiert der Kernel als DPMI-Host, womit mehrere DOS-Anwendungen unter Verwendung des Virtual 8086 Mode des 80386 Prozessors parallel ablaufen können.

Ich hatte das ursprünglich auch nicht ganz richtig formuliert. Das hat nichts mit dem Standard Mode und dem Enhanced Mode zu tun, sondern nur mit dem Kernel: läuft der 386-Windows-Kernel, so sind beide Modi als DPMI-Client ausgeführt. Heißt: der 386-Kernel startet einen DPMI-Host, der dann den Standard- ODER den Enhanced-Mode-"Kernel" als DPMI-Client ausführt.

Auf einem 286 hingegen führt win.com den 286-Kernel aus, der KEINEN DPMI-Host startet, sondern direkt den Standard-Mode-Kernel ausführt.

Ergo: Der Enhanced Mode lässt sich nicht zwinged mit DPMI gleichsetzen. DPMI läuft immer, wenn der 386-Kernel läuft – egal, in welchem Modus.

Soweit, so gut. Wie sollen wir da jetzt weiter vorgehen?

‣Andreas•⚖ 18:24, 30. Mär. 2022 (CEST)

Okay, gib mir etwas Zeit das alles durchzulesen und darauf zu antworten. Das dauert etwas. Mache mich aber gleich an die Arbeit. --IT-Compiler (Diskussion) 18:34, 30. Mär. 2022 (CEST)

7. Programme unter Windows/386

Ein großer Unterschied von DOS- zu Windows Anwendungen ist, dass Windows Anwendungen geräteunabhängig sind, da die Windows API für diese als Abstraktionsschicht dient und alle Hardwarezugriffe somit über den Windowskernel und dessen Treiber laufen. Dies ermöglicht auch die Verwendung von virtuellem Speicher (nur Enhanced Mode) ohne das die Windows Anwendung extra umgeschrieben werden muss, da aus Sicht der Windows Anwendung kein Unterschied zwischen diesem und dem normalen Speicher besteht.

Trifft dieser Satz nicht vollinhaltlich auch auf Windows 2.x/386 zu? Dann hätte er nichts mit Windows 3.x zu tun, sondern nur damit, ob Windows (2.x bis 9x) auf einem 386 läuft oder nicht. Ja – nur bis Windows 3.0 ist das die Frage, da ab Windows 3.1 ohnehin nur noch der Protected Mode genutzt wird. Aber spezifisch für "Windows 3.x" (also das Thema, weil das Lemma) ist es nicht...

Nachtrag: nicht vollinhaltlich, denn virtuellen Speicher gibt es ja erst mit Paging, also im Enhanced Mode. Aber ob im Real Mode oder im Standard Mode ist der Windows-Anwendung erstmal egal... (was Windows 2.x/3.0 8086 und Windows 2.x/386 bzw. Windows 3.x im Standard Mode betrifft...)

‣Andreas•⚖ 18:43, 30. Mär. 2022 (CEST)

Windows 2.x hat überhaupt keine Bedeutung. Ich weiß nicht, warum du immer darauf zurückgreifst. Das hat keiner benutzt. Relevant wurde Windows erst mit Windows 3.x und deswegen muss man dieses gegenüber DOS, also wie es vorher war, hinstellen. Windows 2.x war nicht mehr als ein grafischer Programmstarter für DOS, der viel Speicher brauchte (im Vergleich zur DOSSHELL.EXE oder Norton Commander) und zu dem es so gut wie keine Windows Anwendungen gab und es arbeitete nur im Real Mode und in dem gab es keinen Schutz durch den Protected Mode. Die Windows Anwendungen für Windows 2 konnten ihren Speicher also auch einfach direkt über DOS Funktionen reservieren und liefen dann immer noch. Oder sie konnten direkt auf die HW zugreifen ohne sich um den Windows Kernel zu scheren. In Windows 3.x ist das ab dem Standard Mode und Enhanced Mode anders, denn der Standard und Enhanced Mode laufen beide im Protected Mode, d.h. der Windows Kernel kann Userspaceanwendungen vom HW Zugriff aussperren, was er auch tut. Im Gegensatz zu Windows NT kann man unter Windows 3.x aber noch auf den DOS Kernel über DPMI zugreifen, dann ist die Anwendung aber eine DOS Anwendung und keine Windows Anwendung mehr. Wir sollten tunliches dieses alte nie benutze Windows 2.x aus dem Artikel heraushalten. Der Leser will wissen wie es vor Windows war, und damit ist gemeint "vor Windows 3.x" und wie es nach Windows wurde, also nach Windows 3.x. Windows 2.0 spielt hier überhaupt keine Rolle, das war nicht mehr als ein Demonstrator, dass man auf einem PC auch grafische Oberflächen basteln kann. --IT-Compiler (Diskussion) 19:12, 30. Mär. 2022 (CEST)

Was kam vor Windows 3.0? Windows 2.x und Windows 2.x/386.

Ich will im Artikel mit dem Titel Windows 3.x auch nicht zu sehr Bezug auf Windows 2.x nehmen, keinesfalls. Aber es darf auch nicht so klingen, als wäre vorher nicht schon etwas da gewesen, wenn auch nicht erfolgreich. Windows 3.0 mit dem 8086-Kernel ist quasi eine Fortführung von Windows 2.x. Und, nein, Windows 3.0 war nicht nur wegen dem Enhanced Mode so erfolgreich, sondern auch, weil es noch auf dem 286 funktionierte. Windows 3.0 ist die Bridge-Technologie, die Windows zum Druchbruch verhalf – weil es vom 8086 über den 80286 auch auf dem 80386 lief, aber gleichzeitig auf dem 286 und 386 deren Vorzüge so richtig ausnutzen konnte – und das bei Windows-Programmen, die auch auf dem 8086 liefen! Es konnten somit alle, egal welche Hardware, Windows so richtig nutzen – und Dritthersteller begennen, Windows-Programme zu entwickeln, weil sie jeder verwenden konnte!

Ganz klar war DPMI und die Vorzüge, die der Protected Mode (und V86M) des 386 brachte, die große Revolution.

Das alles muss in den Artikel, wenn dieser Windows 3.x heißt...

‣Andreas•⚖ 19:55, 30. Mär. 2022 (CEST)

Windows 2.0 hat aber nur den Namen Windows. Es hat mit Windows 3.x nicht viel gemeinsam.

Zum Punkt Windows 3.0 und dem 8086, ja, aber man hat sich sehr schnell davon verabschiedet. Das zeigt auch der WMM003.TXT Artikel, darin heißt es:

  NOTE: Real mode is not available in Windows 3.1. Real mode for
  Windows 3.0 was supplied mainly for compatibility with older Windows
  2.x applications. Most, if not all, of these older applications have
  now been updated to work properly with Windows 3.x. Valuable
  development time was saved in not maintaining this outdated mode,
  time that was then spent improving the two remaining Windows modes.

Das nur der enhanced Mode relevant wäre, hat niemand behauptet. Der Standard Mode reichte vielen. Den Real Mode dürften die wenigsten benutzt haben. Außer User mit einem XT kommt da nämlich keiner in Frage und die werden kaum Anwendungen dafür gefunden haben. Der Real Mode von Windows 3.0 war somit mehr Schein als sein. In der Praxis dürften XT Besitzer allein schon aus Mangel an Windows Anwendungen, weiterhin ihre DOS Anwendungen benutzt haben. Der 8086 und Real Mode Windows Programme spielen somit keine Rolle. Dass es den Real Mode im Artikel gibt, dient lediglich der Vollständigkeit im Artikel. Relevanz hatte der aber keine. Und gleiches gilt auch für die Vorgänger von Windows 3.0.

Nein, die Dritthersteller entwickelten für den Standard Mode und später, mit erscheinen der Win32 API sogar nur noch für den Enhanced Mode. Es gibt tausende Anwendungen die im Standard Mode laufen, aber die Zahl an Real Mode Anwendungen für den Real Mode von Windows 3.0 von Drittherstellern dürften gerademal zweistellig sein und das auch eher im unteren Bereich unterhalb von geschätzt 20 Stück. Und die 20 Stück sind nicht einmal besonders bedeutend. Es gibt im Internet Listen, da war außer vielleicht 1 oder 2 Programme nichts besonderes dabei. Und da der Real Mode ab Windows 3.1 nicht mehr unterstützt, hatten die Dritthersteller neben den technischen Unzulänglichkeiten auch aus ökonomischen Gründen keinen Grund den noch zu unterstützen. --IT-Compiler (Diskussion) 20:17, 30. Mär. 2022 (CEST)

Man stelle sich vor, Microsoft hätte Windows 3.0 herausgebraucht und kein einziges existierendes Windows-Programm wäre darauf gelaufen...

Man stelle sich vor, jemand kauft sich Windows 3.0 und installiert es auf seinem IBM PC mit 8088 oder 8086-Prozessor, nur um dann festzustellen, dass kein Windows-Programm darauf läuft.

Dass sich das ganze in die 286- und dann 386-Richtung entwickelt hat, ist ganz klar. Aber der Artikel heißt nicht "Windows 3.1x", sondern "Windows 3.x". Also müssen wir mit dem Real Mode beginnen, bevor wir beim Enhanced Mode enden.

Hast du eine Quelle, auf deren Grundlage du den 8086-Kernel von Windows 3.0 so sehr herunterspielst?

‣Andreas•⚖ 21:16, 30. Mär. 2022 (CEST)

Windows wurde in der Regel mitsamt Komplett PC verkauft. Das war ohne PC gar nicht so einfach zu bekommen. Für die frühen MS-DOS Versionen gilt übrigens das gleiche.

Guck dir die Liste der Windows Real Mode Programme doch an:

https://www.vogons.org/viewtopic.php?p=938759

Die ist so kurz. Für den Standard Mode gibt es über 1000 Programme. --IT-Compiler (Diskussion) 21:40, 30. Mär. 2022 (CEST)

7.b Abschnitt Technik: Dies ermöglicht auch die Verwendung von virtuellem Speicher (nur Enhanced Mode) ohne das die Windows Anwendung extra umgeschrieben werden muss, da aus Sicht der Windows Anwendung kein Unterschied zwischen diesem und dem normalen Speicher besteht.

zusammen mit:

Enhanced Mode (Erweiterter Modus): Im Enhanced Mode kann zusätzlich zum Extended Memory (XMS) auch Speicherplatz auf der Festplatte als virtueller Speicher, einer sogenannten SWAP-Datei, verwendet werden. Dies ist nur im Enhanced Mode möglich.

Laut Quelle funktioniert das auch im Standard Mode auf einem 286:

Standard mode liberated Windows from the constraints of the 640KB barrier. In 80286 protected mode, the CPU used 24 address lines, making the usable physical memory a maximum of 16MB. However, when running with less than 16MB of physical memory, standard mode could still use up to 16MB of address space by a mechanism known as swapping. In standard mode swapping, an entire memory segment (up to 64KB) could be copied out to a swap file, and the corresponding selector could be marked not-present. When the selector was subsequently referenced, the CPU generated a fault. The system handled this by finding memory elsewhere and copying the data from the swap file back into memory.^Quelle

‣Andreas•⚖ 21:24, 30. Mär. 2022 (CEST)

Der Microsoft Artikel WW0335.TXT, auf den ich mich beziehe, erwähnt nichts davon, dass der SWAP Speicher auch im Standard Mode verfügbar wäre. Der SWAP Speicher wird nur im Bezug zum Enhanced Mode erwähnt und er wird sogar beschrieben wie er funktioniert, er braucht das Paging des 386 und es werden 4 k große Pages ausgelagert. Guck dir den Artikel mal an, siehe dieser Abschnitt:

https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/66420#Virtual_Memory_Paging_File_Options_and_Controls

Ich vermute daher mal, dass dieser 10 Anniversary Artikel fehlerhaft ist. Da wird wohl irgend ein junger MS Mitarbeiter geschrieben haben und es nicht genau gewusst haben. Der WW0335.TXT Artikel, auf den ich mich beziehe, ist allerdings für Softwareentwickler von Leute mit Ahnung zu einer Zeit geschrieben worden, als das relevant und aktuell war und das merkt man auch an der Qualität des Artikels.

Und wenn du dir folgenden Artikel anschaust:

http://ps-2.kev009.com/pcpartnerinfo/ctstips/a336.htm

Dann fällt auf, dass man im Control Panel auf das 386 Enhanced Icon klicken muss, um den virtuellen Speicher konfigurieren zu können. Im Standard Mode gibt es im Control Panel aber kein 386 Enhanced Icon und wenn es dieses gäbe, dann wäre es für diesen Modus nicht benutzbar. --IT-Compiler (Diskussion) 21:56, 30. Mär. 2022 (CEST)

Zu 1: Den Satz habe ich aus dem ursprünglichen Text übernommen, das gilt für das meiste im Technik Abschnitt oberhalb der Betriebsmodi. Mir gefällt der auch nicht besonders. Besonders stört mich, dass dieser obere Technikabschnitt wie ein Geschichtsbuch geschrieben ist, anstatt einfach nur auf die Technik einzugehen. Das könnte man also durchaus umformulieren. In meinem letzten Edit von heute habe ich hervorgehoben, dass Windows eine Abstraktionsschicht für die Windows Anwendungen darstellt und diese somit geräteunabhängig sind. Das ist der größte Unterschied zu DOS. Bei DOS musste explizit für bestimmte HW die Anwendung geschrieben werden, seien es höhere Grafikmodi, die Unterstützung von Soundkarten oder der Drucker. Das ist bei Windows alles abstrahiert. Die Windows Anwendung muss nichts mehr darüber wissen, wie die HW funktioniert, sie muss nur mit der Windows API sprechen.

Zu 2: Der 8086 kann bereits Expanded Memory nutzen. Er muss lediglich als Speicherkarte, also Memory Expander Karte zur Verfügung gestellt werden. Dieser Speicher wird dann in den UMB Bereich eingeblendet und dieser kann unter Windows für DOS Anwendungen noch genutzt werden. Es wäre auch möglich gewesen, man hätte Windows auch so programmieren können, dass dies nicht mehr geht und DOS Anwendungen auf den konventionellen Speicher begrenzt wären. Windows unterstützt dies aber, allerdings nur dann, wenn der EMS von einer dedizierten Speicherkarte kommt. Bei dem Speicher oberhalb der 1 MiB, der dann mittels dem EEM386 Treiber als EMS emuliert wird, geht das schon nicht mehr. Dies wird unter Windows nicht unterstützt. Unter einem reinen DOS geht das aber. Deswegen wird das im Artikel erwähnt.

Kann nicht der 80286 bereits per EMS-Emulation die vollen adressierbaren 16 MB im 16-Bit-Protected-Mode des 286 bereitstellen? Muss es wirklich immer – auch auf einem 286 – eine Speicherkarte sein?

Natürlich wurde Windows 3.x so programmiert, dass es den 386 optimals ausnutzen konnte. Microsoft hat bei Windows den 286 quasi übersprungen – was ja der große Streitpunkt bei der Entwicklung von OS/2 mit IBM gewesen ist. Denn IBM wollte ein vollwertiges 286-Betriebssystem, während sich Microsoft bei Windows NT erst gar nicht mit dem 286 beschäftigt hat, aber auch bei Windows 3.x sich nicht länger als notwendig mit dem 286 beschäftigt hat. Darum setzt Windows 3.x auf XMS. Aber auch der 286 bietet XMS per Protected Mode. Siehe Extended Memory Specification.

Warum ist das überhaupt wichtig? Windows läuft auf einem 286 im Standard Mode (oder Real Mode). Per HIMEM.SYS (oder Äquivalent) kann Windows im Standard Mode auf einem 286 auf den Extended Memory per XMS-Spezifikation zugreifen. Oder nicht? Und auch EMS ist auf dem 286 möglich, ich weiß allerdings nicht, mit welchem Treiber. NEAT verwendete dafür eigene Treiber, EMM386 ging jedenfalls nicht.

‣Andreas•⚖ 20:24, 30. Mär. 2022 (CEST)

Die EMS Emulation kann unter Windows 3.x nicht benutzt werden, die CPU spielt dabei keine Rolle. Das habe ich im Artikel auch erwähnt und steht so auch in dem MS Dokument. Es ist eine Expanded Memory Karte erforderlich, nur die geht für DOS Anwendungen im Zusammenhang mit Windows 3.x. Hat man keine, dann hat man Pech gehabt und muss Windows beenden bzw. MS-DOS mit EMS Emulation ohne Windows booten. Ob Windows überhaupt ausgeführt wird, wenn emulierter EMS Speicher geladen wurde, weiß ich gerade nicht. So weit ich mich erinnern kann, ging das nicht. Ich hatte für DOS früher auf meinem 486 ein Bootmenü mit 5 Einträgen. Das 5. war nur für Windows und ohne EMS Treiber aber mit CD-ROM Treiber.

Windows 3.x konnte den 386 nicht optimal nutzen, da es noch einen DOS Unterbau hatte. Für das optimale Ausnutzen des 386er wurde Windows NT programmiert. Und Windows NT ist das Pendant zu OS/2, nicht Windows 3.1. Ich weiß jetzt aber nicht, warum das hier jetzt relevant ist, bzw. warum du das ansprichst?

Nein, Windows 3.x setzt auf XMS, weil EMS eine Krücke war und die EMS Emulation eigentlich nur dazu dient alte DOS Programme, die für Expander Karten geschrieben wurden, auch auf dem 286er und später ohne Expander Karte auszuführen. Bzw. in einer Übergangszeit durch Nutzung von EMS beide Plattformen, sowohl den alten 8086, als auch die neuen 286 und 386er zu unterstützen. Nachdem der 8086 als tot galt, hatte EMS keine Bedeutung mehr und die Entwicklung richtete sich auf XMS und Windows 3.x tat dem gleich (mit Ausnahme des Windows 3.0 Real Mode, der aber nur für die alten 8086 Rechner da war). Dass der 286 kein XMS bieten würde, habe ich nie behauptet.

Ja, kann es. --IT-Compiler (Diskussion) 20:40, 30. Mär. 2022 (CEST)

Windows 3.x hat den 386 optimal ausgenutzt, und zwar im Kontext der Kompatibilität mit DOS. OS/2 hat diesen Spagat auch versucht, ist aber gescheitert. Windows NT hat den 386 optimal ausgenutzt, allerdings ohne volle Kompatibilität zu DOS. Deswegen ist Windows NT am Anfang so schwer in die Gänge gekommen, denn damals war noch sehr viel auf DOS angewiesen, und das ging in der NTVDM von Windows NT nicht, weil so gut wie jeder direkte Hardwarezugriff abgeblockt wurde. Windows 3.x hat genau diese Brücke geschlagen – und den 386 optimal ausgenutzt, denn es bot 32-Bit (mit DPMI für DOS, mit Win32s für Windows), es bot den Hardware-Vorteil vom Virtual 8086 Mode, womit dann auch DOS-Programme Multi-Tasking-fähig wurden. So hatte ich es gemeint.

Das heißt ja nicht, dass das in den Artikel soll. Es ist nur Kontext, der vielleicht Rückschlüsse zulässt, was in den Artikel "Windows 3.x" hinein sollte: nämlich das, was Windows NT und OS/2 nicht konnten, Windows 3.x (mit DOS) aber schon.

One interesting aspect of standard mode Windows was how it handled MS-DOS-based programs. Back then, the vast majority of existing programs were written for MS-DOS.^Quelle

Zu EMS: Windows im 8086 Real Mode kann laut Microsoft EMS-Speicher verwenden:

Windows 3.0 had three separate modes it could be run in, depending on the type of processor installed in the PC. The lowliest of these was real mode, and only required an 8086/8088. In real mode, Windows 3.0 was not much more than a pretty GUI layer over MS-DOS. It was limited to using 640KB, plus whatever memory might be available via the Expanded Memory Specification (EMS). In addition, in real mode Windows utilized none of the processor features like read-only segments and paging.^Quelle

Und im Standard Mode musste Windows keinen EMS-Speicher mehr verwenden, da es ja XMS nutzte. Wie Windows das Speichermanagement erledigte, kann Windows-Programme ja grundsätzlich egal sein. ‣Andreas•⚖ 21:07, 30. Mär. 2022 (CEST)

Der Kern von Windows 3.x ist eine 16 Bit Anwendung. OS/2 hat wegen dem 286er anfangs den Virtual 8086 des 386er nicht benutzt bzw. benutzen können. Wenn ich mich nicht irre, wurde das dann aber auch mit späteren Versionen möglich, so dass man auch unter OS/2 wie bei Windows 3.x im enhanced Mode mehrere DOS Programme gleichzeitig starten konnte.

Du wirst aber trotz DPMI kein DPMI fähiges Spiel mit DOS Extender unter Windows 3.x ausführen können. Das liegt daran, weil die Spiele noch mehr machen, als nur Speicher zu reservieren. Sie greifen auf die Hardware direkt zu und das mag Windows gar nicht.

Was Windows 3.x konnte und Windows NT nicht war:

1. DOS um eine grafische Oberfläche erweitern und Multitasking innerhalb dieser Umgebung möglich zu machen.
2. Auf Rechnern mit wenig Speicher laufen. Windows NT 3.1 verlangte mindestens 12 MB, der war zu der Zeit noch teuer. Windows lief schon mit 4 MB, eventuell auch noch weniger.
3. Auf 286er laufen.

Zu EMS. Wo bitteschön kannst du auf einem 8086er EMS emulieren, natürlich geht das nicht. Das bezieht sich hier also auf die Memory Expander Karten. Und dass das geht, das steht ja auch im Artikel. Und wenn du Windows 3.0 im Real Mode auf einem 286 oder besser ausführst, dann läuft Windows natürlich selber im Real Mode und braucht daher kein XMS, und in den Modi, wo es XMS braucht, da ist emuliertes EMS nur ein Störfaktor, da es Platz verschwendet, der für die Windows Programme da sein sollte, die ja dann nur XMS nutzen. Ob im Real Mode von Windows 3.0 DOS dann emulierten EMS Speicher zur Verfügung stellt, dürfte egal sein. Das sind aber jetzt solche Details, die den Artikel nur unnötig aufblähen. Denn den Real Mode hat auf einem 286 oder besser keiner benutzt, da es dafür bessere Modi gab und auf dem 8086 gab es EMS nur mit Memory Expander Karten und dabei sollten wir das im Artikel so belassen.

Windows nicht, aber die DOS Anwendungen. Natürlich kann es sich lohnen, eine EMS Karte in den Rechner zu stecken, wenn man eine DOS Anwendung hat, die EMS nutzen kann und man gleichzeitig Windows im Standard Mode ausführen möchte und dort aber das normale RAM oberhalb für 1 MiB allein für XMS nutzen möchte, bzw. es sowieso nicht anders geht. EMS ist also für die DOS Anwendungen da, die das nutzen können.

--IT-Compiler (Diskussion) 21:36, 30. Mär. 2022 (CEST)

Das ist aber genau mein Punkt:

In Zeiten von Windows 3.0 war es noch sehr wichtig, dass auch DOS-Anwendungen laufen konnten. Habe ich nun einen 286er und führe Windows im Standard-Modus aus, brauche dann aber ein DOS-Programm, dann wäre es doch von Vorteil, wenn ein Teil der 16 MB RAM auch als EMS verfügbar wäre – für DOS.

21:44, 30. Mär. 2022 (CEST)

Tja, geht aber nicht. Windows unterstützt emuliertes EMS nicht. --IT-Compiler (Diskussion) 22:00, 30. Mär. 2022 (CEST)

Doch, geht schon:

Versions of Windows prior to 3.0 used mostly expanded memory. Windows 3.x does not use expanded memory but may be able to provide it to MS- DOS applications.^{Quelle: Abschnitt Expanded Memory}

Windows 3.0 selbst nutzt EMS nicht (sondern XMS), aber es ist für DOS-Programme verfügbar.

‣Andreas•⚖ 22:21, 30. Mär. 2022 (CEST)

Aber nicht im Standard Mode:

Standard Mode and Expanded Memory

Standard mode Windows 3.1 does not use expanded memory. MS-DOS applications running under standard mode can access expanded memory only if a physical expanded memory board, along with the appropriate memory manager, is present in the machine. Compatible 386 EMMs such as EMM386.EXE can be loaded to provide expanded memory outside Windows. However, 386 EMMs cannot be used to provide expanded memory to MS-DOS applications running in standard mode Windows. If possible, the 386 EMM will be disabled when standard mode loads. For more information on using expanded memory with standard mode see the "Expanded Memory for MS-DOS Applications" section of this application note.

Quelle: Abschnitt Standard Mode and Expanded Memory --IT-Compiler (Diskussion) 22:32, 30. Mär. 2022 (CEST)

Zu 3: Windows 2.x läuft nicht im Protected Mode. Wenn da HIMEM.SYS für etwas verwendet wurde, dann für etwas anderes. In DOS 3.x gibt es HIMEM.SYS jedenfalls noch nicht, das kam erst mit MS-DOS 5.0 und das erschien nach Windows 3.0. Im WW0355.TXT Dokument steht:

Windows 3.x and all applications running under Windows 3.x access 
extended memory through the Microsoft Extended Memory Specification 
(XMS). Rather than accessing extended memory directly, access is made 
through an XMS driver. The driver supplied by Microsoft for this 
purpose is called HIMEM.SYS.

Man könnte das also auch XMS Treiber nennen, und dahinter dann in Klammer (z.B. HIMEM.SYS) schreiben. Ich denke ich werde das mal so einbauen, dann wäre es Herstellerunabhängig.

Da WW0355.TXT von Microsoft stammt, ist es klar, dass DOS von der Konkurrenz, bzw. der HIMEM.SYS-Ersatz davon, nicht erwähnt wird. Microsoft hat sich nicht gerade sehr objektiv verhalten, als es darum ging, ob Windows auch auf z.B. DR DOS lauffähig ist – und wurde dafür ja auch verklagt (und hat verloren, soweit ich mich erinnere).

Eine unabhängigere zweiter/dritte/vierte Quelle wäre wohl sinnvoll...

‣Andreas•⚖ 20:27, 30. Mär. 2022 (CEST)

Wir brauchen dafür keine zweite oder dritte Quelle, es genügt wenn wir es XMS Treiber nennen und ich habe das im Artikel auch schon umgesetzt. --IT-Compiler (Diskussion) 20:43, 30. Mär. 2022 (CEST)

Zu 4: Win32 wurde nachträglich als Patch in alle frühen Windows 3.x eingeführt bei ca. Windows for Workgroups gleich mitgelifert. Die Win32 API von Windows 3.x teilte wesentliche Funktionen mit der API von Windows NT. Dennoch ist der Enhanced Modus von Windows 3.x dafür notwendig, deswegen steht das im Artikel drin. Der Windows Kernel läuft damit weiterhin im 16 Bit Modus, aber die WIN32 API kann bereits 32 Bit Windows Anwendungen unterstützen und somit konnten unter Windows 3.x 32 Bit Windows Anwendungen ausgeführt werden und davon wurde auch rege Gebrauch gemacht. Zwingend erforderlich ist dafür aber der Enhanced Mode und ein 386er oder besser. Im Standard Mode, der ja in erster Linie für den 16 bittigen 286er da ist, geht das z.B. nicht. Mir geht es darum, dass hervorgehoben wird, dass der Betriebsmodi Enhanced Mode diese 32 Bit Unterstützung hat, die anderen Modi können das nämlich nicht.

Was meinst du mit "gleich mitgeliefert"? Dass es auf der Installations-CD drauf war? Ich kann nirgends finden, dass Win32s bei Windows 3.1/3.11 (inklusive "for Workgroups"-Versionen) installiert worden wäre – es musste immer extra installiert werden.

Microsoft hat immer mal wieder Extra-Programme auf der Installations-CD verteilt, die Kunden installieren konnten. Win32s ist aber ein optionaler Teil und für Windows 3.1/3.11 und 3.1/3.11 für Workgroups, der separat zu installieren ist – wie seinerzeit auch DirectX separat (und "für Windows") war.

‣Andreas•⚖ 20:13, 30. Mär. 2022 (CEST)

Die Win32s API erschien als Version 1.1 im Juli 1993 gleichzeitig mit Windows NT 3.1. Es kann also schon sein, dass das bei Windows for Workgroups 3.11, welches am 8. November 1993 erschien, schon dabei war. Es ändert letzten Endes aber nichts an der Aussage im Artikel, denn der Enhanced Mode unterstützt Win32 Anwendungen nach Installation der Win32s API. Der Artikel handelt schließlich nicht über eine spezifische Windows 3.x Version, sondern über Windows 3.x allgemein.. Du müsstest dich also eher fragen, warum du den Punkt weglassen willst, dass der Enhanced Mode 32 Bit Windows Anwendungen ausführen kann, wenn er sie ausführen kann? --IT-Compiler (Diskussion) 20:25, 30. Mär. 2022 (CEST)

Ich will den Punkt nicht weglassen, ich will es nur nicht so hinstellen, als wäre das ohne eine Zusatzinstallation möglich... ‣Andreas•⚖ 20:29, 30. Mär. 2022 (CEST)

Gut, dann fügen wir einfach noch dazu, dass man dazu die Win32s API nachinstallieren muss. --IT-Compiler (Diskussion) 20:45, 30. Mär. 2022 (CEST)

Zu 5: 32 Bit Programme laufen nicht auf dem 286er, der kann nur 16 Bit! Deswegen kann der Standard Mode keine 32 Bit Anwendungen ausführen. Auf einem 386er muss man also Windows 3.x im Enhanced Mode starten, damit man Win32 Anwendungen überhaupt nutzen kann, ansonsten funktionieren die nicht. Und das ist auch einer der Gründe, warum man bei Windows for Workgroups den Standard Mode rausgeschmissen hat. Zu der Zeit hatten schon genug Leute 386er CPUs oder besser und in dem Bereich, in dem WfW benutzt wurde, wurden sowieso 386er oder besser benutzt und da war der 32 Bit Modus für die 32 Bit Anwendungen extrem wichtig.

Im Standard Mode auf einem 386 können 32-Bit-Programme laufen, denn dieser kann 32-Bit. ‣Andreas•⚖ 20:00, 30. Mär. 2022 (CEST)

Nachtrag: Win32s läuft nur im 386 Enhanced Mode. Aber 32-Bit-DOS-DPMI-Programme laufen auf einem 386, wenn Windows im Standard Mode läuft. Das heißt, die Aussage, es würden nur 16-Bit-Programme laufen, ist falsch. Richtig ist: Es laufen nur 16-Bit-Windows-Programme.

Ob ein Windows-Programm unter Umgehung der Windows-API Zugriff auf DPMI hat und daher auch einen 32-Bit-Teil haben kann, weiß ich nicht. Aber nachdem der Standard-Mode-Kernel auf einem 386 selbst ja ein 16-Bit-DPMI-Client ist, wäre es durchaus denkbar, dass ein weiterer 32-Bit-DPMI-Client funktionieren könnte.

Es geht hier also um den Standard Mode auf einem 386, der als DPMI-Client im Protected Mode des 386 läuft. Nicht um den 286-Standard-Mode!

‣Andreas•⚖ 20:43, 30. Mär. 2022 (CEST)

Nein. Der Standard Mode verweigert softwareseitig das 32 Bit Windows Anwendungen ausgeführt werden, selbst wenn man eine 386 CPU hat. Das weiß ich deswegen noch, weil ich damals einen 486er hatte und ich mal Windows im Standard Mode ausführte und dann feststellte, dass es den enhanced Mode verlangt, wenn man eine Win32 Anwendung ausführen wollte. Oder anders gesagt, die Win32 Anwendungen liefen ohne erweiterten Modus nicht. Sie verweigerten den Dienst. Vergleichbar mit dem Versuch eine Windows Anwendung unter einem reinen DOS auszuführen, da kriegt man dann auch eine Fehlermeldung. Der Standard Mode kann also keine 32 Bit Windows Anwendungen ausführen. Die Aussage bezog sich auch auf Windows Anwendungen. Eventuell muss man das im Artikel deutlicher hervorheben, falls das missverstanden wird. Auf DOS bin ich ja erst im nächsten Absatz eingegangen.

Ich vermute mal, dass man keine Windows Programme compilieren kann, die DOS Funktionen via DPMI nutzen. Der Windowsspezifische Compiler wird das möglicherweise überprüfen. --IT-Compiler (Diskussion) 20:53, 30. Mär. 2022 (CEST)

Ich habe jetzt gerade nochmal nachgeschaut, ich hatte das schon im Artikel, dass es um Windows Anwendungen ging. Warum schreibst du dann so, als wäre dies nicht so? Im Artikel steht: In diesem Modus ist die Ausführung von sowohl 16-Bit- als auch erstmals 32-Bit-Windows-Programmen möglich. --IT-Compiler (Diskussion) 20:57, 30. Mär. 2022 (CEST)

Ich sehe gerade, dass du dich auf den Abschnitt Standard Mode bezogen hast. Ich habe da jetzt das Merkmal "Windows Anwendung" hinzugefügt. Dennoch ist das unter Vorbehalt, da ich mir da nicht so sicher bin, ob man im Standard Mode DPMI fähige 32 Bit DOS Programme auf einer 386 CPU ausführen kann. Man müsste das wirklich überprüfen. So eine DPMI fähige 32 Bit DOS Anwendung muss man aber erst einmal finden. Viele Spiele mit DPMI fähigem DOS Extender machen nämlich mehr als nur XMS Memory zu reservieren, sie greifen bspw. direkt auf die Hardware zu und das ist ein No Go unter Windows. Windows verweigert die Ausführung von solchen Programmen. --IT-Compiler (Diskussion) 21:04, 30. Mär. 2022 (CEST)

Zu 6: Ja, das hast du nicht richtig ausgeführt, ich habe das gestern ohne groß nachzudenken so übernommen. Genaugenommen geht es bei DPMI nämlich nur darum, XMS Speicher für DOS und Windows Anwendungen so zur Verfügung zu stellen, damit sie sich nicht gegenseitig ins Gehege kommen. Für das parallele ausführen von DOS Anwendungen ist aber der Virtual 8086 Modus des 386er und somit der Enhanced Modus notwendig, da nur mit dem 386er oder besser für jede DOS Anwendung eine eigene virtuelle Maschine mithilfe des Virtual 8086 Modus genutzt werden kann. Im Standard Mode geht das nicht, da der 286er keinen Virtual 8086 Mode hat.
--IT-Compiler (Diskussion) 19:03, 30. Mär. 2022 (CEST)

Zu 6:

The 80386 kernel was designed to run as a DPMI client. It asked the DPMI host to take it into protected mode, then used the DPMI interface to do things like allocate selectors and allocate memory. If you ran Windows in Standard mode, then the DPMI host was a custom-built DOS extender that was created just for Standard mode Windows. If you ran Windows in Enhanced mode, then the DPMI host was the 32-bit virtual machine manager.^Quelle

Auf einem 386 läuft Windows im Standard-Mode als DPMI-Client unter einem DPMI-Host.

‣Andreas•⚖ 19:48, 30. Mär. 2022 (CEST)

Dann sollten wir das hier:

Im Enhanced Mode fungiert der Kernel als DPMI-Host, womit mehrere DOS-Anwendungen unter Verwendung des Virtual 8086 Mode des 80386 Prozessors parallel ablaufen können.

Zu:

  Im Enhanced Mode können mehrere DOS-Anwendungen unter Verwendung des Virtual 8086 Mode des 80386 Prozessors parallel ablaufen.

ändern. --IT-Compiler (Diskussion) 22:07, 30. Mär. 2022 (CEST)

Grundsätzliche Struktur des Artikels

Kernel oder Modus

Ich hatte ursprünglich die drei Kernel von Windows 3.0 (zwei bei Windows 3.1 und nur noch einer bei Windows 3.11) als Basis herangezogen, nun sind es die Betriebsmodi von Windows selbst. Der Standard Mode kann aber entweder auf dem 80286-Kernel laufen, oder auf deim DPMI-80386-Kernel. Das führt leider zu generellen Aussagen, im Standard Mode sei etwas auf eine bestimmte Art und Weise, was aber nicht auf beide Kernel (für 80286 und für 80386) zutrifft.

Siehe die obige Diskussion. Noch komplizierter wird es, wenn man die Fähigkeit von Windows 3.x für volle DOS-Kompatibilität mit einbezieht. Da macht es im Standard Mode plötzlich einen sehr großen Unterschied, ob der Virtual 8086 Mode des 80386 verfügbar ist oder nicht.

Darum meine generelle Frage: Was für Vorteile bringt es denn, die Modi zu beschreiben? Wäre es nicht besser, den Real Mode im Artikel zu Windows 3.0 genau zu beschreiben, immerhin gibt es diesen in Windows 3.1 und 3.11 nicht mehr. Und wenn man die Kernel als Basis nimmt, erspart man sich auch das auseinanderdröseln des Standard Mode auf einem 286er und einem 386er. Genaueres zu den Modi könnte wiederum entweder in einen eigenen Abschnitt (so ähnlich, wie es jetzt ist, nur die CPU-spezifischen Unterschiede eben wieder raus und auf Basis der drei Kernel erklärt), oder in den Artikel zu Windows 3.1.

‣Andreas•⚖ 21:34, 30. Mär. 2022 (CEST)

Im Standard Mode kannst du den Virtual 8086 Mode des 80386 für DOS Programme aber nicht nutzen. Insofern verhält sich Windows im Standard Mode aus Sicht des Anwenders auf einem 286 oder 386 genau gleich. Der Nutzer wird keinen Unterschied feststellen. Deswegen macht das schon Sinn, dass auf die Betriebsmodi zu beziehen und nicht auf die Kernel. Entscheidend ist doch, was kriegt der Nutzer zu sehen und nicht, wie ist das intern gelöst.

Und volle DOS Kompatibilität kann Windows in egal welchem Modus auch nicht bieten. Denn unter DOS sind noch ganz andere Dinge möglich. Z.B. VCPI DOS Programme, oder Spiele, die direkt auf die HW zugreifen, der Normalfall unter DOS, oder der Unreal Mode. Das geht unter Windows 3.x, in egal welchem Modus, alles nicht.

Der Real Mode passt hier schon rein, denn es geht hier ja um Windows 3.x und das kann man durchaus als Auflistung aller Betriebsmodi verstehen. Daher sollte er schon zumindest erwähnt werden, auch wenn er keine große bedeutende Rolle spielt.

Ich sehe keinen Gewinn darin, wenn man das auf die Kernel beziehen würde. Was machst du, wenn du auf dem 386 den Real Mode Kernel ausführst? --IT-Compiler (Diskussion) 22:15, 30. Mär. 2022 (CEST)

Na, also erstens mach das win.com für mich. Zweitens ist ja jeder x86-Prozessor in sehr vielen Belangen rückwärtskompatibel. Das heißt, ein 386 ist auch ein vollwertiger 8086. Von daher kann man, wenn man lustig ist, so tun, als ob Windows auf einem 8086 laufen würde... Dann erhält man genau das: Windows im Real Mode. Das gleiche gilt für den KRNL286.EXE – auf einem 386er erhält man dann Windows, wie es auf einem 80286 laufen würde (ohne Virtual 8086 Mode).

Und natürlich ist Windows 1.x, 2.x, 3.x und 9x (bzw. als Version 4.x) vollständig DOS-kompatibel, denn für jene Programme, die exklusiven vollen Hardware-Zugriff brauchen, beendet sich dieses Windows einfach – dann ist es DOS, und schon hat man volle Kompatibilität. Bei Windows 9x ist DOS eine der Komponenten, der Modus nennt sich dort "MS-DOS-Modus" und beendet Windows 9x (außer Windows Me, wo Microsoft diese Funktion entfernt hat). Für weniger "exklusive" Programme, und das sollten so ziemlich alle DPMI-Clients auch sein, sollte es genügen, wenn sich Windows pausiert, indem es die Kontrolle an den DPMI-Host abgibt, der dann den anderen DPMI-Client ausführt (ein 32-Bit-DOS-Programm, das einen DOS-Extender nutzt – bei geladenem Windows dann aber den Windows-DPMI-Host). Das schöne an DPMI ist ja, dass sich die Programme nicht in die Quere kommen (sollen).

Und ich fand es eben schon als Vorteil, die drei Kernel zu beschreiben. DENN: Bei Windows 3.1 wurde der Real-Mode-Kernel entfernt – und damit zwar auch der Real Mode, klar, aber bei bei Windows 3.11 wurde dann der 80286-Kernel entfernt, aber damit nicht der Standard Mode. Der existiert im 80386-Kernel weiter, er wurde erst mit Windows 95 entfernt. Diese Unterschiede im Abschnitt "Technik" sagen viel aus, und erlauben in zusätzlichen Abschnitten, die dann die Modi erklären, eine einfachere Gestalltung, denn damit wird ja nicht mehr gesagt "Windows 3.11 hat keinen Standard Mode mehr" – das wäre ja falsch. Jetzt kommt das aber so rüber.

‣Andreas•⚖ 22:32, 30. Mär. 2022 (CEST)

In der Praxis verweigern Spiele, die einen DOS Extender wie bspw. DOS4/GW und ähnliche nutzen unter Windows den Dienst. Erst wenn man Windows beendet, kann man diese Spiele starten.

Windows for Workgroups startet meines Wissens nach immer im Enhanced Mode. Das kannst du nicht im Standard Mode starten, selbst wenn du es mit win /s erzwingst,

Selbst die Englische WP schreibt es so:

WFW 3.11 dropped standard mode support and requires a 386 machine to run.

en:Windows_3.1x#Windows_for_Workgroups_3.11

Als Kompromiss würde ich vorschlagen, das du noch eine Feature Matrix (Tabelle) mit bspw. 4 Spalten hinzufügt, in der könntest du dann die Kernel einbauen.

In der ersten Spalte kommt in den Zeilen der Name des jeweiligen Features und in der zweiten, dritten und vierten Spalte kann man in der ersten Zeile dann den Namen des Kernels nennen. Und dann muss man nur noch da, wo das Feature erfüllt wird, ein Kreuz setzen. Für besondere Anmerkungen kann man dann noch mit solchen Hochstellzahlen auf einen Verweis verweisen. Und die Betriebmodi lassen wir so wie sie sind. Ergänzungen sind natürlich immer möglich. Letzten Endes dürften die verwendeten Kernel aber Featureidentisch mit den entsprechenden Betriebsmodi sein. --IT-Compiler (Diskussion) 22:48, 30. Mär. 2022 (CEST)

So, ich habe jetzt eine Funktionsmatrix als Tabelle erstellt. Die einzelnen Windows Kernel habe ich darin auch eingebaut, damit sollten diese nun abgedeckt sein. --IT-Compiler (Diskussion) 14:19, 31. Mär. 2022 (CEST)

DOS

Meiner Meinung nach sollte DOS und die Kompatibilität dazu in den Artikel, denn es unterscheidet Windows 3.x von Windows NT. Das muss, inklusive Real-Mode-DOS und V86Mode-DOS, VCPI und DPMI und den Fähigkeiten von Windows mit DOS-Fenster, meiner Meinung nach, noch besser erklärt werden.

‣Andreas•⚖ 21:34, 30. Mär. 2022 (CEST)

Im Prinzip ist es ja schon im Artikel in den jeweiligen Betriebsmodi erwähnt. Und natürlich kann man das immer noch weiter ergänzen. Im Standard Mode kann man bspw. nur eine DOS Anwendung gleichzeitig starten, da der V86 Modus fehlt. --IT-Compiler (Diskussion) 22:24, 30. Mär. 2022 (CEST)

Kernel und Lauffähigkeit (Update)

Ich habe jetzt mal meine alten Windows 3.1 und MS-DOS 6.2 Disketten herausgekramt und einige Tests durch Verschieben der einzelnen Kernel in einen Backupordner, so dass sie Windows nicht mehr finden kann, durchgeführt und dabei folgendes herausgefunden:

• Wenn der krnl286.exe Kernel verschoben wurde, dann wird auf einem 386er oder besser wie gehabt der krnl386.exe verwendet. Das gilt sowohl für den Befehl win, win /3 (erzwingt enhanced mode) als auch win /s (erzwingt Standard Mode). Für den Standardmode auf einem 386er wird also defaultmäßig der krnl386.exe verwendet wenn beide oder nur dieser vorhanden sind.
• Wenn der krnl386.exe Kernel verschoben wurde, dann kann man Windows weder mit dem Befehl win noch mit win /3 starten. Windows findet dann den krnl386.exe nicht und meldet dies auch mit einer Fehlermeldung. Wenn man aber nun Windows mit dem Befehl win /s startet, dann wird dieses mal der krnl286.exe Kernel, der eigentlich für den 286er gedacht ist, gestartet und damit funktioniert Windows im Standard Mode auf einem 386er oder besser dann auch.

Welcher Kernel bei einer laufenden Windows 3.1 Sitzung aktiv ist, kann man übrigens noch mit dem sehr praktischen Programm WinMap von Olaf Heß herausfinden. Das ist eine alte Careware Software und im Prinzip eine einfache Form von Task Manager, allerdings ohne die Möglichkeit Prozesse beenden oder terminieren zu können. Man findet sie noch im Internet. Damit wird es dann sehr eindeutig, welcher Kernel verwendet wurde.

Da Win 3.1 keinen Realmode Kernel mehr hat, konnte ich diesbezüglich keine Tests durchführen. Meine Tests in einer VM mit QEMU waren allerdings recht ernüchternd, da es für Windows 3.1 keine generischen VESA Treiber gibt, auch nicht zum Downloaden, um in einer VM wenigstens halbwegs höhere Auflösungen zu fahren. Und wollte jemand einen solchen Treiber programmieren, dann müsste er, wie ich herausfinden konnte, einen Großteil der Grafikroutinen in den Treiber implementieren, weil das wohl früher bei Windows 3.x alles in den Treiber kam. Erst bei Windows 9x/ME ist das anders und die GDI Funktionen von den herstellerspezifischen Treibern besser getrennt, so dass man sich diese Arbeit sparen kann. Für Win9x/Me gibt es daher dann auch zum Glück generische VESA Treiber die mit den generischen VBE VESA fähigen Pseudo Grafikchips der VM dann auch funktionieren. Wer also heutzutage Win16 Programme in einer VM starten will, der verwendet dafür besser ein Windows 9x/Me. WinXP könnte auch gehen, aber als OS mit NT Kernel hat das trotz Kompatibilitätsmodi wieder andere Nachteile. --IT-Compiler (Diskussion) 09:41, 5. Mai 2022 (CEST)

VCPI und DPMI

Scheinbar ist es doch möglich, VCPI Anwendungen unter einer DPMI Umgebung wie Windows laufen zu lassen. Das steht zumindest in folgendem Artikel. --IT-Compiler (Diskussion) 21:54, 24. Aug. 2022 (CEST)