Diskussion:DOS-Extender

IBM und falsches Aufziehen des Themas

An Y2KBug. Du hast jetzt alles bezüglich dem Adressraum wieder rückgängig gemacht, es fehlt also die wichtigste Information und was da steht ist inhaltlich falsch.

• https://de.wikipedia.org/w/index.php?title=DOS-Extender&diff=prev&oldid=263338101

Wir müssen daher mal reden, denn offenbar ist dir nicht bekannt, wie das beim PC funktioniert.

1. 16-Bit-Architektur mit 8-Bit-Daten- ist für den Artikel überhaupt nicht relevant. Weil für das Thema nur der 20-Bit Adressraum und der verfügbare Speicher relevant ist. Den Rest kann man weglassen, ist unnötiges lesen und lenkt den Leser nur vom Wesentlichen ab. Die 16-Bit Architektur bestimmt zwar, wie der Speicher dann tatsächlich im Real Mode adressiert wird, nämlich Segmentadresse + Offset, ist aber ausreichend im Real Mode Artikel beschrieben, für diesen Artikel nicht nötig und bläht ihn auch nur auf. Das kann man also weglassen, da es den Artikel vereinfacht.

Über die genauen Formulierungen können wir gerne reden... ‣Andreas•⚖ 10:42, 15. Jan. 2026 (CET)

2. Du zieht die Einleitung falsch auf, der erste Fehler ist, du beginnst mit DOS:

In 86-DOS, das ab 1981 als PC DOS mit...

Weder der maximal adressierbare Speicher von 1 MiB, noch die 640 KiB werden von DOS bestimmt, sondern von der Hardware. Korrekt wäre es also die Einleitung mit der Hardware zu beginnen, also dem 20 Bit-Adressbus des 8088. Damit sind in Dezimalschreibweise und für dich als Laien in linearer Adressdarstellung die Adressen 0 bis 1048575 verfügbar.

Das ist so nicht ganz richtig. Xenix, OS/2 und Windows NT beispielsweise -- alles u.a. Betriebssysteme für den 386-PC und Kompatible -- haben dieses Limit nicht. Und wenn du dich auf den 8088 im originalen IBM PC versteifst: auch da kann Xenix/86 den oberen Speicherbereich (UMA) nutzen, der DOS -- nicht nur auf einem 8088/8086, sondern auch auf 80286+ weiterhin -- verwehrt beleibt.

(Nachtrag: ist so gemeint, dass DOS selbst mit diesem Speicher nichts anzufangen weiß. Einzelne DOS-Programme, die LIM-EMS-aware sind, natürlich schon, wenn die Treiber geladen sind. Xenix/86 hingegen nutzt diese Speichererweitungskarten vom Betriebssystem aus für Swapping und Caching, oder eine RAM-Disk.) ‣Andreas•⚖ 10:49, 15. Jan. 2026 (CET)

Die letzten beide sind ja auch keine Real Mode Betriebssysteme. Die verwenden alle den Protected Mode. Beim 286 verwenden Xenix und OS/2 dessen PM.

Zu Xenix/86 was du schreibst ist falsch. Auch für Xenix/86 ist dieser Adressraum für Hardware reserviert. Es ist aber wie bei DOS möglich Expanded Memory einzublenden und diesen Speicherbereich dann durch Treiber explizit zu nutzen. Dafür ist dann aber ein entsprechender Treiber notwendig und das muss dem OS entsprechend mitgeteilt werden. Einfach mal in diesen Adressbereich reinschreiben ohne aushandeln ist nicht drin. Bei DOS ist das übrigens genau das gleiche, da heißt es dann EMS.

Es bleibt also für hardware reservierter Adressraum. Selbstverständlich kannst du als Hardware eine Memory Expander Karte anschließen und die sprichst du dann über ein kleines in der Regel 8 bis 64 KiB Fenster in diesem Adressraum, nach dem das alles per Treiber eingerichtet wurde, an.

Was Xenix aber im Gegensatz zu DOS und dessen EMS kann ist diesen Speicherbereich für den Userspace transparent darzustellen. Die Verwaltung des RAM führt nämlich bei Xenix als Unix OS das Betriebssystem durch, die Anwendungen merken also gar nicht, ob sie konventionellen RAM oder RAM auf einer Memory Expander Karte nutzen. Bei DOS müssen Anwendungen dieses RAM über EMS explizit nutzen, also dafür programmiert sein. --~2026-31976-7 (Diskussion) 18:54, 15. Jan. 2026 (CET)

Xenix/286 nützt keinen Protected Mode. Wie Xenix/86 ist es ein Real-Mode-Betriebssystem.

Ja, auch bei Xenix/86 und /286 ist der obere Speicher (UMA) für Geräte (BIOS, Hardware) reserviert. Wie unter DOS kann Xenix auf diesen Speicher nicht als RAM zugreifen, außer eben über Speichererweiterungskarten. Es ist eines der wenigen Unix-Betriebssysteme -- eigentlich das einzige, das mir bekannt ist -- das das kann. Speichererweiterungskarten liegen unter Unix sonst meist brach.

Genau das gleiche wie EMS bei DOS? Nein. Xenix nutzt diese Speicherkarten von sich aus für Swapping, Caching oder eine RAM-Disk. Dafür braucht Xenix keine Treiber. Das ist es, was Xenix bieten kann -- DOS hingegen kennt kein Swapping. Caching kam erst mit SMARTDrive, und auch das ist nicht "das, was DOS bietet", sondern optional. Xenix, ein Unix, kann Swapping und Caching von sich aus.

Und was hat das jetzt mit DOS-Extendern zu tun? Xenix: Xenix/386 ist auf den Protected Mode erweitert worden. Programme können daher auf Xenix/386 mehr Speicher als die 640k (unter Xenix/86 und /286) nutzen. Dafür braucht es keinen Extender.

Und bei DOS? Ach ja, DOS läuft auf 386+ genau gleich wie auf einem 80286: nämlich genau gleich wie auf 8088/8086. Der einzige Unterschied sind Speicher-Manager, aber das bringt den Programmen nichts. UMBs sind erst ab DR DOS 5.0 bzw. MS-DOS 5.0 für ausgesuchte Treiber und TSRs nutzbar, und auch das erst ab 386 und alles unter der 1-MB-Grenze -- was der Limitierung von 8088/8086 entspricht, aber die MMU des 386 verwendet. HIMEM ist ein Trick, das ab dem 80286 ein bisschen Speicher über der 1-MB-Grenze anzapfen kann, aber eben nur als Trick, und mit unendlich vielen Problemen behaftet. Das ist alles ganz anders als es Xenix macht.

Zusammengefasst: DOS-Extender sind spezifisch für DOS auf dem 80286/80386+ und haben zwar mit dem ursprünglichen Design-Limit des IBM PC und PC/XT zu tun, sind aber DOS-spezifisch. Xenix geht einen ganz anderen Weg. ‣Andreas•⚖ 23:50, 15. Jan. 2026 (CET)

Nein, das ist falsch. Xenix 286 ist ein Protected Mode Betriebssystem. Kein Real Mode System, informiere dich mal richtig! Selbstverständlich benötigt Xenix Treiber, weil jede RAM Erweiterungskarte anders sein kann. Dafür sind Treiber erforderlich, die auf die Eigenheiten der Hardware Rücksicht nehmen. Es reicht schon ein anderer Controllerchip oder eine andere Ansteuerung oder Aufteilung der RAM Bänke und schon ist ein anderer Treiber erforderlich. Auch bleibt das Bank Switching identisch bzw. einblenden in den UMB identisch, weil für Hardware Erweiterungskarten kein PM erforderlich ist und auch keiner verwendet wird. Xenix ist auch nicht das gleiche wie EMS, das habe ich dir bereits mit dem Hinweis gesagt, das Xenix das alles transparent für die Anwendungen macht und die Hoheit über den Speicher hat, nicht die Anwendung. Treiber sind aber trotzdem notwendig.

Zu UMBs, das ist falsch. RAM Expander Karten waren schon in frühen MS-DOS Versionen nutzbar, auch da hast du Treiber benötigt und die Software musste das logischerweise unterstützten. Danach kam der LIM Standard, und EMM386 ab MS-DOS 4.0. Ab DR DOS 3.40 macht DR DOS vom HMA Gebrauch, so heißt das kleine Stückchen Speicher oberhalb des UMB. Der HMA kann bereits ab dem 286 genutzt werden und er liegt außerhalb des Adressbereich des 8088. Bei Digital Research machte man das hochladen deswegen um im konventionellen RAM mehr Platz zu schaffen. Ab DR DOS 5.0 machte man für DOS auch von den UMBs aus RAM Expander Karten oder aus RAM aus oberen Speicherbänken Gebrauch. Microsoft zog dann mit MS-DOS 5.0 nach.

Logisch ist Xenix anders als DOS, es wurde nichts Gegenteiliges behauptet. Das konntest du in meinen vorherigen Kommentaren bereits herauslesen, wo klar steht, dass Xenix den Speicher den Anwendungen transparent zur Verfügung stellt. --~2026-34697-1 (Diskussion) 20:14, 16. Jan. 2026 (CET)

Okay. Zu Xenix/286: ohne Beleg wird das offensichtlich nix.

Zu den DOS-Extendern: willst du mir etwa sagen, dass diese *nicht* spezifisch für DOS (MS-DOS-kompatibel) und den IBM PC ab dem 286 (PC/AT; und später 386, meist Klone oder PS/2) sind?

‣Andreas•⚖ 20:53, 16. Jan. 2026 (CET)

Beleg hast du gerade bekommen.

Zu den DOS-Extendern, ich weiß echt nicht was du immer liest, nichts derartiges was du mir jetzt unterstellen willst. steht in meinem Kommentar. Es wäre mal sinnvoll, wenn du das geschriebene verstehst. --~2026-34697-1 (Diskussion) 21:51, 16. Jan. 2026 (CET)

3. Der zweite Fehler ist, du redest von RAM, nicht von Adressraum, viel wichtiger ist aber der Adressraum, weil der das Limit setzt und die Einteilung notwendig macht. In diesen Adressraum kannst du Speicher "einhängen". Beim ersten IBM PC waren das 16 KiB bis maximal 256 KiB. D.h. spätestens ab Adresse 262144 war da keine RAM Zelle mehr, die ein Datum speichern konnte. Spätere Rechner kamen mit mehr RAM, bspw. in Form von 256 KiB großen Speicherbausteinen und auf das Mainboard passten vielleicht 2-4 Stück davon. Womit du auf einem solchen Rechner 4 * 256 KiB verbauen hättest können. Das wären rein rechnerisch somit 1 MiB, nutzen kannst du diese 1 MiB aber nicht, weil du auch noch Adressen bzw. einen Adressbereich benötigst, mit dem du das BIOS ROM und andere Peripheriegeräte ansteuern kannst. Die Information, die du gelöscht hast. Deswegen wurde der Adressraum in einen RAM Bereich und einen Hardwarebereich aufgeteilt. Der RAM Bereich heißt in DOS konventionelles RAM und der Hardwarebereich heißt UMB bzw. UMA. (Randbemerkung: Gute Mainboard Chipsätze verlagerten den nicht nutzbaren RAM in einen Adressbereich oberhalb der Adresse 1048575 und stellten im Adressbereich des UMB eine Hardwarelogik zur Verfügung, die bspw. von einem Expanded Memory Treiber verwendet werden konnte und so bspw. ein 8 KBit bis maximal 64 KiB großes EMS Speicherfenster in den Adressbereich des UMB einblendete um so das restliche RAM, das in den Adressbereich oberhalb von Adresse 1048575 doch noch nutzen zu können, aber das ist ein Randthema, auf das ich jetzt nicht weiter eingehen will, daher zurück zum Wesentlichen.)

Zum Adressraum: auch Xenix/86 konnte zwar bereits Swapping, und war wie DOS theoretisch auf 1 MB Adressraum limitiert -- aber ohne Hardware-Speicherkarten (wie später LIM-EMS unter DOS) konnte auch Xenix die oberen 386k nicht verwenden. (Also auch hier geht es nicht um Adressraum, sondern um RAM.)

Aber auch bei den DOS-Extendern geht es nicht um Adressraum, der in Form eines virtuellen (eventuell nicht vorhandenen) Speichers (wie bei Auslagerungsdateien) verwendet werden soll, sondern darum, tatsächlich verfügbaren RAM für DOS-Programme verfügbar zu machen. Es ist also verkehrt herum: moderne Betriebssysteme haben einen virtuellen Adressraum, wie etwa Windows oder OS/2, und das kann dann auch Speicher einer Festplatte sein, der per Auslagerungsdatei einem Programm "angeboten" wird. (Weitergesponnen: kommt der physische RAM an diese Grenze, bekommt das Betriebssystem ein Problem, siehe etwa die 3-GB-Barriere bei 32-Bit-Systemen.) Unter DOS hingegen gibt es das nicht: nur physisch vorhandener RAM wird genutzt -- bzw. *nicht* genutzt, weil DOS keinen Zugriff darauf hat. Der DOS-Extender macht nun diesen Zugriff AUF RAM (nicht wegen des Adressraums, aber natürlich über den Adressraum, den der Protected Mode bietet) möglich.

Die Segmentierung, die du ansprichst, ist ein technisches Detail. Man kann den vorhanden RAM so oder so nutzen. Das ist eine Vorgabe der Architektur. Auch Xenix/86 konnte keinem Prozess mehr als 64k pro Segment, und auch nur maximal 640k insgesamt zuweisen.

Die Speichererweiterungen per EMS, die du ansprichst, mit UMBs usw., sind entweder (Option A) Hardware-Speicherkarten (später nach dem LIM-Standard), die aber auch auf einem 8088/8086 bereits unter DOS verfügbar sind -- und, interessanterweise, auch unter Xenix/86 sowie unter Xenix/286, das immer noch im Real Mode lief -- oder (Option B) emulierter Speicher nach der bereits etablierten Expanded Memory Specification (EMS), damit Programme, die dieses Protokoll nutzen, weiterhin funktionieren (was auch bei Xenix/286 der Fall ist: das ist im Grunde dasselbe wie Xenix/86 -- der Kompatibilität wegen; erst Xenix/386 nutzte den Protected Mode; das einzigen 16-Bit-Protected-Mode-Betriebssystem, das ich kenne, ist OS/2 1.x).

