Zum Inhalt springen

Windows 3.x

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 21. April 2026 um 14:52 Uhr durch imported>Y2kbug (Erweiterter Modus (Enhanced Mode): win /3).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Windows 3.x
[[Datei:Lua-Fehler in Modul:Wikidata, Zeile 1686: attempt to index field 'wikibase' (a nil value)|150px|alt=]]
Entwickler Microsoft
Lizenz(en) Microsoft EULA (Closed Source)
Erstveröff. Lua-Fehler in Modul:Wikidata, Zeile 1686: attempt to index field 'wikibase' (a nil value)
Akt. Version 3.0 bis 3.2
Kernel PC-kompatibles DOS
Windows-Kernel
Abstammung Windows 1.02.11
↳ Windows 3.x
Chronik Windows 3.0 (1990)
Windows 3.00a (1990)
Windows 3.0 mit Multimedia Extensions 1.0 (1991)
Windows für Pen Computing 1.0 (1992)
Windows 3.1 (1992)
Windows für Workgroups 3.1 (1992)
Windows für Workgroups 3.11 (1993)
Windows 3.11 (1994)
Windows 3.2 (1994)
Sonstiges Entwicklung eingestellt
www.microsoft.com
Datei:MS-Windows-3.0-installation-disks-german.jpg
Microsoft-Windows Version 3.0 Installationsdisketten mit Hardware-Kompatibilitätsliste

Unter der Bezeichnung Windows 3.x werden die Vorgänger der späteren Windows-Betriebssysteme des Softwareunternehmens Microsoft für die 16-Bit- und 32-Bit-x86-Architektur in den 3.x-Versionen zusammengefasst.<ref name="computerwoche-1878091">Manfred Bremmer: Windows 3.x – Microsoft stampft bestes Windows-Release ein. In: Computerwoche. IDG, 6. November 2008, abgerufen am 22. Mai 2018.</ref> Windows war bis Version 3.x ein grafischer Aufsatz für ein PC-kompatibles DOS wie MS-DOS.

Versionen

Die bekanntesten Windows-3.x-Versionen sind:

Es gab noch weitere Versionen, die jedoch keine ähnlich große Verbreitung fanden. Auf eingebetteten Systemen wie Kassensystemen oder Ticketautomaten kam Windows 3.x noch fast 20 Jahre nach seiner Markteinführung zum Einsatz, Lizenzen dafür verkaufte Microsoft noch bis Ende Oktober 2008.<ref name="computerwoche-1878091" />

Technik

Windows 3.x ermöglichte den Betrieb von mehreren Windows-Anwendungen per kooperativem Multitasking in einer grafischen Oberfläche und setzte noch ein laufendes MS-DOS (oder kompatibel, also auch z. B. PC DOS oder DR DOS) voraus, auf dem es lief. In diesem Bezug war es nicht anders als die älteren Windows-Versionen bis Windows 2.x. 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. 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 über den Windowskernel und dessen Treiber laufen. Dies ermöglicht auch die Verwendung von virtuellem Speicher (nur Enhanced Mode), ohne dass die Windows-Anwendung extra umgeschrieben werden muss, da aus Sicht der Windows-Anwendung kein Unterschied zwischen diesem und dem normalen Speicher besteht. Alle Kernel von Windows 3.x sind nur in 16 Bit, das gilt auch für den 386er Kernel, der 32-Bit-Windows-Anwendungen im Enhanced Mode ausführen kann. 32-Bit-Kernel gab es in Windows erst ab Windows NT und Windows 95.

Windows 3.x verwendet selbst keinen Expanded Memory (EMS) mehr, es können aber DOS-Anwendungen per Bank Switching Expanded Memory zur Verfügung gestellt werden. Im Standard Mode ist dies nur möglich, wenn der EMS Speicher von einer Speichererweiterungskarte (memory expander) kommt. Als EMS-Speicher reservierter normaler Speicher oberhalb der 1-MiB-Grenze kann dafür nicht verwendet werden. Dies gilt für alle Betriebsmodi.<ref>Microsoft Product Support Services Application Note (Text File WW0335.txt) WW0335: Memory Management with Windows</ref> Mehr dazu, siehe weiter unten.

Mit der Windows-3.x-Reihe begann der Übergang von reinen 16-Bit-Real-Mode-Windows-Programmen zu 16-Bit- und 32-Bit-Protected-Mode-Windows-Programmen. Dazu gab es ab Windows 3.0 drei verschiedene Betriebsmodi, die abhängig von der CPU beim Start von Windows automatisch den entsprechenden Windows Kernel aufriefen.<ref>Raymond Chen: For the Nitpickers: Enhanced-mode Windows 3.0 didn’t exactly run a copy of standard-mode Windows inside the virtual machine. In: The Old New Thing (Blog). 8. Februar 2013, abgerufen am 23. November 2021 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)).</ref>

