PureBoard

Verfasst: **25.12.2011 23:58**

Jedes Programm hat einen virtuellen Speicherbereich, den es adressieren kann. Unter den meisten
NT-Systemen sind es IMHO 3 GB, wovon 1 GB für das System reserviert bleibt, man also sowieso
nur max. 2 GB verwalten kann. Mehr wird man mit AllocateMemory auch nicht allokieren können,
da PB den Heap- verwendet, was auch für autom. freigeben bei Beendung des Programmes sorgt.

Also werden Deine Berechnungen niemals in einen Bereich kommen, wo der Wert negativ ist.
Unter 64-Bit schon gar nicht erreichbar.

In sehr speziellen Situtationen, Du verwaltest den Speicher selbst (Treiber erforderlich), wäre es
natürlich schöner, wenn PB den Pointer unsigned interpretieren würde (normalerweise natürlich auch,
aber ist nur kosmetisch).

Meine Hand lege ich allerdings nicht dafür ins Feuer, das alles von mir gesagte so 100% trifft, aber
es sollte so in etwa stimmen.

Frohes Fest
Thomas

Verfasst: **26.12.2011 12:17**

Ich finde die Diskussion etwas überflüssig. Ein Fehler ist ein Fehler ist ein Fehler. Was bringt es also darüber zu diskutieren unter welchen Umständen ein Fehler zu Problemen führen kann, wenn es ohnehin viel weniger Arbeit kostet den Fehler einfach zu beheben und man damit auf der sicheren Seite ist?

Eine 32-bit Anwendung kann auch mehr als 4gb adressieren (32-bit CPUs haben schon seit längerem dazu Mechanismen die allerdings nur selten genutzt werden). Ein 32-bit Programm 'sollte' 4gb adressieren können. Unter manchen 64-bit Systemen kann es dies auch. Bei 32-bit Systemen sind es je nach OS und Konfiguration dann 2gb (die kompatible Lösung wegen zu vielen Programmen die Pointer vorzeichenbehaftet verarbeiten), 3gb, 3.5gb oder gar 3.75gb.

Stichworte zum Suchen sind das IMAGE_FILE_LARGE_ADDRESS_AWARE Flag in executables, die /3GB Option, PAE (http://msdn.microsoft.com/en-us/windows ... e/gg487503) und AWE (http://de.wikipedia.org/wiki/Address_Wi ... _Extension).

Verfasst: **26.12.2011 12:33**

Deine Links beziehen sich aber auf den Speicher, den Windows verwalten kann, nicht auf den, den ein einzelnes Programm
nutzen kann, das sind zweierlei paar Schuhe

Verfasst: **26.12.2011 15:17**

Ich weiss nicht worauf Du das beziehst, aber Du hast offenbar nicht alles gelesen worauf ich verwies.

Verfasst: **26.12.2011 15:24**

http://www.winpage.info/pages/Windows/4GB-Problem.php hat geschrieben:Nicht zuletzt aufgrund der drastisch gesunkenen Speicherpreise werden immer mehr Rechner mit mehr als 2 GB, oder gar noch mehr, Arbeitsspeicher ausgerüstet. Spätestens wenn es in Richtung der 4 GB geht, taucht dann eben immer wieder die Frage auf, warum die 4 GB nicht komplett angezeigt, bzw. genutzt werden.

Grundsätzlich muss man hier schon einmal zwischen einem 32-Bit und einem 64-Bit Betriebssystem unterscheiden. Außerdem muss man noch zwischen Anwendungen und Betriebssystem unterscheiden. Einer einzelnen Anwendung kann unter einem 32-Bit Betriebssystem maximal 2 GB an Arbeitsspeicher zugewiesen werden. Die restlichen 2 GB sind für den Betriebssystem-Kernel reserviert. Unter einem 64-Bit Betriebssystem sind es maximal 4 GB für eine einzelne Anwendungen.

Viel entscheidender ist jedoch die Tatsache, wie viel Arbeitsspeicher das Betriebssystem überhaupt verwalten kann, und da sind es bei einem 32-Bit Betriebssystem eben die ominösen 4GB.

Verfasst: **26.12.2011 15:59**

Unter einem 64-Bit Betriebssystem sind es maximal 4 GB für eine einzelne Anwendungen.

Wie bitte? Bezieht sich das so wirklich auf Windows?
Auf dem 64-Bit Linux, das wir zwecks Seminar an der Uni stehen haben, kann ich locker 900 GB RAM allozieren mit einer einzelnen Anwendung. Das System hat 1 TB RAM. Was würde es da bringen, wenn man nur 4 GB pro Anwendung nutzen kann?

Verfasst: **26.12.2011 16:24**

Microsoft hat geschrieben:By default, 64-bit Microsoft Windows-based applications have a user-mode address space of 8 terabytes.

http://msdn.microsoft.com/de-de/library/bb978906.aspx

Verfasst: **26.12.2011 17:25**

Die Infos von winpage.info sind schlichtweg falsch. Stichworte hab ich genannt aber Google/MSDN nutzen und lesen, muss man schon selber

Ich geb aber zu, dass das mit PAE/AWE kaum jemandem bekannt ist und auch nur sehr selten benutzt wird (manche 32-bit SQL Server nutzen es) aber das mit den bis zu 4gb in 32-bit Anwendungen, findet man öfter. Spiele profitieren z.b. davon als 32-bit Version und Tips wie man das nutzt finden sich deshalb auch unter Gamern. Gamer schrecken bekannterweise vor wenig zurück

Aber damit das funktioniert, darf man eben Pointer nicht vorzeichenbehaftet behandeln.

Verfasst: **27.12.2011 01:35**

Um das ganze mal wieder zurück zu holen:
Ich habe nun beschlossen sicherheitshalber nur noch auf Äquivalenz zu prüfen, soll heißen:

Code: Alles auswählen

While Not *Tiefer = *Hoeher
   ;...
   *Tiefer + 4
Wend

oder halt

Code: Alles auswählen

Repeat
   ;...
   *Tiefer + 4
Until *Tiefer = *Hoeher

Verfasst: **27.12.2011 02:57**

Auf meinem 64-Bit windows mit 4 GB RAM schaffe ich es nicht 2 GB RAM in einer 32-Bit Anwendung zu allokieren, bei
knapp über 1,5 GB ist schluß. Mit einer 64-Bit Anwendung gibt es da keine Problem.

Aber das die Pointer unsigned sein sollten, da gebe ich euch recht.

PureBoard

Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?

Re: Wieso sind Pointer vorzeichenbehaftet?