Prozesse - mal wieder ein Prozeßbetrachter (und mehr)

[Delphi-Laie]

Hallo Delphianer!

Hiermit stelle ich mal wieder ein kleines Programm vor, und zwar zum Anzeigen von Prozessen, Modulen, Threads, Fenstern und Kindfenstern ("ChildWindows"). Derlei Programme gibt es ja viele....


Die Idee war, die 4 Schnappschüsse:

- Prozeßschnappschuß (CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS,0)),
- Modulschnappschuß (CreateToolhelp32Snapshot(TH32CS_SNAPMODULE, Prozeßnummer)),
- Threadschnappschuß (CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, Prozeßnummer)) und
- Heap- und Heapblockschnappschuß (CreateToolHelp32Snapshot(TH32CS_SNAPHEAPLIST, Prozeßnummer))

mit den 3 Fensterenumerationen:

- EnumWindows,
- EnumThreadWindows und
- EnumChildWindows

so (sinnvoll) miteinander zu verknüpfen, daß sich ein - auf Basis der damit abrufbaren Informationen - in sich relativ geschlossenes Abbild des laufenden Windows ergibt (unter Hinzufügung weniger anderer Dinge, die mit ausgegeben werden). Dabei findet - im Gegensatz z.B. zum Taskmanager oder ProcessExplorer - keine Intervallaktualisierung beim primären Fenster mit der Prozeßausgabe statt (Abfrage nur beim Programmstart), die anderen Dinge werden erst zur Laufzeit (nach Aufruf) vom Program (Fragender) bzw. vom System (Befragter) abgefragt.

Aufrufe der von den Prozessen ableitbaren Objekte (die stehen in den Titelzeilen der Fenster) erfolgen über Doppelklick auf die jeweilige Zelle des jeweiligen StringGrids.

Der prozeß(nummer)bezogene Threadschnappschuß funktioniert bei mir leider "irgendwie" nicht: Es werden, egal bei welcher Prozeßnummer als Aufrufparameter, grundsätzlich immer alle Threads des Systems augegeben, deshalb habe ich diesen über einen prozeßnummerselektiven Threadschnappschuß bei der Ausgabe modelliert.

Weiterhin, auch das war anzupassen, gibt es anscheinend keinen Befehl "EnumProcessWindows". Dieser läßt sich m.E. folgendermaßen modellieren:

- Threadschnappschuß; bei allen Threads, die zum jeweiligen Prozeß gehören (prozeß(nummer)bezogene Threadselektion), erfolgt ein anschließendes EnumThreadWindows
oder
- EnumWindows, wobei nur alle zum jeweiligen Prozeß gehörenden Fenster ausgegeben werden, also prozeßnummernselektive Fensterauflistung (analog der prozeßnummernselektiven Threadauflistung)

Einfacher ist wohl letzteres, das ich deshalb umsetzte.

Das Programm kann z.B. auch als Alternative verwendet werden, um Routinen bzw. konkret die o.g. aufgerufenen Funktionen in eigenen Programmen zu testen. Weiterentwicklungen des Programmes (z.B. Prozesse terminieren oder Eigenschaften editieren o.ä.) sind nicht geplant.

Leider vergaß ich, die Units rechtzeitig zu selbsterklärenden Bezeichnungen umzubenennen, und der Aufwand dazu wäre jetzt zu groß (fehlersensitiv). Die Stringrids auf den jeweiligen Formularen geben folgendes aus:

Form1: Prozesse
Form2: Module
Form3: Threads
Form4: Fenster
Form5: Kindfenster ("ChildWindows")
Form6: Heapblöcke
Form7: Heaps
Form8: Module32 (nur 64 Bit)
Form9: Prozessorenaffinitäten


Viele Grüße

Delphi-Laie


Edit: Neue, geringfügig fehlerbereinigte und vor allem etwas erweiterte Version hochgeladen. Das Programm erweiterte ich um den vierten Schnappschuß, den Heapschnappschuß (dürfte ein Novum in den deutsch(sprachig)en Delphi-Foren sein). Dieser ermöglicht die Auflistung der Heaps und der Heapblöcke. Ergebnisse liefert der/das bei mir aber nur unter Windows ME, nicht jedoch 2000, XP & Vista, also wohl generell nicht unter NTx, dafür aber wohl generell unter 9x. Also, leider ein wenig zu spät dafür, aber wen's interessiert.... Auch wenn ich dafür wahrscheinlich virtuell gesteinigt werde: Es hat es mich interessiert, dieses Programm auch unter Delphi 2.0 zum Laufen zu bringen, mit Erfolg! Bis daß in den Pfadangaben der Laufwerksbuchstabe fehlt, hält mein D2-Compilat taper und wacker mit seinen späteren, natürlich aufgeblähteren Konkurrenten mit.

Edit 2: Stringgrids der nichtaktiven Formulare nunmehr grau. Kleine Fehlerkorrektur.

