Wie frage ich die noch verfügbaren Windows-Resourcen ab?

[Stephan P.]

Hallo,

einem meiner Programme (oder besser gesagt, einem Programm, dass ein Benutzer mit meiner VCL-Komponentenbibliothek geschrieben hat), gehen anscheinend die Windows-Resourcen aus.

Ich wollte mir jetzt erst mal einen Überblick darüber verschaffen, wie das Programm mit den Resourcen umgeht. Wahrscheinlich bin ich blind, aber ich finde in der Delphi-Hilfe keine Funktion/Methode, mit denen sich die noch verfügbaren Windows-Resourcen (z.B. Windows-Handles) abfragen lassen. Kann mir da vielleicht jemand weiter helfen?

Ich benutze im Moment D7 auf WinXP, habe aber ab D5 auch alle anderen Delphi-Versionen zur Verfügung.

Vielen Dank im Voraus für Eure Hilfe,

Stephan

[Luckie]

Mit Hilfe eines Profilers solltest du die Speicherlecks finden können.

Hm, jetzt bin ich mir nicht mehr sicher, ob man die Dinger so nennt. Aber ich glaube FastMem kann so was auch.

[Bernhard Geyer]

Zitat:

Zitat von Stephan P.

Wahrscheinlich bin ich blind, aber ich finde in der Delphi-Hilfe keine Funktion/Methode, mit denen sich die noch verfügbaren Windows-Resourcen (z.B. Windows-Handles) abfragen lassen. Kann mir da vielleicht jemand weiter helfen?/quote]
Ich glaube nicht das es sowas gibt. Windows wird selbst nicht so genau wissen wieviele Handels es für den Prozess noch übrig hat.

Zitat:

Zitat von Luckie

Hm, jetzt bin ich mir nicht mehr sicher, ob man die Dinger so nennt. Aber ich glaube FastMem kann so was auch.

Nur wenn für jede GDI-Ressource ein Delphi-Objekt übrig bleibt. Für reine GDI-Ressourcen ist FastMM "blind". Hier ist u.U. AQTime sinnvoll einzusetzen.

[Sherlock]

Ich hab da was altes gefunden...das ist allerdings sehr alt.

Delphi-Quellcode:

function GetFreeSystemResources(SysResource: Word): Word;
var
  huser16, huser32: THandle;
  ThunkTrash: array[0..$20] of Word;
  fp, qfp: Pointer;
begin
  result := 0;
  if (SysUtils.Win32PlatForm = VER_PLATFORM_WIN32_NT) then
    exit; // NT
  huser16 := 0;
  huser32 := 0;
  try
    ThunkTrash[0] := huser16;
    huser16 := LoadLibrary16('user.exe');
    fp := GetProcAddress16(huser16, 'GetFreeSystemResources');
    huser32 := LoadLibrary('Kernel32');
    qfp := GetProcAddress(huser32, 'QT_Thunk');
    if (fp = nil) or (qfp = nil) then
      exit;
    asm
      push SysResource
      mov edx, fp
      call qfp
      mov Result, ax
    end;
  finally
    FreeLibrary16(huser16);
    FreeLibrary(huser32);
  end;
end;

Edit: Das Ergebnis sind wohl die freien Ressourcen in %...oder so ähnlich :mrgreen:

Sherlock

[Stephan P.]

Hallo Michael,

Zitat:

Zitat von Luckie

Mit Hilfe eines Profilers solltest du die Speicherlecks finden können.

danke für den Hinweis, aber ich gehe erst mal nicht davon aus, dass es sich um ein Speicherleck handelt. Hier werden wirklich (testweise) tausende Komponenten dynamisch angelegt, die von TCustomPanel abstammen. Mir würde es erst mal reichen, wenn ich eine passende Delphi-Funktion oder -Methode hätte, mit der ich ein Auge auf die noch verfügbaren Resourcen werfen könnte.

Viele Grüße,

Stephan

[Stephan P.]

Hallo,

Zitat:

Zitat von Sherlock

Ich hab da was altes gefunden...das ist allerdings sehr alt.

über GetFreeSystemResources bin ich auch schon gestolpert, aber das scheint noch aus 16-bit Delphi-Zeiten zu stammen...


Viele Grüße,

Stephan

[Sherlock]

Genau...laut MS gibt diese Routine unter W2k und XP immer 90% zurück ^^

Wie auch immer, hier noch ein weiter führender Link dazu:
http://support.microsoft.com/?scid=k...4924&x=18&y=11

Ich glaube auch, daß sowas nicht mehr benötigt wird.

Sherlock

[Bernhard Geyer]

Zitat:

Zitat von Sherlock

Ich glaube auch, daß sowas nicht mehr benötigt wird.

(GDI-)Resourcen sind auch unter Vista/2008 noch eine beschränktes Gut. Die Anzahl der verfügbaren Ressourcen wächst jedoch mit jeder Windows-Version.

[OldGrumpy]

Zitat:

Zitat von Stephan P.

