vom Prog benutzter Speicher nicht in XP Taskman sichtbar?

[Poison Nuke]

Ich habe in einem Program 5000 Bildschirmseiten in den Heap schieben lassen.

Diese konnte ich auch alle wieder einwandfrei abrufen.

Da ich im 50 Zeilen Modus arbeite, sind das insgesamt 8000 Byte pro Seite.
Theoretisch sollte die Anwendung 38MB RAM benötigen, aber im Tsakmanager von XP kann ich keine deratig große Zahl finden, und der Prozess "ntvdm", der ja für DOS zuständig ist, bleibt konstant bei 2600 kByte.

Wo sind diese 38MB aber nun hin???
die können doch nicht einfach verschwinden.

[Felix Kaiser]

Im Realmode fällt das flach und wenn du den Protected Mode nutzt wird das wohl auf den Kernel gerechnet. Der Prozess ntvdm stellt ja nur die Verbindung DOS Anwendung <-> Kernel her, Speicherverwaltung läuft über ihn, wo das genau hingerechnet wird weiß ich nicht, aber Kernelspeicher ist nicht an einen Prozess gebunden im Taskman.

Außerdem hast du Funktionen in Pascal, MemAvail, MaxAvail, etc... prüf doch mal damit.

[nj0y]

Wie kann das denn überhaupt sein, daß ein DOS-Programm mehr als 600 KB Speicher im Heap allokiert??

[Diogenes]

Ganz einfach: Es ist gar kein DOS-Programm mehr. Das DOS wird bei den 32ern emuliert. Ohne es jetzt zu wissen, denke ich, daß dann solche sachen wie GetMem und New "ganz normal" als 32er-Speicher angefordert wird, der vom ntvdm in einen 16-bit Speicherblock "umgerechnet" wird. Aber wie gesagt: Sicher weiß ich das nicht. Das ist nur 1 Vermutung!

[nj0y]

Hmmm, wie können > 1 MB Speicher gemappt werden in 640 KB? Poison Nuke hat das Programm mit Turbo Pascal 6.0 erzeugt, da kommt garantiert ein absolut reines DOS-Programm bei raus, das auch im normalen DOS läuft.

Das wäre ja mal einen Versuch Wert, mal gucken, was das Programm sagt, wenn man es unter normalem MS-DOS laufen läßt!? ;)

[Felix Kaiser]

Wenn er wirklich Turbo Pascal benutzt hat und das Prog im Realmode läuft, dann hat er schlampig geprüft. 5000 unterschiedliche Bildseiten kann er da nicht verwalten, er hat einen Fehler gemacht.

[Diogenes]

@nj0y: Vielleicht hast Du recht. Ich habe wohl ein wenig Real und Protected verwechslt :o

Aber wenn Poison Nuke tatsächlich 38MB im Real-Mode unterbringt ( :rolleyes: ), dann sollte es wohl auch unter echtem DOS gehen - obwohl ich nicht wirklich daran glaube...

[Poison Nuke]

hm, ich bin mir jetzt auch nicht mehr sicher.
Also das mit den einzelnen Seiten ansprechen hab ich mit 80 Seiten eindeutig gesehn, das es ging, bei den 5000 sah es aber auch so aus, als ob er alle Seiten einzeln laden konnte. Damit ihr mal die Fehler oder so finden könnt, hier der Quelltext:


Program FPS;

USES crt;
CONST pschirm:pointer=ptr(47104,0);
TYPE hilf=array[0..7999] of char;
help=array[1..5000] of ^hilf;
VAR philf :^help;
i,j :integer;
p :char;


BEGIN
clrscr;
randomize;
new(philf);
readln;

FOR i:=1 TO 5000 DO BEGIN
gotoxy(1,1); write(i);
FOR j:=1 TO 3999 DO
write(chr(random(3)+176));
move(pschirm^,philf^[i],8000);
END;

readln;
clrscr;

FOR i:=1 TO 5000 DO
move(philf^[i],pschirm^,8000);

readln;
dispose(philf);
END.

[nj0y]

Also wenn ich das richtig sehe, allokierst Du den Speicher für 5000 Pointer. Aber Du allokierst nicht 5000mal den Speicher für den Bildschirm. Die Pointer zeigen alle auf einen zufälligen Bereich im Speicher.

[Poison Nuke]

hm, dann hab ich das mit den Zeigern noch nicht drauf.

Könnte mir dann bitte jmd. erklären, wie ich ein Array aus dem Inhalt von Zeigervariablen deklariere, sodass ich so einen Array, wie ich verucht habe, erstellen könnte, wenn auch nicht mit sovielen Variablen, damit ich im Realmode weiter arbeiten kann.

[Felix Kaiser]

Vergisses, du allozierst ein paar Seiten, wenn der Heap voll ist, bekommst du entweder nen Laufzeitfehler oder nen Zeiger nil zurück. Das eine beendet, das andere ist riskant. Da nil auf 0000:0000 zeigt würdest du mit einem Move die Interrupttabelle überschreiben. Macht einer WinXP Dos Box nix aus, die wird geschlossen mit ner Exception, aber nen echtes DOS killst du dann damit.

[Poison Nuke]

@ Felix Kaiser

Aber es geht!
Ich habe dieses Prog durchlaufen lassen. (Auch wenn es erstmal ewig dauerte, eh die 5000 Bildschirme aufgebaut waren ;) ).

Aber in der nachfolgenden Schleife, wo alle Screeens wieder abgerufen wurden, konnte ich keine "Fehlerhafte" Darstellung erkennen. Und XP hat absolut kein Mucks getan.

Könntest du mir trotzdem mal erklären, wie ich einen Array von Zeigern handle (also wie deklariere ich einen solchen korrekt, und wie rufe ich ihn dann korrekt ab??????)

[nj0y]

Ich kenn mich zwar mit der Pascal-Syntax nicht mehr besonders gut aus (ist schon länger her :D), aber wenn Dein obiger Sourcecode korrekt ist, müßte das so gehen:

FOR i:=1 TO 5000 DO BEGIN
new(philf^[i]);
gotoxy(1,1); write(i);
FOR j:=1 TO 3999 DO
write(chr(random(3)+176));
move(pschirm^,philf^[i],8000);
END;

Neu ist dabei die zweite Zeile, in der Du zu jedem Pointer nochmal einen Bildschirminhalt allokierst.

[Felix Kaiser]

Das geht nicht du Nase, du guckst falsch. Versuch doch mal folgendes: Ein Array von 5000 Elementen die auf eine Liste von 2000 LongInt zeigen. Du hättest 10 Mio LongInt Werte (40 MB). Nun lass mal durchnummeriert alle Werte von 1 bis 10 Mio eintragen und geh dann mal rückwärts, in dem du hinten anfängst und schaust, finde ich wirklich ALLE Zahlen von 10 Mio bis 1 in richtiger Reihenfolge? Antwort: NEIN, probiers, dann merkst dus.

Ganz früher, am Anfang meiner Pascalzeiten, hatte ich auch teils lustige Effekte, die eigentlich NIE gehen dürften in der Theorie, später stellte sich dann IMMER heraus, dass da ein Bug drin war, der eigentlich nur glimpflich ausging und im Tatsächlichen ist nicht das passiert von dem ich dachte, es sei passiert. Hier schauts jetzt aus als ob man mehr als 640k Heap verwalten könnte, dem ist aber nicht so. Du kannst auch kein Auto mit einem Fahrrad abschleppen ...