Edit 3: 1. Automatische Spaltenbreitenanpassung des Stringgrids zur Laufzeit; 2. Die eigentlich erst ab Delphi 4 verfübare Funktion "GetWindowModuduleFileName" in alle Versionen dieses Programmes integriert (durchweg konsistente Ergebnisse erhält man damit aber nur unter Windows 9x/Me), 3. Datentypkonvertierungsfehler für Delphi-Versionen >3 behoben (Heapnummern können unter Win 9x/ME negativ sein).

Edit 4: Automatische Spaltenbreitenanpassung ausgeweitet; Fehler beseitigt.

Edit 5: Automatische Spaltenbreitenanpassung fehlerbereinigt.

Edit 6: Im D2-3-Quelltext und in den Compilaten vergessenes GetWindowModuleFileName ergänzt.

Edit 7: Privileg für (exklusiven?!) Zugriff auf Ring-0- bzw. Kernel(modus)prozesse für dieses Programm angefordert bzw. implementiert (und wieder stand ein Quelltext Luckies dabei Taufpate). Damit ist es nunmehr möglich, auch in den systemnahen bzw. Systemprozessen die Module zu enumerieren, jene Prozesse und deren Threads zu beenden und/oder deren Priorität zu ändern.

Edit 8: Funktionsaufruf GetWindowModuleFileName durch GetWindowModuleFileNameA ersetzt, weil unter Windows ME GetWindowModuleFileName nicht gefunden wird, obwohl es in der DLL enthalten ist (und das Programm deshalb leider mit einem Fehler abbricht). Auch Delphi (4) mogelt diesbezüglich wahrscheinlich aus dem gleichen Grunde und nimmt genau die gleiche Substitution in der Windows-Unit vor.

Edit 9: Subtile Darstellungsfehler behoben; Turbo-Delphi-Compilat hinzugefügt.

Edit 10: Diverse Fehler (Threadprioritätensetzung, Darstellung und Modulanzahlanpassung) behoben.

Edit 11: Sehr viele kleine Fehler behoben. Das Turbo-Delphi-Compilat scheint fehlerhaft zu sein, denn es kann die Heaps unter Windows ME nicht darstellen (weil es das Delphi-4-Compilat jedoch schafft, nehme ich einen Fehler in der Exe-Datei an). Die interne Fehlersuche ist leider nicht möglich, weil Turbo-Delphi nicht auf diesem Windows laufen kann.

Edit 12: Lazarus-32- & -64-Bit-Version (jeweils inkl. Quelltexten) hinzugefügt.

Edit 13: ProcessVersion und ModuleFileName hinzugefügt. Viele kleine Fehlerkorrekturen.

Edit 14: Privileganforderung zum Start nunmehr optional mit Ergebnismitteilung. Prozeßliste läßt sich jetzt mit F5 aktualisieren. Wenige kleine Korrekturen.

Edit 15: Kleine Korrekturen.

Edit 16: Spaltenbreitenanpassung(en) der Stringgrids und Größenanpassung(en) der Formulare an die Stringgrids nunmehr in Prozedur(en) zentralisiert. Viele kleine Detailkorrekturen.

Edit 17: Kleinen Darstellungsfehler in der Lazarus-Version behoben.

Edit 18: Prozessoren- bzw. Prozessorkernaffinitäten für Prozesse und Threads sowie Threadidealprozessorzuordnung (alles für Mehrprozessor-/-prozessorkernsysteme) hinzugefügt. Viele Fehlerbehebungen.

Edit 19: Spalte für Prozeßeigentümer und Gruppe hinzugefügt (ist nicht für 9x/ME, sondern im Zusammenhang mit der hier benutzten Prozeßenumeration, die es nicht für Windows NT gibt, erst ab Windows 2000 verfügbar und wird auch deshalb erst ab diesem Windows auch augegeben, ansonsten wird die Spalte ausgeblendet) Ausgabe für Module32 beim 64-Bit-Lazaruskompilat (logischerweise nur bei 64-Bit-Windows verfügbar und wird auch erst bei 64 Bit ausgegeben, ansonsten wird auch diese Spalte ausgeblendet) in die letzte Spalte verschoben.

Edit 20: Subtilen Fehler in der Lazarus-Variante (Quelltext) bzw. den Lazarus-Varianten (32- & 64-Bit-Compilat) bei der Ausgabe der Prozeßeigentümer (wenn Ermittlung derselben nicht erfolgreich war) beseitigt.

Edit 21: Fehler, die bei mehr als zwei Prozessor(kern)en bei den Prozessorzuordnungsfunktionen auftraten, (hoffentlich) beseitigt.

Edit 22: Fehler im Zusammenhang mit inzwischen beendeten Prozessen behoben: Beim Klick auf die Modul- oder Threadanzahl inzwischen beendeter Prozesse reagiert das Programm jetzt ohne Fehlermeldung.

Edit 23: Mehrere kleinere Fehlerbehebungen, vor allem in der Lazarus-Version.

Edit 24: Zusätzliche Anzeige der 32 Bit bei 32-Bit-Prozessen (auf der Grundlage der IsWow64-Funktion) in der 64-Bit-Version (Lazaruskompilat) hinzugefügt.

