PC, DOS und Windows

Das PC-kompatible Maschinenmodell

Der Erfolg des IBM-PC-kompatiblen Systems beruhte nicht auf einer einzigen geschlossenen Maschine, sondern auf einem weitgehend nachbaubaren Hardware- und Softwaremodell. Prozessor, RAM, ROM-BIOS, Erweiterungsbus, Tastatur, Grafikadapter, Massenspeicher und standardisierte I/O-Adressen bildeten eine Kombination, die von zahlreichen Herstellern kompatibel umgesetzt werden konnte. Für Software bedeutete „PC-kompatibel“ deshalb vor allem: ausreichend gleiches Verhalten an den Stellen, auf die Betriebssysteme und Programme tatsächlich zugriffen.

Diese Offenheit war zugleich Stärke und Fehlerquelle. Zwei Rechner konnten beide DOS ausführen und sich trotzdem bei BIOS-Version, Chipsatz, Grafik, Sound, Festplattengeometrie, IRQ-Belegung oder Timing deutlich unterscheiden. Kompatibilität war in der Praxis kein abstraktes Zertifikat, sondern eine Kette aus Annahmen. Je tiefer Software direkt auf Hardware zugriff, desto enger wurde diese Kette.

x86: Real Mode, 286, 386 und der lange Schatten des 8086

DOS entstand für eine Prozessorwelt, deren Grundmodell vom 8086/8088 geprägt war. Der Real Mode adressiert Speicher über Segment:Offset-Paare. Ein logischer Zeiger besteht aus einem Segmentwert, der um vier Bit nach links verschoben wird, plus einem Offset. Dadurch entsteht der bekannte 20-Bit-Adressraum von grundsätzlich 1 MiB. Mehrere Segment:Offset-Kombinationen können dieselbe physische Adresse bezeichnen.

Der 80286 ergänzte einen Protected Mode mit Deskriptoren und Schutzmechanismen, war für den flexiblen Wechsel zurück in den Real Mode aber unhandlich. Der 80386 änderte die Lage grundlegend: 32-Bit-Register, Paging, ein wesentlich praktikablerer Protected Mode und der Virtual-8086-Modus ermöglichten es, mehrere DOS-ähnliche Umgebungen kontrolliert unter einem 32-Bit-System laufen zu lassen. Genau darauf bauten sowohl 386-Speichermanager als auch Windows im 386 Enhanced Mode und später die Win9x-VMM-Architektur auf.

BIOS, POST, CMOS und die erste Hardwareabstraktion

Das klassische PC-BIOS sitzt zwischen Hardware und Betriebssystem. Beim Einschalten initialisiert die Firmware wesentliche Komponenten, führt den Power-On Self Test durch, ermittelt Bootgeräte und stellt Software-Interrupts für grundlegende Funktionen bereit. Typische Beispiele sind Video über INT 10h, Massenspeicher über INT 13h, serielle Schnittstellen über INT 14h, Tastatur über INT 16h und Drucker über INT 17h. DOS selbst nutzt zusätzlich eigene Systemdienste, vor allem über INT 21h.

CMOS-RAM und Echtzeituhr speicherten bei klassischen AT-kompatiblen Systemen unter anderem Datum, Uhrzeit und bestimmte Hardwareparameter. Falsche CMOS-Werte konnten deshalb zu scheinbar rätselhaften Problemen führen: falsche Festplattengeometrie, fehlende Laufwerke, Bootreihenfolge oder Checksummenfehler. Mit Auto-Erkennung, späteren BIOS-Generationen und schließlich UEFI verschob sich die konkrete Umsetzung, die Grundidee blieb jedoch: Firmware bereitet die Maschine so weit vor, dass ein Betriebssystem übernehmen kann.

Von POST zu DOS: MBR, Bootsektor und Systemdateien

Beim klassischen BIOS-Boot sucht die Firmware ein startfähiges Medium und lädt dessen ersten Bootcode. Bei partitionierten Festplatten liegt im ersten Sektor typischerweise der Master Boot Record mit kleiner Bootroutine und Partitionstabelle. Diese Routine bestimmt die aktive Partition und übergibt an deren Volume-Bootsektor. Von dort werden die betriebssystemspezifischen Startdateien geladen.

Die genauen Dateinamen unterscheiden sich nach DOS-Familie und Version. Bei MS-DOS sind IO.SYS und MSDOS.SYS zentrale Bestandteile, bei IBM PC DOS stehen entsprechend andere Namen wie IBMBIO.COM und IBMDOS.COM. Danach folgen Konfigurationsdateien und schließlich der Kommandointerpreter, typischerweise COMMAND.COM. Diese Trennung ist wichtig: BIOS-Boot, Partitionsboot, DOS-Kern und Shell sind aufeinanderfolgende Schichten, keine einzelne Datei.

DOS-Kern, Geräte und INT 21h

DOS ist klein, aber keineswegs strukturlos. Es verwaltet Dateien, Verzeichnisse, Laufwerke, Zeichen- und Blockgeräte, Speicherblöcke, Prozesse im DOS-Sinn und zahlreiche Systemdienste. Der klassische Zugang für Anwendungen erfolgt häufig über INT 21h, wobei Funktionsnummern in Registern bestimmen, welche Operation ausgeführt wird. Programme können Dateien öffnen, lesen, schreiben, Verzeichnisse wechseln, Speicher anfordern, Datum/Uhrzeit abfragen oder Kindprozesse starten.

Frühere DOS-Generationen waren deutlich einfacher; mit DOS 2.x kamen unter anderem hierarchische Verzeichnisse, dateihandle-orientierte Funktionen und eine stärkere Geräteabstraktion hinzu. Trotzdem blieb das System eng mit dem PC-Modell verbunden. Viele Programme nutzten BIOS oder Hardware direkt, weil diese Wege schneller, flexibler oder für spezielle Funktionen unvermeidlich waren.

COMMAND.COM, interne Befehle und Batchdateien

COMMAND.COM ist nicht „DOS selbst“, sondern der klassische Kommandointerpreter. Interne Befehle wie DIR, COPY, DEL, CD oder SET werden direkt von der Shell bereitgestellt; externe Werkzeuge liegen als COM- oder EXE-Dateien auf Datenträgern. Diese Unterscheidung erklärt, warum einige Befehle auch ohne gleichnamige Datei funktionieren, während andere verschwinden, sobald das zugehörige Programm nicht im Suchpfad liegt.

Batchdateien machten wiederkehrende Abläufe reproduzierbar. Variablen, PATH, bedingte Sprünge, ERRORLEVEL, Aufrufe weiterer Batchdateien und spätere Erweiterungen ermöglichten erstaunlich komplexe Start- und Wartungslogik. Gleichzeitig blieb die Shell bewusst einfach. Viele Installationsprogramme veränderten CONFIG.SYS und AUTOEXEC.BAT direkt, weil genau dort Treiber, Speichermanager und Umgebungsvariablen zusammenliefen.

CONFIG.SYS und AUTOEXEC.BAT als sichtbare Systemarchitektur

In kaum einem anderen verbreiteten PC-System war die Startkonfiguration so offen sichtbar wie unter DOS. CONFIG.SYS lädt Gerätetreiber und legt Kernel-Parameter fest; AUTOEXEC.BAT setzt die anschließend ausgeführte Shell-Umgebung auf. Genau dort entstanden typische Optimierungen und ebenso typische Fehler.

Ein solches Beispiel ist keine universelle Empfehlung. Soundkarten, CD-ROM-Treiber, Netzwerkclients, SCSI-ASPI-Schichten, Maus- und Tastaturtreiber oder Speichererweiterungen konnten zusätzliche Zeilen erfordern. Gerade deshalb gehörte die Reihenfolge zum Systemwissen: Ein Treiber konnte Speicher belegen, einen anderen Treiber blockieren oder verhindern, dass ausreichend konventioneller Speicher für ein Spiel übrig blieb.

640 KB, Upper Memory und die berühmte Speichergrenze

