Diskussion:Konventioneller Speicher

Bis zu 4GB pro Prozess unter x32?

Zumindestens unter der Windows-NT-Reihe ist die Obergrenze pro Prozess in x32 2GB, mir ist mal unter Windows XP x64 Edition der Internet Explorer 7 abgestürzt, weil ich zu veile Tabs geöffnet hatte und der Speicherbeddarf durch ein Memoryleak 2GB erreicht hat (ich war da zufällig gerade im Task Manager drin und habs deshalb bemerkt). Es kann nur daran gelgen haben, weil es waren vond en 4GB RAM, die ich installiert habe, noch ca. 1GB frei. --MrBurns 11:57, 13. Okt. 2009 (CEST)

Das kann ich bestätigen. Der maximal nutzbare Speicher pro Prozess beträgt 2 GiB, wobei Tests gezeigt haben, dass Prozesse abstürzen, sobald sie ca. 1,9 GiB erreichen. --185.151.64.164 10:16, 10. Dez. 2018 (CET)

Was hat das mit konventionellem Speicher zu tun? Das passt wohl eher zu 32-Bit-Architektur, ist aber schon im Artikel 4-GB-Grenze vollständig erklärt.

Zusätzlich findet sich natürlich für Windows etwas darüber von Microsoft selbst, hier (englisch) zum Beispiel.

‣Andreas•⚖ 17:28, 10. Dez. 2018 (CET)

Eigentlich nichts, aber im Artikel gibt es einen Abschnitt "Modernes äquivalentes Problem", wo genau das beschrieben wird. --MrBurns (Diskussion) 18:51, 11. Dez. 2018 (CET)

Das ist so nicht ganz richtig. Es ist durchaus möglich den Userspace Prozessen 3 GB zuzuteilen. Das OS bekommt dann 1 GB weniger. Siehe https://docs.microsoft.com/de-de/windows/win32/memory/4-gigabyte-tuning . Mit dem Artikel hat das aber nichts zu tun. --84.158.122.178 00:20, 22. Dez. 2021 (CET)

Ja, das ist bereits im Artikel 4-GB-Grenze vollständig und richtig erklärt. ‣Andreas•⚖ 11:46, 22. Dez. 2021 (CET)

Bedeutung der 640kB-Grenze unter Win 9x

Bei modernen 32/64-Bit-Betriebssystemen, wie beispielsweise Microsoft Windows 95 und neuer, hat die 640-KB-Speichergrenze keine Bedeutung mehr

das stimmt nicht, da Win9x nicht ladet, wenn man zu viele TSRs geladen (z.B. Win 98SE braucht ca. 500 KB konventionellen Speicher) oder die Himem.sys deaktiviert hat. --MrBurns 12:14, 13. Okt. 2009 (CEST)

Nachdem das noch immer drin steht und sich auch keiner an der Disk. beteiligt, ändere ich den Text mal von "Windows 95 und neuer" auf "Windows NT basierenden Betriebssystemen". --MrBurns 18:43, 20. Feb. 2012 (CET)

Naja, Win9x mag nicht laden, aber wenns erstmal geladen ist (und erst dann lassen sich ja Windows-Anwendungen ausführen) hat diese Grenze keine Relevanz mehr. :-) --RokerHRO 10:13, 22. Feb. 2012 (CET)

Das mag schon sein, aber der Ladevorgang selbst ist ja auch relevant. Ein Windows, das nicht startet, ist ja ziemlich nutzlos. --MrBurns 14:38, 22. Feb. 2012 (CET)

Windows 95 konnte nach dem Starten auch wieder in einen echten MS-DOS schalten. D.h. das DOS musste dazu noch da sein und die CPU in den Real Mode geschaltet werden. --84.158.122.178 00:14, 22. Dez. 2021 (CET)

Einblenden in den UMA oder kopieren unterhalb des 640 KB? Was denn nun? Artikel ist widersprüchlich

Der Artikel ist zusammen mit dem Artikel UMB widersprüchlich. Aus dem Artikel schlussfolgere ich, wenn der Rechner 1 MiB physisches RAM (z.b. 4 x 256 KiB Module) hat, dann stehen 384 KiB dieses RAMs im Adressbereich des UMB nicht zur Verfügung, da der Adressbereich für I/O Sachen für Hardware reserviert ist. Ein Zugriff in den UMB Adressbereich würde also zu einem Zugriff auf die Hardware Peripherie führen und nicht in diese 384 KiB RAM. So weit okay. Dann soll es aber PC Chipsätze geben, die diese 386 KiB RAM einfach in einen Adressbereich oberhalb von 1 MiB einblenden (Remapping), so dass dieser Speicher wieder verfügbar ist. Allerdings ist er im Realmode nicht ansprechbar (Feinheiten bezüglich HMA lass ich mal zur Vereinfachung weg), deswegen gibt es die Extended Memory Spezifikation wie XMS, bei dem das Betriebssystem die CPU in den Protected Mode schalten, dann aus dem Bereich oberhalb von 1 MiB den Speicherinhalt in den konventionellen Speicherbereich unterhalb von 640 KiB kopiert und dann wieder die CPU in den Real Mode schaltet. Ist das so korrekt oder wird nicht in den konventionellen 640 KiB Bereich die Daten kopiert, sondern lediglich per Hardware Bereiche oberhalb von 1 MiB in den UMB Bereich eingeblendet?
Welche Variante ist jetzt genau richtig, das kopieren unterhalb der 640 KiB oder das Einblenden in den UMB?
Und warum konnten das nur einige PC Chipsätze und nicht alle? Die PC Chipsätze, die das nicht konnten, da war der Speicher dann nicht nutzbar, ist das richtig? Hat man also 4 x 256 KiB Module verbaut, dann hätte man sich das 4. Modul sparen können.
Und was passiert, wenn es eine 286er CPU ist und 16 MiB RAM physischen RAM verbaut wird? Dann müsste das Remapping ja entweder oberhalb der 16 MiB RAM dort diese 386 KiB aus den unteren 1 MiB physisch vorhandenes RAM anhängen, womit es nicht mehr benutzbar wäre, oder der ganze Bereich des physischen RAMs ab 640 KiB verschiebt sich per Remapping auf die Adresse ab 1 MiB. Welche Variante wurde verwendet, wenn 16 MiB physisch vorhanderer RAM verbaut waren?--84.158.122.178 00:11, 22. Dez. 2021 (CET)