Die Win16-Architektur von Windows 3.x verwendet sowohl im Real Mode als auch im Standard Mode, sowie der Standard Mode Instanz im erweiterten Modus, segmentierten Speicher, weshalb es Segmentgrößen von 64 KiB gibt. Lediglich für Win32s-Anwendungen, die einen 386er erfordern, ist das Speichermodell flach. Um die Ein- und Ausgabe-Lasten durch den Wechsel und das Laden von anderen Segmenten gering zu halten, wurde Segment-Tuning betrieben, was bedeutet, dass Funktionen die miteinander zusammenhängen darauf optimiert wurden, in diesem einen Segment vorzukommen.<ref>https://devblogs.microsoft.com/oldnewthing/20131008-00/?p=3003 I wrote FAT on an airplane, for heaven’s sake, Raymond Chen</ref>

Für die Reservierung von zusammenhängendendem Speicher größer als 64 KiB wurde unter 16 Bit Windows 3.x für 16 Bit Windows Programme im Real Mode auf die Segmentadresse der Wert 0x1000 hinzuaddiert und im Standard Mode der Wert 8 auf den Selector. Hierfür stand die Variable __AHINCR zur Verfügung.<ref>https://devblogs.microsoft.com/oldnewthing/20171113-00/?p=97386 On memory allocations larger than 64KB on 16-bit Windows von Raymond Chen (englisch)</ref>

Betriebsmodi

Real Mode

Dieser Modus ist für den 8086-Prozessor gedacht und ist derselbe wie bereits von Windows 1.0 und 2.x/286 (nicht Windows/386) bereitgestellte Modus. Er steht nur bis Windows 3.0 zur Verfügung. Alle Windows-Programme arbeiten in diesem Modus im gleichnamigen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) des x86-Prozessors und sind daher auf 16-Bit-Code und einen Adressbereich von 1 MiB begrenzt. DOS-Anwendungen werden darin ausschließlich im Vollbildmodus ausgeführt. Auf späteren Prozessorgenerationen kann der Betriebsmodus durch die Angabe des Kommandozeilenparameters /r erzwungen werden.

Der {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) von Windows 3.0 bietet volle Kompatibilität mit vorigen Windows-Versionen und älteren IBM PCs und kompatiblen Computern. Da aufgrund des knappen Speichers im konventionellen Speicherbereich nur wenige 16-Bit-Windows-Real-Mode-Programme für Windows 3.0 überhaupt entwickelt wurden, spielte er bereits bei der Veröffentlichung praktisch keine Rolle mehr.

Skriptfehler: Ein solches Modul „Vorlage:Siehe auch“ ist nicht vorhanden.

Standard Mode

Im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) läuft Windows im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) des Prozessors, was es Windows-Programmen ermöglicht, über die vom XMS-Treiber (z. B. Vorlage:Monospace) verwaltete Extended Memory Specification (XMS) mehr als 1 MiB RAM zu adressieren.<ref>Microsoft Product Support Services Application Note (Text File WW0335.txt) WW0335: Memory Management with Windows</ref> Für den {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) ist ein 80286-Prozessor oder besser erforderlich. Wie beim {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) können im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) nur 16-Bit-Windows-Programme ausgeführt werden. Im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) ist die Verwendung von LIM-EMS-Erweiterungsspeicher aus {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (XMS), wie für DOS-Anwendungen z. B. per Vorlage:Monospace, nicht möglich, es können aber EMS-Speichererweiterungskarten verwendet werden, die EMS-Speicher für DOS-Anwendungen zur Verfügung stellen können. Diese können im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) nur im Vollbildmodus ausgeführt werden, da das „DOS-Fenster“ den Virtual-8086-Modus erfordert.

Ab Windows for Workgroups ist dieser Modus nicht mehr verfügbar. Auf späteren x86-Prozessor-Generationen kann dieser Betriebsmodus durch den Aufruf von win /s erzwungen werden.

Skriptfehler: Ein solches Modul „Vorlage:Anker“ ist nicht vorhanden.Erweiterter Modus (Enhanced Mode)

