Prozessdaten abrufen und anzeigen

[Kolumbus]

Hallo,

ich arbeite unter XP SP2 mit BDS 2006 und habe eine kleine VCL-Anwendung, die auf eine Dll-Fkt dynamisch zugreift, erstellt. Der Zugriff auf die Dll-Fkt erfolgt über den Zwischenschritt einer Import-Datei. Nachdem die Dll-Fkt abgearbeitet wurde, werden die Resourcen mit FreeLibrary() wieder freigegeben, sollten sie jedenfalls...
Allerdings steigt nach jedem neuen Aufruf der Dll-Fkt die Speicherauslastung des Prozesses um ca. 1000k (laut TaskMgr). Ich habe leider keine Ahnung warum das so ist, da ich Anfänger bin und suche nun nach einer Lösung. Dabei geht es mir auf den Geist ständig den TaskMgr öffnen zu müssen. Der TaskMgr bezieht ja die Prozessdaten irgendwo her, also dachte ich man könnte ja die Speicherauslastung vielleicht auch im Form der Anwendung über ein Label anzeigen lassen, wenn man an die Daten herankommt.
Irgendwo hab' ich schon was von Process->WorkingSet gelesen, habe aber keine Ahnung wie man das implementieren soll...

Könnt Ihr mir helfen an die erforderlichen Prozessdaten zu kommen?

[Christian Marquardt]

Schon CodeGuard ausprobiert?

Sinnvoller als dein geplantes Vorgehen erscheint es mit jedoch, sich den Quelltext der DLL anzuschauen

Ansonsten fang hier an

http://msdn2.microsoft.com/en-us/lib...91(vs.80).aspx

[Kolumbus]

Danke schonmal für die Antwort,

allerdings bin ich damit noch nicht weiter... Im msdn steht ja, dass man mit Working Set Minimum und Maximum des Speichers rausbekommt bzw festlegt - welcher Wert wird denn im TaskMgr angezeigt? Ich dachte der tatsächlich momentan belegte... Und wie komm' ich an den?

In der Dll, ist eine abgewandelte Tutorial-Aufgabe, (eigene Aufgaben üben besser) steht bei mir nur eine klitzekleine Funktion - ungefähr so:

Wait(int W)
{
    sleep(W);
    Application->ProcessMessages;
}

Dann habe ich eine Import-Datei, mit einem Zeiger auf die Dll-Fkt. Dort lade ich in einer Funktion die Dll-Fkt.
Die Import-Datei includiere ich in meine Anwendung #include <Import.h> und rufe dann die Funktion zB. ImpWait(50); aus der Import-Datei auf, die wiederum die Wait-Fkt aus der Dll lädt. Wie oben geschrieben, entlade ich die Dll-Fkt wieder mit FreeLibrary(...); .
In der Anwendung gibt es einfach nur 2 Buttons und ein Label. Ein Btn startet eine Zählschleife von 0 bis 99, die einen delay von 100ms intern hat. Der andere startet dieselbe Zählschleife und nimmt den delay (50ms) aus der Dll-Fkt. Die Zählschritte werden im Label angezeigt, dazu der delay.
Das war schon Alles...

CodeGuard??? Wie, Was, Wo?

[Christian Marquardt]

Wenn das alles ist, was in der DLL steht, wird die DLL wohl direkt dafür nicht verantwortlich sein. Also was willst du mit den Speicherinfos??

Auch ist es schlechtes Vorgehen im Hauptprogramm

EINMAL zum Start es Programmes DLL holen und initialisieren und einmal zum Schluß freigeben.

Des Weiteren benötigt die DLL einen EXPORT und das Programm einen IMPORT. Das kann man in EINER *.h Datei machen
http://www.marquardtnet.info/cecke/t...Im- und Export

[Kolumbus]

Hallo,

Danke für die weitere Antwort. Anscheinend bin ich hier aber falsch. Ich habe nicht danach gefragt, ob es Sinn macht sich die SpeicherInfo's anzeigen zu lassen. Ich will es eben! Dabei kann ich im schlimmsten Fall NUR etwas lernen.

Wenn ich eine statische Dll wollte, hätte ich schon mit export und import gearbeitet, wie ich in meinem 1. Post schrieb - ich möchte eine dynamische Dll.