Der untere Megabyte-Adressraum des klassischen PCs war ungleich verteilt. Die ersten 640 KiB galten als konventioneller Arbeitsspeicher für DOS und Programme. Der Bereich darüber bis 1 MiB war für Grafik-RAM, Adapter-ROMs, BIOS und andere Hardwarefenster reserviert. Diese Aufteilung prägte den DOS-Alltag stärker als die tatsächlich eingebaute RAM-Menge.

Ein Rechner mit vier oder acht MiB RAM konnte trotzdem an einem Programm scheitern, das beispielsweise 610 KiB freien konventionellen Speicher verlangte. Treiber, TSRs und Netzwerksoftware belegten genau diesen kostbaren unteren Bereich. Speicheroptimierung bedeutete deshalb nicht einfach „mehr RAM“, sondern die geschickte Verlagerung geeigneter Komponenten in HMA oder Upper Memory Blocks.

EMS, XMS, HMA und UMB: vier Antworten auf ein altes Problem

EMS entstand als Bank-Switching-Lösung: Zusätzlicher Speicher wird portionsweise in ein festes Fenster im oberen Adressraum eingeblendet. Frühe Implementierungen benötigten spezielle Erweiterungskarten. Spätere 386-Speichermanager konnten EMS mit Paging-Technik emulieren.

XMS beschreibt dagegen den geregelten Zugriff auf Extended Memory. HIMEM.SYS wurde zum typischen XMS-Manager. DOS konnte Teile des eigenen Kerns in die High Memory Area verschieben, während EMM386 auf 386-Systemen freie Bereiche zwischen ROM- und Hardwarefenstern als Upper Memory Blocks bereitstellen konnte. DEVICEHIGH und LOADHIGH verschoben geeignete Treiber und TSRs dorthin.

TSRs, Interrupt-Hooking und residente Erweiterungen

Terminate-and-Stay-Resident-Programme blieben nach dem Start im Speicher und stellten Funktionen später erneut bereit. Maustreiber, Tastaturerweiterungen, Popup-Werkzeuge, CD-ROM-Unterstützung, Netzwerksoftware und zahlreiche Hilfsprogramme nutzten dieses Modell. Technisch geschah das häufig durch das Einhängen in Interruptvektoren oder andere Systemketten.

Daraus entstanden typische Konflikte: falsche Reihenfolge, doppelt belegte Interrupts, schlecht verkettete Handler, zu großer Speicherverbrauch oder Programme, die Annahmen über exklusiven Hardwarezugriff machten. Die Fehlersuche begann deshalb oft mit einem „sauberen Boot“ und schrittweisem Wiederhinzufügen einzelner Komponenten.

I/O-Ports, COM, LPT und direkte Hardwareadressen

Die x86-PC-Plattform besitzt neben dem Speicheradressraum einen eigenen I/O-Port-Adressraum. Viele klassische Geräte wurden über feste oder konfigurierbare Portadressen angesprochen. DOS-Software griff darauf häufig unmittelbar mit IN/OUT-Befehlen zu. Dadurch war Hardware sehr schnell erreichbar, gleichzeitig wurde die konkrete Adressbelegung Teil der Anwendungskompatibilität.

Diese Werte waren typische Konventionen, keine Naturgesetze. Jumper, BIOS-Einstellungen und später Plug and Play konnten andere Belegungen erzeugen. Genau deshalb gehörten Portadresse, IRQ und DMA bei älteren Sound- oder I/O-Karten stets zusammen in die Dokumentation.

IRQ und DMA: Konflikte, die den PC-Alltag prägten

Hardware-Interrupts erlauben Geräten, die CPU auf Ereignisse aufmerksam zu machen. Im klassischen AT-Modell wurden zwei 8259-kompatible Interruptcontroller kaskadiert, wodurch typischerweise IRQ 0 bis 15 zur Verfügung standen. Einige Leitungen waren praktisch fest belegt, andere teilten sich Erweiterungskarten.

DMA-Kanäle ermöglichten Datenübertragung zwischen Gerät und Speicher mit weniger CPU-Beteiligung. Besonders Soundkarten, Diskettencontroller und ältere Geräte machten daraus eine reale Konfigurationsfrage. Zwei Karten mit gleicher IRQ- oder DMA-Belegung konnten einzeln funktionieren und gemeinsam scheitern.

Von ISA über EISA, MCA und VLB zu PCI

Der Erweiterungsbus erzählt die Entwicklung des PCs besonders deutlich. 8-Bit-ISA des frühen PC wurde zum 16-Bit-AT-Bus erweitert. EISA versuchte 32-Bit-Erweiterung bei Rückwärtskompatibilität, während IBMs MCA ein technisch weiterentwickeltes, aber anders lizenziertes Modell verfolgte. VESA Local Bus band schnelle Grafik- und Controllerkarten eng an die 486-CPU-Generation. PCI löste viele dieser Zwischenlösungen durch einen unabhängigeren, konfigurierbaren Bus ab.

Mit PCI veränderte sich auch die Konfiguration. Statt ausschließlich Jumper und fest verdrahteter Ressourcen kamen Konfigurationsräume, Bus-Mastering und systematische Ressourcenvergabe stärker zum Tragen. Spätere PCIe-Systeme sind technisch eine andere Punkt-zu-Punkt-Welt, tragen aber den Software- und Konfigurationsgedanken der PCI-Familie weiter.

IDE/ATA: vom PC-Festplattenanschluss zur langen Parallel-ATA-Linie

IDE integrierte wesentliche Controllerlogik in das Laufwerk und vereinfachte den PC-Massenspeicher gegenüber früheren getrennten Controllerkonzepten. ATA standardisierte diesen Weg. Zwei Geräte konnten klassisch an einem Kanal hängen; ältere Systeme unterschieden häufig zwischen Master und Slave, später sprach die Terminologie präziser von Device 0 und Device 1.

Die Entwicklung reichte von CHS-Adressierung über LBA bis zu höheren Transfermodi. PIO belastete die CPU stärker, Multiword- und Ultra-DMA verlagerten Transfers. Mit schnelleren Ultra-ATA-Modi wurde das 80-adrige Kabel wichtig: weiterhin 40 Pins, aber zusätzliche Masseleitungen zur besseren Signalintegrität. BIOS-, Controller- und Kapazitätsgrenzen konnten große Laufwerke trotz physisch passendem Anschluss unsichtbar oder nur teilweise nutzbar machen.

SCSI: Bus, IDs, Terminierung und eigenständige Controllerlogik

SCSI war im PC-Bereich besonders dort stark, wo mehrere Geräte, hohe Belastung oder professionelle Peripherie zusammenkamen. Hostadapter, Festplatten, Scanner, Streamer und Wechselmedien konnten einen gemeinsamen Bus nutzen. Geräte wurden über SCSI-IDs adressiert; die Busenden benötigten korrekte Terminierung. Falsche Terminierung oder doppelte IDs erzeugten Fehlerbilder, die mit DOS- oder Dateisystemproblemen leicht verwechselt werden konnten.

SCSI entwickelte sich über mehrere elektrische und logische Generationen. Deshalb reicht die Bezeichnung „SCSI“ allein nicht als Verkabelungsanweisung. Narrow/Wide, Single-Ended, Differential-Varianten, Steckverbinder und Geschwindigkeitsklassen unterscheiden sich. Für historische Systeme bleibt die konkrete Hostadapter- und Geräteunterlage entscheidend.

Disketten, Geometrie und Controller

Disketten waren für DOS nicht nur Datenträger, sondern Teil des Boot- und Wartungsmodells. 5,25- und 3,5-Zoll-Laufwerke mit unterschiedlichen Kapazitäten, Spur- und Sektorformaten verlangten passende Controller-, BIOS- und DOS-Unterstützung. Ein Medium konnte mechanisch passen und trotzdem falsch formatiert oder mit einer Geometrie beschrieben sein, die das Zielsystem nicht erwartete.