Der Erweiterter Modus ({{Modul:Vorlage:lang}} Modul:Vorlage:lang:103: attempt to index field 'wikibase' (a nil value)) ist eine Erweiterung des Standard Mode. Für den Enhanced Mode ist ein 386er Prozessor die Mindestvoraussetzung. In diesem Modus ist die Ausführung von sowohl 16-Bit- als auch erstmals 32-Bit-Windows-Programmen möglich. Für 32-Bit-Windows-Anwendungen muss die Win32s-API nachinstalliert werden. 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. Erzwungen werden kann dieser Modus durch den Aufruf von win /3, was allerdings ein kompatibles System voraussetzt.

Im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) läuft eine einzige Instanz des Standard Mode von Windows in einer virtualisierten Umgebung der Virtual-8086-Mode-Einheit der CPU, die ab dem 80386 verfügbar ist. Darin werden alle Win16 und Win32s Anwendungen ausgeführt.<ref>https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013 If Windows 3.11 required a 32-bit processor, why was it called a 16-bit operating system?</ref><ref>https://devblogs.microsoft.com/oldnewthing/20130208-00/?p=5303 For the Nitpickers: Enhanced-mode Windows 3.0 didn’t exactly run a copy of standard-mode Windows inside the virtual machine ab dem 7. Absatz</ref>

Für die DOS-Anwendungen fungiert der Kernel als DPMI-Host, womit mehrere DOS-Anwendungen unter Verwendung des Virtual 8086 Mode des 80386 Prozessors in ihrer eigenen VM-Instanz parallel per präemptivem Multitasking ablaufen können. Wenn die DOS-Anwendung mit DPMI-Support programmiert wurde, kann sie auch mehr als 640 KiB konventionellen Speicher nutzen. Im Enhanced Mode können DOS-Anwendungen auch im grafischen Modus in einem Fenster ausgeführt werden, der Wechsel zum Vollbildmodus ist nicht nötig.

Im Erweiterten Modus läuft als Übergeordnete Instanz der Hypervisor, der alle diese virtuellen Maschinen, also die eine Standard Mode VM-Instanz für die Win16/32s Anwendungen, als auch alle anderen VM-Instanzen für die DOS-Anwendungen, verwaltet.<ref>https://devblogs.microsoft.com/oldnewthing/20100517-00/?p=14013 If Windows 3.11 required a 32-bit processor, why was it called a 16-bit operating system?</ref> Im Enhanced Mode sind VxD 32-Bit-Windows-Gerätetreiber möglich, obwohl Windows 3.x auch weiterhin die 16-Bit-Treiber von DOS verwenden kann.

Funktionsmatrix