Zusammengefasst: Das wären rein rechnerisch somit 1 MiB, nutzen kannst du diese 1 MiB aber nicht, weil du auch noch Adressen bzw. einen Adressbereich benötigst, mit dem du das BIOS ROM und andere Peripheriegeräte ansteuern kannst. stimmt zwar grundsätzlich auf dem 8088, aber auch auf dem 286+ weiterhin unter DOS. Erst OS/2 1.x kann die vollen 16 MB eines 286 nutzen, und 386-Betriebssystem wie Windows NT, Xenix/386, BSD/386 (Unix am PC) und Linux können den vollen Adressraum eines 386 nutzen. Das ist unter DOS nicht möglich, und erst ab dem 386 mit MMU kann ansatzweise das erste Megabyte überhaupt ausgeschöpft werden (obwohl die Hardware zu diesem Zeitpunkt bereits weit mehr bietet).

‣Andreas•⚖ 10:42, 15. Jan. 2026 (CET)

Du benötigst immer Adressraum um RAM anzusprechen. Selbst wenn du es durch ein kleines Fenster im für Hardware reservierten Bereich (in DOS UMB genannt) machst, wie bei Expanded Memory Karten oder dem VRAM der Grafikkarte, deren RAM du per Bank Switching dann umschalten kannst, um den passenden RAM Bereich in das Fenster im UMB Bereich einzublenden.

Der Adressraum ist IMMER vollständig vorhanden, weil er durch die CPU als adressierbarer Bereich, nämlich die 2^20-1, definiert ist. Die CPU arbeitet mit Adressen, und deren Raum ist der Adressraum. Ob dahinter aber RAM steckt oder Hardware oder einfach gar nichts, ist eine ganz andere Geschichte. Und beim IBM PC geht das definitiv nutzbare RAM per Festlegung eben nur bis zu diesen 640 KiB, alles darüber hinaus ist für die Hardware reservierter Bereich und logischerweise kann diese Hardware auch eine Memory Expander Karte sein oder die Fähigkeit über den Mainboard Chipsatz mitbringen und so dann zusätzlichen RAM bereitstellen. Dieses RAM muss dann aber gesondert per Treiber bereitgestellt werden. Bei Xenix erfolgt das für die Anwendungen transparent, bei DOS nicht. In beiden Fällen geht es zuverlässig ohne Quick and Dirty nur über Treiber, ohne Treiber hast du nur diese 640 KiB.

Und auch bei DOS Extendern benötigst du Adressraum. Der große Unterschied ist nur, dass die im Protected Mode einen viel größeren Adressraum zur Verfügung haben. Beim 286er kannst du dank 24 Adressleitungen im PM bis zu 16 MiB an RAM ansprechen, wenn du soviel einbaust und der Chipsatz das unterstützt, beim 386DX und später sind es bis zu 4 GiB an RAM. Der 386SX hat nur 24 echte Adressleitungen, weswegen es bei dem auch nur maximal 16 MiB sind.

Bei 386er kommt noch hinzu, dass die Abbildung virtuell ist und du somit auch langsamen Festplattenspeicher als RAM missbrauchen kannst, wenn der DOS Extender das unterstützt. Windows 3.x kann das im Enhanced Mode. Für die Anwendung ist das dann virtueller Adressraum.

Es ist also nicht verkehrt herum, du hast immer Adressraum, es geht nie ohne. Und du musst mit dem Adressraum anfangen, weil er im Real Mode aufgeteilt ist und der obere Bereich für Hardware reserviert ist.

Zu:

Unter DOS hingegen gibt es das nicht: nur physisch vorhandener RAM wird genutzt -- bzw. *nicht* genutzt, weil DOS keinen Zugriff darauf hat.

Auch DOS nutzt Adressraum, wenn es auf Peripheriegeräte zugreifen soll. Ich glaube bei dir liegt ein Verständnisproblem vor. Adressraum ist nicht immer RAM, das sind zwei verschiedene Dinge. Stell dir normales RAM als weitere Hardware Peripherie vor, die ohne Treiber gleich genutzt werden kann, dann wird es vom Verständnis für dich sicher einfacher. Und beachte hierbei, dass du dich auf den Adressbereich oberhalb der 640 KiB nicht verlassen kannst, wenn du Daten in RAM speichern willst, weil dort ohne Aushandlung über Treiber auch kein RAM sein kann und darf.

Zu:

sind entweder (Option A) ... oder (Option B) ...

Das hatte ich bereits alles geschrieben. Es gibt keinen Grund das erneut zu erwähnen.

erst Xenix/386 nutzte den Protected Mode

Das ist falsch. Bereits Xenix 286 nutzte den Protected Mode und konnte so bis zu 16 MiB ansprechen. --~2026-31976-7 (Diskussion) 19:33, 15. Jan. 2026 (CET)

Alles benötigt und nutzt Adressraum. What's your point? Geht es beim DOS-Extender um Adressraum? Adressraum ist nur ein Mittel zum Zweck: wie willst du ohne den nötigen Adressraum den Speicher, der zwar vorhanden aber eben außerhalb des verfügbaren Adressraums liegt, ansprechen? Geht es DOS-Extendern um Adressraum? Nein, es geht um physisches RAM. Beim Swapping geht es um Adressraum. Die Auslagerungsdatei -- das ist Adressraum pur: hier wird nicht RAM sonder Adressraum geboten. Bei DOS-Extendern wird aber RAM genutzt -- explizit!

Zu Xenix/286: Hast du eine Quelle dafür? Ich kann nur finden, dass Xenix/286 im Real Mode läuft...^ref

‣Andreas•⚖ 23:59, 15. Jan. 2026 (CET)

Der Punkt ist, dass du mit dem Adressraum anfangen musst. Das habe ich oben geschrieben und dort bereits ausführlich erklärt.

Du kannst nur Speicher ansprechen, der innerhalb des Adressraum liegt oder wie bei RAM Expander Karten dann per Bank Switching in den Adressraum eingeblendet wird. Also bspw. irgendwo im UMB ein 64 KiB Fenster, der zum RAM der Expander Karte führt. Die hat vielleicht 4 x 64 KiB drauf. Per Befehl an den Treibern schaltest du dann von den 64 KiB auf den nächsten KiB Block per Bank Switching um, falls du diesen ansprechen willst, erst dann ist er im verfügbaren Adressraum verfügbar. Also nur das, was eingeblendet ist.

Bei DOS Extender wird dein Adressraum größer, weil du in den Protected Mode schaltest und zusätzlich das A20 Gate auf enabled schaltest. Deine Aussage, dass es nicht um Adressraum geht ist falsch.

Und Swapping ist ein ganz anderes Thema, da brauchst du für echtes Swapping die MMU des 386 und Page Tables (VTables), was dir dann in einem virtuellen Adressraum sowohl RAM als auch Speicherplatz auf der Festplatte einblenden kann.

Die Auslagerungsdatei -- das ist Adressraum pur: hier wird nicht RAM sonder Adressraum geboten.

Was für ein Unsinn! Eine Auslagerungsdatei ist ein Speicherplatz der per MMU und vtables in einen virtuellen Adressraum eingeblendet wird. Eine Auslagerungsdatei ist nicht selbst Adressraum, wie du hier behauptest.

Nochmal, du hast das nämlich leider immer noch nicht verstanden. Adressraum und Speicherplatz sind zwei völlig verschiedene Dinge. Adressraum wird durch die CPU limitiert, Speicherplatz durch den Adressraum und das, was du an Speicher einbaust.

Du solltest mal deine eigene Quelle richtig lesen. Er schreibt da in Deutsch übersetzt:

Soweit ich weiß, liefen Unix-Systeme außer Xenix in den 1980er Jahren, bevor sie Unterstützung für den 386er und den 32-Bit-Protected-Mode erhielten, 16-Bit-Programme (und auch das Betriebssystem) im Real Mode statt im 16-Bit-Protected-Mode. Bitte korrigiert mich, falls ich falsch liege.

Verkürzt heißt die Aussage:

Soweit ich weiß, liefen Unix-Systeme außer Xenix ...., bevor sie Unterstützung für .... 32-Bit-Protected-Mode erhielten, ... im Real Mode statt im 16-Bit-Protected-Mode. ...

Dem ging es also um andere Unix-Systeme, nicht um Xenix. Xenix 286 wurde für den 286er angepasst und verwendet dort den Protected Mode.

Zu Xenix/286: Hast du eine Quelle dafür?

Klar, das ist ganz einfach. Es steht im Xenix 286 Device Driver Guide drin, zwar wird der Protected Mode nicht explizit namentlich erwähnt, aber man erkennt es bereits an den Privilege Levels des Kernels und Userspaces auf Seite 14 (bzw. 2-4)

• http://www.bitsavers.org/pdf/intel/system3xx/xenix-286/174393-001_XENIX_286_Device_Driver_Guide_Nov84.pdf

Darin heißt es im Abschnitt Privilege Levels:

Programs executing on an iAPX 286 processor have an associated privilege level. The privilege level ranges from 0 (most privileged/most trusted) to 3 (least privileged/least trusted). All kernel code and device driver code executes at level 0 (most privileged), allowing access to all of memory and execution of any iAPX 286 instruction. All other code in a XENIX 286 system executes at level 3 (least privileged), which restricts memory access and instruction execution to protect user processes from each other and to protect the kernel from user processes.

Dazu muss man wissen, x86 Prozessoren haben im Protected Mode bzw. ab dem 286 vier Privilege Levels. Von Ring 0 bis Ring 3. (Und mit der Einführung der modernen Virtualisierung kam noch einer dazu, aber das ist jetzt nebensächlich und kannst du im entsprechenden WP Aritkel nachlesen.) Xenix 286 macht davon Gebrauch, das steht auch in dem zitierten Text und bietet somit echten Hardwareschutz für den Kernel und die Treiber, die beide im Level 0 bzw. Ring 0 laufen. Die Programme laufen in Level 3 bzw. Ring 3. Im Real Mode würde es so etwas nicht geben, weil es dort keine Privilege Level und Hardwareschutzmechanismen gibt. --~2026-34697-1 (Diskussion) 21:48, 16. Jan. 2026 (CET)

4. Festgelegt wurde die Aufteilung durch IBM, die haben in ihrem Technical Reference Manual nämlich einfach den Adressbereich von 655360 (in Hex: A0000h) bis einschließlich 1048575 (in Hex: FC000h) reserviert. Dieser Bereich konnte daher von keinem Betriebssystem für Programme genutzt werden, weil er als reserviert gilt und jederzeit sich in diesem Adressraum Hardware befinden könnte.

• https://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf

Siehe Seite 2-27 und andere. Damit ist das auch mit einer Quelle belegt. Das wurde also nicht von den Entwicklern von DOS entschieden, noch ist dafür die CPU verantwortlich. Auch dass die CPU 16 Bit ist, spielt hier keine Rolle.

Toll. Danke für den Link. Das es technisch so umgesetzt wurde, war vorher schon klar, die Technical Reference bestätigt das nur nochmals. Es ist aber etwas ganz anderes, wer das damals so entschieden hat. Folgendes hat Bill Gates einmal dazu gesagt: The machine was going to be 512K at one point, and we kept pushing it up ...^ref Ein solches Design war damals aber absolut üblich: [...] there has to be RAM and ROM in a system, and I/O (like video) is usually something to be put in-between. [...] even the template for the IBM PC, the Apple II [...] did it that way ... it even features a similar split 6:2 for RAM vs. I/O and ROM. For the PC it's 5:3.^ref

‣Andreas•⚖ 10:43, 15. Jan. 2026 (CET)

Nein, was soll da anders sein? IBM hat es so festgelegt, alle die zu IBM kompatibel sein wollten, folgten dieser Reservierung bzw. Einteilung des Adressbereich. Der untere Adressraum für bis zu 640 KiB RAM, der Adressraum oberhalb für Hardware (was auch Memory Expander Karten sein können). Was Bill Gates dazu sagte spielt keine Rolle, er hat das nicht entschieden und das auch nicht festgelegt, das war IBM. Willst du jetzt den konkreten Mitarbeiter haben, der bei IBM diese Entscheidung getroffen hat oder was? Entscheidungen werden im Namen des Unternehmens getroffen, daher ist IBM völlig ausreichend als Urheber.

In der Frühphase des IBM PC gab es Unternehmen, die MS-DOS mit ihrem eigenen x86 PC auslieferten, bei dem dass dann anders gemacht wurde und dort konnte die angepasste MS-DOS Version für Anwendungen dann auch mehr ansprechen, die waren aber zum IBM PC nicht voll kompatibel und haben sich daher nicht durchgesetzt. Die Kompatibilität zum IBM PC gab den Ton an.

--~2026-31976-7 (Diskussion) 19:47, 15. Jan. 2026 (CET)

Dann lass es doch bitte einfach weg...

