CommandLines der Prozesse unter Windows 64 Bit ermitteln?

[Delphi-Laie]

Allmählich scheint es so, als müßte wegen Überforderung ich aussteigen.

Sebastian, danke für die plausible Erklärung! Allerdings wundert es mich, daß im Delphi-Proramm CPU64-Compilierungsoptionen vorhanden waren. Welchen Sinn haben die, wenn kein 64-Bit-Windows vorgesehen ist? Die 64 Bit des Zentralprozessors sind doch außerdem für die Katz', wenn nur 32-Bit-Windows verwendet wird!

Wie gesagt, ich lasse jetzt lieber die Finger von PEB & Co., es gibt ja noch die andere Möglichkeit, die Kommandozeilen abzufragen.

Noch was zu komprimierten/gepackten oder unkomprimierten/ungepackten Records. Die Delphi-Hilfe suggeriert, daß dieses Schlüsselwort überflüssig, aber auch nicht schädlich sei, weil die Records ohnehin intern gepackt würden. Bei den weiter oben in dieser Diskussion aufgeführten Funktionen macht es aber sehr wohl einen Unterschied, ob man das "packed" verwendet oder wegläßt, wie ich durch die üblichen Experimente herausfand.

Zacherl, danke für Dein ausführliches Beispiel, das ich recht bald ausprobieren werde!

[jaenicke]

Zitat von Delphi-Laie:

Sebastian, danke für die plausible Erklärung! Allerdings wundert es mich, daß im Delphi-Proramm CPU64-Compilierungsoptionen vorhanden waren. Welchen Sinn haben die, wenn kein 64-Bit-Windows vorgesehen ist?

Die sollten verwendet werden, wenn ein 64-Bit Compiler verwendet wird. Welche du konkret meinst, sehe ich gerade nicht.

Zitat von Delphi-Laie:

Die 64 Bit des Zentralprozessors sind doch außerdem für die Katz', wenn nur 32-Bit-Windows verwendet wird!

Es gibt aber kaum noch neue 32-Bit CPUs.

Zitat von Delphi-Laie:

Noch was zu komprimierten/gepackten oder unkomprimierten/ungepackten Records. Die Delphi-Hilfe suggeriert, daß dieses Schlüsselwort überflüssig, aber auch nicht schädlich sei, weil die Records ohnehin intern gepackt würden.

Das verstehe ich aber deutlich anders:
http://docwiki.embarcadero.com/RADSt...turierte_Typen

Zitat:

Die Verwendung von packed wird nicht empfohlen, da es die Kompatibilität mit anderen Sprachen oder Plattformen verhindern kann, den Datenzugriff verlangsamt und sich bei Zeichen-Arrays auf die Typkompatibilität auswirkt.

[Zacherl]

Zitat von Delphi-Laie:

Zacherl, danke für Dein ausführliches Beispiel, das ich recht bald ausprobieren werde!

Funktioniert sowohl mit 32, als auch mit 64 Bit Prozessen. Wobei dein eigener Prozess ebenfalls ein 32 oder 64 Bit Kompilat sein kann. Müsste man lediglich noch modifizieren, wenn man es auf einem nicht-64-bit System starten will, welches die IsWow64Process API nicht kennt.

[Delphi-Laie]

Zacherl, danke, ich bleibe dran, nur heute probiere ich es nicht mehr aus.

Sebastian, mal eben die Hilfe von Delphi 2.0 zu packed befragt:

"Das reservierte Wort packed gibt dem Compiler in einer strukturierten Typdeklaration an, daß die Datenspeicherung, selbst auf Kosten eines langsameren Zugriffs auf eine Komponente einer Variable dieses Typs, komprimiert werden soll.
Es hat jedoch in Delphi keine Auswirkung, weil das Packen der Daten automatisch erfolgt."

Zugegeben, die Hilfen in Delphi 3 und 4 (mehr habe ich jetzt nicht zur Hand) schreiben beide schon wieder etwas anderes, aber nichts gegensätzliches.

[jaenicke]

Zitat von Delphi-Laie:

Sebastian, mal eben die Hilfe von Delphi 2.0 zu packed befragt:

Die Hilfe hat sich seit damals eben wie Delphi selbst auch weiterentwickelt.

[Delphi-Laie]

Zitat von jaenicke:

Die Hilfe hat sich seit damals eben wie Delphi selbst auch weiterentwickelt.

Sicher, aber die von mir zitierten Sätze sind ja nicht zufällig in die Delphi-Hilfe gelangt.

Zacherl, ein ganz dickes Dankeschön! Erster Test auf 64 Bit mit einem XE2-Compilat, auch 64 Bit, und es funktioniert, welch ein Glückshormonausstoß! Werde ich in mein Programm "Prozesse" integrieren, das nunmehr auch als 64-Bit-Compilate die Spalte "Commandlines" auszufüllen imstande sein wird.

[Delphi-Laie]

Noch als Ergänzung: Das 32-Bit-Compilat bricht schon bei seinem Start mit einer Fehlermeldung ab, soweit ich das überblicke, scheitert es mal wieder an der (statisch aufgerufenene) ntdll.dll, die die wow64-Funktionen nicht beinhaltet. Das ist jetzt aber nicht wichtig, denn wenn der 64-Bit-Strang funktioniert, ist das schon die entscheidende Hilfe und Problemlösung.

[Zacherl]

Zitat von Delphi-Laie:

Noch als Ergänzung: Das 32-Bit-Compilat bricht schon bei seinem Start mit einer Fehlermeldung ab, soweit ich das überblicke, scheitert es mal wieder an der (statisch aufgerufenene) ntdll.dll, die die wow64-Funktionen nicht beinhaltet.

Mhh das ist wirklich seltsam. Auf welcher Windows Version hast du das 32 Bit Kompilat denn getestet? Auf meinem Win8.1 64 Bit findet er die Imports ohne Probleme. "Theoretisch" sollte der Code auf allen 64 Bit Systemen lauffähig sein. Auf 32 Bit Plattformen wird im 32 Bit Kompilat die IsWow64Process API und die nativen Wow64 Imports fehlen.

Finde leider auch keine richtigen Infos darüber ab welcher Win Version die Wow64 APIs hinzugefügt wurden.

Edit: Da die APIs aber bereits in einem Blog Artikel von 2005 genannt werden, sollten sie ab Vista wohl vorhanden sein (natürlich nur bei der 64 Bit Version).

[Delphi-Laie]

Windows 7 64 Bit.

War auch nur eine Vermutung meinerseits, woran es liegen könnte. Mit dynamischer DLL-Einbindung könnte man den Fehler wohl genauer eingrenzen.

Edit: Kommando zurück, die Fehlermeldung erfolgt nicht beim Start, sondern beim Aufrufen der Clickprozedur, und zwar mit einer Exzeption der Klasse EOSError mit er Meldung "Ein Aufruf einer Betriebssystemfunktion ist fehlgeschlagen."

Ist wohl nicht wichtig.

[Zacherl]

Puh unter einem 64 Bit OS sollte das definitiv nicht passieren. Kannst ja mal einfach testweise ein delayed hinter die Imports der nativen Wow64 APIs schreiben und zusätzlich den ganzen Teil der im {$IFDEF WIN32} Block der Funktion steht mit einem if Is64BitOS then absichern.

Die Is64BitOS Funktion findest du hier:
http://stackoverflow.com/a/1634007/3140346