Real Mode Standard mode Enhanced Mode
Windows-Kernel
8086-Kernel KERNEL.EXE Ja Nein Nein
286-Kernel KRNL286.EXE Nein Ja Nein
386-Kernel KRNL386.EXE Nein Ja<templatestyles src="FN/styles.css" /> 1 Ja
Unterstützte Prozessoren
8086/8088 und 80186 Ja Nein Nein
80286 Ja Ja Nein
80386 oder besser Ja<templatestyles src="FN/styles.css" /> 8 Ja<templatestyles src="FN/styles.css" /> 8 Ja<templatestyles src="FN/styles.css" /> 9
Versionen
Windows 3.0 Ja Ja Ja
Windows 3.1 Nein Ja Ja
Windows 3.11 Nein Ja Ja
Windows 3.2 Nein Ja Ja
Windows für Workgroups 3.1 Nein Ja Ja
Windows für Workgroups 3.11 Nein Nein Ja
Funktionen
Windows läuft im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) Nein Ja Ja
Virtueller Speicher mit „Swap“-Auslagerungsdatei<templatestyles src="FN/styles.css" /> 2 Nein Nein Ja
Multitasking präemptiv zwischen DOS-Anwendungen Nein Nein Ja
kooperativ zwischen Windows-Anwendungen<templatestyles src="FN/styles.css" /> 3 Ja Ja Ja
kompatibel mit Windows-1.x- und 2.x-Programmen Ja Nein Nein
VCPI-fähigen DOS-Programmen ?<templatestyles src="FN/styles.css" /> 4 Nein Nein
32-Bit-Windows-Anwendungen via Win32s<templatestyles src="FN/styles.css" /> 5 Nein Nein Ja
DPMI-Unterstützung für DOS-Programme Nein Ja Ja
DOS-Umgebungen nur eine gleichzeitig Ja Ja Nein
mehrere gleichzeitig Nein Nein Ja
DOS-Anwendungen im Fenster Nein Nein Ja
Speicher für DOS-Anwendungen {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (EMS) per EMS-Speicherkarte Ja Ja Ja
{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (EMS) im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (XMS) Ja<templatestyles src="FN/styles.css" /> 6 Nein<templatestyles src="FN/styles.css" /> 7 Ja
{{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (XMS) per DPMI Nein ? Ja
VxD 32-Bit-Windows-Gerätetreiber Nein Nein Ja

<templatestyles src="FN/styles.css" />

<templatestyles src="FN/styles.css" />
1) 
Windows muss dazu via win /s im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) gestartet werden.
<templatestyles src="FN/styles.css" />
2) 
Vom Virtuellen Speicher können auch DOS-Programme Gebrauch machen, wenn sie {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (XMS) und DPMI unterstützen.
<templatestyles src="FN/styles.css" />
3) 
Die Ursache, warum Windows 3.x und Win16-Programme allgemein nur kooperatives Multitasking verwenden, liegt darin begründet, dass der 8086 weder über eine {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (MPU), noch über eine {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) (MMU) verfügt. Mindestens eines von beidem ist für präemptives Multitasking aber erforderlich, wenn es performant bleiben soll.
<templatestyles src="FN/styles.css" />
4) 
Windows nutzt im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) selbst nur Konventionellen Speicher. Ein VCPI-DOS-Treiber dürfte daher nicht stören, es ist allerdings mindestens ein 80386-Prozessor erforderlich.
<templatestyles src="FN/styles.css" />
5) 
Dazu muss die Win32s-Funktionsbibliothek nachträglich installiert werden.
<templatestyles src="FN/styles.css" />
6) 
Nur mit Unterstützung durch den Prozessor, daher ab 80286.
<templatestyles src="FN/styles.css" />
7) 
Im {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) wird das von Windows nicht unterstützt, da dem 80286 der {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value) fehlt.<ref>Microsoft Dokument WW0335.TXT Abschnitt „Standard Mode and Expanded Memory“</ref>
<templatestyles src="FN/styles.css" />
8) 
{{{2}}}
Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value) <templatestyles src="FN/styles.css" />
9) 
Bei weniger oder gleich 2 MiB Arbeitsspeicher wird Windows trotz vorhandener 32 Bit CPU immer im Standard Modus gestartet. Falls virtueller Arbeitsspeicher definiert wurde, kann der Erweiterte Modus allerdings mit dem Parameter /3 beim Start erzwungen werden. Ist kein virtueller Arbeitsspeicher definiert, dann führt die Verwendung dieses Parameters bei zu wenig Ram zu der Fehlermeldung: „KERNEL: Heap-Initialisierung nicht möglich“ und der Startvorgang bricht ab.

TCP/IP

Obwohl TCP/IP und damit das World Wide Web (ein Teil des Internets) unter Windows nicht zur Verfügung standen, gab es für das zu Beginn der 1990er Jahre aufstrebende weltweite Netz bereits Software von Drittanbietern, die das Protokoll für Windows 3.0 und 3.1 nachrüsteten. Mit Winsock (kurz für „Windows Sockets“) wurde ab 1991 eine dazu notwendige Schnittstelle gemeinsam von unterschiedlichen Firmen entwickelt,<ref></ref> auf deren Grundlage Programme wie Webbrowser auch unter Windows 3.x TCP/IP nutzen können.<ref name="Christopher_Tse-The_Moment-Wolverine">Christopher Tse: TCP/IP vs. Windows for Workgroup Wolverine. In: The Moment: Columbia’s Science and Engineering Newspaper, Back Issue 1 March 1995. 1. März 1995, abgerufen am 27. September 2025 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)): „Peter Tattam’s Trumpet Winsock is the current standard for TCP/IP management under the Microsoft Windows environment. Most of the Winsock.dll (Windows Socket Driver) Internet applications are developed and tested with this program. The current version of Trumpet Winsock 2.0 Release B is very stable and reliable. There was not any real competition for Trumpet Winsock until Microsoft unveiled the final release of Wolverine, a 32 bit TCP/IP stack for Windows for Workgroup (WFW) 3.11. The seamless integration between Wolverine and Windows quickly establishes a wide install base for the software giant’s new entry to the Internet software market. As of press time, both Trumpet Winsock and Wolverine are free and available for download from almost every network-related FTP site. Trumpet Winsock has the advantage of being a ‘well-known’ TCP manager.“</ref> So stellten viele Internetdienstanbieter (ISP, kurz für {{Modul:Vorlage:lang}} Modul:Vorlage:lang:103: attempt to index field 'wikibase' (a nil value)) ihren Kunden die für das Internet nötigen Programme bereit, darunter neben einem damals nicht kostenlosen Browser auch die Winsock-TCP/IP-Software für Windows.<ref>Detlef Borchers: Wie vor 30 Jahren das World Wide Web entstand. In: Heise online. 8. Dezember 2020.Vorlage:Abrufdatum; Zitat: „Der Trend wurde noch ausgeprägter, als O’Reilly gemeinsam mit dem Unternehmen Spry begann, sein Angebot ‚Internet in a Box‘ zu verkaufen. Diese Ibox für Windows enthielt zum stattlichen Preis von gut 100 US-Dollar auf fünf 3,5-Zoll-Disketten eine Version des Mosaic-Browsers, einen TCP/IP-Stack für Windows, den man damals benötigte, um Windows 3.1 ans Internet zu bekommen, sowie ein Nutzerkonto für InterServ, dem Provider-Angebot von Spry.“.</ref> Von Microsoft gab es einen unter dem Codenamen „Wolverine“ entwickelten 32-Bit TCP/IP-Stack erst 1994, der nur auf Windows für Workgroups 3.11 funktioniert und Win32s erfordert, und wie letzteres nachinstalliert werden muss.<ref name="Christopher_Tse-The_Moment-Wolverine" /> Erst in Windows 95 integrierte Microsoft TCP/IP als fixen Bestandteil des Betriebssystems.<ref></ref>

