Hier ist noch eine kleine Beweisführung zum Thema Windows 3.11, die ich schon lange mal vorführen wollte. Das hat jetzt nicht nur damit zu tun, wie ein „veraltetes“ System mit Speicher umgeht, sondern auch mal wieder damit, wie wir dort angekommen sind, wo wir heute PC-mentalitätsmäßig sind.

Es war so um das Jahr 1995 herum (nun ratet mal, warum ausgerechnet in diesem Jahr ;-)), daß PC-Zeitschriften anfingen, die Geschichte vom unzulänglichen Windows 3.11 zu erzählen, daß nur 16 MB Arbeitsspeicher verwalten kann. Sollte jemand also mehr als 16 MB Speicher im Rechner haben, oder einen Speicherkauf planen, und noch immer das „uralte“ Programm verwenden, so läge viel vom teuren Speicher einfach brach. Zum Glück hatte ein sehr guter Freund der PC-Zeitschriften gerade im Jahr 1995 ein nagelneues „32-Bit“-Betriebssystem auf den Markt gebracht, daß voll viel Speicher verwalten konnte. Also steigt um und holt es euch.

Die Legende von der 16-MB-Begrenzung in Windows 3.11 hielt sich beharrlich und selbst heutzutage nicken es noch IT-Experten aus Desinteresse als Wahrheit ab. Auch im CF wurde das Thema damals durchdiskutiert und einiges an Blech geredet („Windows 3.11 kann nur 16 MB verwalten, weil es halt ein 16-Bit-Betriebsystem ist.“) Letztlich war es aber auch dort, daß die MS-Werbestory von Experten widerlegt wurde. Es ist eigentlich erstaunlich, warum sie überhaupt geglaubt wurde, denn jeder mit mehr als 16 MB Arbeitsspeicher hätte die Geschichte problemlos selbst überprüfen können, einschließlich der Redakteure. Aber Aufrüstmagazine Marke PCgo & Co hatten gerade in den späteren 90ern wohl immer recht und jede Begründung für Aufrüsten, Umrüsten und Wegschmeißen war gerne gesehen.

Die Beweisführung ist höchst einfach, hier vorgeführt auf meinem Pentium 166 mit 64 MB Arbeitsspeicher und WfW 3.11:

Nach dem normalen Start zeigt der Rechner eine Speicherverfügbarkeit von ca. 226 MB. Das sind die physikalischen 64 MB plus virtueller Speicher mittels einer großzügig dimensionierten, temporären Auslagerung. Diese taucht als Datei win386.swp mit variabler Größe auf der Platte auf, beim Start ist sie ca. 11 MB groß. Maximal kann der virtuelle Speicher auf etwa 2 GB definiert werden, also DOS-Partitionsgröße bzw. Plattengröße bei mir.

Für eine ordentliche Beweisführung müssen wir die Auslagerung natürlich deaktivieren und neu starten. Danach sehen wir:

Das sind die physikalischen 64 MB Arbeitsspeicher abzüglich ca. 9 MB, die Windows für sich selbst belegt. Das ist eigentlich ziemlich viel, aber es läuft auch in hoher Auflösung mit Calmira XP 4.0, dickem Hintergrundbild und Erweiterungsroutinen. Ganz glücklich bin ich nicht damit, aber 9 MB sind noch halbwegs im Rahmen und ließen sich bei Bedarf auch merklich verringern. Auslagerungsdatei ist nun natürlich keine mehr auf der Festplatte, alles findet im physikalischen Arbeitsspeicher statt.

Aber was ist nun mit den 54 MB, die laut Anzeige im Speicher noch frei sind? Könnte Windows 3.11 nur 16 MB verwalten, dann müsste ja kaum mehr etwas übrig sein, und das System schnell an die Grenze stoßen. Laden wir doch einfach mal ein paar größere Bilder in den Speicher, von den Eigenschaften her in etwa wie folgt:

Nach einer Handvoll geladener Bilder (allzu viele gehen mit deaktivierter Auslagerung natürlich nicht, daher sollte diese auch aktiviert sein) sieht die Speicheranzeige so aus:

Nun sind weitere 46 MB im physikalischen Speicher mit Bilddaten belegt, ohne Auslagerung auf der Platte. Wo ist denn nun die 16-MB-Begrenzung, wegen der man unbedingt auf ein neues System hat umsteigen sollen?

P.S. Falls Beiträge dieser technischen Art zu langweilig für die Retro-Webseite sind, dann sage man mir bitte kurz Bescheid. Ich werde sie dann hier nicht reinstellen.

Avatar-Foto

Von Chris Pfeiler

on allen Retro-Schreibern bin ich wohl derjenige, der das Thema am Persönlichsten vertritt. Ich habe privat keinen digitalen Lifestyle im modernen Stil, also kein Handy, iKram oder aktuelle Rechner. Viele Leute finden das zum Haareraufen und würden mich gerne „missionieren“, ich finde aber, daß einem ein sog. veraltet-analoger Lebensstil viele Ideen und Perspektiven vermitteln kann.

8 Gedanken zu „Die mysteriöse 16-MB-Grenze“
  1. Naja was hilft das alles, Windows 3.11 war trotzdem nur ein 16-bit Aufsatz für ein 16-bit DOS, mit einigen 32-bit Erweiterungen, die aber auch nicht besser waren als die ganzen DOS-Extender-Krücken. Wenn man nicht nur Anwender sondern auch Programmierer ist, weiß man ein echtes 32-bit Betriebssystem durchaus sehr zu schätzen. Dieser Sprung war wesentlich relevanter als der Sprung von 32-bit auf 64-bit.

    Das Problem ist, bei 16-bit liegt die natürliche Grenze eigentlich schon bei 64KB Speicher. Um die zu umgehen, muss man schon mit solchen Krücken wie Segment und Offset arbeiten, was einfach nur lästig ist. Bei einem echten 32-bit System kann ich bis zu 4GB Speicher an einem Stück mit einer einzigen 32-bit Zahl linear adressieren. Speziell bei Spielen, die SVGA Auflösungen ab 640×400 aufwärts nutzen wollten, und dabei so performant bleiben wollten wie die älteren VGA Spiele in 320×200, kam man um eine lineare 32-bit Adressierung nicht herum. Nur so kann man jeden Pixel direkt ansprechen ohne erst mal das korrekte Segment zu ermitteln.

    Genau dieses Feature versuchten dann halt solche DOS-Extender oder das 32-bit Subsystem von Windows 3.11 irgendwie an ein 16-bit System dranzuflanschen, und irgendwie funktionierte das auch, aber elegant ist was anderes.

    Für mich war mein PC zu dieser Zeit eine reine Spielemaschine, Windows 3.11 hat mich daher auch nie besonders interessiert, da 99% der Spiele sowieso direkt von DOS (+Extender) auf Win95 gesprungen sind. Und das kann ich keinem Spieleprogrammierer übel nehmen.

    PC Zeitschriften schreiben viel Quatsch wenn der Tag lang ist, aber der Übergang zu 32-bit Betriebssystemen hatte durchaus seine Berechtigung und kann keinesfalls auf eine Marketing Kampagne für gewisse Betriebssystemhersteller reduziert werden. Ich fand es nur schade, das OS/2 so sang und klanglos untergegangen ist, das sah mir eigentlich vielversprechender aus als Win95.

    P.S.: Diese lustigen Dreh-Captchas hier funktionieren bei mir im Opera Browser irgendwie auch nur bei jedem zehnten Versuch…

  2. „Das Problem ist, bei 16-bit liegt die natürliche Grenze eigentlich schon bei 64KB Speicher.“

    Das ist die Adressierungsgrenze von 8-Bit Rechnern, 16 Bit Rechner können mehr adressieren. Die maximal verwendbare Speichergröße wird durch den Prozessor bestimmt und in der Regel nicht durch das OS (es sei denn der Hersteller setzt eine künstliche Grenze). Auf einem 80386 Prozessor konnte Windows 3.11 in der Tat nur 16 Megabyte adressieren, da der Prozessor nur einen 24 Bit breiten Adressbus besitzt.

  3. Doch doch, das mit den 64KB bei 16-bit ist schon genau richtig. Ein 16-Bit-Wert hat einen Wertebereich von 2^16 = 65536 Bytes, also 64KB. Natürlich gab es aber auf IBM-PCs unter DOS bis zu 640KB Speicher bzw. eigentlich ein ganzes MB. Um so viel Speicher adressieren zu können, muss eine 16-Bit CPU aber eben schon zwei Register verwenden, ein Segment- und ein Offset-Register. Das Segment bestimmt, auf welchen 64KB Block man zugreift, und innerhalb dieses 64KB Blocks adressiert man dann mit dem Offset-Register. Bei noch älteren 8-Bit-Rechnern wird der Speicher typischerweise mit zwei 8-Bit-Registern oder einem speziellen 16-Bit Adressregister adressiert, womit man auf 64KB Speicher kommt (C=64 beispielsweise).

    Das fiese bei der Segment/Offset geschichte ist dann noch, daß es mehrere Segment/Offset Kombinationen gibt, die im Endeffekt die gleiche absolute Speicheradresse beschreiben, da Segment und Offset sich quasi um 8 Bit „überlappen“, womit man im Endeffekt eben nicht 2^32 sondern nur 2^24 Bytes addressieren kann. Nun tippe man mal 2^24 in den Taschenrechner und was kommt heraus? 16.777.216, also genau die ominösen 16MB von denen im Artikel die Rede ist.

    Ein original IBM PC (8088 btw 8086) hatte sogar nur eine 20-bittige Adressleitung und konnte daher nur 1 MB adressieren. Das ist der Ursprung der berühmten 640KB Grenze von DOS (640KB normaler Speicher + „UMA“ (upper memory area). Beim 286er konnte man dann aber dank 24-bittiger Adressleitung wirklich 16MB addressieren, allerdings nur im neuen „Protected Mode“, den man erst extra aktivieren musste.

    Trotzdem konnte man auch unter DOS bereits mit EMS mehr als 16MB Speicher nutzen. Das geht, indem man quasi mehrere „Seiten“ im Speicher hat, von denen man aber immer nur eine gleichzeitig in den adressierbaren Bereich unterhalb von 16MB „einblenden“ kann. Das ist aber umständlich zu programmieren, bläht somit den Programmcode unnötig auf, und ist natürlich auch eher inperformant.

    Der 386er war dann der erste richtige 32-bit Prozessor. Der hat im Protected Mode dann wirklich eine 32-bittige Adressleitung und kann daher 4 Gigabyte am Stück adressieren. Keine Segmente und Offsets mehr, keine EMS Verrenkungen mehr – es war einfach ein traumhafter Fortschritt aus Sicht des Programmierers.

    Man konnte dieses Feature zwar wie gesagt unter DOS mit Extendern oder unter Win3.11 mit entsprechenden 32-bit Erweiterungen („Win32s“) auch nutzen, aber schön war das alles nicht.

    Wenn Zeitschriften das damals auf die 16MB Sache reduziert haben war das zwar sehr oberflächlich betrachtet. Trotzdem gab es im Detail viele andere gute Gründe, um Windows 3.11 auf Wiedersehen zu sagen und auf ein natives 32-Bit System zu setzen.

  4. Gut, da haben wir uns falsch verstanden, ich war auf den direkt adressierbaren Speicher aus, den die Adressleitungen und interenen Register zulassen, Du auf den innerhalb von 16 Bit darstellbaren Wertebereich. Mit deinen Ausführungen hast Du selbstverständlich recht.

  5. Nachtrag:
    ich glaube das wir eben aneinander vorbei geredet haben liegt daran, dass ich in der Tat den 68000 vor Augen hatte, der ja intern in der Tat mir einem 32 Bit Adressraum und nicht mit 64 KB Blöcken gearbeitet hat, auch die 8 Bit Computer haben ja intern mit einem 16 Bit Adressraum gearbeitet.
    Das war bei den Intels ja anders und da es im Artikel ja um Windows ging, hat der 68000er da natürlich nichts zu suchen. Also einfach meine Kommentare ignorieren :-)

  6. Alles ganz nett, aber knapp an der Realitaet vorbeit. Das eine Thema ist die hardware, das andere Windows.

    Hardware:
    Die 8086 hat 20 Bit und kann so 1 MB addressieren. Sie ist wohl einer der reinsten (und schoensten) 16 Bit Prozessoren die es gibt. Anders als bei anderen 8 und 16 Bit Prozessoren gibts keine Sondergroessen (1 Bit dressen auf 8 Bit CPUs etc.). Alle Datentypen sind 16-bitig, auch Adressen. Die trennung in 16 Bit Segment und 16 Bit innersegment Adresse ermoeglichte von anfang an den Betrieb von Multitasking und Multiprogramming-Umgebungen wie Unix. Von anfang an war geplant diese 16 Bit Welt auch auf groesseren Systemen mit Virtueller Adressierung zu unterstuetzen. Dazu gabs dann einen Satz an Regeln, wenn man die einhielt, dann waren die Programme problemlos aufwaertskompatibel:

    – Kein Rechnen mit Segmenten.
    – Keine I/O Befehle im Programm
    – Kein Schreiben in Codesegmente
    – Kein Ausfuehren von Code in Datensegmenten
    – Kein Ueberlappen der Segemnte

    Segmente sind Handles auf den (virtuellen) Speicher, keine Adressen. Und da liegt das Problem der meisten DOS-Programme: jede menge superintelligener Programmeirer haben eben doch mit Segemnten gerechnet und sich darauf verlassen dass das jede Segmentnummer immer 16 byte hinter der vorhergelegenen liegt

    286:
    Die 286 brachte dann einen 24 Bit Adressbus und eine richtige Segmenttabelle (die Rechnung in der 8086 sollte man sehen wie eine Segmenttabelle mit 64k eintraegen die alle 16 byte liegen und keinen Speicherschutz haben). Damit liessen sich jetzt 16 MB adressieren. Ein Segment konnte an beliebiger Stelle liegen und bis zu 64K umfassen (immer noch saubere 16 Bit – Einzig die Speicherverwaltung im Kernel musste was von mehr als 16 Bit wissen – wie bei der 8086)..

    386er (und folgende):
    die Adressbreite sieg auf (bis zu) 32 Bit (je nach Typ gab es 26-30 Adresspins). Die Segmente blieben (im 16 Bit Modus) weiterhin 16 Bit. Wer seine Anwendungen 1979 gemaess den Regeln programmiert hatte konnte sie unveraendert auf einem 386er (geeignetes OS vorausgesetzt) laufen lassen. Bestes beispiel dafuer war Xenix (bzw. die Derivate), auf diesem Unix geschriebene Anwendungen die fuer 8086 Systeme mit 1 MB (und 3-8 Usern:) geschrieben wurden liefen anstandslos noch in den 90ern auf 386ern mit mehreren hundert MB.

    Zusatzlich fuehrte Intel mit dem 386er sowohl einen 32 Bit Mode fuer Anwendungen ein (immer noch mit Segmenten, die aber 32 Offset haben konnten), als auch einen Virtual 86 Modus. Letzterer war ein boeser Hack, damit all die Programme, die sich nicht an die Regeln hielten (also vieles aus der DOS Welt) .

    Zur Hardware hinzu gehoert auch noch der sogenannte (LIM) EMS-Speicher. Das waren Speichererweiterungen, die Speicher in 16 KB Bloecken in den Hauptspeicher einblenden konnten. Unter DOS verwendete man dafuer den Adressraum zwischen C0000 und F0000 – jenachdem welche sonstigen Karten da steckten. Auf A0000 lag ja die Grafik. Unter Windows gabs aber zusaetzliche Anwendungen – siehe unten.

    Und damit kommen wir zur Software Also Windows.

    Ab Windows 2 (genauer 2.1 und 2.11), gabs Windows als Windows, Windows/286 und Windows/386. Die ersten 2 waren dabei die gleiche Distribution, das Win/386 hatte zusaetzliche Teile im Kernel, und lief auf allem, von 8086 bis 386. Im Betrieb wurden dabei 3 Modi unterschieden, die man beim Start auswaehlen konnte:

    Real Modus (win /r):
    Das einzig Moegliche auf einer 8086/186. Ohne weiteres sind damit nur 1 MB adressierbar. mit EMS jedoch 5 MB, da Win bis zu 4 MB EMS als Speicher fuer Programme nutzen konnte. Daher wurde fuer solche Rechner empfohlen den Hauptspeicher auf 384 kB zu reduzieren(!) um so 16 EMS Fenster (256kB) einblenden zu koennen. Bei der Umschaltung der Programme wechselte Windows dann auch die eingeblendeten EMS-Seiten. Zusaetzlich gabs noch ein Interface, dass Programme selber EMS-Seiten (im oberen Speicher) verwalten konnten (ueber ein Windos-Interface). Ein so ausgestatteter Rechner mit 10 MHz 8088 durchaus mit einer 6 MHz 286 mithalten. Und mit einer NEC V20 und 12 MHz sogar kreise um einen AT laufen :)

    Standard Modus (win /s):
    Hier wurde die Faehigkeit des 286ers ausgenuetzt 16 MB zu adressieren. EMS Unterstuetztung gab es zwar auch noch, sinnvoll war es aber nur fuer Programme die EMS selbst ansteuerten. Ohe irgendwas (oder mit weniger als 2 MB Speicher) starteten auch 386er in diesem Modus.

    386er Modus (win /3):
    Wie schon gesagt hatte intel der 386 einen virtuellen 8086 Mosus spendiert. Win/386 verwendete den jetzt um jedem Programm praktisch eine eigene 8086 bereitzustellen. Dadurch wurde eine grosse Kompatibilitaet zu DOS Programmen hergestellt (die jetzt wieder wild mit Zeigern rechnen durften), leider wars aber auch langsamm. Deswegen empfahl MS auch selbst auf 386ern lieber den Standardmodus zu verwenden, wenn es die Programme erlaubten. Trotzdem wurden mit Windows 2.x auch auf einem 386er nur 16 MB Speicher unterstuetzt, da die 24 Bit Segmenttypen verwendet wurden.

    Auch wenn Windows 3 dann eine einzige Distribution wurde, averringert wurden die Varianten erst mit Win 3.1x – das schaffte den Real-Mode ab. auch wenn, zumindest in einigen Varianten der /r noch zu einem erfolgreichen Start auf einem XT fuehrte. Mit 3.x wurden dann auf 386ern die 32 Bit Tabelleneintraege unterstuetzt.

    Zusammengefasst schauen die Speichergrenzen so aus:

    8086 ohne EMS: 1 MB
    8086 mit EMS: 5 MB
    80286 : 16 MB
    80386 Win 2.x: 16 MB
    80386 Win 3.x: 1 GB

    Gruss
    H.

  7. Moin, ich möchte mal etwas über 16 Bit-Mode vs 32 Bit-Mode sagen, weil darüber immer wieder falsche Informationen verbreitet werden.

    Der Unterschied zwischen dem 16 Bit-Mode und dem 32 Bit-Mode liegt lediglich darin, wie Befehle mit und ohne Operandsize/Adressize/Registersize-Prefixe von der CPU interpretiert und verarbeitet werden. Mit der Segmentgröße hat das überhaupt gar nichts zu tun.

    So ist es auf einem Intel 80386 DX schon im 16 Bit-PM möglich den gesamten 4 Gigabyte mit 32 Bit-Offsetregister zu adressieren. Dafür muss man die Segmentgröße im GDT/LDT-Eintag entsprechernd erweitern. Ein Umschalten in den 32 Bit-Mode ist dafür aber gar nicht nötig.

    Dirk

Kommentare sind geschlossen.