Vollständigen Datei- oder Verzeichnisnamen über das Handle ermitteln

[himitsu]

Ich hab noch nie erlebt, daß die Codeoptimierung negative Auswirkungen hatte?
Und dazu soll diese Optimierung auch nicht das Verhalten des Programms verändern, also gibt es auch keine Nachteile.

Würde mich also mal interessieren, wie soein Code aussieht, welcher mit Optimierung nicht mehr funktioniert.

[ASM]

Zitat von himitsu:

Ich hab noch nie erlebt, daß die Codeoptimierung negative Auswirkungen hatte?

Vielleicht hast Du ja nie mit Delphi 7 gearbeitet ?

Alles von mir Beschriebene bezieht sich auf das Arbeiten mit Delphi 7. Mit dieser Version arbeite ich noch immer standardmäßig (warum auch nicht).

Jetzt habe ich den Code gerade noch einmal unter Delphi XE compiliert und zwar einmal mit und einmal ohne Aktivierung der Optimierung.
Ergebnis: OK, in Delphi XE ist inzwischen offenbar die Optimierung überarbeitet. Hier im konkreten Fall hat die Einstellung der Optimierung jedenfalls keinen Einfluss mehr auf den erfolgreichen Ablauf. Die Frage bleibt, ob das immer so sein wird; ich bin da aus meiner Erfahrung skeptisch.

Bei der Compilierung mit Delphi 7 dagegen kann die Aktivierung/Deaktivierung der Optimierung einen ganz entscheidenden Einfluss auf das korrekte Funktionieren des Programms haben, exakt wie gerade beschrieben. Versuche es doch selbst einmal unter Delphi 7: den Code zur Beoachtung des deutlich unterschiedlichen Erfolgs hast Du ja von mir wie oben beschrieben.

[brechi]

Der Compiler verhaspelt sich da nicht, der letzte Parameter muss entweder als PDWORD oder "out DWORD" deklariert sein, denn dein code funktioniert bei mit erst recht nicht.
Und danach funktioniert es betimmt auch mit D7 + Optimierung.

Code:

ReturnLength [out, optional]
    An optional pointer to a location where the function writes the actual size of the information requested. If that size is less than or equal to the ObjectInformationLength parameter, the function copies the information into the ObjectInformation buffer; otherwise, it returns an NTSTATUS error code and returns in ReturnLength the size of the buffer required to receive the requested information.

Und wenn du schon Verbesserungvorschläge machst, warum pruefst du nicht den Rückgabewert deines 1. Aufrufes von NtQueryObject?
Im übrigen hab ich auch unter D/ (lange her wo ich es benutzt habe) nie Probleme mit der Optimierung gehabt.

[brechi]

So also ich hab mich bei der Dokumentation verlesen, aber anscheinend ist ein "out DWORD" doch richtig, jedenfalls funktioniert der Code dann damit und man erhaelt als Rückgabe "C0000004" = STATUS_INFO_LENGTH_MISMATCH + die Richtige Laenge in ReturnSize.

[This function may be changed or removed from Windows without further notice.] -> mit Windows7 /D2007 hier getestet

Edit2:
bin ich blöd?:
"optional pointer to a location" = "Adresse eines Speicherbereichs" oder? -> demnach MSDN richtig und muss ein "out DWORD" besser "PDWORD" sein da optional, also ggf nil.

[Aphton]

Es ist bestimmt ein var ReturnLength: DWord oder pReturnLength: PDWord (beides sind ja ~mehr oder weniger~ intern Pointer)
Doppelte Pointer -> var pReturnLength: PDWord oder mit out wäre sinnlos.
-Edit-
Das ist auch üblich so bei der Win API!
-/Edit-

@Himitsu Bezgl. der Codeoptimierung:
Mir ist es unter dem verbuggten Turbo Delphi Explorer auch einige Male passiert, dass die Optimierung Codeteile zerfetzt hat und generell das Debuggen unmöglich machte.
Es wurden zB Codestellen gar nicht kompiliert - ich schätz mal, der Compiler dachte sich (warum auch immer), dass die Stelle nie ausgeführt wird und "optimierte" sie weg... Hab mich sehr oft darüber aufregen dürfen. Ist also nichts seltenes.

[ASM]

Zitat von Aphton:

