Large-Address-Aware flag

**Luckie**

Jupp, es muß erstmal im Windows aktiviert sein, dann muß das PE-Flag gesetzt sein und alle Programmteile in deinem Programm müssen dieses unterstützen (sonst passieren unerwartete Dinge).

Nicht nur dann. Das kann auch schon so passieren, weil Windows dann auch an seine Grenzen kommt. Für Windows bleiben dann nämlich nur 1 GB Adressen im Adressraum übrig. Und das ist arg knapp.

**himitsu**

Alle Programme zusammen können mehr als die 2 GB belegen.

Das Flag sagt ja nur, daß der einzelne Prozess nicht mehr als 2 virtuelle GB bekommt.
Aber auch mit nur 2 GB können schon 2 solcher Programme alles überfüllen. Mit LAA würde das nur schon ein einzelnes Programm schaffen.

**BUG**

Zitat von himitsu:

Alle Programme zusammen können mehr als die 2 GB belegen.

Das Flag sagt ja nur, daß der einzelne Prozess nicht mehr als 2 virtuelle GB bekommt.
Aber auch mit nur 2 GB können schon 2 solcher Programme alles überfüllen.

Afaik geht es darum, das Windows im virtuellen Adressraum des Programm (eines jeden Programms) zu wenig Platz hat. Es geht also nicht direkt um den physikalischen Speicher.

**Luckie**

Normalerweise hat jeder Prozess unter 32-Bit einen Adressraum von 4GB, wo von 2GB für Windows reserviert werden. Dort blendet Windows die Adressen der System DLLs ein. Wird nun dieses Flag gesetzt, hat ein Prozess von diesen 4GB 3GB zur Verfügung und Windows nur noch 1GB. Und mit 1GB stößt Windows so ziemlich an seine Grenzen.

**himitsu**

Das hast du jetzt falsch verstanden.

Von dem virtuellen Adressraum der Anwendungen nimmt Windows nix für seine Verwaltungsaufgaben, sowie für die Cache.

Windows 32 hat seinen 2/4 GB adressierbaren Speicher ... mit PAE (Physical Address Extension) auch mehr.
Dazu dann noch die Pagefile.

Die reservierten/genutzten Teile des virtuellen Speichers jeder Anwendung wird dabei in den physischen Speicher gemäppt,
wobei es sich standardmäßig (vorwigend) von den hohen physikalischen Speicherbereichen etwas für sich und die Treiber nutzt.

Mit LAA kann man jetzt erstmal nur sagen, welchen virtuellen Bereich die Anwendung nutzen kann/darf,
aber wo dieses dann im physischen Speicher (RAM/Pagefile) liegt, ist dem Programm selber vollkommen egal.
Die einzelnen virtuellen Speicherblöcke können sogar wild verteilt im physischen RAM und teilweise auch in der Pagefile liegen.

Einige Teile existieren sogar nichmal direkt im RAM. Viele der MMFs z.B., worüber auch die Binaries der EXEn/DLLs im virtuellen Arbeitsspeicher liegen.
Ist nicht genug Platz im RAM, dann landen große (unveränderte) Teile nicht in der Pagefile ... wäre ja unnötig, da die ja direkt in der EXE-Datei zu finden sind, von wo man sie wieder laden kann, sobald das Programm sie benötigt.

**Luckie**

Bitte nachlesen:

http://msdn.microsoft.com/de-de/library/ms189334.aspx
Und wirf auch mal einen Blick auf die Grafik. Sie zeigt genau das, was ich erklärt habe.

Zitat:

Alle Betriebssystemversionen ab Windows 2000 Server, einschließlich Windows Server 2003, besitzen einen Parameter in Boot.ini, mit dem Anwendungen Zugriff auf 3 GB Prozessadressraum gewährt wird. Der Adressraum für den Kernelmodus wird dann auf 1 GB beschränkt.

Wo, sich die Daten dann letztendlich befinden, drüber habe ich gar keine Aussage getroffen. Ich kenne ein Windows mit 512MB, dass da der Adressraum auf die Festplatte ausglegaret werden muss ist klar.

**himitsu**

Deswegen muß man es doch auch an 2 Stellen aktivieren, wenn man es nutzen will.

Einmal für Windows (wobei z.B. die WindowsFileCache nicht nur auf den höheren Speicherbereich beschränkt ist)
und dann noch das Flag im jeweiligen EXE-Header.

Das EXE-Flag hat aber keine Wirkung auf die "reale" Speicherverwaltung des Windows,
sondern nur auf die Virtuelle der Anwendung.

**Luckie**

Zitat von himitsu:

Deswegen muß man es doch auch an 2 Stellen aktivieren, wenn man es nutzen will.

Ich habe nichts anderes behauptet.

Zitat:

Einmal für Windows (wobei z.B. die WindowsFileCache nicht nur auf den höheren Speicherbereich beschränkt ist)

Wie kommst du denn jetzt auf den Windows File Cache?

Zitat:

Das EXE-Flag hat aber keine Wirkung auf die "reale" Speicherverwaltung des Windows,
sondern nur auf die Virtuelle der Anwendung.

Auch da habe ich nichts anderes behauptet.

**Bernhard Geyer**

Zitat von Luckie:

Wird nun dieses Flag gesetzt, hat ein Prozess von diesen 4GB 3GB zur Verfügung und Windows nur noch 1GB. Und mit 1GB stößt Windows so ziemlich an seine Grenzen.

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden? Es gibt genügend Teile von Windows die den Anwendungs-Prozessraum nicht tangieren. Bei 1GB physikalischen RAM gebe ich dir echt mit den Grenzen wenn es um Vista oder Win7 geht.

Ich gebe dir aber recht das man eigentlich in vielen Fällen einen Design-Fehler im Programm hat wenn 2 GB an virtuellen RAM für die nicht reichen würden. Außer natürlich man entwickelt sowas wie ein DBMS ...

Aber mir hat schon mal geholfen bis zur Behebung eines Implementierungsmangels die Anwendung mal mit dem 3GB-Schalter kompilieren zukönnen

. Und da mittlerweile 64-Bit Windows der Standard ist braucht der Anwender auch nix konfigurien. Win32-Prozesse haben unter Win64 eigentlich immer 3GB zur "eigenen" Verfügung.

**Luckie**

Zitat von Bernhard Geyer:

Und? Schon mal ein Windows gesehen das versucht annähernd 1 GB an System-DLLs in einem 32-Bit Prozess zu laden?

Keine Ahnung, aber laut Jeffrey Richter, sind angeblich schon 2GB unter Windows 200 recht knapp bemessen. Eventuell hat sich das ab Windows XP geändert.