(Es ist einfach so, egal wer es wo wann festgelegt hat. Bill Gates sagt ja selbst, dass man (Microsoft?) die ursprüngliche 1:1-Aufteilung 512k-512k für "RAM" (Arbeitsspeicher) und "ROM" (system, I/O) "gepusht" hat... (Wer? Wann? Wirklich nur IBM? Oder doch auf Druck von Microsoft?)

‣Andreas•⚖ 00:02, 16. Jan. 2026 (CET)

Es ist nicht egal. Im Artikel schreibst du:

In 86-DOS, das ab 1981 ...Dieser Speicher wurde auf 640 KiB für Betriebssystem und Programme und 384 KiB für den Zugriff auf Geräte wie das BIOS oder den Grafikspeicher aufgeteilt. Dadurch steht auf IBM-PC-Kompatiblen unter DOS nur 640 KiB „Konventioneller Speicher“ zur Verfügung.

Das suggeriert, dass man das so bei der Entwicklung von DOS entschieden hätte. Das ist Öl für die, die Bill Gates in ihrer Ahnungslosigkeit immer den Satz

"640K ought to be enough for anybody"

unterstellen und es ist auch falsch. Weil das nicht durch DOS entschieden wurde, sondern durch die Reservierung des Adressraums durch IBM. Besonders betroffen von dem Problem sind die Leute, die früher von den Heimcomputern kamen und bspw. beim Amiga mit RAM Erweiterung 1 MiB RAM zur Verfügung hatten. Gerade die wundern sich immer und verstehen das nicht. Die ganze Lästerei basiert auf Ahnungslosigkeit, deswegen muss man das wissen und hier richtig im Artikel erklären.

Auch deine Aussage im Artikel, dass 384 KiB RAM den Geräten und dem BIOS zur Verfügung gestellt werden, ist falsch. Das habe ich dir ja hier jetzt schon mehrfach erklärt warum das falsch ist. Vor allem in dem Abschnitt, den du übersprungen hast wird das deutlich, aber du willst wohl nicht dazulernen.

Also nochmal:

1. Es gibt nur 640 KiB RAM im Adressraum des Real Modes das man ohne Gefahr nutzen kann.

2. Der Adressraum oberhalb der 640 KiB Adressgrenze bis diese 1 MiB Adresse ist für Hardware reserviert.

3. Es gibt RAM Erweiterungskarten und später Mainboardchipsätze, die RAM in diesem Bereich mit passenden Treibern einblenden können.

4. Diese 384 KiB RAM in diesem reservierten Bereich werden beim 286 vom Chipsatz, sofern der das kann über den 1 MiB Adressbereich verschoben (Remapping) oder sind, da wo Hardware eingeblendet ist, nicht zugänglich.

5. Alle 4 Punkte sind nicht DOS spezifisch, sondern sind eine Folge der Aufteilung bzw. Reservierung des Adressraums durch IBM.

6. Wenn der 286 Chipsatz dieses Remapping kann, dann liegen diese 384 KiB per Hardware oberhalb des 1 MB Adressraums, womit sich im UMB kein RAM befindet. Mit für den Mainboard Chipsatz passenden UMB-Treiber kannst du dieses RAM in DOS dann in Form eines kleinen EMS Fenstern in den UMB Bereich wieder einblenden. Andere Real Mode Betriebssysteme könnten mit passenden Treibern vergleichbares leisten, wie die dann den RAM den Anwendungen zur Verfügung stellen, ist deren Sache.

7. Beim 386er gibt es für das, was beim 286er in Punkt 6 beschrieben ist, eine universelle Lösung. Diese kann dann in DOS mit dem EMM386 Treiber oder den Alternativen, wie QEMM386 auf die gleiche Weise in den UMB eingeblendet werden. Wenn das nicht gemacht wird, dann gilt auch da, im UMB ist kein RAM. Generell ist ohne diese Einblendung somit auf allen 386er und späteren Prozessoren im UMB kein RAM, du hast nur 640 KiB im unteren Adressraum.

Hast du das jetzt endlich verstanden?

Auch dein Satz in der Einleitung ist falsch, du schreibst im Artikel:

In 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, und mit MS-DOS vermarktet wurde, steht nur 1 MiB Arbeitsspeicher zur Verfügung.

Es gibt keinen 1 MiB Arbeitsspeicher, es sind nur 640 KiB, der Rest ist ein Minenfeld (siehe oben). Und deswegen wäre es hier richtig vom Adressraum zu sprechen. Also zu schreiben, dass nur ein Adressraum von 1 MiB zur Verfügung steht. Das wäre korrekt, dann kann man die Aufteilung erklären, womit dann klar ist, warum es nur 640 KiB Arbeitsspeicher im Real Mode sind (+ die Nebensächlichkeit, wenn man mit Memory Expanderkarten arbeitet oder einen 386er hat und Bereich in den UMB einblenden kann).

Damit wird nämlich auch gleich klar, warum es in DOS so Krücken wie EMS Speicher gibt. Und von da kann man dann zu den Protected Mode DOS Client Programmen übergehen, die DOS Extender nutzen. --~2026-34697-1 (Diskussion) 22:34, 16. Jan. 2026 (CET)

5. Hardware benötigt Adressraum und ist über Adressen im Adressraum zugänglich, wird also in den Adressraum eingeblendet. Die Größe des Adressraums im Real Mode sind durch diesen 20-Bit breiten Adressbus bestimmt und die Größe des Adressraums, der für Hardware reserviert ist, ist beim IBM PC und seinen kompatiblen durch obiges Dokument zementiert. An den PC angeschlossene Hardware wird ausschließlich nur über Adressen und Adressräume angesteuert, denn einen anderen Raum kennt die CPU nicht. Da gibt es keine Nebenkanäle.

Wenn die CPU also die LEDs einer 7-Segment Anzeige ansteuern soll, dann geschieht dies über Adressen auf der die Leitungen zu der Segmentanzeige geschaltet sind. Theoretisch könnte man das direkt machen, auf dem PC würde man das im Normalfall indirekt über die serielle Schnittstelle machen, die ist aber ebenfalls nur über Adressen in diesem Adressraum zugänglich. oder in Modern eben über USB usw.. Moderne Hardware macht allerdings von Adressbereichen weit über der Adresse 1048575 Gebrauch und benötigt dann aber den 32 Bit Protected Mode oder besser zum Ansteuern. Eine LED kann man also durch Senden eines Bits bzw. genauer Bytes, denn die CPU arbeitet mit Bytes, an eine für die LED festgelegte Adresse im UMB beim Real Mode ein und ausschalten, den Zustand der LED kann man in der Regel aber nicht auslesen, daher dient diese Segmentanzeige nicht als Speicher, sie kann nicht wie RAM genutzt werden. Es ist in diesem Fall nur ein Weg in nur eine Richtung durch schreiben einer 0 oder 1 in eine Adresse wird die LED ein- oder ausgeschaltet. An dieser Stelle, die von hardware reserviert ist, kann also kein RAM sein und ist auch kein RAM und wenn da RAM wäre, weil der RAM Baustein groß genug wäre, dann wäre das RAM an dieser Adresse nicht verfügbar.

Dann gibt es noch andere Hardware, die in den UMB Bereich eingeblendet wird. Das ist z.B. ganz anderes RAM. Z.B. das RAM einer Soundkarte auf der Platine einer Soundkarte für deren Wavetable Instrumentendatenbank. Auch diese wird über den Adressraum geladen. Damit man eine große Wavetable Instrumentendatenbank haben kann, z.B. 4-8 MiB, nutzt man logischerweise nur einen kleinen Adressraum um das RAM zu laden. Das Laden kann dann bspw. seriell oder über Bank-Switching oder vergleichbaren Techniken erfolgen. Im UMB braucht man dann einen Adressbereich von bspw. 1 bis 32 KiB, je größer, desto schneller geht das mit dem Laden oder man setzt eine 32 Bit CPU voraus, hat damit einen Adressraum von 2^32-1 und lädt das Wavetable RAM über den Protected Mode. Lösungen gibt es viele. Die viel gängigere Hardware, anstatt das das Wavetable RAM einer Soundkarte, ist allerdings das RAM der Grafikkarte, das ist separates RAM, das ist kein RAM des Hauptspeichers. Daher nennt man das VRAM. Auch das VRAM der Grafikkarte wird in den Adressbereich im UMB eingeblendet. Bei VGA beginnt das bei Adresse 655360 (A0000h), also direkt über dem 640 KiB Block. Wenn du also in diesen Bereich Nullen oder Einsen schreibst, dann schreibst du nicht in den Hauptspeicher, sondern in das RAM der VGA Karte. Dieser begrenzte Adressraum für die VGA Karte ist übrigens auch der Grund, warum du am PC am Anfang nur einen Monitor anschließen konntest. Es ging mit Herkules Karten zwar noch ein zweiter, weil Herkules Karten mit ihrem Herkules Modus in einem anderen Adressraum arbeiteten, aber VGA war das nicht. Mehr Monitore bzw. Bildschirmflächen oder unter der Haube VRAM Fenster, die SVGA Modi und besser erlaubten, wurden erst möglich, als man Grafikkarten und 32 Bit Betriebssysteme einsetze, die Adressräume weit oberhalb der Adresse 1048575 im Protected Mode und besser verwendeten und dort Adressräume zur Verfügung stellte, hinter denen das VRAM war, mit der man mehrere Bildschirmflächen eines Mulitmonitor Setups mit Inhalt füllen konnte.

Anstatt RAM kann so Hardware auch einfach nur Register haben, die in diesen Adressbereich eingeblendet sind. Die Register steuern dann bspw. einen Chipsatz auf der Peripheriekarte und sind Teil von diesem. Bei Grafikkarten kann das bspw. das auswählen des VGA Modus sein, das dann über die Register des Grafikchips geschieht. Auch diese Register benötigen Adressen im Adressbereich der von der x86 CPU zugänglich ist. Intern kann ein Chipsatz auf der Peripheriekarte zwar noch weitere Register, einen eigenen Prozessor und andere Dinge haben, aber in diesem Fall geht um Register des Chipsatzes, die von außen aus zugänglich sind, also von der x86 CPU über deren Adressraum beschrieben werden können.

Ebenso kann man Datenleitungen über den Adressraum zur Verfügung stellen. Die Serielle Schnittstelle ist mit Nullmodemkabel an die ein zweiter PC angeschlossen ist, eine solche Datenleitung. Und wenn du Daten zum zweiten PC senden willst, dann schreibst du mit der x86 CPU des ersten Rechners in einen bestimmten Adressbereich an dem dann diese serielle Schnittstelle sitzt. Auch dieser Adressbereich ist nicht für RAM zugänglich.

Und dann gibt es noch ROM. Das BIOS ist bspw. ein solches. Das wird beim PC ganz am Ende in den Adressbereich eingeblendet, also vor Adresse 1048575+1. Beim ersten IBM PC war das 8 KBit groß und lag somit bei Adresse 1040383 bis einschließlich 1048575. Reserviert hat IBM allerdings 48 KiB, so das spätere BIOS ROMs größer werden durften. ROM ist nur lesbar, nicht beschreibbar. Auch in diesem Adressbereich gibt es somit kein RAM (mal abgesehen von so Lösungen wie Shadow RAM) und auch dieser Adressbereich ist nicht für RAM vorgesehen. (Anmerkung: Ja, später kam noch EPROM, EEPROM, Flash usw. dazu, das theoretisch beschreibbar ist, aber in der täglichen Nutzung gilt das als nur lesbarer Adressbereich) Peripherie Hardware kann eigenes ROM haben. Die Grafikkarte hat bspw. ein Video ROM, die SCSI Karte hat ein eigenes ROM für ihre Firmware. Eine TV Karte hat ROM für ihre Firmware usw.. All das benötigt im Adressbereich des UMB einen Adressraum, der nicht für RAM benutzt werden kann.

Und zum Schluss gibt es noch Memory Expander Karten, die dann auch in den UMB Adressbereich kleine 8-64 KiB große Fenster eingeblendet haben, über die man dann mit einem EMS Treiber in DOS Speicher für DOS Real Mode Programme zur Verfügung stellen kann, bei denen dann die Nutzung von EMS Speicher berücksichtigt wurde. Beim 386er und später wird solcher EMS Speicher dann unter Nutzung eines EMM386 Treibers und des RAM oberhalb der Adresse 1048575 in den für Real Mode Programme zugänglichen UMB Adressbereich eingeblendet. EMS Speicher kann allerdings nur für Daten genutzt werden, nicht für Programmcode. Die Verwendung des EMS RAM, inkl. dem Bankswichting, wenn man mehr als 64 KiB nutzen will, wird über den EMS Treiber ausgehandelt. Auch die Adresse, wo die Software diesen RAM Bereich im UMB finden kann, wird so über den Treiber mitgeteilt.

Hab ich jetzt nur überflogen, habe aber nichts daran auszusetzen. Scheint OK zu sein -- sehe ich auch so. ‣Andreas•⚖ 10:42, 15. Jan. 2026 (CET)

6. So, jetzt weißt du, warum im Normalfall Speicher oberhalb der 640 KiB auf einem IBM PC bei Real Mode Betriebssystemen nicht genutzt werden kann. Beachte hier, dass ich hier Betriebssystem schreibe, nicht DOS. Man könnte ein komplett anderes Betriebssystem schreiben, das kein DOS ist, im Real Mode funktioniert und immer noch diese 640 KiB Grenze hätte, weil IBM das so durch die Reservierung des Adressbereichs festgelegt hat.

Ja, das sehe ich genauso. Auch Xenix/86 und Xenix/286 haben das 640k-Limit. ‣Andreas•⚖ 10:42, 15. Jan. 2026 (CET)

Xenix 286 hat kein 640K Limit, da es im Protected Mode läuft und bis zu 16 MiB ansprechen kann

--~2026-31976-7 (Diskussion) 19:52, 15. Jan. 2026 (CET)

Tut es das? Sicher? ‣Andreas•⚖ 00:03, 16. Jan. 2026 (CET)

Ja, Quelle siehe oben. --~2026-34697-1 (Diskussion) 22:40, 16. Jan. 2026 (CET)

7. Und damit kommen wir zum Thema falsches Aufziehen. Du fängst mit DOS an. DOS legt das aber nicht fest, sondern die Hardware. Korrekt wäre also mit dem Adressraum der CPU anzufangen, dann den für die Hardware reservierten Adressraum (nicht RAM!) zu erklären um dann auf die 640 KiB zu kommen, die man dann als RAM für Betriebssysteme und Software nutzen kann. Und erst ab da, kannst du dann mit DOS anfangen.

Gibt es denn DOS-Extender auch unter Xenix/86? Ich dachte, die DOS-Extender wären exklusiv für MS-DOS-Kompatible auf IBM-PC-Kompatiblen? Und, wie bereits in Punkt 3 zum Adressraum erläutert, ging es den DOS-Extendern nicht um den Adressraum per-se, sondern um physichen RAM, der sonst brachlag, weil DOS damit nichts anfangen konnte. Ja, auf IBM-Kompatiblen, und damit nicht allgemein auf MS-DOS. (OEM MS-DOS lief z.B. auch auf dem PC-98 oder dem FM-TOWNS, aber dort gab es bzw. brauchte es *keine* DOS-Extender!)

Wo liefen DOS-Extender:

1. auf MS-DOS und kompatiblen DOS
2. auf IBM-PC-kompatiblen Computern

Wozu wurden DOS-Extender verwendet:

1. um physischen RAM nutzen zu können

NICHT um virtuelle Speicherverwaltung zu betreiben. Wenn man das will, sollte man nicht für DOS sondern für modernes Betriebssystem schreiben, wo es wirklich um Adressraum geht. DOOM gab es als DOOM95 ja auch für Windows 95, wo das nun tatsächlich zutrifft. (Off-topic:) Aber auch da wieder: Die DOOM95-Portierung stammte von Microsoft zur Werbung (engl. promotion) von DirectX, da damals die meisten Spiele weiterhin für DOS geschrieben wurden. Warum? Weil dort, per DOS-Extender, ohnehin der vorhandene RAM -- der ja nicht nur als Adressraum, sondern real benötigt wurde! -- nutzbar war, und per direkter Ansteuerung der Hardware (Grafikkarte) Windows nur im Weg war. Erst mit DirectX konnte Microsoft langfristig auch Windows zur Spieleplattform machen, aber noch nicht mit der ersten Version, da da noch viel fehlte...

‣Andreas•⚖ 10:43, 15. Jan. 2026 (CET)

Du willst doch die Geschichte erklären, wie es unter DOS zu den DOS Expandern kam. Dazu gehört zu erklären, wie es in DOS überhaupt zu einem 640 KiB Limit kam, die Ursache beginnt also bei der Hardware und dem Adressraum, der entsprechend aufgeteilt bzw. durch IBM reserviert wurde.

NICHT um virtuelle Speicherverwaltung zu betreiben.

Da scheint mir wieder ein Verständnisproblem bei dir vorzuliegen. Adressraum hat erst einmal nichts mit virtueller Speicherverwaltung zu tun. Adressraum ist das, was die CPU über Adressleitungen und Register adressieren kann. Im Real Mode ist dieser Adressraum nicht virtuell und trotzdem vorhanden.

DOOM nutzte auch in DOS, dank des DOS Extender einen 32 Bit großen, in dem Fall virtuellen, Adressraum, und war daher entsprechend einfach nach Windows 95 zu portieren. Es wurde noch in Zeiten von Windows 3.1 zuerst für WinG geschrieben, dann für Direct2d, was dann DOOM95 für Windows 95 wurde. Neben der Anpassung an WinG und später Direct2d war noch eine Änderung von VCPI nach DPMI nötig.

Zum Offtopic. Genaugenommen wurde es zuerst für WinG geschrieben um Windows, bereits zur Zeit von Windows 3.x generell als Spiele OS zu bewerben. Es war damals ja noch nicht einmal klar, ob Windows 95 einfach nur Windows 4.0 heißen würde. Im Doom Artikel hat vor 1-2 Jahren ein nicht so schlauer Laie wieder mal einen Revert durchgeführt und in seiner vollen Unkenntnis der Sachlage den Revert mit der Lüge "Trägt nichts zum Artikel bei" oder so ähnlich vermerkt. Ich habe mir damals gedacht, was für ein ...., es aber dann so gelassen, weil ich keine Zeit hatte, das erneut zu korrigieren. Ich hatte es ja schließlich bereits korrigiert, momentan steht da halt viel falsches drin. Und die Übersicht leidet auch, das war ein weiterer Grund das zu bearbeiten. Ich hatte es schön in Unterabschnitte eingeteilt und geordnet. Die Bewerbung von WinG mittels eines funktionstüchtigen DOOM Ports, der bereits unter Windows 3.1 lief führte dann dazu, dass bereits einige Spiele erschienen, die dann unter Windows 3.1 unter Nutzung von WinG liefen. Die erste Version von Civilization 2 ist ein mir bekanntes Beispiel das WinG nutzt und unter Windows 3.1 läuft. Erst mit dem Add-On ist dann Windows 95 erforderlich. So richtig offiziell als eigenständiger Retail Release wurde dann Doom95 für Windows 95, zu dem Zeitpunkt gab es dann aber schon eine Reihe von weiteren Spielen für Windows 95 die Direct2d oder WinG nutzten. Das Doom Video mit Bill Gates bewirbt auch diese spätere Doom95 Version, die Direct2D verwendet.

und per direkter Ansteuerung der Hardware (Grafikkarte) Windows nur im Weg war. Erst mit DirectX konnte Microsoft langfristig auch Windows zur Spieleplattform machen,

Wer wollte, der konnte bereits WinG vor DirectX bei Windows 3.x nutzen und hatte damit einen sehr direkten und somit performanten, aber nicht HW beschleunigten Zugang unter Umgehung von GDI zur Grafikhardware. Was WinG allerdings noch fehlte, war der Rest, wie DirectInput, DirectSound, DirectPlay etc. für die Soundausgabe, Eingabe oder Netzwerkfunktionen. Das kam erst alles unter dem Sammelbegriff DirectX mit Windows 95.

Hier gibt es eine unvollständige Liste an WinG Spielen, wobei der Eintrag bezüglich Civ2: Test of Time falsch ist. Test of Time erschien erst nach Civ 2 und erschien für Windows 9x, nicht für Windows 3.x. Es war das Hauptspiel Civ 2, das WinG nutzte. Also ein Fehler in dieser Datenbank, leider inzwischen hinter einer Loginwall:

• https://www.pcgamingwiki.com/wiki/List_of_WinG_games

--~2026-31976-7 (Diskussion) 20:20, 15. Jan. 2026 (CET)

Adressraum hat immens mit der virtuellen Speicherverwaltung zu tun: 2. Satz aus Virtuelle Speicherverwaltung (Hervorhebung von mir): Der virtuelle Speicher bezeichnet den vom tatsächlich vorhandenen Arbeitsspeicher unabhängigen Adressraum, der einem Prozess vom Betriebssystem zur Verfügung gestellt wird.

Auf einem 32-Bit-System mit z.B. 1 MB physisch verbautem RAM kann ein Betriebssystem jedem Prozess (unter DOS ist jedes Programm genau ein Prozess) entweder 2 GB oder 3 GB Arbeitsspeicher virtuell zur Verfügung stellen. Die Mechanismen dazu heißen Paging und/oder Swapping.

Genau das macht ein DOS-Extender NICHT. Im Gegenteil erlaubt der DOS-Extender einem Programm (ja: Protected Mode) den Zugriff auf physisch vorhandenen RAM sicher -- aber nicht als reinen Adressraum im Sinne des Wortes, denn das könnte auch per Paging vorhandener Arbeitsspeicher sein. Der DOS-Extender hingegen macht den physischen RAM adressierbar. Klar ist das auch ein Adressraum, denn wie sonst kann der Prozess auf den physischen RAM zugreifen? Aber eben nicht auf den gesamten Adressraum, außer der PC hat zufällig wirklich 4 GB verbaut (oder 3 GB oder 2 GB oder irgendetwas dazwischen, da es ja auf jeder Hardware nach Abzug der Hardware-Adressen von BIOS, VRAM, I/O etc. nur noch unterschiedlich großen freien Adressraum gibt).

‣Andreas•⚖ 00:12, 16. Jan. 2026 (CET)

Ich muss das Kommentar jetzt leider wegen dem Bearbeitungsfilter zerlegen:

Adressraum hat immens mit der virtuellen Speicherverwaltung zu tun:

--~2026-34697-1 (Diskussion) 23:15, 16. Jan. 2026 (CET)

(Vielleicht mag er die Segment Offset schreibweise nicht, daher anders geschrieben)

Nein, eben nicht. Die Adressen

Segment = 0000 Offset = 0000

bis

Segment = FFFF Offset = 0010 (also 0xFFFF0 bzw. 1048575 )

sind der Adressraum des 8086 und 8088. --~2026-34697-1 (Diskussion) 23:18, 16. Jan. 2026 (CET)

0000 0000 bis 0xFFFF FFFF (2^32-1 = 4294967295) ist der Adressraum des 386 und alle folgenden 32 Bit x86 CPUs.

Verbaust du bei einem 8086 nur 512 KiB RAM, dann ist dein Adressraum immer noch

Segment = 0000 Offset = 0000

bis

Segment = FFFF Offset = 0010

groß.

Bei allen Adressen oberhalb von

Segment = FFFF Offset 0010

hast du beim 8086 einen Wrap-Around in den unteren Bereich, wieder angefangen bei

Segment = 0000 Offset = 0000.

Das liegt daran, weil der Wrap-Around hardwaremäßig durchgeführt wird. --~2026-34697-1 (Diskussion) 23:20, 16. Jan. 2026 (CET)

Ja, es ist die Segment Offset Schreibweise mit Doppelpunkt, an der sich die Zensurfunktion stört.

Die Null, gefolgt von x Schreibweise mag die Zensurfunktion auch nicht.

Zu:

Auf einem 32-Bit-System mit z.B. 1 MB physisch verbautem RAM ...

ist der Adressraum des 32-Bit Systems immer noch 2^32-1 groß, also --~2026-34697-1 (Diskussion) 23:23, 16. Jan. 2026 (CET)

Hex Adresse 8 mal die Null bis Hex Adresse 8 mal F. (was für ein sch* die Zensurfunktion)

Nochmal, Adressraum ist kein RAM. RAM liegt, wie jede andere Hardware im Adressraum.

Kein Wunder warum du das nicht verstehst, dass die Einleitung im Geschichteabschnitt umgeschrieben werden muss. --~2026-34697-1 (Diskussion) 23:24, 16. Jan. 2026 (CET)

Hier kannst du den Kommentar unzerstückelt lesen:

Wikipedia:Bearbeitungsfilter/415#So etwas kriegt euer Filter nicht gebacken --~2026-34697-1 (Diskussion) 23:25, 16. Jan. 2026 (CET)

8. Zwar lies ich den Anfang mit der DOS Einleitung, aber den Rest hatte ich alles korrigiert, was du wieder auf falsch durch deinen revert gestellt hast. Daher schlage ich jetzt vor, dass du diesen ersten Absatz neu bzw. umschreibst. Fang mit dem Adressraum der CPU ab, gehe dann auf den von IBM reservierten Adressraum für die Hardware ein, um dann am Ende zu den 640 KiB und zum Schluss zu Real Mode Betriebssystemen wie DOS zu kommen. Im Prinzip müsste man dann noch über Real Mode DOS Programme sprechen, die über die Krücke EMS Speicher und XMS Speicher etwas mehr RAM nutzen können, aber immer noch Real Mode DOS Programme sind. Erst danach kommen die Protected Mode DOS Programme, die einen DOS Extender nutzen. --~2026-29971-4 (Diskussion) 21:37, 14. Jan. 2026 (CET)

Nein, mit dem Adressraum fangen wird sicher nicht an. Siehe Antworten zu Punkt 3 und Punkt 7.

Wenn du da noch etwas richtigstellen willst, dann danke ich dir, aber bitte eher weniger als mehr. Es wäre besser, wenn wir uns nicht zu sehr in unbelegte Details verstricken würde. Und damit meine ich nicht, dass das Detail nicht belegbar wäre -- ja, der 8088 hatte 20 Adressleitungen, da hast du vollkommen recht -- sondern unbelegt im Zusammenhang mit DOS-Extendern. Genau wie deine Fixierung auf den Protected Mode. Ja, der spielt eine wesentliche Rolle, damit das alles funktioniert. Aber die Programme wurden nicht WEGEN des Protected Modes geschrieben, sondern der Protected Moder ermöglicht den Programmen, das zu tun, was sie tun wollen: Zugriff auf mehr RAM.

‣Andreas•⚖ 10:42, 15. Jan. 2026 (CET)

Und diese Antworten sind nunmal falsch. Lies dir dazu meine heutigen Antworten durch. Und unbelegt ist da gar nichts, du hast einen Quellenbeleg erhalten.

Zu "sondern unbelegt im Zusammenhang mit DOS-Extendern.". Was ist denn das jetzt für ein Quatsch! Es gibt eine reale Geschichte, wie es zu den DOS Extendern kam, die waren dazu da, den Anwendungen mehr Speicher ohne Krücken zur Verfügung zu stellen und den Anwendungen zumindest bei den DOS Extendern für 386er und später einen linearen Adressraum zur Verfügung zustellen, was die Programmierung und übrigens auch die Portierung deutlich erleichterte und auch der Performance zugute kam, was übrigens mit dem Windows Artikel belegt ist, den ich bereits im Artikel als Quelle eingefügt hatte.

Aber die Programme wurden nicht WEGEN des Protected Modes geschrieben

Derartiges habe ich nirgends behauptet. Meine Aussage ist, dass diese Programme, die dann DOS Extender nutzen, keine Real Mode Programme mehr sind und diese Aussage ist vollkommen richtig. Das gilt sowohl für die Anwendungen, die 286er DOS Extender nutzen, als auch Anwendungen die 386er DOS Extender nutzen.

Vorteile der DOS Extender gegenüber Real Mode Anwendungen oder Real Mode Anwendungen mit Krückenlösungen wie EMS :

1. Linearer Adressraum bei den 32 Bit DOS Extendern (nur ab 386)
2. Wegen 1 viel einfachere Programmierung. In C konntest du bspw. wirklich ein Array erzeugen, das größer als 64 KiB war und hast dafür keine compilerspezifischen Schlüsselwörter wegen den 64 KiB Segmentgrenzen benötigt, die nicht Teil des C Standards waren und es nur für die Compiler für den Real Mode gab. Man konnte also standardkonform in ANSI C programmieren. Damit war auch eine Programmierung auf einer ganz anderen Entwicklungsmaschine, die kein DOS und kein PC war, möglich. John Carmack hat das bspw. bei DOOM so gemacht, er kaufte sich eine Indigo SGI Maschine für viel Geld und entwickelte DOOM darauf, bevor er es auf den PC portierte. Der Vorteil, bei Abstürzen des Spiels sparte das reale Zeit, weil das Unix Betriebsystem bei einem Absturz des zu testenden Codes, anders als in reinem DOS, nicht mitgerissen wurde.
3. Wegen 1 viel einfachere Portierung, z.B. vom Amiga auf den PC. Beispiel: Das Spiel "Die Siedler"
4. Viel mehr RAM direkt ohne Krücken nutzbar
5. Weil das RAM ohne Krücken direkt nutzbar ist, läuft die Anwendung im Ergebnis auch viel performanter
6. Mit VESA VBE 2.0 wird es dann bei Spielen so richtig performant, weil der Abstieg und Kontextswitch in den Real Mode um den VGA RAM Bereich zu beschreiben wegfällt.

Du liegst also vollkommen falsch, wenn du glaubst, dass der einzige Vorteil nur im mehr RAM lag. Die DOS Extender hatten weitere reale Vorteile, auch in der Programmierung, Portierung, Performance etc.. Das wird insbesondere auch daran deutlich, das man die 286 DOS Extender relativ schnell übersprungen hat und nur für wenige Anwendungen nutzte. Deiner Meinung war es ja nur RAM, wenn es nur mehr RAM gewesen wäre, wären mit den DOS Extendern für den 286er auch bis zu 16 MiB möglich gewesen, den übersprang man aber recht schnell. Ab ca. 1993 wird das besonders deutlich, da zu dem Zeitpunkt reihenweise DOS Spiele herauskamen, die einen 386 voraussetzten, weil sie so einen 32 Bit DOS Extender nutzen der vieles vereinfachte. Und zwar wechselten diese oft nur wegen dem 32 Bit DOS Extender. Manche Spiele hätte man auch im reiner Real Mode unter Nutzung von EMS realisieren können, oder 286 DOS Extender dafür nutzen können wenn es nur mehr RAM gewesen wäre, der Aufwand wäre aber höher und somit teurer gewesen.

Das lässt sich alles belegen. Das habe ich alles schon hier und da gelesen und nein, ich such dir die Quellen dazu jetzt nicht raus, das kannst du selber machen.

Ich erwarte von dir also immer noch, dass du die Einleitung änderst und mit dem Adressraum beginnst. Immerhin hast du den Revert verursacht und so wie es jetzt steht, kann man das nicht stehen lassen. --~2026-31976-7 (Diskussion) 20:43, 15. Jan. 2026 (CET)

Du vermischt viel zu viel, was nichts miteinander zu tun hat. Etwa EMS. Speicher aus LIM-EMS steht im Grundsatz nur für Daten zur Verfügung. Programme können in diesem Speicher nicht laufen. Per DOS-Extender hingegen laufen im zusätzlichen Speicher Programme -- auch auf dem 286er. Dass sich der linear adressierbare Speicher auf dem 386 natürlich irgendwann in den 1990ern durchsetzte, als auch Windows begann, nur noch auf 386SX oder besser zu laufen, zeigt nur, dass 286-Systeme in den 1990ern verschwanden. Hingegen sind viele Programme um 1990er noch 286-fähig, oder es gab zwei Versionen: AutoCAD und AutoCAD/386 (Release 10: 1988/1989). Auch Lotus 1-2-3 lief noch bis 1990 auch auf 286ern per DOS-Extender:

• Lotus 1-2-3 3.4: 1992
• Lotus 1-2-3 4.0: 1994

Weitere Programme, die mit dem 80286 per DOS-Extender die bis zu 16 MB RAM ausnutzen konnten:

• dBASE IV 1.1: 1989
• MATLAB 2.5: 1989
• Paradox 3.5: 1989
• Mathematica 1.2: 1990
• Borland C++ 2.0: 1991
• Borland C++ 3.0: 1992
• Borland Pascal 7.0: 1992
• WordPerfect 6.0: 1993

Klarerweise wurde immer mehr Software exklusiv für den 386 veröffentlicht. AutoCAD/386 z.B. nutzte VCPI, und das setzte einen 386 voraus. DPMI hingegen hatte wieder Untersützung für den 286-Protected-Mode, und das ersetzte/beerbte ja bekanntlich VCPI.

Die Quintessenz ist aber jene: du kannst schreiben was du willst, aber bitte nur hier auf der Diskussionsseite. Alles, was du in den Artikel packst, musst du belegen. ‣Andreas•⚖ 00:27, 16. Jan. 2026 (CET)

Ich vermische gar nichts, du kannst mir nicht folgen.

Etwa EMS. Speicher aus LIM-EMS steht im Grundsatz nur für Daten zur Verfügung.

Das hast du gut erkannt, das steht in meinem aller ersten Kommentar bereits drin. Da habe ich nämlich geschrieben:

"EMS Speicher kann allerdings nur für Daten genutzt werden, nicht für Programmcode."

Den Rest spar ich mir, denn du scheinst, wie man sehen kann, nicht richtig mitzulesen.

Lies oben Mein Kommentar vom 22:34, 16. Jan. 2026 (CET), sowie das bezüglich dem Adressraum, den ich mehrfach wegen dem Zensurfilter zerstückeln musste, da steht das wesentliche zum Thema Artikelverbesserung drin und weswegen wir hier die Diskussion führen. --~2026-34697-1 (Diskussion) 23:35, 16. Jan. 2026 (CET)

Nachtrag: Kurz und klar: DOS-Extender gibt es für 286 (16-Bit-Protected-Mode, segmentierter Speicherzugriff) und 386+ (32-Bit-Protected-Mods, flat memory). Die Limitierung von 8088/8086 ist da aber nicht mehr vorhanden. Es ist eine Limitierung von DOS, nicht von der Hardware, die der Kompatibilität geschuldet ist. Denn 286-DOS ist quasi OS/2 1.0 -- das ist DOS (mit einem erweiterten API, nämlich dem von OS/2) auf einem 286er. (Nicht vergessen, dass OS/2 1.0 keine grafische Oberfläche hatte und wirklich wie DOS aussah!)

D.h. Für DOS-Extender liegt der Fokus klar auf DOS auf dem IBM PC mit 286/386, nicht auf dem Limit von DOS auf dem 8088/8086. VCPI und DPMI sind quasi das fehlende DOS-API für einen geregelten Zugriff auf den Erweiterten Speicher (XMS). Das ist aber nicht DOS selbst, sondern eine Erweiterung von DOS, so wie man Windows bis Windows 3.x als eine Erweiterung sehen kann. Erweiterungen müssen aber nicht zwangsweise da sein (installiert sein) und auch nicht verwendet werden, damit z.B. MS-DOS als DOS gilt. Und weil das so ist, und weil es konkurrierende (exklusive) Erweiterungen gab, kommt es zu Inkompatibilitäten und Problemen, wenn man mehr als ein Programm nutzen will, eventuell auch noch gleichzeitig (Multitasking). ‣Andreas•⚖ 11:15, 15. Jan. 2026 (CET)

Es ist eine Limitierung von DOS, nicht von der Hardware, die der Kompatibilität geschuldet ist.

Du hast überhaupt nicht verstanden worum es hier geht und redest komplett am Thema vorbei. Es ist die Hardware des Real Mode bzw. später Real Mode genannt, die DOS auf 640 KiB konventionelles RAM beschränkt hat. Wäre der Protected Mode von Anfang an zur Verfügung gestanden oder wäre die CPU gleich 32 Bit gewesen, hätte das erste DOS ganz anders ausgesehen. Dann wäre es nämlich bspw. ein 32 Bit Betriebssystem geworden, in dem man linear bis zu 4 GB an RAM adressieren hätte können.

Logischerweise führt ein Real Mode DOS, das nur 640 KiB konventionelles RAM adressieren kann oder Krücken wie EMS benötigt zu DOS Extendern, die dann im Protected Mode laufen und wesentlich mehr können. Trotzdem musst du bei der Hardware anfangen,weil die festgelegt hat wie DOS aussieht. Und dass es nur 640 KiB und nicht 768 oder 800 KiB, wie bei den zum IBM PC inkompatiblen Rechnern, geworden sind, liegt an der Entscheidung von IBM, den UMB Bereich ab A0000h beginnen zu lassen, also diesen Bereich für die Hardware zu reservieren. Das ist auch belegt.

DOS wurde also so, weil IBM den Bereich so aufteilte und der Adressraum auf 2^20 Adressen auf dem 8088 begrenzt ist. Von da geht man den nächsten Schritt. Und du hast diese Information entfernt und suggerierst nun dem Leser, dass man bei DOS einfach die Grenze willkürlich bei 640 KiB gezogen hat, es DOS bzw. Microsofts Schuld sei, nicht der der Hardware und gehst dann zu den DOS Extendern über. --~2026-31976-7 (Diskussion) 21:11, 15. Jan. 2026 (CET)

Ich fange doch bei der Hardware an: MS-DOS auf dem IBM PC ab dem PC/AT (286).

Nicht: MS-DOS auf dem PC-98.

Auch nicht: MS-DOS auf dem FM-TOWNS.

Auch nicht: Concurrent DOS (von Digital Research, Variante von CP/M) auf dem PC/AT (80286)

Auch nicht: OS/2 1.0

Es scheint mir, als hättest du nicht verstanden, dass die Limitierung von DOS ausgeht. OS/2 1.0 kann DOS-Programme ausführen, obwohl es im Protected Mode läuft. Concurrent DOS ist eine Weiterentwicklung von CP/M, das ursprünglich ein 8-Bit-Betriebssystem war: CP/M (8-Bit) --> MP/M (8-Bit) --> CP/M-86 (16-Bit) --> MP/M-86 (16-Bit) --> Concurrent CP/M‑86 --> Concurrent DOS. Auch Concurrent DOS ist wie OS/2 DOS-kompatibel, aber nur deswegen, weil es im Real Mode läuft. DOS-Extender sind aber nicht für Concurrent DOS geschrieben. Genauso wenig wie sie für Xenix/86 oder /286 geschrieben wurden, OBWOHL diese Betriebssysteme die gleichen Limitierungen wie DOS auf dem PC/AT aufweisen.

Also, bleiben wir bei der Sache. Geht es um die Limitierungen des IBM PC? Jein, denn diese treffen auch auf PC/IX (PC-Unix für den 8086 von IBM), Xenix, CP/M-86, MP/M-86, QNX 1.x, ... zu.

Geht es um die Limitierungen des IBM PC unter DOS? Ja. Aber nicht auf einem 8088/8086 oder 80186.

Geht es um Betriebssysteme für den 80286? Jein. Obwohl die meisten Betriebssystem auf dem 286 weiterhin den Real Mode verwendeten und damit dieselben Limits wie auf dem 8086 haben, geht es nicht um diese Betriebssysteme. Außer OS/2 1.x und wenigen Exoten wie Siemens SINIX-286 (ein PC/AT-Unix) und Intel RMX/286 (ein Echtzeit-Betriebssystem) haben wohl keine der Betriebssysteme wirklich je den Protected Mode des 80286 verwendet. Außer DOS-Extender: 286-DOS-Extender gab es bereits zu Beginn dieser Entwicklung.

Es geht also explizit um DOS, und es geht explizit um das Limit, das geschichtlich vom originalen IBM PC stammt, aber unter DOS auch auf dem 286 (wie bei den meisten anderen Betriebssystemen auch) und 386 (sogut wie alle anderen Betriebssystem haben hier den Schritt zum Protected Mode gemacht) weiterhin besteht.

1. DOS

2. IBM PC

Was passt dir an dieser Logik nicht? ‣Andreas•⚖ 00:54, 16. Jan. 2026 (CET)

MS-DOS ist ein Betriebssystem, keine Hardware.

Es scheint mir, als hättest du nicht verstanden, dass die Limitierung von DOS ausgeht.

Genau das tut es ja nicht und habe ich dir hier schon mehrfach und ausführlich erklärt. Aber du liest ja nicht richtig mit.

Daher gilt auch für diesen Abschnitt:

Lies oben Mein Kommentar vom 22:34, 16. Jan. 2026 (CET), sowie das bezüglich dem Adressraum, den ich mehrfach wegen dem Zensurfilter zerstückeln musste, da steht das wesentliche zum Thema Artikelverbesserung drin und weswegen wir hier die Diskussion führen. --~2026-34697-1 (Diskussion) 23:43, 16. Jan. 2026 (CET)

Noch eine kleine Ergänzung:

OS/2 1.0 kann DOS-Programme ausführen, obwohl es im Protected Mode läuft.

Dazu, für DOS Programme wechselt OS/2 1.0 auf dem 286 zwischen dem Real Mode und Protected Mode hin und her. Es bleibt also nicht ständig im PM. Außerdem kann in OS/2 auf dem 286 nur eine DOS Anwendung zur gleichen Zeit ausgeführt werden.

Siehe dazu:

• https://web.archive.org/web/20170103220718/http://bitsavers.informatik.uni-stuttgart.de/pdf/ibm/pc/os2/84X1434_OS2_Technical_Reference_Volume_1_Sep87.pdf

Seite 36 bzw. 2-10

Der LOADALL Mechanismus für den 286 war damals, als OS/2 1.0 erschien bereits bekannt.

Siehe dazu auch die englische WP Seite LOADALL.

Weitere Infos siehe auch:

• https://www.weather.gov/media/wrh/online_publications/TAs/ta9211.pdf

Auch Concurrent DOS ist wie OS/2 DOS-kompatibel, aber nur deswegen, weil es im Real Mode läuft.

Ja, das hast du richtig erkannt, Concurrent DOS läuft im Real Mode und speichert die nicht aktiven DOS Programme auf Festplatte zwischen. Das sollte jetzt auch kein Problem sein, sie laufen nicht gleichzeitig.

Die nächste Version, Concurrent DOS 286 verwendet aber bereits den Protected Mode, das erlaubt schnellere Wechsel, weil man die DOS Programme im RAM oberhalb der 1 MiB zwischenspeichern kann. Ob man DOS Anwendungen in der 286 Version in einer Software Emulationsumgebung laufen lässt oder wie bei OS/2 in den Real Mode wechselt müsste ich mir genauer ansehen, die gefundenen Artikel sind hier leider etwas diffus. Ersteres würde aber definitiv auf Kosten der Kompatibilität gehen und die Anwendung langsamer laufen, so dass nur sauber programmierte Real Mode DOS Anwendungen, die sauber die DOS API nutzen und keine Hacks nutzen funktionieren würden.

DOS-Extender sind aber nicht für Concurrent DOS geschrieben.

Und das hat auch niemand behauptet. Sowohl bei OS/2, als auch Concurrent DOS 286 oder Windows 3.x Standard Mode kannst du nur Real Mode DOS Programme ausführen, der Protected Mode wird von den genannten Systemen nämlich selbst benötigt. Ein "Highlander", wie ein DOS-Extender würde da nicht reinpassen. Eine Ausnahme gibt es allerdings für 286er konforme DPMI fähige DOS Programme, die würden den DPMI Host von Windows 3.x erkennen und dann den nutzen und somit trotzdem laufen. VPCI fähige DOS Programme oder irgendwelche proprietären Lösungen laufen allerdings nicht. --~2026-34697-1 (Diskussion) 01:22, 17. Jan. 2026 (CET)

Das wird mir langsam zu viel. Du beschreibst nicht die DOS-Extender, sondern die #Speichertypen von PC-kompatiblem DOS. Klar ist die Aufteilung von 640k RAM und 384k ROM eine Vorgabe des IBM PC, aber die Nutzung ab dem 286 und besonders dem 386 ist *keine* Vorgabe des IBM PC. Wie wäre es eine IBM-PC-Hardware-Vorgabe, dass DOS im oberen Speicherbereich UMBs nutzen soll oder muss? Und wo gibt IBM ab dem PC/AT mit 286 vor, dass (und wie) ein Betriebssystem (wie DOS) die HMA zu nutzen hat?

Das Thema hier sind nicht der IBM PC mit 8088-CPU und auch nicht die Speichertypen von DOS, sondern DOS-Extender. DOS-Extender laufen nicht auf dem 8088/8086, und sie nutzen auch keinen UMB, keine HMA: sie laufen wie jedes andere DOS-Programm auch im konventionellen Speicher -- zumindest ein Teil. Der DOS-Extender selbst ist quasi ein Mini-Betriebssystem, das dann die Funktionen und die Verwaltung für ein anderes DOS-Programm übernimmt, das im Protected Mode läuft (unter DOS nicht vorgesehen) und den erweiterten Speicher verwenden kann (unter DOS, abseits vielleicht dem kleinen Teil HMA, nicht vorgesehen).

Ist es eine Hardware-Limitierung, dass ein Betriebssystem auf dem 286 nur 1 MB RAM adressieren kann? Nein: der 286 bietet den Protected Mode, der PC/AT ist also in der Lage, 16 MB RAM (oder virtuellen Speicher) direkt zu adressieren. Jedes Betriebssystem für den 286 kann von diesem Speicher Gebrauch machen. Außer diese Betriebssysteme limitieren sich auf den Real Mode, dann ist es aber eine Limitierung des Betriebssystems. OS/2 ist ein echtes 286-Betriebssystem, das daher dieses Limit nicht aufweist. OS/2-Programme können mehr als 640k RAM verwenden. OS/2-EXE-Dateien haben daher auch ein anderes EXE-Format. Der Kompatibilität mit DOS geschuldet hat OS/2 trotzdem die Fähigkeit, DOS-Programme -- die dann weiterhin auf das DOS-Limit von 640k beschränkt bleiben -- auch auszuführen. DOS geschuldet ist das ganze -- wie unter DOS auch -- nicht Multitasking-fähig. Ja, der 386 hebt sogar dieses Limit von DOS auf, weil hier eine Hardware-seitige Fähigkeit hinzugefügt wurde, extra für den Real Mode. Es ist also kein Wunder, dass die meisten PC-Betriebssystem den 286 übersprungen haben (und ihn wie den 8086 verwendeten).

DOS-Extender sind da, weil DOS eine Limitierung hat, nicht der IBM PC: ab dem 386 könnte DOS in den Protected Mode wechseln und den gesamten RAM nutzen. Xenix hat das gemacht. OS/2 hat das gemacht. All diese Systeme wurden für den 386 erweitert. DOS aber nicht. Daher braucht DOS auch DOS-Extender.

macOS ist ja heute auch nicht auf 8 MB RAM limitiert, weil das seinerzeit die Limitierung des Macintosh II war. Unter System 6 konnte man den 24-Bit-Speicherzugriff mit Zusatzsoftware auf 32-Bit erhöhen. System 7 hatte dann bereits 32-Bit-Speicherzugriff. Das ist also keineswegs eine Limitierung der Hardware, sondern eine des Betriebssystems. Eine neuere Version bzw. die Weiterentwicklung muss sich eben an die neuen Fähigkeiten der Hardware anpassen, seien es nun Geräte, für die Treiber geschrieben werden müssen, oder mehr Speicher.

DOS hat das nicht getan. DOS-Extender waren die Folge.

Bitte bleib beim Thema DOS-Extender, und erkläre mir nicht die DOS-Speichertypen oder den Protected Mode. ‣Andreas•⚖ 09:57, 17. Jan. 2026 (CET)

Zu:

DOS-Extender sind da, weil DOS eine Limitierung hat, nicht der IBM PC

Du hast immer noch nicht begriffen, dass der kritisierte Abschnitt Geschichte heißt, es geht um die Einleitung, die eine Heranführung zu sein hat das steht schon alles oben. Weil es um Geschichte und um die Einleitung geht brauchst du eine Herleitung vom Real Mode und der Hardware, dann über DOS um dann beim DOS Extender zu landen. Man fängt da nicht bei DOS an und schiebt dann sachlich falsch DOS die Schuld in die Schuhe, weswegen es nur 640 KiB könne, wie du es machst. Man zäumt das auch nicht von Hinten mit falschen Baustellen auf. Auf meinen Kommentar oben von gestern 22:34, 16. Jan. 2026 (CET) wo ich dir das alles nochmal ausführlich erläutert habe und warum die Einleitung im Geschichte abschnitt Murks ist, gehst du gar nicht ein.

DOS-Extender sind da, weil DOS eine Limitierung hat, nicht der IBM PC:

Du ziehst es immer noch geschichtlich falsch auf. Warum hat DOS überhaupt eine Limitierung, weil dies dem Adressraum des 8088/86 und der Aufteilung durch IBM geschuldet ist. So musst du es erklären, so musst du anfangen und nicht so, wie du es im Artikel machst, was zu falschen Unterstellungen führt.

: ab dem 386 könnte DOS in den Protected Mode wechseln und den gesamten RAM nutzen. Xenix hat das gemacht. OS/2 hat das gemacht. All diese Systeme wurden für den 386 erweitert. DOS aber nicht.

Nein, das könnte DOS nicht, weil es selbst nur im Real Mode arbeitet, das BIOS benötigt, das auch im Real Mode arbeitet und die Hardware somit nicht ausreichend von der Software abstrahieren kann, wie es OS/2 und Xenix machen und können. Bei letzteren beiden wird der Speicher nämlich vom Betriebssystem verwaltet, bei DOS ist das größtenteils nicht der Fall und liegt in der Verantwortung der Anwendung. Deswegen hast du in DOS solche Krückenlösungen, die eine Folge davon sind, dass DOS kein gescheites Betriebssystem ist.

Bleib DU bitte beim Thema. Es ist schon eine Frechheit, dass du, der die ganze Zeit mit irgendwelchem anderen Kram, von Xenix bis OS/2 ausschweift, oder eine neue Baustelle aufmacht, jetzt sogar mit dem Mac anfängt, und der die Hausaufgaben nicht gemacht hat und nicht weiß, was Adressraum ist und dem man erklären muss, dass Adressraum nicht das gleiche wie RAM ist, mir vorwirfst, nicht beim Thema zu sein. --~2026-37078-9 (Diskussion) 20:23, 17. Jan. 2026 (CET)

Der IBM PC wurde mit DOS als Betriebssystem zusammen von IBM eingeführt. CP/M kam erst später. DOS war durch und durch für diesen PC konzipiert. Du kannst die Geschichte nicht umdrehen, wie es dir passt.

MS-DOS gibt es auch auf anderen PCs, und dort ist das Limit zwar ein anderes, aber die Art und Weise wie DOS diesem Limit Treu blieb ist der Umstand, auf den es ankommt. IBM hat OS/2 als DOS-Nachfolger gesehen. OS/2 war ein 286-Betriebssystem, es kam nur viel zu spät. Als Nachfolger blieb es DOS-kompatibel und erweiterte die IBM-PC-Architektur gleichzeitig, indem OS/2-Programme von diesem Limit nicht mehr betroffen sind.

Xenix ging einen anderen Weg. Du hattest Recht, Xenix/286 war auch durch und durch ein 286-Betriebssystem.

The operating system in question is IBM Personal Computer XENIX 1.0. It’s historically significant, not so much because it was the second OS licensed by IBM from Microsoft, but rather because it was the first protected-mode OS available for a PC (the IBM PC/AT to be exact).^ref

IBM hat Microsoft Xenix 3.0 mit dem IBM PC/AT dann auch als IBM Xenix 1.0 vermarktet. Weil IBM kein 286-Betriebssystem hatte: DOS war bekanntlich keines, und OS/2 war noch lange nicht fertig.

Ob jedoch auch Xenix/86-Programme unverändert unter Xenix/286 liefen, darüber kann ich nichts finden. Für DOS gab es da bereits so viele Programme, dass die Binärkompatiblität sehr wichtig war. Für Xenix, dass der Unix-Tradition folgte, war das weniger wichtig bzw. weniger ein Problem: die Programme wurden (großteils unmodifiziert, oder mit nur sehr wenigen notwendigen Änderungen) einfach für Xenix/286 neu übersetzt (kompiliert).

Einzig, dass Xenix/386 auch 16-Bit-Xenix-Programme ausführen kann, darüber habe ich etwas gefunden:

It’s a classic Unix OS, adapted for PCs. It handles at least up to 16 MB RAM, supports virtual consoles, it uses paging, it is fully compatible with existing 16-bit Xenix binaries, but also supports 32-bit applications. It’s a real 32-bit PC operating system.^ref

Es ist also schon MS-DOS (86-DOS, PC DOS) *und* der IBM-PC-Kompatible, nicht nur der IBM-PC-Kompatible. Das Limit mag von IBM eingeführt worden sein, aber wenn man sich die anderen PCs, die nicht IBM-kompatibel sind, ansieht, so haben die ein ähnliches Limit. Das Limit ist also nicht dem IBM PC, sondern der Architektur basierend auf dem 8086 (oder 8088) geschuldet.

Die Tatsache bleibt, dass auf dem 8088/8086 von IBM und anderen Herstellern ein Limit von 1 MB existierte, dass vom jeweiligen Hersteller für BIOS und Geräte beschnitten wurde. So hatte der DEC Rainbow 100 beispielsweise unter OEM MS-DOS 704-736 kB Konventionellen Speicher für Programme zur Verfügung, während es beim IBM PC eben 640 kB waren. Davon sind auch andere Betriebssysteme betroffen, etwa Xenix/86.

Tatsache bleibt aber auch, dass DOS dieses Limit auf den 80286 und 80386+ mitnahm. Die Speichererweiterungskarten, später als LIM-EMS standardisiert, können zwar für RAM-Disks und Daten verwendet werden, nicht aber für Programme -- der Speicher für Programme blieb somit auf den ursprünglichen konventionellen Speicher limitiert, ob mit oder ohne EMS. Die Versuche, die 640k doch noch etwas besser zu nutzen, beschränken sich auf Gerätetreiber und TSRs, die für DOS beim Start geladen werden: diese nutzen dann UMBs, sehr selten auch die HMA, aber DOS nutzte ab DOS 5.0 (DR DOS 5.0, MS-DOS 5.0) die HMA für Teile von sich selbst. Damit blieb mehr von den 640k für die Programme frei, die sich so auch nicht mit dem kompilizierten Versuch herumärgern müssen, die UMA oder die HMA zu nutzen.

Die UMA steht erst auf dem 386 für DOS zur Verfügung, weil eine MMU verfügbar sein muss. Oder eine Hardware-Karte mit Speicher ("ROM") ian dieser Adresse, wie es auch EMS-Speicherkarten machten. Damit kann auch auf dem 8088/8086 und 80286 DOS diesen Teil der UMA für UMBs nutzen. Und wie bei LIM-EMS ist auch bei XMS der Speicher nur für Cache oder RAM-Disks, also für Daten, nutzbar, oder als LIM-EMS-Emulation, also wiederum für Daten. XMS liegt für Programme brach, und das Limit -- das da heißt: Programme sind auf den Konventionellen Speicher beschränkt -- besteht damit weiterhin.

Das Limit von 640k beim IBM PC oder 704k oder 768k oder sogar 898k bei einigen anderen 8086-PCs mit OEM MS-DOS blieb also für DOS erhalten, und zwar auch auf Nachfolge-Modellen (wenn es die gab) mit 80286 und 80386+. Während Xenix an den Protected Mode des 80286 angepasst wurde und OS/2 spezifisch für den 80286 geschrieben wurde, blieb DOS beim Real Mode und diesem RAM-Limit. Auf dem 80386 wurde die Sache deswegen besser, weil Intel dazugelernt hatte und eine Real-Mode-Emulation in Hardware realisiert hat: den Virtual 8086 Mode.

Was also im Artikel zu DOS-Extendern stehen sollte, ist:

• DOS-Extender sind quasi ein Mini-Betriebssystem, denn nur so ist es Protected-Mode-Programmen überhaupt möglich, unter DOS zu laufen.
• Außerdem müssen die Extender noch sicherstellen, dass sie mit HIMEM und EMM386 und allen anderen DOS-Tricks, sowie mit TopView, DESQview, Windows und anderen unter DOS viel-genutzten Programmen kompatibel bleiben.

Aber das schreiben wir bitte nicht einfach so in den Artikel, sondern mit Quellenangaben (die ich im Moment noch nicht habe!). Und wir müssen nicht den Protected Mode erklären, und auch nicht die DOS-Speichertypen. Die Erklärungen sollen sich auf das beschränken, was DOS-Extender betrifft, und nicht mehr.

Was deine Kritik angeht: In 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, und mit MS-DOS vermarktet wurde, steht nur 1 MiB Arbeitsspeicher zur Verfügung. Das stimmt, denn in 86-DOS bzw. später MS-DOS und PC DOS, und jedem anderen PC-kompatiblen DOS, ist diese 1-MiB-Grenze des Arbeitsspeichers weiterhin vorhanden, auch auf 286ern und 386ern+. Zwar wurde 86-DOS eigentlich gar nicht für den IBM PC geschrieben, sondern für die 8086-Prozessorplatine von SCP. Dennoch ist der große Erfolg wohl als PC DOS und MS-DOS für immer mit dem IBM PC verknüpft. Auch auf der SCP-Platine ist das Limit im Real Mode 1 MiB. Der Satz ist unterteilt: In 86-DOS [] steht nur 1 MiB Arbeitsspeicher zur Verfügung. ist der erste Teil. Weil 86-DOS aber weniger bekannt ist, ist das erklärt: 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, und mit MS-DOS vermarktet wurde ist diese Erklärung.

Allerdings gibt es DOS-Extender *nur* für die PC-Plattform. Das heißt, in weiterer Folge geht es um das Limit auf dem IBM PC, nicht allein um das des 8088/8086. Andere Plattformen, wie der PC-98 oder der FM-TOWNS, haben keine DOS-Extender, obwohl sie ebenfalls 286er, 386er, 486er und noch neuer genutzt haben, und ein OEM-MS-DOS verwendeten.

Das ist die Begründung, warum ich in weiterer Folge nur noch über die PC-Plattform und deren Limits geschrieben habe.

Aber, bitte erkläre mir, warum das falsch ist. Aber bitte erkläre mir nicht die Speichertypen oder den Protected Mode, sondern bleibe bei den DOS-Extendern. Und wenn du einen konkreten Vorschlag machst, was du ändern willst, das aber durch die bisherigen Quellen im Artikel noch nicht begründet ist, dann bring auch bitte diese Quelle gleich hier mit. Denn sonst ist das alles wertlos für den Artikel.

‣Andreas•⚖ 23:48, 17. Jan. 2026 (CET)

Der IBM PC wurde mit DOS als Betriebssystem zusammen von IBM eingeführt. CP/M kam erst später. DOS war durch und durch für diesen PC konzipiert. Du kannst die Geschichte nicht umdrehen, wie es dir passt.

Höre bitte mal auf, mir Sachen zu unterstellen, die gar nicht da stehen. Was du übersiehst, IBM legte die Hardware fest bevor MS-DOS fertig war, das ist auch logisch.

Und Intel legte die Limits des 8088/8086 fest, bevor IBM überhaupt begann, den IBM PC zu entwickeln. Das ist auch logisch. ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Das Limit mag von IBM eingeführt worden sein, aber wenn man sich die anderen PCs, die nicht IBM-kompatibel sind, ansieht, so haben die ein ähnliches Limit.

Es geht hier nur um IBM kompatible, einschließlich der IBM Rechner selbst. Nicht kompatible sind nicht Thema des Artikels. Für die gab es auch keine DOS Extender. Deswegen ist die 640K Grenze relevant, die IBM festgelegt hat. Nichtkompatible PCs sind hierfür irrelevant und hatten zudem angepasste MS DOS Versionen, gerade weil sie nicht kompatibel waren. Das ist aber nicht Gegenstand des Artikels.

Genau. Und auf den IBM-PC-Kompatiblen ist es immer ein Limit von 640K, egal von wem das wann festgelegt wurde. Da der 80286 dieses Limit nicht mehr aufweist, der IBM PC/AT damit bestückt ist, und Betriebssysteme wie Xenix/286 und OS/2 1.x ebenfalls kein solches Limit mehr haben, ist es eben doch ein Limit von MS-DOS auf dieser Plattform. ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Die Speichererweiterungskarten, später als LIM-EMS standardisiert, können zwar für RAM-Disks und Daten verwendet werden, nicht aber für Programme -- der Speicher für Programme blieb somit auf den ursprünglichen konventionellen Speicher limitiert,

Du hast hier ein Missverständnis, was deinem Wissensmangel bezüglich der Programmierung geschuldet ist. Eine x86 CPU hat vier Segmentregister, ab dem 386 kommen noch zwei hinzu. Diese Segmentregister zeigen im Real Mode in den Adressraum der CPU. Im Normalfall also in den Adressraum des konventionellen Speicher. Das EMS Fenster liegt in der Regel im UMB. Und du kannst das Datensegment, als auch das Codesegment (CS) deines DOS Programms (siehe Speichermodell) an jede Adresse zeigen lassen, die innerhalb des Adressraums der CPU im Real Mode liegt, also grundsätzlich für die CPU erreichbar ist. Das gilt auch für den UMB.

Das weiß ich. Programme "hochlanden" in UMBs würde sonst gar nicht funktionieren. ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Was du nicht machen kannst, ist Code ausführen, der in EMS Speicher liegt und aus diesem EMS Fenster im UMB durch Bank-Switching oder ändern des Bereichs, auf den das EMS Fenster im extended Memory zeigt, ausgeblendet ist, also vor der CPU versteckt ist. Denn dieser Code wäre im Real Mode für die CPU nicht erreichbar und somit nicht ausführbar. Damit er ausführbar ist, muss er sich im Adressraum des Real Mode befinden. Du kannst den EMS Speicher aber als Datenspeicher für Code, den du darin auslagerst, nutzen. Diesen Code würde man in dem Fall in dem Moment als Daten werten, er wäre dann kein Code, der ausgeführt wird. Um ihn aber auszuführen, musst du ihn in wieder in den Adressraum des Real Mode einblenden. Das wäre problemlos machbar. Im Normalfall lässt man den Code aber im konventionellen Speicher und lädt nur die Daten in den EMS, das ist schneller und performanter und damit kommen auch die Compiler und Linker klar. Standardlinker und Compiler gehen davon aus, dass der Code im konventionellen RAM liegt, mit denen müsstest du den Code also in den konventionellen RAM zurückkopieren. Direkt den Code im EMS Fenster ausführen, würde zwar CPU seitig gehen, erfordert aber manuelle Programmierung in Assembler.

Das ist klar. EMS und XMS wurden aus diesen Gründen nie für ausführbaren Code genutzt, obwohl es mit extrem viel Aufwand doch irgendwie möglich wäre. Aber was hat das mit DOS-Extendern zu tun? ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Und außerdem sage ich dir jetzt schon zum dritten mal, dass ich dir bereits im Eingangskommentar erklärt habe, dass EMS nur für Daten ist, mit Daten ist alles gemeint, was gerade nicht ausgeführt wird.

Und ich frage dich zum dritten Mal, was EMS mit DOS-Extendern zu tun hat? ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Die UMA steht erst auf dem 386 für DOS zur Verfügung, weil eine MMU verfügbar sein muss. Oder eine Hardware-Karte mit Speicher ("ROM") ian dieser Adresse, wie es auch EMS-Speicherkarten machten. Damit kann auch auf dem 8088/8086 und 80286 DOS diesen Teil der UMA für UMBs nutzen.

Es gibt für 286 einige Mainboard Chipsätze, die den Speicher oberhalb der 640 KiB in den Adressbereich oberhalb der 1 MiB remappen also in höhere Adressbereiche verschieben. Diesen erweiterten Speicher kannst du dann per EMS Treiber wieder in den UMB Bereich einblenden, damit die CPU diesen im Real Mode ansprechen kann. Ein 386er ist also nicht zwingend, wenn der MB Chipsatz des 286 MB das kann. Das sagte ich dir aber bereits oben schon, so wie ich dir schon vieles oben sagte.

Denkst du denn, ich weiß das nicht? Spezial-Hardware gibt es immer wieder. Für Programme ist das aber wertlos, denn ein Entwickler von IBM-PC-Software kann nicht davon ausgehen, dass jemand einen NEAT-Chipsatz & Co hat. Die Programme sollen im Normalfall ja auch auf einem IBM PC/AT laufen. Und wieder: was hat das mit DOS-Extendern zu tun? ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Zu:

Was also im Artikel zu DOS-Extendern stehen sollte, ist:

• DOS-Extender sind quasi ein Mini-Betriebssystem, denn nur so ist es Protected-Mode-Programmen überhaupt möglich, unter DOS zu laufen.
• Außerdem müssen die Extender noch sicherstellen, dass sie mit HIMEM und EMM386 und allen anderen DOS-Tricks, sowie mit TopView, DESQview, Windows und anderen unter DOS viel-genutzten Programmen kompatibel bleiben.Der IBM PC wurde mit DOS als Betriebssystem zusammen von IBM eingeführt. CP/M kam erst später. DOS war durch und durch für diesen PC konzipiert. Du kannst die Geschichte nicht umdrehen, wie es dir passt.Der IBM PC wurde mit DOS als Betriebssystem zusammen von IBM eingeführt. CP/M kam erst später. DOS war durch und durch für diesen PC konzipiert. Du kannst die Geschichte nicht umdrehen, wie es dir passt.

Das kannst du alles im Technik Abschnitt erwähnen, hier geht es um Geschichte.

Und wir müssen nicht den Protected Mode erklären, und auch nicht die DOS-Speichertypen. Die Erklärungen sollen sich auf das beschränken, was DOS-Extender betrifft, und nicht mehr.

Hier geht es um den Geschichteabschnitt. Niemand hat gefordert, den PM nochmal zu erklären, der steht Logischerweise erklärt im PM Artikel. Was aber trotzdem notwendig ist, ist zu erklären, dass DOS Extender den Protected Mode benötigen und die DOS Programme, die den DOS Extender nutzen, Protected Mode Programme sind. Es sind nämlich keine Real Mode Programme. Der DOS Extender darf logischerweise aber Programmteile im Real Mode haben, die "Nutzlast" an Programmcode, also der eigentlichen Anwendung liegt aber im Protected Mode. Das sagte ich dir aber schon oben alles und ist mit DOS Protected Mode Programm gemeint.

Das mag stimmen, aber du hast mir hier zur Geschichte immer wieder UMBs, HMA, EMS und den Protected Mode erklärt, um... genau: um was eigentlich zu sagen? Was hat das mit der Geschichte der DOS-Extender zu tun? ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Das stimmt, denn in 86-DOS bzw. später MS-DOS und PC DOS, und jedem anderen PC-kompatiblen DOS, ist diese 1-MiB-Grenze des Arbeitsspeichers weiterhin vorhanden, auch auf 286ern und 386ern+.

Nein, das stimmt halt nicht. Denn Adressraum und Speicher ist nicht das gleiche. In DOS Real Mode hast du nur diese 640 KiB RAM konventionelles RAM (das ganze andere Zeugs, EMS, HMA zur Vereinfachung mal außer acht gelassen). 640 KiB RAM, kein bischen mehr, weil der Rest entweder von HW überdeckt ist, lückenhaft ist, also nicht zuervlässig genutzt werden kann oder über die FFFFFh Adresse hinaus verschoben wurde.

Das alles habe ich aber klar in meinem neuen Textvorschlag erklärt und du hast es nicht verstanden. Du verstehst es nach 3 Tagen Diskussion immer noch nicht. Das ist traurig. Es ist der Adressraum, der größer ist als das konventionelle RAM. Da muss es aber bei dir wohl erst Klicken, bis du den Unterschied verstehst. Vielleicht kann dir ein anderer auf die Sprünge helfen und es dir noch einmal erklären, dass RAM und Adressraum nicht das gleiche ist.

Vielleicht hilft dir folgendes:

In 64 Bit ist der Adressraum 2^64 Bit groß. Also die Adressen 0 bis FFFF FFFF FFFF FFFF h, dein RAM aber, das ist in der Regel viel viel kleiner. (Anmerkung: virtuelle Adressen und Co lasse ich mal zur Vereinfachung weg.) --~2026-37078-9 (Diskussion) 01:40, 18. Jan. 2026 (CET)

Nein, das hilft mir nicht. Das ist wieder EMS, HMA, 640k usw. Was hat das mit der Geschichte der DOS-Extender zu tun?

An meinem Satz stört dich "1 MB-Grenze vom Arbeitsspeicher?" Habe ich geändert in 1-MB addressierbar, also genau: "1 MiB Adressraum". Passt dir das jetzt? Auf einem 386er -- wo DOS-Extender mit VCPI 1989 landeten -- ist das allerdings nur im Real Mode richtig, da der 386er bereits eine MMU besitzt und somit mit UMBs mehr Arbeitsspeicher nutzen kann. Und auf einem 286er, wo DOS-Extender ja auch funktionieren, ist der Adressraum mit der HMA ebenfalls etwas größer. Aber okay, lassen wir das...

Passt dir das jetzt so? Und wieso hast du nicht den Vorschlag gemacht, statt 1 MiB Arbeitsspeicher einfach 1 MIB Adressraum zu schreiben? Zu meinem Verständnis: Dein Edit hatte nicht gerade *nur* diesen Bezug, sondern hauptsächlich hast du den Real Mode beim IBM PC beschrieben (der in gleicher Weise jedoch auch bei allen Nicht-IBM-kompatiblen PCs mit 8086-CPU vorhanden war, etwa dem DEC Rainbow 100). Mit deiner Zusammenfassung konnte ich dann wirklich nichts anfangen:

Es ist nicht egal, weil auch eine andere Aufteilung der 1 MB möglich gewesen wären. Diese Aufteilung beschloss IBM und geht aus den vorherigen 2 Sätzen nicht hervor, da die nur über die 1 MB Grenze der HW handeln. Wenn das fehlt, dann suggeriert das, dass die Entwickler von DOS das so entschieden hätten, das ist aber falsch. Außerdem geht es hier um den Adressraum, weniger um das RAM, Geräte haben bspw. ihre Register eingeblendet , die darüber angesteuert werden.

Dass eine Andere Aufteilung möglich gewesen wäre, habe ich dir ja belegt, weil Bill Gates sogar einmal erwähnt hatte, dass es zu einem bestimmten Zeitpunkt sogar 512k:512k hätte sein sollen. Wer schließlich und letztendlich für die Aufteilung verantwortlich ist, ist aber nicht das Thema dieses Artikels. Wenn wir es einfach nicht ansprechen, ändert sich ja wohl nicht der Umstand, dass es so ist?

Dass dies suggerierte, das Limit käme von DOS, habe ich nun ebenfalls entschärft, indem ich den IBM PC in einem einzigen Satz (nun mit Beistrich) beschreibe. Keiner kann nun mehr glauben, das ursprüngliche Limit ginge von DOS aus -- obwohl es auf dem 286 und 386, weil dieses weiterhin im Real Mode laufen muss, natürlich sehrwohl von DOS ausgeht. (Aber das haben wir ja schon ausführlich erörtert, indem OS/2 und Xenix dieses Limit ja nicht haben.)

DOS-Extender laufen jedoch gar nicht auf 8088/8086, und weil ich die Phrase "entschied IBM" weghaben wollte (es ist irrelevant), kam anschließend mein Revert. Wenn du kleine Änderungen machst und gut begründest, passiert dir das sicher nicht mehr, dass dein gesamter Edit revertiert wird. ‣Andreas•⚖ 09:32, 18. Jan. 2026 (CET)

Fortsetzung und Zusammenfassung (Dritte Meinung)

Im Artikel steht momentan im Geschichte Abschnitt folgende Einleitung:

In 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, und mit MS-DOS vermarktet wurde, steht nur 1 MiB Arbeitsspeicher zur Verfügung. Dieses Limit ist auf den im IBM PC verwendeten 8088-Prozessor zurückzuführen, einer 16-Bit-Architektur mit 8-Bit-Daten- und 20-Bit-Adressbus. Dieser Speicher wurde auf 640 KiB für Betriebssystem und Programme und 384 KiB für den Zugriff auf Geräte wie das BIOS oder den Grafikspeicher aufgeteilt. Dadurch steht auf IBM-PC-Kompatiblen unter DOS nur 640 KiB „Konventioneller Speicher“ zur Verfügung.

Diese ist eine mangelhafte, schlechte, geschichtlich und sachlich falsche Einleitung weil:

1. Folgender Teil

In 86-DOS, das ab 1981 als PC DOS mit dem IBM PC, Modell 5150, der die PC-Plattform begründet, und mit MS-DOS vermarktet wurde, steht nur 1 MiB Arbeitsspeicher zur Verfügung. Dieses Limit ist auf den im IBM PC verwendeten 8088-Prozessor zurückzuführen, einer 16-Bit-Architektur mit 8-Bit-Daten- und 20-Bit-Adressbus.

Ist sachlich falsch, weil dem IBM-PC nur ein Speicher von 640 KiB zur Verfügung steht, nicht 1 MiB, da der restliche Bereich des 1 MiB großen Adressraums für Periepheriegeräte reserviert wird (ja, das können auch RAM Erweiterungskarten sein, aber auch das sind nur Peripheriegeräte). Siehe dazu auch Punkt 3. Das Limit des 1 MiB großen Adressraums ist zudem auf den 20-Bit Adressbus der CPU und ihrer Art und Weise den Adressraum in SEGMENT und OFFSET Weise anzusprechen zurückzuführen. Die Erwähnung, dass es eine 16-Bit Architektur mit 8 Bit Datenbus sei, ist nicht die Begründung und der 8 Bit Datenbus ist hier komplett irrelevant.

2. Der nächste Teil

Dieser Speicher wurde auf 640 KiB für Betriebssystem und Programme und 384 KiB für den Zugriff auf Geräte wie das BIOS oder den Grafikspeicher aufgeteilt. Dadurch steht auf IBM-PC-Kompatiblen unter DOS nur 640 KiB „Konventioneller Speicher“ zur Verfügung.

suggeriert dem Leser, dass man diese Einschränkung auf 640 KiB so bei der Entwicklung von DOS entschieden hätte. Dies ist aber nicht korrekt, weil die 640 KiB aus der Aufteilung des Adressraum durch IBM herrühren, in dessen Korsett sich DOS dann einfügen musste, um keine Schwierigkeiten für Anwendungen zu verursachen. Diese Suggestion, dass es DOS Schuld sei, führt historisch mehrfach belegt, zu falschen Unterstellungen, wie bspw. dass Bill Gates gesagt hätte "640K ought to be enough for anybody".

3. Außerdem ist auch die Aussage sachlich falsch, da keine 384 KiB RAM für Geräte wie BIOS oder Grafikkarte zur Verfügung gestellt werden. Wäre im Rechner 1024 KiB RAM verbaut, so könnten auf diese 384 KiB oberhalb der Adresse 9FFFFh (also oberhalb der unteren 640 KiB) nicht zuverlässig zugegriffen werden, weil sie von der angeschlossenen Hardware überblendet werden würde oder durch den Mainboard Chipsatz durch Remapping in höhere Adressbereiche oberhalb der Adresse FFFF0h (also oberhalb von 1 MiB) verschoben werden würde.

4. Notbehelfskrücken, wie RAM Erweiterungskarten, mit denen dann RAM in den Adressbereich zwischen Adresse A0000h (655360) und FFFF0h (1048575), auch UMB genannt, in einem maximal 64 KiB Fenster als EMS Speicher einblenden und für Daten der Real Mode DOS Anwendungen dann nutzen konnte, werden gar nicht im Geschichteabschnitt erwähnt, obwohl sie historisch bedeutend sind.

5. Außerdem wird nicht klar und deutlich zwischen RAM und Adressraum unterschieden.

Daher ist mein Vorschlag für den Geschichteabschnitt die folgende neue und sachlich korrekte Formulierung:

Beim ersten IBM PC, Modell 5150 steht ein Adressraum von 1 MiB (Adresse 00000h bis FFFFFh bzw. in Dezimalschreibweise 0 bis 1048575) zur Verfügung. Dies ergibt sich durch den 20-bit breiten Adressbus des im IBM PC verwendeten 8088-Prozessor. Durch IBM wurde der obere Adressbereich von Adresse A0000h bis FFFFFh (Dezimal 655360 bis 1048575) für Hardware reserviert, so dass im Real Mode einem Betriebssystem nur der untere Adressraum von Adresse 0000h bis einschließlich 9FFFFh (0 bis 655359) für RAM zur Verfügung stehen, womit sich ein maximaler Arbeitsspeicher von 640 KiB ergibt. Dieser Speichereinschränkung unterliegt auch 86-DOS, das ab 1981 als PC DOS mit dem ersten IBM PC ausgeliefert und später auch als MS-DOS für kompatible PCs vermarkted wurde.

Dieser 640 KiB große Speicherbereich wird in DOS konventioneller Speicher genannt. Der Adressraum darüber wird in DOS UMB genannt. Um diese Limitation zu erweitern, wurden zunächst Speicherkarten (auch Memory Expander genannt) eingeführt, die in den oberen Adressraum eingeblendet wurden, mit denen in DOS sogenannter EMS-Speicher nach dem LIM-Standard mehr Speicher für Real Mode DOS Anwendungen zur Verfügung stand, welcher aber ausschließlich nur für reine Daten genutzt werden konnte.

Mit erscheinen des Intel 80286-Prozessors, welcher einen breiteren Adressbus von 24-Bit hatte, konnte im Real Mode durch die gegebene Adressierungsart Segmentadresse + Offsetadresse der Adressbereich zwischen Adresse 100000h und 10FFEFh (1048575 bis 1114095) bei eingeschaltetem A20-Gate verwendet werden, womit sich ein zusätzlicher Speicher von 65519 Bytes ergab, welcher in DOS als HMA definiert wurde.

Von da geht es dann im Geschichte Abschnitt mit dem bereits im Artikel stehenden Text weiter, in dem dann das Aufkommen der DOS Extender erklärt wird, die für DOS Programme, die im Protected Mode laufen, mehr Speicher oberhalb des HMA zur Verfügung stellen können.

Dieser neue Text löst folgende Probleme:

1. Die Ursache, warum man in DOS erst einmal nur 640 KiB RAM zur Verfügung hat, wird auf die Hardware und die Adressraumaufteilung durch IBM zurückgeführt, womit das sachlich korrekt ist.
2. Zwischen RAM und Adressraum wird klar und deutlich unterschieden.
3. Fehlerhafte Zitate, die man Bill Gates unterstellt, verlieren beim Leser so ihre Grundlage, da dieser nun richtig informiert ist, wie es wirklich war und warum DOS anfangs nur 640 KiB RAM zur Verfügung hatte.
4. Dem Leser wird klar, dass im Adressraum des UMB erst einmal kein Speicher liegt.
5. Die Krückenlösungen wie EMS durch bspw. Speicherkarten und HMA ab dem 286er werden als Überleitung zu der Entwicklung der DOS Expander erwähnt und bleiben nicht unerwähnt. Wenn dieser Abschnitt zu lang ist, könnte man den gegebenenfalls kürzen und auf die jeweiligen Artikel verweisen.

Falls noch Verlinkungen im Textvorschlag fehlen, kann man die noch nachtragen. Auch könnte man noch die Segment und Offset Schreibweise hinzufügen, die lasse ich hier jetzt aber weg, weil das nur Probleme mit dem Bearbeitungsfilter (Zensurfilter) gibt, der das Kommentar dann nicht akzeptiert. Die Hexschreibweise könnte man auch in modern, also mit vorangestellter 0 gefolgt von einem X schreiben, anstatt klassisch mit einem kleinen h am Ende, warum ich das noch nicht gemacht habe, ist ebenfalls dem Zensurfilter geschuldet.

Noch etwas. Andreas ist der Meinung, dass man die Einleitung mit DOS, nicht mit der Hardware beginnen müsse. Ein Versuch meinerseits die Einleitung mit DOS zu beginnen und dann mit der Hardware, deren Aufteilung des Adressraums, der verwendeten CPU, dem Adressbus und der Adressierungsart zu kombinieren, hat zu solch schwer zu lesenden langen Sätzen geführt, das ich deswegen alles noch einmal umschrieb und doch mit der Hardware anfing, wie ich es ursprünglich vor hatte, um dann zu DOS überzugehen. Wer also meint, dass er das besser könne und es fehlerfrei und mit allen notwendigen Inhalten schafft, der kann gerne einen weiteren noch besseren Textvorschlag einbringen. --~2026-37078-9 (Diskussion) 22:34, 17. Jan. 2026 (CET)

Antwort:

EMS hat im Artikel und in der Argumentation über DOS-Extender nichts verloren. UMBs und die HMA sind marginal ein Erwähnung wert -- wenn, dann aber mit Quellenangabe. Außerdem: wozu?

Den Rest: Siehe oben. Die Kurzfassung: DOS-Extender gibt es nur auf IBM-PC-kompatiblen Computern und PC-kompatiblem DOS. Das ist exklusiv, und daher müssen auch (die Real-Mode-)Teile von DOS-Extendern, damit das ganze überhaupt funktioniert, in den 640k Konventionellem Speicher von DOS auf der durch den IBM PC geschaffenen Plattform laufen.

‣Andreas•⚖ 23:52, 17. Jan. 2026 (CET)

Wegen der Geschichte über Speicher und DOS . Der Abschnitt heißt ja nicht Technik, sondern Geschichte.

Dein zweiter Absatz ist am Thema vorbei, denn hier hat niemand behauptet, dass es DOS-Extender auf anderen Computern oder Betriebssystemen gäbe. Dass die Real Mode Teile von DOS-Extendern in den 640k müssen, kannst du im Technik Abschnitt erwähnen, sofern es da noch nicht geschehen ist, hier geht es um Geschichte, also ein ganz anderes Thema. --~2026-37078-9 (Diskussion) 00:05, 18. Jan. 2026 (CET)

Am Thema vorbei... Ich dachte, es geht um DOS-Extender. Sorry. Worum geht es? ‣Andreas•⚖ 00:08, 18. Jan. 2026 (CET)

Die Geschichte bis zur Entstehung der DOS-Extender und warum sie entstanden sind. Ist das wirklich so schwer?

Alles andere, wie DOS-Extender genau funktionieren usw. gehört in andere Abschnitte des Artikels. Dort kannst du auch explizit erwähnen, dass es DOS-Extender nur für 86-DOS (wie du es nennst, also nicht Amiga DOS usw.) gibt, wenn du eine derart explizite Erwähnung für unbedingt so wichtig hältst. --~2026-37078-9 (Diskussion) 01:48, 18. Jan. 2026 (CET)

Na dann passt ja alles. EOD. --‣Andreas•⚖ 08:53, 18. Jan. 2026 (CET)

Ist das Sarkasmus oder zeigt es einen Konsens an? Mein Ironiedetektor ist leider gerade kaputt und inhaltlich verstehe ich die Diskussion nicht. Falls ihr hier fertig seid, nehmt es doch bitte bei 3M raus – falls nicht kann ich mangels Sachkenntnis wohl nicht helfen. Gruß --Winkekatze (Winken) 19:27, 19. Jan. 2026 (CET)

Danke. Das mit der 3M habe ich gar nicht mitbekommen. Ich verstehe nicht ganz, was der temporäre Benutzer von mir will. Nachdem ich die 3M nicht initiiert habe, kann ich aber auch nicht deren Beendigung guten Gewissens veranlassen. ‣Andreas•⚖ 13:36, 20. Jan. 2026 (CET)

Okay, dann lassen wir es doch einfach noch offen, vielleicht versteht ja jemand anderes, was hier los ist. Da die Anfrage aber relativ unspezifisch ist, habe ich so meine Zweifel. Gruß --Winkekatze (Winken) 13:41, 20. Jan. 2026 (CET)

Ebenso. Wie gehen wir eigentlich diesbezüglich mit temporären Benutzern um? Man kann die ja nicht einmal anpingen, oder sinnvoll über deren Diskussionsseite Kontakt aufnehmen. Wenn sich derjenige also nicht mehr meldet -- oder jemand anders, der so tut, als wäre er derselbe... Ich jedenfalls kenne mich mit temporären Benutzern zu wenig aus. ‣Andreas•⚖ 13:46, 20. Jan. 2026 (CET)

Guter Punkt. Hilfe:Echo#mention sagt „Wenn [...] ein registrierter anderer Benutzer verlinkt wird, erhält der angesprochene Benutzer eine Benachrichtigung darüber.“ [Hervorhebung von mir]

Ich würde aber davon ausgehen, dass jemand, der eine 3M-Anfrage stellt, die entsprechende Disk beobachtet... --Winkekatze (Winken) 13:50, 20. Jan. 2026 (CET)

Also einfach etwas warten. Wenn in ein paar Tagen nichts passiert können wir das hier mE beenden. Gruß --Winkekatze (Winken) 13:51, 20. Jan. 2026 (CET)

Ist auch meine Herangehensweise... In jedem Fall: Danke! Hätte die 3M sonst gar nicht bemerkt. ‣Andreas•⚖ 14:42, 20. Jan. 2026 (CET)

Hi, mich hat die IP vor 2 Tagen um eine dritte Meinung gebeten (Benutzer Diskussion:Siegbert v2#Einladung), zu der ich aber bis jetzt nicht gekommen bin.

Ich habe am Sonntag versucht, die lange Änderungshistorie und die lange Diskussion hier jetzt irgendwie nachzuvollziehen.

Im Kern geht es lt. Einladung wohl um die folgende Aussage:

Adressraum hat immens mit der virtuellen Speicherverwaltung zu tun

Grundsätzlich stimmt das; allerdings kann/sollte man es explizit auf den virtuellen Adressraum beziehen. Als Beispiel wird das auf der MSDN-Seite zum virtuellen Adressraum gleich im ersten Satz genannt. Der virtuelle Adressraum ist natürlich ein Eckpfeiler der virtuelle Speicherverwaltung.

Als Einschätzung zum aktuellen Stand des Artikels und dem bisherigen Diskussionsverlauf würde ich auch sagen, dass man im Hinblick auf die Allgemeinverständlichkeit nicht bis auf atomare Ebene heruntergehen und auch nicht alle Besonderheiten für alle möglichen Systeme abdecken muss/sollte.

Die "640-KiB-Grenze" wird bereits im Artikel Konventioneller Speicher#Die 640-KiB-Grenze abgedeckt. Das sollte man hier nicht nochmal redundant abbilden, zumal es dort auch etwas genauer beschrieben ist. Allerdings ist jener Artikel derzeit völlig unbelegt, was eine weitere Großbaustelle darstellt. Ich war so frei, einen Belege-Baustein zu platzieren. --Siegbert v2 (Diskussion) 16:55, 20. Jan. 2026 (CET)