Es ist bestimmt ein var ReturnLength: DWord oder pReturnLength: PDWord (beides sind ja ~mehr oder weniger~ intern Pointer)

Offenbar aber doch nicht gleichwertig.
Dazu noch einmal hinichtlich dieses letzten Parameters von NtQueryObject() die MSDN zitiert: "An optional pointer to a location where the function writes the actual size of the information requested.".
Explizit dazu die Deklaration:

Code:

NtQueryObject(
IN HANDLE ObjectHandle, 
IN OBJECT_INFORMATION_CLASS ObjectInformationClass, 
OUT PVOID ObjectInformation, 
IN ULONG Length, 
OUT PULONG ResultLength 
);

Wenn ich also wie folgt deklariert habe:

Code:

Var
  ReturnSize: DWORD;
  pReturnSize: PDWORD;

dann ist also eindeutig als Parameter an NtQueryObject()zu übergeben pReturnsize (und zwar zwingend als OUT resp.VAR) und nicht einfach nur als ReturnSize.

Was passiert nämlich im Ergebnis ?:

Parameter als OUT PDWORD deklariert:
Optimierung OFF: ResultLength = 9460301
Optimierung ON: ResultLength = Accession Error

Parameter als PDWORD deklariert:
Optimierung OFF: ResultLength = 9460301
Optimierung ON: ResultLength = 48401

Parameter als OUT DWORD deklariert:
Optimierung OFF: ResultLength: = 10
Optimierung ON: ResultLength = 1308584

Eindeutig völlig neben der Spur liegt also die Verwendung des Parameters als einfaches OUT (oder VAR) DWORD.

Wie außerdem zu sehen ist, kommt es bei aktivierter Optimierung selbst bei der Deklaration des Parameters als PDWORD zu völlig unterschiedlichem Ergebnis, was so eigentlich gar nicht passieren dürfte, da die Adressen der entsprechenden Pointer vor und nach dem Aufruf von NtQueryObject() unverändert an derselben Speicherstelle liegen. Unter deaktivierter Optimierung tritt dieser Effekt nicht auf, ganz wie es zu erwarten ist.


Aber noch etwas anderes:
Der Eingabeparameter Length bezieht sich auf die Größe des Ausgabepuffers zu ObjectNameInformation.Eigentlich sollte nun diese Größe von Length auf die Ausgabe der ResultLength gar keinen Einfluss haben, denn NtQueryObject() stellt angeblich nur die Größe des Ausgabepuffers entsprechend der im 2.Parameter genannten Anforderung fest. Und allein das Funktionsergebnis teilt mit, ob die in Length angegebene Größe des Ausgabepuffers zur Durchführung der vorgesehenen Aktion ausreichend ist. Setzt man jedoch den Wert von Length=0, was ja auf das Ergebnis von ResultLength gar keinen Einfluss haben dürfte, dann kommt es sowohl mit als ebenso auch ohne Optimierung zum Accession Error. Andererseits genügt bereits ein eingegebenes Length=100, um dem Erfolg von NtQueryObject() zu erreichen, obwohl dieser Wert weit niedriger ist als der in ResultLength zurückgegebene Wert der benötigten Größe des Ausgabepuffers. Alles sehr merkwürdig und auf Grund der recht dürftigen Dokumentation seitens MS kaum nachvollziehbar.

[Zacherl]

Ich verweise hier nochmal auf das Alignment bzw. die Enum Typ Größe. Mit den entsprechenden Compiler Switches funktionieren bei mir folgende Varianten problemlos:

Delphi-Quellcode:

var
  ReturnLength: ULONG;
begin
  // Deklaration als PULONG
  NtQueryObject(x, x, x, x, @ReturnLength);
  // Deklaration als var ULONG
  NtQueryObject(x, x, x, x, ReturnLength);

Ich kann mich irren, aber soweit ich weiß, interpretiert Delphi einen OUT Parameter genauso wie einen VAR Parameter. Sprich, wenn du, wie in deinem Beispiel ReturnLength als OUT PULONG deklarierst, ist das dann der Pointer auf den Pointer auf ReturnLength und nicht nur der Pointer auf ReturnLength.