Bootdisketten, Treiberdisketten und Rettungsmedien hatten deshalb eine besondere Bedeutung. Für das Archiv ist heute nicht nur die Dateiablage wichtig, sondern möglichst ein sektorgetreues Image mit Prüfsumme, dokumentiertem Format und Zuordnung zum ursprünglichen System. Die physische Diskette und das Datenabbild erfüllen unterschiedliche Archivfunktionen.

FAT12 und FAT16: einfache Struktur mit großer historischer Wirkung

Die FAT-Familie organisiert Dateien über Clusterketten, deren Verkettung in der File Allocation Table steht. FAT12 eignet sich besonders für kleine Volumes wie klassische Disketten. FAT16 vergrößert den adressierbaren Clusterraum und wurde zum prägenden DOS-Festplattendateisystem. Verzeichnisstrukturen, Dateiattribute und 8.3-Dateinamen bildeten eine bewusst einfache, gut implementierbare Welt.

Die Einfachheit hatte Grenzen. Clustergröße und maximale Clusterzahl beeinflussten die nutzbare Volumegröße. Große Partitionen konnten mit großen Clustern erheblichen Slack Space erzeugen. Außerdem fehlten Journaling, ACLs und viele Schutzmechanismen späterer Dateisysteme. Nach einem Absturz war deshalb die Konsistenz von FAT-Ketten und Verzeichniseinträgen ein zentrales Thema für CHKDSK, SCANDISK und Wiederherstellungswerkzeuge.

VFAT, lange Dateinamen und FAT32

Windows 95 brachte lange Dateinamen in die verbreitete FAT-Welt, ohne die DOS-Kompatibilität vollständig zu brechen. VFAT speichert zusätzliche Verzeichniseinträge für den langen Namen und hält parallel einen kompatiblen 8.3-Alias bereit. Genau daraus entstanden typische Effekte: Unter reinem DOS waren nur die Kurzformen sichtbar, und Werkzeuge, die lange Namenseinträge nicht verstanden, konnten Metadaten beschädigen.

FAT32 erweiterte später die Clusteradressierung und machte größere Volumes mit kleineren Clustern praktikabler. Trotzdem blieb FAT32 konzeptionell ein FAT-Dateisystem. Berechtigungen, Journaling und die engere Systemintegration von NTFS gehörten zu einer anderen Architektur. Der Übergang von FAT16 zu FAT32 löste Kapazitätsprobleme, aber nicht die grundsätzlichen Grenzen der FAT-Familie.

DOS-Anwendungen, Speichermodelle und DOS-Extender

DOS-Programme reichten von kleinen COM-Dateien bis zu großen EXE-Anwendungen mit Segmentierung, Overlays und eigenem Speicher-Management. Compiler unterschieden tiny, small, medium, compact, large oder huge memory models, weil Code und Daten nicht beliebig in einem einzigen 64-KiB-Segment lagen. Near- und Far-Pointer waren reale Architekturentscheidungen, keine bloße Compilerfolklore.

Mit 286 und 386 entstanden DOS-Extender, die Protected Mode und deutlich mehr Speicher nutzbar machten, während DOS für Datei- und Gerätedienste im Hintergrund erhalten blieb. DPMI standardisierte später einen wichtigen Teil dieser Umgebung. Spiele und technische Anwendungen konnten damit weit über die konventionelle 640-KiB-Welt hinausgehen, ohne vollständig auf ein anderes Betriebssystem wechseln zu müssen.

DOS-Geräte, DEVICE-Treiber und die offene Treiberkette

DOS behandelt nicht jede Ein- und Ausgabe als normale Datei. Zeichen- und Blockgeräte besitzen eigene Treiberstrukturen, die beim Start in die Geräteliste eingebunden werden können. Namen wie CON, NUL, PRN oder AUX gehören zu dieser Gerätewelt. Deshalb können Befehle Daten beispielsweise nach NUL umleiten, obwohl keine gewöhnliche Datei dieses Namens existiert.

CONFIG.SYS lädt zusätzliche Treiber über DEVICE oder DEVICEHIGH. Solche Treiber konnten Tastatur-, Speicher-, SCSI-, CD-ROM-, Netzwerk- oder Spezialhardware unterstützen. Die Reihenfolge war relevant, weil jeder Treiber Speicher belegte und Dienste für nachfolgende Komponenten bereitstellen konnte. Ein scheinbar nebensächlicher Treiber konnte deshalb bestimmen, ob später noch genügend konventioneller Speicher verfügbar war.

CD-ROM als gutes Beispiel

Klassische DOS-CD-ROM-Unterstützung bestand häufig aus zwei Schichten: einem gerätespezifischen oder controllerbezogenen Treiber in CONFIG.SYS und MSCDEX als Erweiterung, die das Laufwerk in die DOS-Laufwerks- und Dateisystemwelt einband. Ein fehlender Teil führte zu typischen Symptomen: Hardware konnte erkannt sein, aber kein Laufwerksbuchstabe erschien; oder MSCDEX war vorhanden, fand aber keinen passenden Gerätetreiber.

Laufwerksbuchstaben, Pfade, 8.3-Namen und Dateiattribute

DOS organisiert Datenträger über Laufwerksbuchstaben. A: und B: waren historisch eng mit Disketten verbunden, C: wurde zum typischen ersten Festplattenlaufwerk. Ein Pfad kombiniert Laufwerk, Verzeichnisse und Dateinamen. Das wirkt selbstverständlich, ist aber eine sehr konkrete historische Konvention, die bis in moderne Windows- Systeme sichtbar geblieben ist.

Klassische DOS-Dateinamen folgen dem 8.3-Schema: bis zu acht Zeichen Basisname und bis zu drei Zeichen Erweiterung. Programme entwickelten daraus eigene Konventionen – EXE, COM, BAT, SYS, INI, CFG, DAT und viele andere. Attribute wie Read Only, Hidden, System und Archive ergänzten die Verzeichniseinträge. Das Archive-Bit spielte historisch auch bei inkrementellen Sicherungsstrategien eine Rolle.

Eine Besonderheit der DOS-Shell ist, dass jedes Laufwerk einen eigenen „aktuellen“ Verzeichniszustand behalten kann. Der Wechsel von C: nach D: und zurück muss deshalb nicht zum Root-Verzeichnis führen. Diese kleinen Verhaltensdetails erklären viele Batchdateien, Installationsprogramme und scheinbar eigenartige Pfadfehler.

Codepages, Tastaturbelegung und nationale DOS-Varianten

Text auf klassischen PCs ist ohne Zeichencodierung nicht vollständig beschrieben. DOS nutzte OEM-Codepages, deren Zeichenbelegung sich je nach Region unterschied. Deutsche Systeme verbanden Tastaturtreiber, COUNTRY-Einstellungen und Codepages, damit Eingabe, Anzeige und Sortierung zu den erwarteten Zeichen passten. Eine Datei mit Bytewerten enthält deshalb nicht automatisch dieselben sichtbaren Zeichen auf jedem System.

Diese Ebene wird bei Archivmaterial schnell wichtig. Umlaute, Rahmenzeichen, ANSI-/OEM-Konvertierungen und später Windows-Codepages können beim Kopieren in moderne Unicode-Systeme falsch interpretiert werden. Eine originale Textdatei sollte deshalb nicht allein nach ihrer heutigen Darstellung beurteilt werden. Bytefolge, vermutete Codepage und ursprüngliches Programm gehören zusammen in die Dokumentation.

CGA, EGA, VGA und die PC-Grafik vor einheitlicher Beschleunigung

Die PC-Grafik entwickelte sich über mehrere Adapterfamilien. CGA verband Text- und einfache Farbgrafikmodi, EGA erweiterte Auflösung und Farbmöglichkeiten, VGA setzte ab Ende der 1980er einen besonders langlebigen Kompatibilitätsanker. BIOS-Video über INT 10h bot standardisierte Funktionen; leistungsorientierte Programme programmierten Register und Videospeicher häufig direkt.

