Fehler: Für diesen Befehl ist nicht genügend Speicher verfügbar.

[Michaell]

Zitat:

Zitat von himitsu (Beitrag 1395863)

Bei halbwegs aktuellen 64 Bit-Windowsen ist das standardmäßig schon seit Jahren aktiviert.

Wie im 1sten Beitrag geschrieben: Die PCs wo meine SW läuft verwenden Win 7 oder Win 10 jeweils in der 32 Bit Version. Nur mein Entwicklungsrechner ist 64 Bit und dort hatte ich das Problem noch nie.

[himitsu]

3-GB und 4-GB ist quasi das Gleiche.

3-GB deshalb, weil ein 32 Bit-Windows den letzten 1 GB für Treiber und Cache nutzt und daher nicht den User-Mode-Programmen zur Verfügung stehen.
In 64 Bit-Windows sind für 32 Bit Programme daher bis zu den vollen 4 GB nutzbar.
(die ersten 64 KB sind aber nie nutzbar und sind immer nur Treibern vorbehalten, als Puffer für die Übergabe in den Programmspeicher)

Je nach Windows-Version und verfügbaren RAM sind dann halt 3, 3.5, "ewta" 3.75 oder eben 4 GB im Programm, bzw. "physische" für alle Programme nutzbar.



Tja, im 32 Bit-Windows ... k.A. wie es da in aktullen Windowsen (nach Windows 9x) aussieht, also ob schon aktiv oder nicht.
Du kannst dir eine Testanwendung schreiben,
die 4GB-Option aktivieren (

Delphi-Quellcode:

{$SetPEFlags IMAGE_FILE_LARGE_ADDRESS_AWARE}

),
GlobalMemoryStatusEx abfragen, ullTotalVirtual anzeigen (MEMORYSTATUSEX)
und dann ausprobieren was überall geht.


[info]
Effektiv kann ein Programm in jedem 32 Bit-Windows auch über 4 GB Arbeitsspeicher verwalten. (z.B. über Pageing, MemoryMapping usw.)

Ich habe hier ein kleines Testprogramm (32 Bit-Konsolenanwendung), das reserviert sich physischen Speicher und macht dir locker 100 GB RAM voll, ohne dass der Speicher ausgelagert werden kann (Pagefile).
Aber das hilft dir nicht viel, da du den Speicher nicht selber verwaltest.

[Michaell]

Zitat:

Zitat von Michaell (Beitrag 1395858)

Genau das mache ich zur Zeit, deshalb kommt doch auch beim Programstart die Meldung. Der Tipp hier ist aber "... den Bereich früh einmal anfordern ..." -> ich muß mir die Reihenfolge meiner vielen "new" ansehen und gegebenenfalls bzw. wenn möglich umsortieren.
...

Das war tatsächlich möglich: Via 'Project -> Options -> Forms' kann man alle Formulare sortieren. Ich habe also mein frmBitmap an die 2te Stelle nach meinem Hauptformular verschoben. Das kann man dann auch in der <ProjectName>.cpp Datei sehen:

Code:

...
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{    try
     {
                 Application->Initialize();
                 Application->HelpFile = "";
       Application->CreateForm(__classid(Tfrm_MainWin), &frm_MainWin);
       Application->CreateForm(__classid(TfrmBitmap), &frmBitmap);
       Application->CreateForm(...
     }
     catch ...
}

Dort habe ich dann einen Breakpoint gesetzt, step over durchgeführt und Sch... der Fehler ist noch immer da. :(
Widerspricht das nicht der Annahme, das ich im 2 GiB Adressraum meines Progs. zwar genug freie Speicherbereiche habe aber halt keinen der die benötigten ca. 300 MiB hat?

[EWeiss]

Wo ist denn dein Problem mache es doch so wie Zacherl gesagt hat teile das Bitmap in 4 oder mehr Teile auf und gut ist.
Irgendwann wirst du immer an eine grenze stoßen und dann ?
Fängst wieder von vorne an.

gruss

[himitsu]

Zitat:

Delphi-Quellcode:

Application->CreateForm(...

k.A. wie viel das ist,
aber, wenn man sich schon bei Programmstart mit allem Möglichen den Speicher zumüllt, dann kann es schonmal bissl eng werden.

Man kann alternativ die Forms auch erst dann "dynamisch" erzeugen, wenn man sie wirklich braucht.


Aber so oder so, ab spätestens 250-300 MB gibt es immer mal Probleme, in 32 Bit-Anwendungen. (persönliche Erfahrungswerte)
Die einzig sichere Lösung ist also ein Auftrennen oder Verkleinern dieses großen Blocks. (oder in einen separaten Prozess auslagen oder 64 Bit)

[Der schöne Günther]

Ich verstehe noch nicht was

Delphi-Quellcode:

Application->CreateForm

damit zu tun hat. Kann man die Bitmap nicht vor den ganzen Formularen erstellen? Wenn man dann noch nicht einmal 300 MB am Stück hat würde ich mich allerdings auch wundern :!:

[himitsu]

Für die 300 MB ist so schon kaum freier Speicher.
Wenn du vorher nun noch mehr Speicher im RAM belegst, dann erhöht sich die Chance, dass kein zusammenhängender 300 MB-Block mehr verfügbar ist.

[KodeZwerg]

Du könntest dir eine Prozedur schreiben die den komplett installierten (nicht nur den freien) Speicher belegt so das Windows gezwungen wird Auszulagern, nun gib den Speicher wieder frei, je nach Windows Einstellung steht Dir nun sehr viel mehr am Stück zur Verfügung oder Dll's von anderen Anwendungen laden sich selbst wieder in den schnellen Speicher, das mehr frei ist > ist ein positiver Nebeneffekt, das es Zeit kostet (auch Windows Nachladezeit, da alle Caches danach überfüllt bzw geleert sind) ist als negativer Aspekt anzusehen (Icons Fenter Text Farben alles wird neu erschaffen).
(Ziel der Übung: Memory Defrag)

[Der schöne Günther]

Das ist nicht richtig.

Was Windows macht ist völlig unerheblich, Windows hat genug Puste. Eine Anwendung (z.B. Delphi) arbeitet sowieso nicht mit "echtem" Hauptspeicher sondern mit virtuellem Speicher. Das Betriebssystem (z.B. Windows) kümmert sich in Kombination mit spezieller Hardware-Beschleunigung aus der CPU um die Übersetzung von virtuellen Adressen deines Prozesses in die entsprechenden "echten" Speicheradressen.

Der virtuelle Speicher ist hierbei weiterhin in Seiten unterteilt. Das Ein- und Auslagern betrifft Seiten. Es ist egal welche Seiten Windows hier ein- und auslagert, das Problem betrifft seinen privaten, virtuellen 2GB-Adressraum für seinen Prozess. Davon dass diese Seiten auch wild über den Arbeitsspeicher verteilt sein können (siehe Bild) wollen wir gar nicht erst anfangen.

Viele kleine Stücke zu belegen und anschließend freizugeben verändert nicht die "Reihenfolge" in diesem Adressraum. Es wird ihm danach nicht mehr zusammenhängender Speicher zur Verfügung stehen.

Viel Zeit zum Lesen?

1. https://de.wikipedia.org/wiki/Paging
2. Silberschatz et. al: Operating System Concepts

[Luckie]

Ich denke, da läuft grundsätzlich was falsch bei ihm. Man nehme doch nur mal Photoshop oder Audio-Bearbeitungsprogramme, die auch schon unter 32 Bit mit großem Dateien umgehen konnten. Also ich bin ja meist der Überzeugung, wenn man an die Grenzen von Windows stößt, macht man was falsch.