Außerdem: Wenn du ReturnLength lokal als PULONG deklarierst, dann zeigt dieser Pointer entweder ins Leere (auf 0) oder wird mit einem Zufallswert initialisiert. Ruftst du dann die API auf und übergibst die Variable direkt, dann wird natürlich versucht die Rückgabelänge in einen invaliden Speicherbereich zu schreiben.
Wenn du ReturnLength aber als ULONG deklarierst und dann @ReturnLength übergibst, zeigt der Pointer auf die korrekt adressierte lokale Variable.

Zur Verdeutlichung:

Delphi-Quellcode:

var
  ReturnLength: ULONG;
  pReturnLength: PULONG;
begin
  // Wir gehen von einer ReturnLength deklaration als PULONG aus
  // FALSCH:
  // pReturnLength ist hier ein uninitialisierter Pointer. 
  // die API versucht die Länge zu schreiben, indem sie dereferenziert: pReturnLength^ := Länge
  // da der Pointer aber auf einen undefinierten Speicherbereich zeigt, bekomst du eine AV
  NtQueryObject(x, x, x, x, pReturnLength);
  // RICHTIG:
  // der Speicher von ReturnLength wurde von Delphi korrekt alloziiert
  // wir übergeben die Referenz auf diesen Speicher, also den Pointer, der auf ReturnLength zeigt
  NtQueryObject(x, x, x, x, @ReturnLength);

Das Problem mit der Übergabe von Length = 0 kann ich ebenfalls nicht nachvollziehen. Der Aufruf von NtQueryObject(x, x, nil, 0, x) funktioniert für mich wunderbar. Aber vermutlich rührt dieses Problem von deiner fehlerhaften Implementation der ReturnLength her.

[Assarbad]

Zitat von himitsu:

Ich hab noch nie erlebt, daß die Codeoptimierung negative Auswirkungen hatte?

Nicht? Dann ist dir eine Menge entgangen, oder du schreibst bisher nur Code in der Geschmacksrichtung Vanille und machst nix exotisches

Zitat von himitsu:

Und dazu soll diese Optimierung auch nicht das Verhalten des Programms verändern, also gibt es auch keine Nachteile.

Sollte, hätte, könnte. Leider muß ich dir unrecht geben. ASM hat vollkommen recht mit seiner Aussage. Es gibt diese Möglichkeit und man sollte sie in Betracht ziehen

Optimierer haben bspw. Probleme mit Pointer-Aliasing, nur um ein Beispiel zu nennen. Auf Architekturen auf denen Alignment dann auch noch eine echte (nicht wie bei x64) Rolle spielt (SPARC usw.) stellt dir der Optimierer dann öfter mal einen Fuß. Nicht umsonst rät bspw. das Gentoo Wiki beim gcc nur bis -O2 zu gehen. Das ist durchaus auf andere Compiler übertragbar, auch wenn die Fehler sich mit jeder Implementierung/Version unterscheiden werden.

Zitat von Zacherl:

Dann sind wohl in den Jedi Native API Headers "massenweise Fehler", denn genau von dort habe ich die Funktionsdeklaration kopiert. Des weiteren solltest du, deinem Namen nach zu schließen, wissen, dass OUT oder VAR intern (auf Assembler-Ebene) 1 zu 1 wie ein Pointer behandelt wird.

Und warum dann nicht gleich die Units nehmen? Haben dich die Copyright-Vermerke gestört?

Es schleichen sich da immer wieder Fehler ein, schließlich haben Marcel und ich das manuell gemacht und dann die Verantwortung ohnehin irgendwann abgegeben.

Aber bei aller Kritik: ich finde es cool, daß du deinen Code hier zur Verfügung stellst

[himitsu]

Kommt drauf an, ich hab schon einige Fehler gesehn, aber eben nur noch keinen, welcher durch die Codeoptimierung entstand.

Grade eben (vor vielleicht 15 Minuten) hatte ich einen netten Compilerbug.

Der Code war richtig, aber ein einer Stelle, welche seit Monaten problemlos funktioniert, wurde proütlich was von >>ungültiges Zeichen "?" gefunden<< bemängelt.
Über's SVN konnt ich dann rausfinden, daß ich knapp 120 Zeilen und mehrere Funktionen davor einige Zuweisungen geändert hatte.
Sobald ich auch nur irgendeine der 5 Zeilen auskommentierte oder eine Kleinigkeit änderte funktionierte es urplötzlich wieder, also da 120 zeilen später.

Wobei ich gerade diesen Fehler auch schon seit mindestens 2 Jahren nicht mehr hatte.