VGA war dabei mehr als „640×480“. Textmodi, planare Grafik, 256-Farben-Modi und programmierbare Register ermöglichten sehr unterschiedliche Arbeitsweisen. Mode 13h mit 320×200 und 256 Farben wurde für DOS-Spiele populär, weil der lineare 64-KiB-Bildspeicher vergleichsweise einfach anzusprechen war. Anspruchsvollere Techniken nutzten sogenannte Mode-X-Varianten und planare Organisation für Scrolling oder Page-Flipping.

SVGA brachte herstellerspezifische Erweiterungen und später VESA-BIOS-Schnittstellen, um höhere Auflösungen und Farbtiefen einheitlicher zugänglich zu machen. Mit Windows verlagerte sich die Verantwortung zunehmend in Grafiktreiber, GDI und später DirectX.

PC-Sound: PC Speaker, AdLib, Sound Blaster und MIDI

Der frühe PC Speaker war technisch sehr einfach und für Systemsignale ausreichend, aber keine allgemeine Audiolösung. AdLib machte FM-Synthese im Spielebereich populär. Sound-Blaster-kompatible Karten verbanden später digitale PCM-Wiedergabe, FM-Synthese, Gameport und je nach Modell MIDI-Funktionen. Dadurch entstand eine neue Kompatibilitätsmatrix aus Basisadresse, IRQ und DMA.

Typische Setup-Dialoge verlangten Werte wie Port 220h, IRQ 5 oder 7 und DMA 1. Diese Zahlen waren nicht dekorativ: Sie mussten mit der realen Kartenbelegung übereinstimmen. Ein falscher IRQ konnte Musik noch funktionieren lassen, während digitale Samples ausfielen; eine falsche DMA-Einstellung konnte Knattern, Stillstand oder fehlende Wiedergabe erzeugen.

MIDI war eine getrennte Ebene. Externe Klangerzeuger, MPU-401-Kompatibilität, Gameport-MIDI und General-MIDI- Geräte machten „MIDI-Musik“ abhängig vom tatsächlich angeschlossenen Synthesizer. Die allgemeine Audio- und MIDI-Technik steht ausführlich auf audio-und-midi.htm.

UART, serielle Schnittstelle und Parallelport

COM-Ports verbanden Modems, Mäuse, Terminals, Messgeräte und zahlreiche Spezialgeräte mit dem PC. UART- Bausteine pufferten und serialisierten Daten; ältere 8250/16450-Varianten besaßen gegenüber 16550A-Systemen geringere Pufferfähigkeiten. Bei hohen Übertragungsraten und stark belasteten Systemen konnte das den Unterschied zwischen stabiler Verbindung und verlorenen Zeichen ausmachen.

Der Parallelport war ursprünglich auf Drucker ausgerichtet, wurde aber ebenfalls zur universellen Bastelschnittstelle. Spätere EPP-/ECP-Modi erweiterten Richtung und Geschwindigkeit. Scanner, Dongles, Wechsellaufwerke und Programmieradapter nutzten diese Möglichkeiten. Mit USB verschwanden viele dieser Alltagsanwendungen, für historische Systeme bleiben COM und LPT jedoch zentrale Diagnose- und Datenwege.

Windows 3.x: grafische Umgebung auf einer DOS-geprägten Plattform

Windows 3.0 und 3.1 machten die grafische PC-Umgebung für einen breiten Anwenderkreis praktisch. Program Manager, File Manager, GDI, USER, gemeinsame DLLs und die Windows-API bildeten eine andere Oberfläche als DOS, der Startpfad blieb jedoch eng mit DOS verbunden. DOS initialisierte Maschine und Treiber; WIN.COM startete anschließend Windows.

16-Bit-Windows-Anwendungen teilten erhebliche Teile der Systemumgebung und arbeiteten unter einem kooperativen Multitaskingmodell. Ein schlecht reagierendes Programm konnte die gesamte grafische Sitzung blockieren. Gleichzeitig bot Windows Speicherverwaltung, Druckertreiber, Schriftarten, DDE, Zwischenablage und gemeinsame Geräteabstraktion, wodurch Anwendungen deutlich weniger eigene Hardwarelogik mitbringen mussten als typische DOS-Programme.

Real Mode, Standard Mode und 386 Enhanced Mode

Frühere Windows-Versionen mussten sehr unterschiedliche Prozessoren bedienen. Der Real Mode blieb an das 8086-Modell gebunden. Standard Mode nutzte den Protected Mode des 286 und darüber. Der 386 Enhanced Mode setzte die Fähigkeiten des 80386 ein, insbesondere Virtual-8086-Umgebungen und Paging, um DOS-Sitzungen und Windows-Komponenten flexibler voneinander zu trennen.

Damit verschob sich die PC-Architektur sichtbar. Ein DOS-Programm konnte innerhalb einer virtuellen Maschine laufen, während Windows den realen 386 kontrollierte. Direkte Hardwarezugriffe blieben möglich, wurden aber zunehmend virtualisiert oder überwacht. Genau hier liegt eine wichtige Vorstufe der späteren Windows-9x-VMM.

Windows 95: Win32 im Massenmarkt, aber DOS bleibt Teil des Starts

Windows 95 veränderte Oberfläche, API und Treibermodell deutlich. 32-Bit-Win32-Anwendungen, präemptives Scheduling für Win32-Threads, lange Dateinamen, Registry, Plug and Play und eine stärker integrierte Netzwerkumgebung machten das System weit moderner als Windows 3.1. Trotzdem blieb die DOS-Abstammung technisch sichtbar: Der Start durchlief weiterhin reale DOS-nahe Phasen, und Kompatibilität zu DOS- und 16-Bit-Windows-Software war ein zentrales Designziel.

Genau diese Mischarchitektur erklärt viele Eigenschaften. Win32-Programme waren besser voneinander isoliert als klassische 16-Bit-Windows-Anwendungen, doch Altkomponenten und VxDs konnten den gesamten Rechner destabilisieren. Ein „32-Bit-Windows“ bedeutete deshalb nicht automatisch dieselbe Architektur wie Windows NT.

Windows 98 und Windows ME: Ausbau und Endpunkt der DOS-basierten Linie

Windows 98 führte die 9x-Architektur mit stärkerer USB-, AGP-, ACPI- und WDM-Unterstützung weiter. FAT32, größere Datenträger, neuere Grafik- und Multimedia-Schnittstellen sowie verbesserte Plug-and-Play-Mechanismen passten zu der PC-Hardware der späten 1990er. Windows 98 Second Edition wurde für viele Systeme zum besonders langlebigen Stand, weil es alte und neue Hardware vergleichsweise breit verband.

Windows ME war der letzte große Vertreter dieser DOS-basierten Consumer-Linie. Die langfristige Richtung war zu diesem Zeitpunkt bereits klar: Die NT-Familie bot das stabilere Fundament für Speichertrennung, Mehrbenutzerbetrieb, Dienste, Rechte und moderne Treiber. Windows XP führte die Consumer-Welt schließlich auf die NT-Basis.

Win16, Win32 und Kompatibilitätsschichten

„Windows-Programm“ bezeichnet technisch sehr unterschiedliche Generationen. Win16-Anwendungen der Windows- 3.x-Welt verwenden 16-Bit-APIs und segmentierte Speicherannahmen. Win32 brachte ein 32-Bit-API-Modell, flachere Adressräume und ein anderes Prozess-/Thread-Verständnis. Windows 95 musste beide Welten gleichzeitig unterstützen und hielt deshalb erhebliche Kompatibilitätsmechanismen im System.

Auch Windows NT unterstützte lange ältere Anwendungen über Subsysteme und Übersetzungsschichten. Auf 32-Bit- x86-Systemen konnten viele Win16-Anwendungen über WOW und DOS-Programme über NTVDM laufen. 64-Bit-Windows entfernte diesen nativen 16-Bit-Unterbau. Das erklärt, warum eine alte EXE auf Windows XP noch problemlos starten kann, auf einem heutigen 64-Bit-System aber Emulation oder Virtualisierung benötigt.