Edit 25: Titelzeile des Hauptformulars um F5-Hinweis ergänzt.

Edit 26: Unterschiedliche Quelltexte für verschiedene Delphiversionen zu einem Quelltext für alle Delphiversionen (außer 1) zusammengeführt und vereinheitlicht.

Edit 27: Quelltexte überarbeitet, infolgedessen compiliert die Lazarus-Variante jetzt komplett im FPC-Modus. XE2-Quelltexte und Compilate (32 & 64 Bit) hinzugefügt. Die Erkennung der 32-Bit-Prozesse unter 64 Bit funktioniert jetzt auch mit den 32-Bit-Compilaten.

Edit 28: Wegen eines XE2-Fehlers bei der Mehrzellenauswahl in Stringgrids, der beim Lunathema erscheint, den Drawingstyle auf gdsClassic geändert (Voreinstellung war gdsThemed).

Edit 29: XE2-32-Bit-Compilat neu erstellt - ist nunmehr ohne den "CPU-Bug".

Edit 30: Durch Entfernen derr Laufzeittypinformationen (RTTI) (außer in der Unit System) konnte die Größe der XE2-Compilate um ca. 30% verringert werden.

Edit 31: Mehrere (Kind-)Fenstereigenschaften im Enum(Child)Windows hinzugefügt, außerem etliche kleine Fehler entfernt.

Edit 32:
- absolute Spaltenadressierungen in den Stringgrids durch Konstanten ersetzt. Damit können die spaltenbezogenen Reihenfolgen der Anzeigen in den Stringgrids durch einfaches Ändern der Konstanten selbst gewählt werden (in den Quelltexten der jeweiligen Units).
- Anzahl der anzeigbaren Fenstereigenschaften wesentlich erhöht (s. auch Windowstyles und extended Windowstyles in MSDN).
- Korrekturen bei den Prozessorzuordnungen und Vorzugsprozessorwahl der Threads
- etliche Detailkorrekturen

Edit 33:
- Die Zeilen aller Stringgrids können jetzt anhand der Einträge ("Schlüssel") einer beliebigen Spalte sortiert werden.
- Korrekturen bei den Heapblöcken und Hepas

Edit 34: Heapblockzählung jetzt auch im Hauptformular korrekt. Heapfenster inkl. Heapblockanzahl und Möglichkeit der Heapblockausgabe. Kleine Korrekturen.

Edit 35: Die Zuordnung Prozessoren zu Prozessen bzw. Threads ist jetzt über ein zusätzliches Formular flexibler möglich. Etliche Fehlerkorrekturen.

Edit 36: Die Childwindows können nunmehr auch direkt aus der Prozeß- und der Threadliste aufgerufen werden. Weiterhin werden die Childwindows mit dem Parentprozeßhandle ausgegeben. Wiederum Fehlerkorrekturen.

Edit 37: Neben dem Handle (Edit 36) wird bei den Childwindows nun auch der Name und der Klassennname des Parentwindows ausgegeben.

Edit 38: Fenster werden jetzt daraufhin geprüft (und das Ergebnis ausgegeben), ob sie einem (nicht)reagierenden ("hängenden") Programm angehören (ab Windows 2000).

Edit 39: Fehler, die auftraten, wenn man auf die Heaps oder Heapblöcke eines inzwischen beendeten Prozesses klickte, beseitigt.

Edit 40: 3 weitere Prozeßgrößen auf der Basis der NTQueryInformationProcess-Funktion (und weiterer Funktionen), die den P(rocess) E(nviroment) B(lock) auslesen, hinzugefügt. Die Idee stammt von Codeproject. Ein ganz herzlicher Dank geht an Zacherl, der mir in dieser Diskussion entscheidend half, das für 64 Bit zu portieren.

Edit 41: Funktion "IsAdmin" hinzugefügt, auf NTx erfolgt auf ihrer Basis nun Prüfung auf Administrationsstatus und auf Grundlage ihres Ergebnisses die Nachfrage, ob maximale Privilegien angefordert werden sollen, optional. Weiterhin wird nur noch angezeigt, wenn die maximalen Privilegien nicht erreicht werden.

Edit 42: Startergonomie weiter verbessert (vereinfacht), Fehler in iswow64-Funktion behoben.

Edit 43: Startergonomie der XE2-Compilate verbessert, so wird jetzt auch unter UAC-Betriebsprogrammen (ab Vista) korrekt ermittelt, ob das Programm Administrationsrechte hat. Ein Dank geht an diese Diskussion.

Edit 44: Die 64-Bit-Versionen zeigen nun auch die 32-Bit-Module der 32-Bit-Programme/-prozesse an.