danke für den Hinweis, aber ich gehe erst mal nicht davon aus, dass es sich um ein Speicherleck handelt. Hier werden wirklich (testweise) tausende Komponenten dynamisch angelegt, die von TCustomPanel abstammen. Mir würde es erst mal reichen, wenn ich eine passende Delphi-Funktion oder -Methode hätte, mit der ich ein Auge auf die noch verfügbaren Resourcen werfen könnte.

Das wird alleine schon bei den Windowhandles knapp, fürs Userland sind (bei XPXP2, wie es unter anderen Versionen aussieht, kann ich auf Anhieb nicht sagen) ohne Klimmzüge nur ca. 10.000 davon verfügbar - wenn die weg sind, schlagen Aufrufe zum Erzeugen eines neuen Fensters usw. einfach fehl und das wars. Diese Situation hatte ich mit dem IE7 häufig da ich dort etliche Tabs offen hatte (von denen frisst jedes unglaubliche Mengen an Handles) - man merkts dann erst wenn keine Fenster mehr aufgehen :) IE7 zumachen oder unbenötigte Tabs schließen und schon gehts wieder.

[Muetze1]

1. Ein Profiler kann die Laufzeiten in Programmteilen ermitteln - wie sollte dieser bei Speicherlecks helfen? Bitte auf Fachbegriffe achten, wenn sie schon genannt werden und nicht vollkommen verkehrt. (Luckie :warn: )
2. Bei Delphi kommt man leicht in die Bedrängnis mit den Resourcen, da viele einfache Objekte mehr Handles benötigen als man braucht. Ein TCanvas beinhaltet neben dem HDC auch gleich noch einen HPEN und HBRUSH.
3. Bei Win95 waren Windowsglobal ein GDI Handleliste von 32K verfügbar. Ab Win98 waren es schon 64K und mit ME wurde es auf 92K angehoben. Mit NT und deren Nachfolgern wurden die Handles dynamisch gehandhabt, aber trotzdem sind sie begrenzt. Hier greift aber eher der Windows eigene Schutz und so wird u.a. ein Prozess mit mehr als 20.000 reinen GDI Handles sang und klanglos beendet. Die VCL hält es manchmal durch die Exceptions nicht mehr aus und zerschiesst das Programm auch mal selber vor dieser Grenze, da es noch manche Ecken der VCL gibt, wo die alloziierten Handles nicht überprüft werden.

[Olli]

Zitat:

Zitat von Muetze1

1. Ein Profiler kann die Laufzeiten in Programmteilen ermitteln - wie sollte dieser bei Speicherlecks helfen? Bitte auf Fachbegriffe achten, wenn sie schon genannt werden und nicht vollkommen verkehrt. (Luckie :warn: )

Darauf habe ich nur eine Antwort: das " :warn: "-Smiley sollte man nur einsetzen, wenn man sich vorher nochmal seiner Aussage versichert hat. Nicht nur Fachbücher und Wikipedia widersprechen dir darin, daß Profiler mehr können und tun als die Laufzeit eines Codeabschnitts zu messen, sondern auch echte Profiler. AQTime (siehe angehangener Screenshot) zum Beispiel bietet weit mehr Optionen an. Und AQTime integriert sich auch in die Delphi IDE bzw. BDS. Habe ich derzeit aber nicht installiert, daher der Screenshot der Standalone-GUI von AQTime.

[Muetze1]

Zitat:

Zitat von Olli

Darauf habe ich nur eine Antwort: das " :warn: "-Smiley sollte man nur einsetzen, wenn man sich vorher nochmal seiner Aussage versichert hat. Nicht nur Fachbücher und Wikipedia widersprechen dir darin, daß Profiler mehr können und tun als die Laufzeit eines Codeabschnitts zu messen, sondern auch echte Profiler.

Ich hatte mich dessen versichert - u.a. in der angegebenen Quelle. Die Hauptaufgabe liegt im profiling und somit in der Zeit. Dies war bei den ersten Profilern vor Jahren schon ihre einzige Aufgabe und Möglichkeit und heutzutage wird natürlich mehr in die Produkte integriert, schon allein als Verkaufsargument. Eine Antivirenlösung ist heutzutage allein schon nicht mehr zu bekommen, sondern nur noch im Zusammenhang mit einem Skripblocker, Firewall, etc. Die Hauptaufgabe liegt trotzdem immernoch dem Namen entsprechend bei der Erkennung und entsprechenden Gegenmaßnahmen bei Viren. Ein BIOS war früher nur dazu da eine Grundinitialisierung des Rechners vorzunehmen und dann die Kontrolle an das OS abzugeben. Heutzutage befindet sich ein Linux mit im BIOS um zu surfen und auch ist es zu einem ganzen Serviceanbieter aufgestiegen und kann deutlich mehr als sein eigentlicher Hauptzweck, der sich noch immer durch den Namen widerspiegelt (Basic Input/Output System).