DLLs, gemeinsame Laufzeitbibliotheken und Versionskonflikte

Dynamic Link Libraries ermöglichen gemeinsam genutzten Code und waren von Anfang an ein wichtiger Teil der Windows-Architektur. Anwendungen konnten dadurch Systemfunktionen und gemeinsame Komponenten laden, ohne jeden Code statisch mitzubringen. Gleichzeitig entstand die berüchtigte Konfliktklasse unterschiedlicher DLL-Versionen, Suchpfade und Installationsprogramme, die gemeinsam genutzte Dateien überschrieben.

Spätere Windows-Versionen verbesserten Versionierung, Side-by-Side-Komponenten und Systemdateischutz. Für die historische Diagnose bleibt dennoch wichtig, dass „fehlende DLL“ nur ein Symptom ist. Falsche Version, fehlender Runtime-Satz, beschädigte Registrierung oder ein anderer Suchpfad können denselben Fehlertext erzeugen.

Geräte-Manager: Ressourcen und Treiber werden sichtbar

Mit Windows 95 wurde der Geräte-Manager zu einem zentralen Diagnosewerkzeug. Hardwareklassen, Treiber, Ressourcen, Konflikte und Gerätezustände waren nicht mehr ausschließlich in Jumperplänen oder INI-Dateien zu suchen. Gelbe Warnsymbole, unbekannte Geräte oder deaktivierte Komponenten lieferten einen ersten Hinweis auf fehlende Treiber oder Ressourcenkonflikte.

Diese Sicht vereinfachte die Fehlersuche, ersetzte aber nicht das Verständnis darunter. Ein Gerät konnte korrekt erkannt und dennoch elektrisch, firmwareseitig oder treiberintern fehlerhaft sein. Umgekehrt konnte ein vollständig funktionsfähiges Gerät ohne passende INF- und Treiberdateien als unbekannte Hardware erscheinen.

APM, ACPI und der Übergang zu betriebssystemgesteuerter Energieverwaltung

Frühe PCs kannten Energieverwaltung nur begrenzt. APM verlagerte Teile der Steuerung in BIOS-Funktionen. ACPI ging weiter und beschrieb Hardware- und Energiezustände so, dass das Betriebssystem eine wesentlich aktivere Rolle übernehmen konnte. Standby, Ruhezustand, Prozessorzustände, Gerätestrom und das automatische Abschalten nach dem Herunterfahren wurden dadurch systematisch integrierbar.

Gerade beim Übergang zu Windows 98/2000/XP war ACPI zugleich eine Fehlerquelle. BIOS-Fehler oder unpassende Treiber konnten Suspend/Resume, IRQ-Routing oder das Abschalten beeinträchtigen. Energieverwaltung ist daher kein bloßes Komfortmerkmal, sondern Teil der Hardware-/Firmware-/OS-Schnittstelle.

Blue Screen, Schutzverletzung und unterschiedliche Absturzklassen

Nicht jeder blaue Bildschirm bedeutet dasselbe. Windows 9x konnte bei schweren VxD-, Treiber- oder Schutzproblemen in einen Blue-Screen-Zustand geraten. Windows NT verwendet den Bug Check als kontrollierten Systemstopp, wenn ein sicherer Weiterbetrieb im Kernelmodus nicht mehr gewährleistet ist. Stopcode und Parameter sind Diagnoseinformationen, keine bloße Fehlermeldung.

Nutzerprogramm-Absturz und Kernel-Bugcheck müssen deshalb getrennt werden. Ein einzelner Prozess kann durch ungültigen Speicherzugriff enden, ohne dass Windows selbst ausfällt. Ein fehlerhafter Kernel-Treiber, defekter RAM, instabile Hardware oder beschädigte Kernelstrukturen können dagegen den gesamten Rechner stoppen. Ereignisprotokoll, Dumpdatei und reproduzierbarer Auslöser sind dann wesentlich aussagekräftiger als die Farbe des Bildschirms.

Registry: zentrale Konfiguration statt verstreuter INI-Welt

Die Windows-Registry bündelt System-, Hardware- und Benutzerkonfiguration in hierarchischen Schlüsseln und Werten. Sie ersetzte nicht schlagartig jede INI-Datei, wurde aber ab Windows 95 und Windows NT zum zentralen Mechanismus für zahlreiche Einstellungen. Hardwareerkennung, Dienste, Dateizuordnungen, COM-Komponenten, Benutzerprofile und Treiberkonfiguration erhielten dadurch eine gemeinsame Datenbasis.

Der Vorteil zentraler Struktur war zugleich ein Wartungsrisiko. Fehlerhafte Werte konnten weitreichende Folgen haben, und einfache Dateikopie ersetzte nicht immer eine konsistente Sicherung der Systemzustände. Für die Archivierung alter Windows-Installationen sind deshalb Systemdateien, Registry-Hives, Treiber und Datenträgerabbild als zusammengehöriger Zustand zu betrachten.

Plug and Play: Ressourcenvergabe wird Teil des Systems

Klassische ISA-Hardware verlangte häufig manuelle Jumper für I/O-Adresse, IRQ oder DMA. Plug and Play sollte diese Konfiguration automatisieren. BIOS, Betriebssystem und Gerät mussten dazu Informationen austauschen, Ressourcen erkennen und konfliktfrei zuweisen. Mit PCI wurde dieser Ansatz wesentlich natürlicher als bei nachträglich automatisierten ISA-Karten.

„Plug and Play“ beseitigte Konflikte nicht vollständig. Falsche BIOS-Einstellungen, ältere nicht-PnP-Karten, Treiberfehler und knappe Legacy-Ressourcen konnten weiterhin Probleme erzeugen. Die Fehlersuche verlagerte sich jedoch von Jumperlisten zu Geräte-Manager, Ressourcenansichten und Treiberzustand.

VxD, WDM und die Verschiebung vom Hardwarezugriff zum Treibermodell

Windows 9x nutzte Virtual Device Drivers, kurz VxDs, um Hardware und virtuelle Maschinen zu verwalten. Diese Komponenten liefen mit hohen Privilegien und konnten tief in Systemfunktionen eingreifen. Leistungsfähige Grafik-, Sound-, Netzwerk- oder Massenspeichertreiber waren deshalb ebenso zentral wie potenziell systemkritisch.

Mit dem Windows Driver Model entstand eine Brücke zwischen späterem Windows 98 und Windows 2000. Ziel war eine stärker vereinheitlichte Treiberbasis für moderne Geräteklassen, Energieverwaltung und Plug and Play. Die vollständige NT-Treiberarchitektur blieb dennoch eigenständig. Ein Treiber, der unter Windows 98 lief, war nicht automatisch mit jeder NT-Version kompatibel.

GDI, DirectDraw, Direct3D und der Wandel der PC-Grafik

GDI abstrahierte klassische 2D-Ausgabe, Fenster, Schriften, Drucker und Zeichenoperationen. Für Büro- und Standardanwendungen war diese Abstraktion entscheidend. Spiele und Multimedia benötigten jedoch direkteren und schnelleren Zugriff auf Grafik- und Soundhardware. DirectX bündelte dafür verschiedene Schnittstellen, darunter historisch DirectDraw, DirectSound, DirectInput und Direct3D.

Damit veränderte sich die Spieleentwicklung vom direkten VGA-Registerzugriff unter DOS zu einer betriebssystemvermittelten Hardwarebeschleunigung. Treiberqualität wurde noch wichtiger: Ein fehlerhafter Grafiktreiber konnte eine Anwendung ebenso begrenzen wie die GPU selbst. Das PC-System wurde leistungsfähiger, aber die Verantwortung wanderte stärker in APIs und Treiberschichten.

Windows NT: eine andere Linie unter ähnlicher Oberfläche