Und die Import-Datei brauche ich, damit man bei umfangreicheren Dll's noch den Überblick über die enthaltenen Funktionen behält. Aber wie schon geschrieben, ich wollte hier nicht die Sinnhaftigkeit meines Vorgehens oder die Vor- und Nachteile von statischen und dynamischen Dll's diskutieren.

Ich wollte einfach nur an die Prozessdaten...

So, denn

MfG

[Christian Marquardt]

Anscheinend bin ich hier aber falsch.

Du wirst dir wohl schon sagen lassen müssen, wenn du ein konzeptionellen Fehler hast. -> hier mehrmaliges Laden

Ich wollte einfach nur an die Prozessdaten...

Es gibt in Windows nicht einfach "nur die Prozessdaten". Um ALLES zu bekommen die ein Haufen von Systemfunktionen aufzurufen.

Dazu kann man Informationen aus der

Process_Information Struktur bekommen
mit Open Process Daten erfahren
uvm

Starte hier

http://msdn2.microsoft.com/en-us/library/ms684847.aspx

[Kolumbus]

Danke für Deine Geduld,

Du wirst dir wohl schon sagen lassen müssen, wenn du ein konzeptionellen Fehler hast. -> hier mehrmaliges Laden

Hm, entschuldigung - anscheinend hatte ich bisher nicht verstanden, dass ich einen Fehler mache!

Also mehrmaliges Laden... ich hatte das allgemein bisher so verstanden, dass ich beim ProgStart die Dll-Fkt noch nicht aufrufe / lade, sondern dies nur mache, wenn ich sie brauche; Ebenso die Dll selbst, erst wenn ich sie brauche referenzieren...
- Oder kann ich die Dll vorher referenzieren (Programmstart), die Dll-Fkt aber erst aufrufen wenn ich sie benötige und das ganze ist trotzdem noch dynamisch, weil das Referenzieren der Dll allein noch keinen großartigen Speicherverbrauch mit sich bringt? Meinst Du das so?

Zu den Prozessdaten:

... die Speicherauslastung des Prozesses ... (laut TaskMgr) ...

Mehr Prozessdaten wollte ich nie!

[Christian Marquardt]

Irgendwo sollte man ja mal seine Anforderungen anpassen:

Wenn ich eine Funktion in einer DLL habe, und diese nur ein paar Mal benutze, ist sicherlich zu diesem Zeitpunkt komplette Intitialisierung sinnvoll

bis zu

ich benötige die Funktion x-Mal in der Sekunde wo dann ein statisches Laden sinnvoll ist.

[Christian Marquardt]

Eigentümlich, dass du in anderen Foren genau die gleichen Antworten bekommen hast und es sich herausstellt, dass du auch noch die dyn. Implementierung falsch vorgenommen hast.....

[Kolumbus]

Das war gerade der springende Punkt - die Antwort habe ich mehrmals gebraucht, da ich mich ja an ein Tutorial gehalten habe und der Meinung war, es wäre richtig. Wenn ich von dem was ich mache nicht ein bißchen überzeugt wäre, bräuchte ich garnicht erst anfangen... erst recht als Anfänger. Und wenn man sich mal die Arbeit machen würde nachzuschauen, würde man sehen, dass ich mich sogar sehr genau an das entsprechende Tutorial gehalten habe. Es fehlen halten gewisse Randbedingungen im Tutorial, die durchaus drin stehen könnten - zumindest als Empfehlung.
Und ich möchte nochmal klarstellen: Es ging nicht darum ein sinnvolles Projekt zu schaffen, sondern im Bezug auf größere Projekte die Funktion von dynamischen dll's zu verstehen und das Erstellen zu üben. Das mit dem häufigen Aufruf war nun ein spezielles Problem der von mir erstellten Testanwendung, kein Generelles das aus Unverständnis herrührt.
Hier noch der Link zum Tutorial: Das Builder-Tutorial

MfG

Edit: Inzwischen Komme ich an die Prozessdaten heran, nach denen ich ursprünglich gefragt hatte. Über Pseudohandle aus GetCurrentProcess mit Funktion GetProcessMemoryInfo... Nur welche Bedeutung die Werte aus den Process_Memory_Counters haben, ist mir bislang noch ein Rätsel!? Über Tips hierzu wäre ich dankbar.