Mit anderen Worten: Die Grenzen verwischen und der genannte Profiler hat das gesuchte definitiv nicht in der Hauptaufgabe. Heutzutage könnte ich genauso gut einen Debugger empfehlen, der übernimmt solche gesuchten Dinge z.T. auch schon.

Im Ergebnis bleibe ich beim dem Smiley, da es nicht die Hauptaufgabe eines Profilers ist und es von daher auch noch genug Profiler gibt, welche dieses nicht unterstützen. Ich nutze z.B. ProDelphi und dies hat eine solche Funktion nicht und es auch ein Profiler...

[Olli]

Zitat:

Zitat von Muetze1

Eine Antivirenlösung ist heutzutage allein schon nicht mehr zu bekommen, sondern nur noch im Zusammenhang mit einem Skripblocker, Firewall, etc.

Wetten daß? Und wenn wir die letzte Firma sind, auch die neue, in Planung befindliche Version, wird sich auf diese Kernaufgabe konzentrieren. Ich will nicht ausschließen, daß irgendwann mal was anderes dazukommt, aber das Einzelprodukt bleibt verfügbar.

Zitat:

Zitat von Muetze1

Mit anderen Worten: Die Grenzen verwischen und der genannte Profiler hat das gesuchte definitiv nicht in der Hauptaufgabe. Heutzutage könnte ich genauso gut einen Debugger empfehlen, der übernimmt solche gesuchten Dinge z.T. auch schon.

Keine Frage. Und der Application Verifier zusammen mit WinDbg sind eine gute Alternative ... oder sollte ich besser sagen: wären eine gute Alternative, wenn ja wenn Delphi PDB oder zumindest die alten DBG (CV) Dateien erzeugen würde.

Zitat:

Zitat von Muetze1

Im Ergebnis bleibe ich beim dem Smiley, da es nicht die Hauptaufgabe eines Profilers ist und es von daher auch noch genug Profiler gibt, welche dieses nicht unterstützen. Ich nutze z.B. ProDelphi und dies hat eine solche Funktion nicht und es auch ein Profiler...

Sicher, gibt es Profiler die nicht alles anbieten und sicher sind die trotzdem Profiler. Der Punkt ist, daß aber diese verschiedenen Disziplinen (drei an der Zahl bei Wikipedia) von "Profilern" beherrscht werden (du kannst natürlich auch schnell die Wikipediaseite bearbeiten :zwinker: ). Nur weil der von dir benutzte nicht alle diese Disziplinen beherrscht, ist er nicht der Maßstab für den Begriff Profiler - aber er ist auch nicht weniger ein Profiler nur weil er nicht alle Disziplinen beherrscht. Das ist wie bei einem Kompiler von dem man verlangt, er solle alle Programmiersprachen kompilieren können.

Ich denke das Mißverständnis könnte im Begriff "Laufzeitverhalten" liegen. Die Betonung liegt dabei eben nicht auf Laufzeit, ansonsten könnte man ja auch direkt "Laufzeit" schreiben. Es geht oftmals nichtmal um Zeit sondern eher um die Anzahl von Aufrufen oder eben die Benutzung bestimmter Ressourcen. Und während nicht alle Profiler die AQTime unter diesem Namen anbietet auch der Definition auf Wikipedia entsprechen, so sind doch alle drei Disziplinen dort vertreten.

[Luckie]

Zitat:

Zitat von Muetze1

1. Ein Profiler kann die Laufzeiten in Programmteilen ermitteln - wie sollte dieser bei Speicherlecks helfen? Bitte auf Fachbegriffe achten, wenn sie schon genannt werden und nicht vollkommen verkehrt. (Luckie :warn: )

Du hättest nicht nur meinen ersten Satz lesen sollen, sondern auch den Rest des Textes. Dann hättest du gesehen, dass ich mir selber nicht mehr so ganz sicher war, wie man solche Programme nennt.

[Muetze1]

:warn: Thomas, lies die Beiträge genauer und äussere dich in diesem Forum nur fachlich und nicht zu anderen Themen, die dich nichts angehen - oder verschwinde hier.

Ich hatte den letzten Teil anders verstanden, weil Profiler gibt es und ich hatte deine Unsicherheit nicht auf die richtige Programmfunktion bezogen sondern auf den richtigen Namen des Programmtyps.

[OldGrumpy]

Zitat:

Zitat von Muetze1

:warn: Thomas,[...]

Wer ist Thomas? :gruebel:

[Muetze1]

Zitat:

Zitat von OldGrumpy

Zitat:

Zitat von Muetze1

:warn: Thomas,[...]

Wer ist Thomas? :gruebel:

Ich war gemeint. Das war eine ironische Aussage an mich selbst adressiert. Da es mir hier z.Z. mehr als zu bunt ist, habe ich aber mein Profil entsprechend gesäubert und halte mich bis auf weiteres von diesem Forum fern. Von daher ist der Zusammenhang aufgrund des fehlenden Namens nicht mehr verständlich gewesen.