Windows NT entstand nicht als bloße Weiterentwicklung von Windows 3.x oder DOS. Die Architektur trennt Benutzer- und Kernelmodus, Prozesse besitzen geschützte virtuelle Adressräume, und zentrale Kernelmodus- Komponenten übernehmen Speicherverwaltung, I/O, Objektverwaltung, Prozess-/Thread-Verwaltung und Sicherheit. Anwendungen greifen nicht frei auf Hardware zu; Gerätetreiber und definierte Systempfade vermitteln.

Innerhalb des Kernelmodus wird zwischen dem niedrigeren Kernel, dem umfangreicheren Executive und der Hardware Abstraction Layer unterschieden. Diese Trennung erklärt, warum NT-Systeme andere Stabilitäts- und Sicherheitsgrenzen besitzen als Windows 9x. Ein Fehler in einem Benutzerprozess muss nicht den gesamten Rechner stoppen; ein fehlerhafter Kernel-Treiber kann es dagegen weiterhin.

Prozesse, Threads, virtueller Speicher und Schutz

In der NT-Linie ist ein Prozess vor allem ein Ressourcen- und Adressraumcontainer; ausführende Einheiten sind Threads. Jeder Prozess sieht einen virtuellen Adressraum, dessen Seiten auf physischen RAM, Auslagerungsdatei, Dateien oder gemeinsam genutzte Bereiche abgebildet werden können. Paging und Speicherschutz verhindern, dass normale Anwendungen beliebig in fremde Adressräume schreiben.

Das ändert die Fehlerkultur grundlegend. Unter DOS konnte ein Programm große Teile des Maschinenzustands direkt verändern. Unter NT führen ungültige Zugriffe in Benutzerprogrammen typischerweise zu einer Ausnahme im betroffenen Prozess. Systemweite Abstürze verlagern sich stärker auf Kernelcode, Treiber oder Hardware. „Stabiler“ bedeutet hier also nicht fehlerfrei, sondern bessere Fehlergrenzen.

HAL: Hardwareabstraktion ohne vollständige Hardwareferne

Die Hardware Abstraction Layer kapselt plattformspezifische Details, damit Kernel und Treiber nicht jede konkrete Interrupt-, Timer- oder Busvariante selbst kennen müssen. Historisch war das besonders wichtig, weil Windows NT auf mehreren Prozessor- und Systemarchitekturen laufen sollte. Auch innerhalb der PC-Welt unterschieden sich Interruptcontroller, Multiprozessorlogik und andere Plattformdetails.

HAL bedeutet nicht, dass Hardwareunterschiede verschwinden. Gerätetreiber müssen weiterhin das konkrete Gerät verstehen. Die HAL abstrahiert dagegen bestimmte Plattformmechanismen, auf denen der Rest des Kernelmodus aufsetzt. Diese Schicht ist ein gutes Beispiel dafür, wie sich die PC-Welt von direkter DOS-Hardwarekontrolle zu strukturierter Systemvermittlung entwickelte.

NTFS: Metadaten, Rechte, Journaling und eine andere Dateisystemklasse

NTFS unterscheidet sich konzeptionell deutlich von FAT. Dateien und Verzeichnisse werden über Metadaten in der Master File Table beschrieben. Sicherheitsdeskriptoren und ACLs erlauben differenzierte Rechte, Journaling schützt Metadatenkonsistenz, und weitere Funktionen wie Kompression, Sparse Files, Reparse Points, Alternate Data Streams oder je nach Windows-Version Verschlüsselung erweitern das Modell.

Diese Funktionen machen NTFS nicht automatisch gegen jeden Datenverlust immun. Journaling schützt primär die strukturelle Konsistenz bestimmter Dateisystemoperationen, nicht den Inhalt jeder gerade bearbeiteten Datei. Auch NTFS benötigt Backups. Für historische Dual-Boot-Systeme war zusätzlich wichtig, dass reines DOS oder Windows 9x NTFS nicht nativ wie FAT lesen konnte.

Konten, ACLs und die Verschiebung von „PC-Besitz“ zu Systemrechten

DOS kennt praktisch keine lokale Mehrbenutzersicherheit. Wer Zugriff auf die Maschine besitzt, kann im Normalfall auf nahezu alle DOS-erreichbaren Dateien und Geräte zugreifen. Windows 9x ergänzt Benutzerprofile und Netzwerkidentitäten, erreicht aber nicht die Schutzarchitektur der NT-Linie.

Windows NT behandelt Benutzer, Gruppen, Zugriffstoken, Sicherheitsdeskriptoren und ACLs als zentrale Betriebssystemobjekte. Dienste können unter eigenen Konten laufen, Dateien und Registry-Schlüssel besitzen differenzierte Rechte, und Domänen können Identität über einzelne Rechner hinaus organisieren. Damit wird „Administrator“ eine definierte Sicherheitsrolle und nicht bloß die Person vor dem Rechner.

Dienste, Treiber und der NT-Systemstart

Die NT-Linie startet nicht nur eine grafische Shell. Bootloader, Kernel, HAL, Boot-Start-Treiber, Session- und Dienstekomponenten bauen schrittweise eine Umgebung auf, bevor eine interaktive Anmeldung erfolgt. Der Service Control Manager startet konfigurierte Dienste, überwacht Abhängigkeiten und verwaltet Dienstzustände.

Das erklärt typische Fehlerbilder: Ein Rechner kann den Kernel laden und trotzdem vor der Anmeldung scheitern, weil ein Boot-Treiber oder Dienst blockiert. Umgekehrt kann die grafische Shell ausfallen, obwohl Netzwerk- und Hintergrunddienste weiterlaufen. „Windows startet nicht“ muss deshalb in eine konkrete Bootphase übersetzt werden.

Windows 2000 und Windows XP: NT wird zur allgemeinen PC-Basis

Windows 2000 führte die NT-Linie mit breiter Plug-and-Play-, ACPI-, USB- und WDM-Unterstützung stärker in den allgemeinen PC-Alltag. Windows XP verband diese Grundlage schließlich mit dem Consumer-Markt und ersetzte die DOS-basierte 9x/ME-Linie als Hauptweg. Für viele Systeme bedeutete das einen sichtbaren Stabilitätsgewinn, aber auch strengere Anforderungen an Treiber und ältere Anwendungen.

DOS-Anwendungen verschwanden nicht sofort. NTVDM und Kompatibilitätsschichten hielten viele 16-Bit- und DOS-Programme auf 32-Bit-x86-Systemen lauffähig. Mit dem späteren Übergang zu 64-Bit-Windows entfiel dieser native 16-Bit-Unterbau weitgehend. Emulation und virtuelle Maschinen wurden damit für alte Software wichtiger.

Netzwerk: Packet Driver, IPX/SPX, NetBEUI, TCP/IP und SMB

PC-Netzwerke begannen im Alltag lange vor allgegenwärtigem TCP/IP. DOS-Netzwerkclients nutzten Packet Driver, ODI- oder NDIS-Schichten; Novell-Netze machten IPX/SPX verbreitet; Microsoft-Umgebungen setzten unter anderem NetBEUI und SMB-basierte Datei-/Druckdienste ein. Windows for Workgroups brachte Peer-to-Peer-Netzwerk direkt in die Windows-3.x-Welt.

TCP/IP wurde mit Internetzugang und heterogenen Netzen zunehmend zum gemeinsamen Fundament. Winsock schuf eine Windows-Socket-Schnittstelle für Anwendungen. In Windows NT/2000/XP verschob sich die Netzwerklogik weiter in dauerhaft laufende Dienste, Domänenintegration, DNS, DHCP und systemweite TCP/IP-Konfiguration.

Die vertiefte Entwicklung von Heimvernetzung und Protokollen steht auf netzwerk-und-heimvernetzung.htm.

Modems, COM-Ports, RAS und DFÜ-Netzwerk