Edit 45:
- Modulefilenames (von GetWindowModuleFileName) entfernt, da überflüssig,
- der Exitcode sowie die Anzahl GUI-Objekte, Userobjekte und der Prozeßhandles werden in der Prozeßtabelle für jeden Prozeß angezeigt,
- das Prozessorenzuordnungsformular zeigt nunmehr an, für welchen Prozeß und / bzw. Thread es derzeit gültig ist,
- die Funktion "IsAdmin" funktioniert jetzt auch bei den Lazarus-Compilaten,
- die Prozeßnamen (exe-Dateien) stehen jetzt links in einer fixierten Spalte,
- bessere Is(UserAn)Admin-Funktion aus diesem Beitrage (Dank an Nico!) und
- verbesserte Ergonomie bei der Zuweisung des Vorzugsprozessors.

Edit 46: Quelltextüberarbeitung in Unit 1 und 3 sowie kleine Fehlerbehebungen.

Edit 47: Kleine Fehlerbeseitungen.

Edit 48: Die Lazarusversion kann jetzt im FPC- und im Delphimodus kompiliert werden.

Edit 49:
- der Fortschritt beim Zählen der Heapblöcke kann jetzt grob visuell verfolgt und dieses Zählen auch abgebrochen werden
- diverse Fehlerbeseitigungen

[Dezipaitor]

Zitat von Delphi-Laie:

Lazarus ist nach meiner Beobachtung tendenziell weniger fehlertolerant als Delphi, so daß diese Arbeit auch viele (kleine) Fehler in den Delphi-Quelltexten offenbarte.

Du verwendest den ObjectFPC Modus, der inkompatibel mit Delphi ist. Er ist angelehnt an Turbo Pascal, so dass man auch noch Zeiger mit "^." angeben muss, statt nur dem Punktoperator zu nutzen. Frag Corpsman, der kann dir die Unterschiede runterbeten, besonders die mit Zeigern.

Zitat von Delphi-Laie:

Hinzu kam auch noch eine Spalte für 32-Bit-Module (Ergebnisse sind nur unter 64 Bit möglich), ich konnte allerdings noch kein Programm finden, das welche benutzt.

Soweit ich weiß, können 64bit Prozesse 32bit Module laden, wenn man nur die Ressourcen lädt. Könnte das hier sein?

Zitat von Delphi-Laie:

Für die volle Funktionalität empfielt sich, das Programm als Administrator bzw. mit Administratorrechten auszuführen. Damit kann man auch in den Systemprozessen und -threads fast nach Belieben schalten und walten, d.h. Prioritäten verändern oder sogar Prozesse bzw. deren Threads (gewaltsam) beenden (die Privilegien dafür holt sich das Programm zum Programmstart). Zu meinem Erstaunen läßt sich damit sogar Windows 6.1 („7“) zum Absturz bringen.

Warum? Du bist Admin, da kannst du machen was du willst. Das ist keine Sicherheitslücke und daher im Bereich des möglichen.

Zitat von Delphi-Laie:

Das 32-Bit-Compilat funktioniert im übrigen auch und sogar unter Windows ME.

Könnte dann auch unter Win98 gehen.

Zitat von Delphi-Laie:

Wochen-, ja monatelange Ein-Mann-Projekte können kaum fehlerfrei sein, zumal man dabei nur sein eigener Korrektor ist bzw. sein kann. Fehlerberichte sind mithin mit Dank willkommen!

