Diskussion:Windows 3.x

message: 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)
replies: text: 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)
thread_title:  DOS 

message: 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)
thread_title:  Kernel und Lauffähigkeit (Update) 

message: 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)
thread_title:  VCPI und DPMI