Bedeutung

Mit Windows 3.0 und 3.1 gelang Microsoft der Durchbruch auf dem Markt für grafische PC-Betriebssysteme.<ref name="heiseonline_2953258">Detlef Borchers: 30 Jahre Windows: Der lange Weg zum Durchbruch. In: Heise online. 20. November 2015.Vorlage:Abrufdatum</ref><ref>Peter Stelzel-Morawietz: 35 Jahre Windows: von Version 1.0 zu 10. In: PC-Welt. 24. November 2020, abgerufen am 30. Juli 2022.</ref> Die eigentliche Bedeutung steckte jedoch in der stabilen Programmierschnittstelle ({{Modul:Vorlage:lang}} Modul:Vorlage:lang:103: attempt to index field 'wikibase' (a nil value), kurz API), die in ihrer 16-Bit-Ausprägung auch Win16 genannt wurde. 16-Bit-Windows-Programme aus Windows 2.0 funktionierten dabei weiterhin, jedoch nur im Real Mode.

Windows 3.x bereitete den Weg hin zu Windows 9x, das als eigenständiges Betriebssystem den MS-DOS-Unterbau in das Betriebssystem integrierte und die 32-Bit-Funktionen sowohl im 32-Bit-API Win32 als auch bei Kernkomponenten wie dem Speichermanager und Multitasking erweiterte.

Beide Generationen, also Windows 3.x als auch Windows 9x (welches als Windows 4.x entwickelt wurde), waren in der Retrospektive Lückenfüller für das neu entwickelte Windows NT, das ein vollständiges 32-Bit-Betriebssystem war – auf der damaligen Hardware jedoch zu ressourcenhungrig und zu teuer. Erst mit Windows XP gelang Microsoft der vollständige Umstieg auf die mit Windows NT eingeführte neue Technik.

Windows 3.x/9x und Windows NT haben ein ähnliches und in großen Teilen identisches API. Unter Windows 3.x konnte eine abgespeckte Variante der Win32-API nachinstalliert werden, Win32s, während Win16-Applikationen auch unter Windows-NT-Versionen weiterhin lauffähig waren. Erst in 64-Bit-x86-Versionen von Windows, also ab Windows XP x64 Edition (2005) bzw. Windows Vista x64 (2007), steht das Win16-API nicht mehr zur Verfügung.

Weblinks

Literatur

  • Charles Petzold: Programming Windows 3.0 Microsoft Press, 1990, ISBN 1-55615-264-7
  • Charles Petzold: Programming Windows 3.1, 3rd Edition Microsoft Press, 1992, ISBN 1-55615-395-3
  • Matt Pietrek: Windows Internals: The Implementation of the Windows Operating Environment Addison-Wesley Publishing Company, 1993, ISBN 0-201-62217-3
  • Andrew Schulman, David Maxey, Matt Pietrek: Undocumented Windows: A Programmer's Guide to Reserved Microsoft Windows Api Functions Addison-Wesley Publishing Company, 1992, ISBN 0-201-60834-0

Einzelnachweise

<references />

<templatestyles src="Erweiterte Navigationsleiste/styles legacy.css" />Vorlage:Klappleiste/Anfang

DOS-Linie
16-Bit auf DOS

Windows 1.0Windows 2.x

3.x (16- u. 32-Bit auf DOS)

Windows 3.0Windows 3.1

9x (32-Bit, MS-DOS integriert)

Windows 95Windows 98 (SE)Windows Me

NT-Linie
CE-Linie 

Windows CEWindows MobileWindows Phone 7

Vorlage:Klappleiste/Ende