*RF: Im Kontextmenü steht "Prozeß". Richtig wäre "Prozess". Das kommt öfters vor.
*Umlaute werden nicht korrekt dargestellt, was man z.b. in der Titelleiste sieht (f?r, Prioritaets?nderung).
*Die WindowsModuleFileName Spalte bei "Windowanzahl" (warum verwendest du eigentlich keine deutschen Begriffe?) enthält öfters mal Müllzeichen.
*Wozu die Spalte dwSize? Die ist eh immer gleich bei deiner SDK Version.
*Handles werden normalerweise nicht und Speicheraddressen auf keinen Fall in dezimaler Schreibweise angegeben (8791771447296 ... was sind denn das für Zahlen?)
*Man kann die Spalten garnicht größer machen, d.h. einige Daten werden einfach abgeschnitten. (Schau dir mal das an: http://www.remkoweijnen.nl/blog/wp-c...xprocesses.png )
*Beste Meldung "Fenster ohne Childwindows"
*Beste Spalten: "sichtbar?" und "enabled?"

[Delphi-Laie]

Danke!

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Lazarus ist nach meiner Beobachtung tendenziell weniger fehlertolerant als Delphi, so daß diese Arbeit auch viele (kleine) Fehler in den Delphi-Quelltexten offenbarte.

Du verwendest den ObjectFPC Modus, der inkompatibel mit Delphi ist. Er ist angelehnt an Turbo Pascal, so dass man auch noch Zeiger mit "^." angeben muss, statt nur dem Punktoperator zu nutzen. Frag Corpsman, der kann dir die Unterschiede runterbeten, besonders die mit Zeigern.

So sehr interessiert mich das nun auch wieder nicht. Ich verwandte zunächst den Delphimodus, doch als ich den FPC-Modus als ebenso funktionierend herausfand, beließ ich es dann doch bei letzterem.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Hinzu kam auch noch eine Spalte für 32-Bit-Module (Ergebnisse sind nur unter 64 Bit möglich), ich konnte allerdings noch kein Programm finden, das welche benutzt.

Soweit ich weiß, können 64bit Prozesse 32bit Module laden, wenn man nur die Ressourcen lädt. Könnte das hier sein?

Vermutlich ja. Es ist einfach eine zusätzliche Funktion, die unter 64 Bit zur Verfügung steht - also baute ich sie mit ein. Vielleicht spukt sie ja mal bei irgendeinem Prozeß auch etwas ungleich null aus.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Für die volle Funktionalität empfielt sich, das Programm als Administrator bzw. mit Administratorrechten auszuführen. Damit kann man auch in den Systemprozessen und -threads fast nach Belieben schalten und walten, d.h. Prioritäten verändern oder sogar Prozesse bzw. deren Threads (gewaltsam) beenden (die Privilegien dafür holt sich das Programm zum Programmstart). Zu meinem Erstaunen läßt sich damit sogar Windows 6.1 („7“) zum Absturz bringen.

Warum? Du bist Admin, da kannst du machen was du willst. Das ist keine Sicherheitslücke und daher im Bereich des möglichen.

Leider nein. Windows 7 hat es z.B. geschafft, ein Verzeichnis zu erstellen, an das ich beim besten Willen nicht herankomme. Es gelang mir einfach nicht, mich - auch als Adminstrator - als Besitzer dort mit einzutragen, geschweige denn, irgendwelche anderen Besitzer zu löschen. Also komme ich dort nicht heran. Das Zeitalter, daß man selbst als Administrator auf dem Computer alles kann und darf, geht langsam, aber sicher zu Ende.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Das 32-Bit-Compilat funktioniert im übrigen auch und sogar unter Windows ME.

Könnte dann auch unter Win98 gehen.

Ist anzunehmen. Die Schnappschüsse und Enumerationen funktionieren n.m.W. schon ab Windows 95, der Prozeßschnappschuß aber mit Sicherheit nicht unter NT 4.0.

Zitat von Dezipaitor:

*RF: Im Kontextmenü steht "Prozeß". Richtig wäre "Prozess". Das kommt öfters vor.

Oh nein, nicht doch! Die tradierte Orthographie ist nicht falsch, das hat sogar das BVerfG klargestellt. Ich verwende auch gar keinen scheinbaren Neuschrieb (in Wirklichkeit Orthographie des 18. und 19. Jahrhunderts!), sondern vermeide lediglich Inkompatibiliäten mit Sonderzeichen.

Zitat von Dezipaitor:

*Umlaute werden nicht korrekt dargestellt, was man z.b. in der Titelleiste sieht (f?r, Prioritaets?nderung).

Das meinte ich mit Fehlern, die man kaum bemerkt, und werde es natürlich noch ändern.

Zitat von Dezipaitor:

*Die WindowsModuleFileName Spalte bei "Windowanzahl" (warum verwendest du eigentlich keine deutschen Begriffe?) enthält öfters mal Müllzeichen.

Für die Müllzeichen kann ich nichts, und wenn das die Funktion so zurückliefert, dann wird das dort eben so erscheinen. Für Windowanzahl hätte ich natürlich auch Fensteranzahl nehmen können, und ich werde es auch tun.

Zitat von Dezipaitor:

*Wozu die Spalte dwSize? Die ist eh immer gleich bei deiner SDK Version.

Wenn der Prozeßschnappschuß mit seinem process32first und -next (dito bei den Modulen und Threads) immer den gleichen Wert zurückliefert, dann steht dort eben immer der gleiche Wert. Mir kommt es vor allem auf die Visualisierung der drei Schnappschüsse und der drei Enumerationen an (s.o.).

Zitat von Dezipaitor:

*Handles werden normalerweise nicht und Speicheraddressen auf keinen Fall in dezimaler Schreibweise angegeben (8791771447296 ... was sind denn das für Zahlen?)

Also wären Hexadezimalzahlen angemessener? Würde ich mich darum bemühen, auch das zu ändern.

Zitat von Dezipaitor:

*Man kann die Spalten garnicht größer machen, d.h. einige Daten werden einfach abgeschnitten. (Schau dir mal das an: http://www.remkoweijnen.nl/blog/wp-c...xprocesses.png )

Abgeschnitten wird m.E. gar nichts, denn die Grids werden nach dem jeweils größten bzw. längsten Element jeder Spalte skaliert. Welche Spalte wird wo abgeschnitten? ColSizing hatte ich tatsächlich vergessen - das hätte eigentlich wie bei der Delphi-Variante sein sollen - auch dafür danke!

Zitat von Dezipaitor:

*Beste Meldung "Fenster ohne Childwindows"

Ja sicher, denn wer kann denn etwas mit Kindfenstern anfangen?

Zitat von Dezipaitor:

*Beste Spalten: "sichtbar?" und "enabled?"

Dito: Wer kann denn etwas mit „erlaubt“ oder „zugelassen“ anfangen?

Gruß

Delphi-Laie

[Dezipaitor]

Zitat von Delphi-Laie:

Leider nein. Windows 7 hat es z.B. geschafft, ein Verzeichnis zu erstellen, an das ich beim besten Willen nicht herankomme. Es gelang mir einfach nicht, mich - auch als Adminstrator - als Besitzer dort mit einzutragen, geschweige denn, irgendwelche anderen Besitzer zu löschen. Also komme ich dort nicht heran. Das Zeitalter, daß man selbst als Administrator auf dem Computer alles kann und darf, geht langsam, aber sicher zu Ende.

Aber doch. Sag mir das Verzeichnis und ich sag dir, was du falsch gemacht hast. Wobei es hier gut sein kann, dass deine NTFS Struktur beschädigt wurde.

Zitat von Delphi-Laie:

Oh nein, nicht doch! Die tradierte Orthographie ist nicht falsch, das hat sogar das BVerfG klargestellt. Ich verwende auch gar keinen scheinbaren Neuschrieb (in Wirklichkeit Orthographie des 18. und 19. Jahrhunderts!), sondern vermeide lediglich Inkompatibiliäten mit Sonderzeichen.

Und warum soll "ß" kein Sonderzeichen für andere Sprachen sein? Natürlich kannst du schreiben, wie du willst. Bedenke jedoch, dass man deine (Un-)Taten im Internet auch viel später noch lesen können wird. Ich kenne jetzt deine berufliche Situation nicht, daher will ich mich an alle wenden. Denn, ob schlechter Programmierstil oder schlechter Sprachstil, es kann sich beides schlecht auswirken auf eine berufliche Laufbahn.

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Umlaute werden nicht korrekt dargestellt, was man z.b. in der Titelleiste sieht (f?r, Prioritaets?nderung).

Das meinte ich mit Fehlern, die man kaum bemerkt, und werde es natürlich noch ändern.

Ich habe sie sofort bemerkt. Sie fallen ja ins Auge. Aber das scheint mir ein Problem mit FPC/Lazarus zu sein?
Es wäre interessant zu wissen, woran das liegt. Vllt sind auch deine PAS Dateien kein UTF8 ?

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Die WindowsModuleFileName Spalte bei "Windowanzahl" (warum verwendest du eigentlich keine deutschen Begriffe?) enthält öfters mal Müllzeichen.

Für die Müllzeichen kann ich nichts, und wenn das die Funktion so zurückliefert, dann wird das dort eben so erscheinen. Für Windowanzahl hätte ich natürlich auch Fensteranzahl nehmen können, und ich werde es auch tun.

Das ist die Standardausrede der Programmierer, die keine Lust haben. Prüfe die Werte, die du nutzt auf Korrektheit und schon ist das gegessen.

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Wozu die Spalte dwSize? Die ist eh immer gleich bei deiner SDK Version.

Wenn der Prozßschnappschuß immer den gleichen Wert zurückliefert, dann steht dort eben immer der gleiche Wert. Mir kommt es vor allem auf die Visualisierung der drei Schnappschüsse und der drei Enumerationen an (s.o.).

Nein, das ist keine Datenausgabe, sondern eine Eingabe. Der Wert kommt von dir:
pe.dwSize:=SizeOf(TProcessEntry32);

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Handles werden normalerweise nicht und Speicheraddressen auf keinen Fall in dezimaler Schreibweise angegeben (8791771447296 ... was sind denn das für Zahlen?)

Also wären Hexadezimalzahlen angemessener? Würde ich mich darum bemühen, auch das zu ändern.

Ja das hat sich vor 20-30 Jahren so eingebürgert.

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Beste Meldung "Fenster ohne Childwindows"

Ja sicher, denn wer kann denn etwas mit Kindfenster anfangen?

Nanu? Da fehlte noch mein Kommentar:
Falls du für Kunden ein Programm schreiben solltest, ist diese Meldung nichts wert. Ich wusste im ersten Augenblick auch nicht, was ich damit anfangen sollte. Aber das nur so als Tipp.

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Beste Spalten: "sichtbar?" und "enabled?"

Dito: Wer kann denn etwas mit „erlaubt“ oder „zugelassen“ anfangen?

Mach es andersherum: Schreib "Deaktiviert" = "Disabled".


PS:
Hast du eigentlich etwas Interessantes zu berichten, was die Konvertierung von 32bit auf 64bit betrifft? Würde mich interessieren.

[Delphi-Laie]

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Leider nein. Windows 7 hat es z.B. geschafft, ein Verzeichnis zu erstellen, an das ich beim besten Willen nicht herankomme. Es gelang mir einfach nicht, mich - auch als Adminstrator - als Besitzer dort mit einzutragen, geschweige denn, irgendwelche anderen Besitzer zu löschen. Also komme ich dort nicht heran. Das Zeitalter, daß man selbst als Administrator auf dem Computer alles kann und darf, geht langsam, aber sicher zu Ende.

Aber doch. Sag mir das Verzeichnis und ich sag dir, was du falsch gemacht hast. Wobei es hier gut sein kann, dass deine NTFS Struktur beschädigt wurde.

Die Festplatte wurde inzwischen formartiert, weil ich Windows 7 ohnehin neu aufspielte, ich kann es also nicht mehr mit Sicherheit sagen. Allerdings finde ich auf derselben Festplatte nunmehr die Systemverzeichnisse „Documents and Settings“, „Dokumente und Einstellungen“ sowie „Programme“ (letzteres erstaunlicherweise auch noch einmal als Nichtsystemverzeichnis, also doch Namensdoppelungen möglich?!), die weder Zugriff zulassen noch im Kontextmenü unter „Eigenschaften“ den Reiter „Sicherheit“ anbieten. Ich kann mich allerdings erinnern, daß das Verzeichnis, das mich ärgerte, diesen Reiter anbot, doch dort waren die Buttons „Hinzufügen“ und „Entfernen“ deaktiviert, und unter „erweitert“ unter dem Reiter „Berechtigungen“ waren nach meiner Erinnerung auch alle Buttons deaktiviert, auch bei den anderen Reitern kam ich nicht weiter, obwohl ich viele, viele Minuten an diesem Gerödel verbrachte. Ich muß dazu sagen, daß ich den damaligen und den jetzigen Zugriff von meinem Windows XP, das ich auf auf jenem Computer habe, versuchte. Genau weiß ich es nicht mehr, und es paßt ja auch nicht zur Thematik dieser Diskussion.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Oh nein, nicht doch! Die tradierte Orthographie ist nicht falsch, das hat sogar das BVerfG klargestellt. Ich verwende auch gar keinen scheinbaren Neuschrieb (in Wirklichkeit Orthographie des 18. und 19. Jahrhunderts!), sondern vermeide lediglich Inkompatibiliäten mit Sonderzeichen.

Und warum soll "ß" kein Sonderzeichen für andere Sprachen sein? Natürlich kannst du schreiben, wie du willst. Bedenke jedoch, dass man deine (Un-)Taten im Internet auch viel später noch lesen können wird. Ich kenne jetzt deine berufliche Situation nicht, daher will ich mich an alle wenden. Denn, ob schlechter Programmierstil oder schlechter Sprachstil, es kann sich beides schlecht auswirken auf eine berufliche Laufbahn.

Nunja, eine jahrhundertealte, historisch gewachsene (und nachweislich überlegene!) Tradition fortzuführen, halte ich nicht unbedingt für einen schlechten Sprachstil, aber das gehört noch weniger in diese Diskussion.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Umlaute werden nicht korrekt dargestellt, was man z.b. in der Titelleiste sieht (f?r, Prioritaets?nderung).

Das meinte ich mit Fehlern, die man kaum bemerkt, und werde es natürlich noch ändern.

Ich habe sie sofort bemerkt. Sie fallen ja ins Auge. Aber das scheint mir ein Problem mit FPC/Lazarus zu sein?
Es wäre interessant zu wissen, woran das liegt. Vllt sind auch deine PAS Dateien kein UTF8 ?

UTF8 hört sich für mich nach Unicode an. Meine Pas-Dateien liegen bei. Mehr kann ich dazu nicht sagen. Tja, und ausgerechnet dieser offensichtliche Fehler entging mir - Betriebsblindheit - übersehen im doppelten Sinne des Wortes.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Die WindowsModuleFileName Spalte bei "Windowanzahl" (warum verwendest du eigentlich keine deutschen Begriffe?) enthält öfters mal Müllzeichen.

Für die Müllzeichen kann ich nichts, und wenn das die Funktion so zurückliefert, dann wird das dort eben so erscheinen. Für Windowanzahl hätte ich natürlich auch Fensteranzahl nehmen können, und ich werde es auch tun.

Das ist die Standardausrede der Programmierer, die keine Lust haben. Prüfe die Werte, die du nutzt auf Korrektheit und schon ist das gegessen.

Das ist für mich keine Ausrede, weil mir bis dato überhaupt nicht bewußt war, daß dort ein Fehler vorliegen könnte, zumindest nicht mit gewisser Wahrscheinlichkeit. Und selbst, wenn, so bin ich mit ziemlicher Sicherheit damit überfordert, den zu finden. Letztlich wird doch nur eine DLL-Funktion aufgerufen (die ohnehin unter 9x/ME am aussagekräftigsten ist). So ist mir auch unklar, warum der Fehler nur sporadisch auftritt. Um Ausreden geht es mir auch deshalb nicht, weil ich durchaus möchte, alle Fehler auszumerzen, sofern es in meiner Kraft liegt.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Wozu die Spalte dwSize? Die ist eh immer gleich bei deiner SDK Version.

Wenn der Prozßschnappschuß immer den gleichen Wert zurückliefert, dann steht dort eben immer der gleiche Wert. Mir kommt es vor allem auf die Visualisierung der drei Schnappschüsse und der drei Enumerationen an (s.o.).

Nein, das ist keine Datenausgabe, sondern eine Eingabe. Der Wert kommt von dir:pe.dwSize:=SizeOf(TProcessEntry32);

Nun, ich sehe aber nicht, daß ich den Wert im Quelltext zuweise, den das Programm anzeigt, sondern eben den SizeOf, der vom Programm ermittelt wird.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Handles werden normalerweise nicht und Speicheraddressen auf keinen Fall in dezimaler Schreibweise angegeben (8791771447296 ... was sind denn das für Zahlen?)

Also wären Hexadezimalzahlen angemessener? Würde ich mich darum bemühen, auch das zu ändern.

Ja das hat sich vor 20-30 Jahren so eingebürgert.

Na, dann wird das zu verändern versucht. Mit strtohex und hextostring sieht es aber nicht so rosig aus.... Edit: Inttohex scheint das Gewünschte zu können. Ist allerdings m.E. nicht gerade eine glückliche, selbsterklärende Funktionsbenennung.

Zitat von Dezipaitor:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Beste Meldung "Fenster ohne Childwindows"

Ja sicher, denn wer kann denn etwas mit Kindfenster anfangen?

Nanu? Da fehlte noch mein Kommentar:
Falls du für Kunden ein Programm schreiben solltest, ist diese Meldung nichts wert. Ich wusste im ersten Augebblick auch nicht, was ich damit anfangen sollte. Aber das nur so als Tipp.

Für Kunden schriebe ich genau das, was die haben möchten - jedoch bin ich natürlich kein Informatiker und mithin ohne kommerzielles Interesse bzw. kommerziellen Zwang. Nur, für dieses Programm bin ich selbst mein (bester?) Kunde!

Zitat von Dezipaitor:

PS:
Hast du eigentlich etwas Interessantes zu berichten, was die Konvertierung von 32bit auf 64bit betrifft? Würde mich interessieren.

Gegenfrage: Was interessiert Dich denn, daß es für Dich interessant ist?
Bis auf die tlhelp64-pas-Unit, die ich benötigte, weil die jwatlhlp32-unit von FPC nicht 64-bittig ist, ist der Compilierungsbericht genauso erfreulich wie gähnend langweilig: Es funktioniert mit beiden Lazarussen perfekt; 64 Bit erzeugen nicht eine Fehlermeldung oder auch nur Warnung mehr! Lazarus ist für mich trotz des etwas schwerfälligeren, weniger komfortablen Umganges als Delphi eine ernstzunehmende Programmiersoftware.

Gruß

Delphi-Laie

[Dezipaitor]

pe.dwSize:=SizeOf(TProcessEntry32); SizeOf wird zur Kompilierzeit in einen konstanten Wert umgewandelt. Der Record TProcessEntry32 ist ja bekannt, und damit auch seine Größe. D.h. da steht dann z.B. wirklich
pe.dwSize := 134;

[Teekeks]

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Beste Meldung "Fenster ohne Childwindows"

Ja sicher, denn wer kann denn etwas mit Kindfenstern anfangen?

Und wie wäre es mit

Zitat:

Fenster ohne Unterfenster

?

[Delphi-Laie]

Zitat von Dezipaitor:

pe.dwSize:=SizeOf(TProcessEntry32); SizeOf wird zur Kompilierzeit in einen konstanten Wert umgewandelt. Der Record TProcessEntry32 ist ja bekannt, und damit auch seine Größe. D.h. da steht dann z.B. wirklich
pe.dwSize := 134;

Schon zur Kompilierzeit?

Hülle ich diese Größenzuweisung mit zwei Ausgaben ein, z.B.

Delphi-Quellcode:

showmessage(inttostr(pe.dwSize));
pe.dwSize:=SizeOf(TProcessEntry32);//oder pe.dwSize:=SizeOf(pe);
showmessage(inttostr(pe.dwSize));

, dann erscheinen - logischerweise zur Laufzeit - unterschiedliche Werte: Der erste ist abenteuerlich, der zweite dürfte/müßte stimmen. Edit: Klar, stimmt schon, was Du schreibst, denn SizeOf ist ja das, was übergeben wird, war mein Versehen.

Zitat von Teekeks:

Zitat von Delphi-Laie:

Zitat von Dezipaitor:

*Beste Meldung "Fenster ohne Childwindows"

Ja sicher, denn wer kann denn etwas mit Kindfenstern anfangen?

Und wie wäre es mit

Zitat:

Fenster ohne Unterfenster

?

Danke für den Vorschlag! Als Feind der Sprachanglifizierung versuche ich, überflüssige Anglizismen zu vermeiden, so z.B. Fenster statt Window zu verwenden (dabei sind die Grundlage dessen, was dort auf dem Bildschirm gehandhabt sind, eigentlich die Formulare und nicht die Fenster). Damit kann sicher jeder etwas anfangen. Doch diese Childwindows sind m.E. dermaßen eingebürgert, daß ich bei den Kindfenstern und auch - in abgeschwächter Form - bei den Unterfenstern annehme, daß damit kaum jemand etwas anfangen kann. Diese Unterfenster sind doch auch genaugenommen keine Fenster, sondern visuelle Elemente/Komponenten/Objekte (was auch immer), oder?

Eine neue, weiter fehlerbereinigte Version dieses kleinen Programmes werde ich in Kürze in meinem Eröffnungsbeitrag veröffentlichen.