Der klassische PC war für DFÜ besonders geeignet, weil serielle Schnittstellen und Modemsoftware tief in den Alltag integriert wurden. Hayes-kompatible AT-Befehle, COM-Port, IRQ, UART, Terminalprogramm und Telefonleitung bildeten eine nachvollziehbare Kette. Unter DOS konnten Terminalprogramme unmittelbar mit dem UART arbeiten; Windows verlegte zunehmend mehr davon in Treiber und Kommunikations-APIs.

Mit SLIP und vor allem PPP wurde aus der seriellen Modemverbindung ein IP-Zugang. Windows-RAS und das DFÜ-Netzwerk verbanden Einwahl, Authentisierung, Protokollkonfiguration und Routing zu einer benutzerfreundlicheren Oberfläche. Technisch blieb darunter jedoch eine zeitkritische serielle Verbindung mit Modemzustand, Leitungsqualität und Protokollaushandlung.

Die historische Modem- und Mailboxpraxis ist ausführlicher auf modems-und-dataphon.htm, modems-mailboxen-und-protokolle.htm und mailboxen-bbs.htm dokumentiert.

Von MBR und BIOS zu GPT und UEFI

Die klassische DOS-/BIOS-Welt basiert auf MBR-Partitionierung und Firmwarediensten, die aus der frühen PC-Architektur stammen. MBR stellt nur vier primäre Partitionseinträge bereit; erweiterte Partitionen und logische Laufwerke umgehen diese Grenze. Bei klassischen 512-Byte-Sektoren führt die 32-Bit-Sektoradressierung zudem zu der bekannten Größenordnung von rund 2 TiB als praktische MBR-Grenze.

GPT und UEFI gehören zu einer späteren Generation. GPT verwendet GUID-basierte Partitionseinträge und redundante Metadaten; UEFI lädt Programme aus einer EFI-Systempartition statt ausschließlich eines winzigen MBR-Bootcodes. Moderne Windows-Systeme verbinden diese Technik mit x86-64, Secure Boot und wesentlich größeren Datenträgern. Diese Mechanismen werden hier nur als Fortsetzung eingeordnet, nicht rückwirkend zum DOS-Modell erklärt.

Multiboot: mehrere Systemgenerationen auf einer Maschine

Der Übergang zwischen DOS, Windows 9x und NT führte häufig zu Multiboot-Systemen. Eine FAT-Partition konnte DOS und Windows 9x tragen, während Windows NT/2000 zusätzlich NTFS-Volumes nutzte. Bootmanager mussten die passende Startumgebung wählen, und Laufwerksbuchstaben konnten je nach System unterschiedlich erscheinen.

Multiboot ist technisch reizvoll, aber archivisch anspruchsvoll. Ein Installationsprogramm kann Bootsektoren oder aktive Partitionen verändern, ein älteres System versteht neuere Dateisysteme nicht, und Reparaturtools sehen möglicherweise nur einen Teil der Umgebung. Deshalb gehören Partitionsschema und Bootmanagerzustand zur Sicherung, nicht nur die sichtbaren Dateien.

Emulation und Virtualisierung als heutiger Zugang zu DOS und altem Windows

Alte PC-Software lässt sich heute häufig über Emulatoren oder virtuelle Maschinen zugänglich halten. Vollständige PC-Emulation kann CPU, Chipsatz, Grafik, Sound und Massenspeicher historischer Maschinen nachbilden. Virtualisierung nutzt dagegen stärker die reale CPU und stellt virtuelle Geräte bereit. Beide Wege sind nützlich, beantworten aber andere Fragen als Originalhardware.

Ein DOS-Spiel in einer emulierten Sound-Blaster-Umgebung kann funktional erhalten sein, ohne Timing, Monitorbild oder reale ISA-Hardware exakt abzubilden. Eine alte Windows-Installation in einer virtuellen Maschine kann Dateien und Programme zugänglich machen, während originale Treiber für reale SCSI- oder Grafikkarten bedeutungslos werden. Deshalb sollte eine virtuelle Rekonstruktion als eigene Archivfassung dokumentiert werden.

Datensicherung: Dateien, Systemzustand und sektorgetreue Images

Für DOS-Systeme konnte eine Dateikopie oft erstaunlich viel retten, weil Installation und Konfiguration transparenter waren. Trotzdem reichten Dateien allein nicht immer: Bootsektor, Partitionstabelle, versteckte/systemnahe Dateien, Dateireihenfolge bestimmter Bootkomponenten oder Kopierschutz konnten wichtig sein. Sektorgetreue Images erhalten deshalb einen anderen Informationsumfang als normale Backups.

Windows verschärfte diese Unterscheidung. Registry, offene Dateien, NTFS-Rechte, Dienste, Bootdaten und installierte Treiber bilden einen Systemzustand, der nicht mit einer simplen Kopie von C:\ gleichzusetzen ist. Für Archivzwecke sind deshalb drei Ebenen sinnvoll: unveränderte Nutzdaten, logische Dateisicherung und ein dokumentiertes Datenträgerimage. Prüfsummen und eine Beschreibung der Hardwarekonfiguration gehören dazu.

Die operative Backup-Praxis wird auf datensicherung-und-backups.htm und backups.htm vertieft.

Systematische Fehlersuche: erst Schicht, dann Detail

PC-Fehler werden schneller verständlich, wenn die betroffene Schicht bestimmt wird. Kein POST ist kein Dateisystemfehler. Ein BIOS-erkanntes Laufwerk ohne bootfähige Partition ist kein Kabelproblem. Ein DOS-Boot mit Absturz beim Laden eines Treibers ist etwas anderes als ein Windows-Kernel-Fehler. Ein Win32-Programmfehler bedeutet nicht automatisch instabile Hardware.

1. Strom und POST: erreicht die Maschine reproduzierbar die Firmwarediagnose?
2. Firmwareerkennung: stimmen RAM, Laufwerke, Controller und Bootreihenfolge?
3. Bootmedium: wird MBR/Bootsektor erreicht und der korrekte Systemloader gefunden?
4. DOS-/Treiberphase: tritt der Fehler vor oder nach CONFIG.SYS/AUTOEXEC.BAT auf?
5. Windows-Start: betrifft der Fehler VMM/9x, NT-Kernel, Treiber, Dienst oder grafische Shell?
6. Anwendung: ist ein einzelnes Programm betroffen oder das gesamte System?
7. Datenträgerzustand: liegen Lesefehler, Dateisystemschäden oder nur Konfigurationsfehler vor?

„Beim PC ist ‘geht nicht’ keine Diagnose. Erst die Boot- oder Betriebsschicht macht aus dem Symptom einen Fehlerbereich.“

Wiederherstellung: Bootdiskette, Safe Mode, Recovery Console und Offline-Arbeit

Die Werkzeuge veränderten sich mit der Systemgeneration. DOS-Systeme ließen sich häufig über eine saubere Bootdiskette, SYS, FDISK, FORMAT, CHKDSK oder herstellerspezifische Diagnosewerkzeuge untersuchen. Windows 9x ergänzte abgesicherten Modus, Startprotokolle und Reparaturmöglichkeiten, blieb aber eng mit DOS-Werkzeugen verbunden.

Windows 2000/XP brachte NT-spezifische Wiederherstellungswege wie Recovery Console, Last Known Good, Ereignisprotokolle und NTFS-Prüfung. Für Archivsysteme ist heute oft die Offline-Arbeit besser: Datenträger zunächst sichern, dann Analyse und Reparatur an einer Kopie durchführen. Eine Reparatur, die direkt auf einem alternden Originaldatenträger schreibt, kann unwiederbringlich mehr verändern als der ursprüngliche Fehler.

A2386SX-25: die PC-Welt als Hardwarebrücke im Amiga 2000

Im SSLXY-Archiv ist der Amiga 2000 mit A2386SX-25 ein besonders klarer Übergangspunkt. Die PC-Welt erschien dort nicht erst als späterer Ersatz für den Amiga, sondern bereits als zusätzliche Architektur innerhalb eines Big-Box-Amiga. 80386SX-PC-Hardware, PC-Software und Janus-Vermittlung existierten neben dem Amiga-System.

