8GB Speichernutzung trotz 32bit Programme

Mit einem 32-bit-Prozess: Keinesfalls. Mit 32-bit-Adresspointern ließen sich (ohne Vorzeichen, also "Large Address Aware") maximal 4 GB adressieren; ein Teil davon bleibt 32-bit-Prozessen aber zusätzlich versperrt für Funktionen im Windows-Kernel sowie für Geräte, die ihren eigenen Speicher in den RAM einblenden (Memory Mapped I/O; v.a. Grafikkarte und Soundkarte tun so etwas).

Man kann aber die 8 GB mit vielen parallel laufenden 32-bit-Programmen füllen.

Nein. "Normale" 32 Bit Programme koennen maximal 2 GB adressieren, mit einem kleinen Trick bis zu 4 GB (LARGEADDRESSAWARE Linker Flag).

Zitat von LigH

Mit 32-bit-Adresspointern ließen sich (ohne Vorzeichen, also "Large Address Aware") maximal 4 GB adressieren; ein Teil davon bleibt 32-bit-Prozessen aber zusätzlich versperrt für Funktionen im Windows-Kernel sowie für Geräte, die ihren eigenen Speicher in den RAM einblenden (Memory Mapped I/O; v.a. Grafikkarte und Soundkarte tun so etwas).

Hier bringst du aber einiges durcheinander. Auf einem 64 Bit System kann eine (large address aware) 32 Bit Anwendung die vollen 4 GB adressieren. Die Mappings in den 4 GB Bereich sind ausserhalb des Speichers fuer Anwendungen und das auch nur bei 32 Bit Windows.

Edit:
Siehe auch hier:

Zitat

Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory. If you run Testlimit on 64-bit Windows, you’ll see it consume the entire 32-bit addressable address space

Aaaha ... dann lohnt es sich ja doppelt, auf ein 64-bit-Windows zu setzen: Nicht nur dass 64-bit-Prozesse mehr als 4 GB RAM adressieren können, auch 32-bit-Prozesse kommen sogar weit über die 3,25 GB, oder wie viel bei 32-bit-Windows üblich war. Dann kann man den PAE-Kernelpatch als "netten Versuch" stecken lassen.

Nein, nicht mit einem Registry-Eintrag. Und mehr als 4 GB pro 32-bit-Prozess auch nicht.

Das "Large Address Aware"-Flag ist ein Eintrag im Header einer EXE, der darauf hinweist, dass der Compiler bzw. Linker darauf geachtet hat, bei Pointern alle 32 bit für die Adresse zu verwenden und das höchstwertige Bit nicht für Markierungen eines Status zu missbrauchen (z.B. ob der Pointer im Moment überhaupt auf einen zugewiesenen Bereich verweist).

Man kann den Header von Programmen patchen, dass sie das LAA-Flag bekommen. Wenn sie Pointer ohne Sonderfunktionen verwenden, geht das auch eventuell gut. Sollte aber das höchstwertige Bit für besondere Funktionen missbraucht werden (weil 32-bit-Prozesse auf 32-bit-Systemen ja nur maximal 2 GB adressieren können), dann kann ein Patch mit LAA-Flag auch zu Abstürzen führen. Das kann auch passieren, wenn DLLs in diesem Programm benutzt werden, die das tun (wie bestimmte Direct3D-Teile; aber immer wenn man etwas sucht, findet man alles andere...).

Richtig, so was kann man machen. Das wurde bereits bei einigen kommerziellen 3D-Spielen erfolgreich getan (teilweise bevor dann die Hersteller selber LAA-Builds veröffentlicht haben), z.B. Gothic 3 oder Skyrim.

Das geht auch mit VirtualDub; leider mag Avery Lee das nicht von sich aus tun, weil alle Plugins das auch verkraften müssten.

Zitat von Avery Lee

Sorry, this does indeed allow greater memory usage, but I can't do this. VirtualDub itself is fine with /LARGEADDRESSAWARE, but plugins would also be affected by this change. I incurred a raft of issues when I did something similar by enabling visual styles and it turned out that several video filters had interface problems with version 6 of comctl32.dll. I would need to find another way to handle this issue
like a prelauncher or running Avisynth out of process.

Neben dem Tool von NTCore würde ich eher das von FordGT90Concept empfehlen, weil letzteres erst auf Knopfdruck patcht und das auch rückgängig machen kann, außerdem verwaltet es alle bisher bearbeiteten Programme.

Zitat von LigH

Dann kann man den PAE-Kernelpatch als "netten Versuch" stecken lassen.