Puh, so viele Fragen auf einmal. Ich versuche mal zu ordnen:

1) Ja, im Original-Chipsatz von Intel für den 80286 war der RAM, der an den Adressen A0000_hex…FFFFF_hex liegt, nicht nutzbar und lag brach. Der NEAT-Chipsatz hatte eine eigene programmierbare Hardware-MMU und konnte damit unabhängig von der CPU Speicherbereiche ummappen und somit a) den o.g. Speicherbereich z.B. auf Adressen jenseits der 1-MB-Grenze mappen oder b) mit Hilfe eines speziellen Gerätetreibers als EMS-Seiten zur Verfügung stellen. Der für EMS reservierte Speicher befindet quasi "außerhalb" des Adressraumes, bis eben auf die Speicherseiten, die über die EMS-Schnittstelle jeweils gerade eingeblendet werden.

Die CPUs ab dem 386er haben eine eigene MMU dabei, die all das ebenso kann. Dafür muss die CPU aber "Paging" aktiviert haben, was nur im Protected Mode oder Virtual 86 Mode geht. Treiber wie EMM386.SYS machen genau das.

2) XMS ist eine Schnittstelle, die Zugriff auf den Speicher jenseits der 1-MB-Grenze im Real Mode erlaubt, indem die CPU kurz in den Protected Mode geschaltet wird, die gewünschten Speicherbereiche umherkopiert werden (also von dem Bereich unter der 1-MB-Grenze in den Bereich jensweits davon und umgekehrt, oder zwischen zwei Bereichen jensweits der 1-MB-Grenze).

3) Dass der XMS-Treiber namens "Himem.sys" auch die HMA (also die ersten 64 KB jenseits der 1-MB-Grenze, die auch im Real Mode erreichbar sind) verwaltet, hat schlicht den Grund, dass der XMS-Treiber eben den Zustand des A20-Gates kennen und ggf. ändern muss.

Alle Fragen beantwortet, alle Unklarheiten beseitigt? --RokerHRO (Diskussion) 12:15, 24. Dez. 2021 (CET)

Vielen Dank für die ausführliche Antwort. Ich fasse es also mal so zusammen und was ich auch von anderen Webseiten so darüber finden konnte:

Der Adressbereich zwischen A0000hex…FFFFFhex ist für Peripipheriegeräte reserviert und das "dahinterliegende" RAM liegt brach, kann also nicht genutzt werden, oder wird per spezieller Chipsätze beim 286er in einen Adressbereich oberhalb von 1 MiB eingeblendet, so dass es dort wieder zur Verfügung steht. Ab dem 386 kann die MMU der CPU das von Haus aus.

EMS (Expanded Memory) kann von ISA Expander Karten oder, ab dem 286er aus dem höheren Speicherbereich oberhalb von 1 MiB kommen, sofern entsprechend viel RAM verbaut ist. EMS Speicher wird hierbei als maximal 64 KByte großer Block per Hardware in den Adressbereich des UMB, also zwischen A0000hex…FFFFFhex eingeblendet und steht dann für die Real Mode Anwendung, zur Verfügung.

XMS (Extended Memory) gibt es erst ab dem 286er, da erst ab diesem der Protected Mode zur Verfügung steht und die CPU höhere Adressbereiche adressieren kann. Damit eine Anwendung, die im Real Mode arbeitet, diesen Speicher nutzen kann, schaltet der XMS Memory Extender in den Protected Mode, kopiert dann den gewünschten Dateninhalt aus dem oberen 1 MiB Bereich in den konventionellen Speicher unterhalb von 640 KiB und schaltet dann in den Real Mode zurück und übergibt die CPU dann an den aufrufenden Real Mode Prozess. Ab neueren HIMEM.SYS Versionen wird die 386er CPU stattdessen in einen Unreal Mode geschaltet wo der Speicher dann ohne Umschalten in den Protected Mode zur Verfügung steht und was schneller als der Umweg über den Protected Mode und zurück geht.

Beide Varianten benötigen einen Treiber. Bei EMS bspw. für MS-DOS EMM386.SYS und bei XMS HIMEM.SYS. --84.158.122.178 07:41, 27. Dez. 2021 (CET)