Diese Konstellation macht den Plattformwechsel historisch interessanter. DOS und PC-Software waren nicht plötzlich „die neue Welt“, sondern längst technisch bekannt. Der spätere Wechsel zu eigenständigen Windows- PCs veränderte vor allem Schwerpunkt, Leistung, Peripherie und Alltagssoftware. Die A2386SX-25-Seite bleibt deshalb Hardware- und Bridgeboard-Tiefenakte; diese Seite erklärt die PC-Systemlogik, auf die das Board traf.

Vom Parallelbetrieb zum eigenständigen Windows-PC

Der konkrete Wechsel von Amiga- zu PC-zentrierter Arbeit gehört auf pcshift.htm. Für die technische Einordnung ist entscheidend, dass dieser Übergang nicht nur eine andere CPU oder ein anderes Gehäuse bedeutete. Treibermodell, Dateisystem, Entwicklungswerkzeuge, Netzwerksoftware, Browser, Datensicherung und Peripherieorganisation veränderten sich gleichzeitig.

Der später dokumentierte Sony VAIO PCV-R702 steht für diese Windows-PC-Phase. Der Dell Precision M50 von 2002 markiert anschließend eine mobile Workstation-Linie. Die heutige x86-64-Welt ist technisch weit von DOS entfernt, trägt aber weiterhin zahlreiche historische Schichten mit: Laufwerksbuchstaben, x86-Kompatibilität, Teile des Win32-API-Modells, MBR-Unterstützung und jahrzehntelang gewachsene Dateiformate.

Amiga und PC: nicht „besser oder schlechter“, sondern andere Systemlogik

Ein direkter Vergleich zwischen klassischem Amiga und DOS-PC führt schnell in falsche Ranglisten. Technisch interessanter sind die Unterschiede. Der Amiga bündelte Grafik, Audio, DMA und Betriebssystem enger um eine definierte Plattform. Der PC setzte stärker auf austauschbare Erweiterungskarten, BIOS-Konventionen und eine wachsende Kompatibilitätslandschaft vieler Hersteller.

Unter AmigaOS waren Exec, Message Ports, Libraries, Devices und die Custom Chips zentrale Denkmodelle. Unter DOS dominierten BIOS-/DOS-Interrupts, direkte I/O-Ports, TSRs, Segmentierung und knappe konventionelle Speicherbereiche. Windows verschob den PC später zu APIs und Treiberschichten, während NT eine deutlich strengere Systemtrennung etablierte. Beide Welten zeigen, wie stark Softwarearchitektur durch die zugrunde liegende Hardwaregeschichte geprägt wird.

Die Amiga-Seiten amigaos-exec.htm, amiga-dos.htm und amiga-ocs-ecs-aga.htm bilden dafür die Gegenperspektive.

Historische PCs erhalten: Hardware, Software und Konfiguration gemeinsam

Ein alter PC ist nicht vollständig dokumentiert, wenn nur Gehäuse und CPU bekannt sind. BIOS-Version, Mainboard, Chipsatz, RAM, Steckkarten, IRQ/DMA-Konfiguration, Laufwerke, Controller, Kabel, Partitionierung, Dateisystem, DOS-/Windows-Version, Treiber und Konfigurationsdateien bilden gemeinsam den Zustand.

Besonders wichtig sind Installationsmedien und Treiber. Eine seltene ISA- oder frühe PCI-Karte kann elektrisch funktionsfähig sein und ohne den passenden Treiber praktisch unbrauchbar bleiben. Deshalb gehören Disketten, CD-ROMs, Handbücher, Jumperpläne, BIOS-Images und Registrierungs- beziehungsweise Konfigurationsdaten als eigenes Archivmaterial zur Hardware.

• Datenträger zuerst sichern: alternde Festplatten und Disketten nicht durch unnötige Schreibvorgänge belasten.
• Konfiguration fotografisch und textlich erfassen: Steckplätze, Jumper, Kabel und Kartenpositionen dokumentieren.
• Softwarestand festhalten: DOS-/Windows-Version, Service Packs, Treiber und zentrale Anwendungen erfassen.
• Images und Dateien getrennt bewahren: sektorgetreues Abbild plus zugängliche Dateikopie.
• Virtuelle Rekonstruktion getrennt kennzeichnen: Emulation ist ein Arbeitszugang, nicht das Originalsystem.

Technischer Stand 2026

Die frühen DOS- und Windows-Eigenschaften auf dieser Seite werden als historische Systemzustände behandelt, nicht als aktuelle Empfehlungen. Microsoft stellt die Originalquellen von MS-DOS 1.25, 2.0 und 4.0 heute selbst zu Referenzzwecken bereit; dadurch lässt sich die frühe DOS-Architektur unmittelbar gegen Quelltext prüfen. Moderne Windows-Dokumentation führt die NT-Grundstruktur weiterhin mit Executive, Kernel und HAL als getrennten Kernbausteinen fort.

Dateisysteme werden ebenfalls versionsbezogen eingeordnet. FAT12, FAT16, VFAT und FAT32 gehören zur langen FAT-Linie; NTFS folgt einem anderen Metadaten-, Rechte- und Journalingmodell. exFAT ist eine spätere Fortentwicklung der FAT-Familie und wird hier nur als spätere Einordnung erwähnt, weil die Kernseite den Übergang von DOS zu Windows NT dokumentiert.

Moderne Rechner verwenden typischerweise UEFI, GPT, x86-64, PCI Express, NVMe und wesentlich strengere Treiber-/Sicherheitsmodelle. Diese Technik ersetzt die historischen Schichten nicht als Archivwissen. Gerade die Rückwärtskompatibilität der PC-Welt erklärt, warum Begriffe wie BIOS, MBR, Laufwerksbuchstaben, Win32, x86 und FAT bis heute in Werkzeugen und Fehlersituationen auftauchen.

Was die PC-, DOS- und Windows-Linie über Systemtechnik zeigt

Die wichtigste Lehre dieser Plattformgeschichte ist die Bedeutung von Schichten. Ein PC besteht nicht aus „Windows“, ein DOS-Rechner nicht aus COMMAND.COM und ein NT-System nicht aus der grafischen Shell. Firmware, Bootcode, Dateisystem, Kernel, Treiber, Dienste und Anwendungen können jeweils unabhängig funktionieren oder scheitern.

Die zweite Lehre ist Rückwärtskompatibilität als technische Last. Viele seltsame Eigenschaften des PCs sind verständlich, sobald bekannt ist, welche ältere Software oder Hardware dadurch weiter funktionieren sollte. 640-KiB-Grenzen, A20-Gate, Legacy-IRQ, Laufwerksbuchstaben, 8.3-Namen, MBR und Win32 sind keine zufällige Sammlung, sondern Spuren dieser Entwicklung.

Die dritte Lehre ist Dokumentation. Ein sauber notierter IRQ oder Treiberstand war 1993 genauso wertvoll wie heute eine Firmwareversion, ein Dateisystem-Hash oder ein reproduzierbares Backup. Systeme werden nicht durch Größe beherrschbar, sondern durch nachvollziehbare Zustände.

„Vom 640-KB-DOS-Rechner bis zum modernen Windows-PC bleibt dieselbe Regel: Erst die Schicht bestimmen, dann den Fehler suchen.“

Querverweise im SSLXY-Archiv

• SSLXY-Hauptseite
• Übergang zur PC-/Windows-Welt
• Hardware-Landkarte
• Systemübersicht
• Amiga 2000 mit A2386SX-25
• AmigaDOS
• AmigaOS Exec
• Sony VAIO
• Dell Precision M50
• Schnittstellen
• Schnittstellen und Kabel
• Laufwerke und Diskettenstationen
• SyQuest
• Netzwerk und Heimvernetzung
• Modems und Dataphon
• Modems, Mailboxen und Protokolle
• Mailboxen und BBS
• Software- und Tool-Alltag
• Datensicherung und Backups
• Werkstatt und Diagnose