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

[himitsu]

Zitat:

was ohnehin grundsätzlich immer dringend zu empfehlen ist.

Wieso?

Das ist so, als wenn man drinend empfiehlt immer auf die VCL zu verzichten
und immer nur mit vollen Debuginfos kompiliert.

[Assarbad]

Faszinierend. Die Annahme daß ein Volume auch einen Laufwerksbuchstaben haben müsse ist mal grob falsch (Reparse Points/Volume Mount Points). Ansonsten schließe ich mich weitgehend ASM an. Es wäre cleverer den Pfad so wie er ankam zurückzugeben, falls die Umwandlung fehlschlägt.

Ebenso kann ein Volume an mehreren Stellen eingehangen sein (genau wie in Linux auch).

[ASM]

Zitat von himitsu:

Wieso?

Das ist so, als wenn man drinend empfiehlt immer auf die VCL zu verzichten
und immer nur mit vollen Debuginfos kompiliert.

Worin genau soll denn der Vorteil der "Optimierung" liegen ?

Ich habe - im Falle recht komplexer Projekte - bereits wiederholt äußerst schwerwiegende, fatale Probleme erfahren müssen, insofern die Optimierung zunächst aktiviert gewesen war. Die ist ja leider per default in jedem neuen Projekt aktiviert, was anscheinend nicht durch Voreinstellung abgeschaltet werden kann und immer erst explizit manuell in jedem neuen Projekt vorgenommen werden muss. Sobald die Optimierung dann nachträglich deaktiviert worden war, war damit auch das spezielle Problem beseitigt - wie auch eben jetzt beschrieben.

Dagegen habe ich noch nie ein einziges entsprechend compilerbedingtes Problem beobachtet, welches durch eine Deaktivierung der Optimierung verursacht worden war.
Unabhängig davon steht im übrigen eine aktivierte Optimierung allzu häufig dem Debugging lokaler Variablen heftig im Wege.

Nenne mir also einen einzigen Grund, warum die Aktivierung der Optimierung wirklich sinnvoll und notwendig wäre.

[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.

[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.