Do 29. Mär 2012, 10:42 von DOSferatu
Ich kann erklären, woran das liegt.
Wenn man mehr als 63,99999 MB RAM drin hat, gibts Probleme.
Denn die "Mechanismen" (Subroutinen) lesen nicht die ERSTEN 64 MB, sondern die "UNTERSTEN". Will sagen: 64 MB-1 ist eine 26 Bit Zahl.
(Erklärt sich so: Speicher >1MB wird in 1kB-Blöcken reserviert, weil 1024 = 10 Bit, bleiben 16 Bit übrig. Man kann da nur max. 65535 solcher Blöcke reservieren, da 16Bit Technik/Programmierung.)
Alle Bits über 26Bit werden "abgeschnitten", es passiert quasi ein sogenannter "Wraparound", d.h. von einer Zahl, die größer als 26 Bit ist, werden als Speichergröße dann nur die untersten 26 Bit genommen (wobei - siehe oben - natürlich die untersten 10 Bit = 0 sind).
Hat man also ein Vielfaches von 64 MB an Speicher drin, so wird als Speicher 0 MB zurückgegeben. Oder anders ausgedrückt: Es wird immer die Menge Speicher zurückgegeben, die den REST entspricht, der bei Teilung der wahren Speichermenge durch 64MB entsteht:
Beispiel:
24 MB div 64 MB = 0, Rest 24 MB
72 MB div 64 MB = 1, Rest 8 MB - Hier würde 8 MB freier Speicher angezeigt.
Dasselbe Problem gab es auch mit älterem DOS Zeug. Grund dafür war die HIMEM.SYS (bis Version 2.x), die nur mit 16Bit Registern gearbeitet hat und auf maximal 64MB minus 1024 beschränkt war.
Die HIMEM.SYS ab Version 3.0 haben auch Befehle, die mit 32Bit Registern arbeiten und daher die vollen 4 GB erkennen/reservieren können (die Befehls-Nummern entsprechen dann den normalen 16Bit-Befehlen - die es dort auch noch gibt - plus 128). Damit könnte man theoretisch 4096 GB (4 TB) reservieren lassen - natürlich erlaubt 32Bit-Adresserung nur max. 4 GB.
ABER: Selbst wenn man jetzt eine neue HIMEM.SYS (v 3.0) in das Windows-3.x-Verzeichnis reinkopiert, ist nicht gesagt, daß dies dann auch mit den 32Bit-Befehlen benutzt wird.