Ich bin froh, daß es den PAE-Kernelpatch gibt, weil das 64-Bit-W7 kein vernünftiges DOS mehr hat. Ich habe einen Rechner deshalb extra von 64- auf 32-Bit downgegraded. Glücklicherweise gilt eine W7-Lizenz für 32- und 64-bit-Versionen gleichermaßen.

Gruß

akapuma

Zitat

downgegraded.

statt beide Systeme auf 2 getrennten Platten installieren.
Trägerlose Schublade auf...und die andere HDD rein....

Jeder, was er braucht ... ich hatte letztens Probleme mit einem alten USB-Scanner, für den es keine W7-Treiber mehr gab, den hab ich noch zeitweise per XP in VirtualBox verwendet.

Dann gab's Austausch-Hardware.

Zitat von akapuma

weil das 64-Bit-W7 kein vernünftiges DOS mehr hat

Das hat es doch seit dem NT-Kernel (NT bzw. 2000) nicht mehr? Wie unterscheiden sich denn die "DOSse" in Win 7 32 und 64 Bit?

Zitat von illCP

Das hat es doch seit dem NT-Kernel (NT bzw. 2000) nicht mehr? Wie unterscheiden sich denn die "DOSse" in Win 7 32 und 64 Bit?

Ganz einfach. Wenn ich bei W7-32 auf ein DOS-Programm klicke, dann startet es. Wenn ich das bei W7-64 mache, dann kommt eine Fehlermeldung. Es sind selbst gemachte DOS-Programme, mit PowerBasic for DOS. Im Anhang ein Beispiel, weil ich die Fehlermeldung nicht mehr kenne.

INTERPOL.7z

Gruß

akapuma

Zitat von akapuma

Ganz einfach. Wenn ich bei W7-32 auf ein DOS-Programm klicke, dann startet es. Wenn ich das bei W7-64 mache, dann kommt eine Fehlermeldung. Es sind selbst gemachte DOS-Programme, mit PowerBasic for DOS. Im Anhang ein Beispiel, weil ich die Fehlermeldung nicht mehr kenne.

INTERPOL.7z

Gruß

akapuma

Bei Windows 95/98 konnte man noch mit Einschränkungen auf das darunterliegende DOS zugreifen. Windows NT (alles von 3.1 bis 6.x) hat kein DOS, die "Eingabeaufforderung" ist eine Emulation.
Genug mit dem Haarspalten - 16 Bit Programme laufen nicht auf 64 Bit Windows. Es gibt aber DosBox.

Darüber hinaus hat Windows 7 64-bit auch kein Textmodus-Vollbild mehr. Also Alt+Enter geht mit dem Far Manager beispielsweise nicht mehr.

Irgendwann ist mal Schluss mit Abwärts-Kompatibilität. Und das hat durchaus auch gute Gründe.

Stimmt, 16 Bit-Programme laufen ggf. noch unter Win 7 32 Bit, unter 64 Bit nicht mehr - das betrifft nicht nur DOS- sondern auch Windows-Programme. Adobe Premiere 6.5 lässt sich beispielsweise unter Win 7 64 nicht mehr installieren: Das Programm an sich ist zwar eine 32 Bit-Anwendung, der Installer jedoch 16 Bit.

Zitat von LigH

Irgendwann ist mal Schluss mit Abwärts-Kompatibilität. Und das hat durchaus auch gute Gründe.

So ist es. Wenn nun gar kein Weg an der Verwendung alter DOS-Programme (die wohlgemerkt mittlerweile mindestens 13 Jahre alt sein müssen) vorbeiführt, würde ich hier eher auf das von Grouch genannte DOSBox oder - falls hier Probleme/Inkompatibilitäten auftreten - eine Kombination aus einer Virtualisierungssoftware (kostenlos z.B. VirtualBox, kostenpflichtig VMWare) und einem "echten" DOS (z.B. das kostenlose FreeDOS oder ein originales MS-DOS 6.22) setzen.

Mein DOS-Programm wird von GKnot heraus gestartet, und startet selbst verschiedene Windowsprogramme, z.B. x264 und mkvmerge. Ich glaube, daß die Verwendung einer Box da nicht so einfach ist.

Ich kann mit Win7/32 gut leben. Meine Rechner haben 4GB, die ich dank PAE-Kernelpatch auch nutzen kann.

Gruß

akapuma

Ich hoffe allerdings für dich, dass du dein AGKP ebenso als Win32-CLI erzeugen lassen kannst. Du bist ja nicht sein einziger Anwender ... möglicherweise ...