AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Code-Bibliothek Neuen Beitrag zur Code-Library hinzufügen Delphi Vollständigen Datei- oder Verzeichnisnamen über das Handle ermitteln

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

Ein Thema von Zacherl · begonnen am 24. Apr 2012 · letzter Beitrag vom 27. Apr 2012
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von Aphton
Aphton

Registriert seit: 31. Mai 2009
1.198 Beiträge
 
Turbo Delphi für Win32
 
#11

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

  Alt 26. Apr 2012, 13:33
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.
das Erkennen beginnt, wenn der Erkennende vom zu Erkennenden Abstand nimmt
MfG
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
3.794 Beiträge
 
Delphi XE3 Professional
 
#12

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

  Alt 26. Apr 2012, 14:22
... allerdings habe ich dies nicht weiter getestet.
Eben, ich wollte nämlich schon gerade fragen: hast Du den Code jemals selbst erfolgreich getestet ?
Selbstverständlich funktioniert er mit validen File Handles unter XE2 wunderbar, sonst hätte ich den Code kaum gepostet.

Eindeutig wohl eher aber nur per "Copy & Paste" von irgendwoher ungeprüft übernommen..
Denn "Dein" Code funktioniert weder unter Delphi 7 noch unter Delphi XE.
Es grenzt schon stark an Unverschämtheit mit sowas (noch dazu ohne Beweise) zu unterstellen. Lediglich die Funktion zum Ermitteln der korrekten Partitionsbuchstaben habe ich aus einer vorhandenen C-Source portiert. Ich bin so freundlich und teile bestimmte Funktionen, die für andere Leute nützlich sein könnten und du kommst mit deinem jämmerlichen Halbwissen daher, posaunst falsche Tatsachen und machst meine Arbeit schlecht.

Erste Stolperstelle: Der Status bei folgendem Call
Code:
Status := NtQueryObject(hFile, ObjectNameInformation, ObjectInformation, ReturnLength, @ReturnLength);
ist "nicht erfolgreich".
Genau und das liegt nicht etwa an meinem Code, sondern daran, dass du vergessen hast Aligned Records per Compilerdirektive zu aktivieren, bzw. UNICODE_STRING sogar noch (fälschlicherweise) absichtlich als packed record deklarierst.

Im eigentlichen Code sind nämlich massenweise Fehler,
z.B. ist in der Funktionsbeschreibung von NtQueryObject() der letzte Parameter nicht als OUT- bzw. VAR-Parameter deklariert. Das aber ist zwingend erforderlich, weil genau dieser Wert anschließend Parameter für den Zugriff auf die Daten der OBJECT_INFORMATION_CLASS ist.
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.

Zweitens, die (lokale) Deklaration
Code:
var ObjectInformation: PUNICODE_STRING
ist völliger Unsinn.
ObjectInformation muss vielmehr ein Record vom Typ OBJECT_NAME_INFORMATION sein; entsprechend muss ein pObjectInformation:=@OBJECT_NAME_INFORMATION eingeführt werden, weil der Zugriff über den Pointer läuft. Dadurch ändern sich natürlich zwingend eine Anzahl Anweisungen. Man erhält dann mit der Abfrage auf pObjectInformation^.Name.Buffer den korrekten DeviceNamen zum Filehandle.
Dann schau dir mal ganz genau die Deklaration von OBJECT_NAME_INFORMATION an. Oh Wunder: Es befindet sich ein einzelnes Feld vom Typ UNICODE_STRING darin. Also auch hier: Kein Fehler!

Letztens (das Letzte i.e.S.):
Und diesen DeviceNamen nun mit DeviceNameToFilePath() in den logischen WindowsFilepath konvertieren zu wollen, ist ein völlig falscher Ansatz; das ergibt als Ergebnis einfach nur einen leeren String;
In diesem Falle stimme ich zu. Hier ist es wohl sinnvoller bei Fehlschlag den unkonvertierten Namen anstelle eines leeren Ergebnisses zurückzuliefern.

Ansonsten: Danke dir für deinen wirklich fundierten und hilfreichen Beitrag!

Achja ...:
Noch ein sehr wichtiger, ergänzender Hinweis als Nachtrag zu meinem Code:

In der Compileroption (Menu: Optionen >> Compiler-Tab >> Codeerzeugung) muss unbedingt die Optimierung deaktiviert werden, was ohnehin grundsätzlich immer dringend zu empfehlen ist.

Der Compiler verhaspelt sich sonst in FileHandleToFilePath() bei der Ermittlung der benötigten Größe des Ausgabepuffers im ersten Aufruf von NtQueryObject(). Irgendetwas geht da unverständlicherweise intern mit der Zuweisung der Speichergröße an den entsprechenden Pointer schief. Folge: weil dann nicht auf den Ausgabepuffer zugegriffen werden kann, kann somit daraus auch nicht der Devicename zum Filehandle ausgelesen werden und somit natürlich auch nicht der Win32Filepath ermittelt.
Vollkommener Blödsinn. Der Code Funktioniert auch mit Compileroptimierung wunderbar. Und unverständlich ist an dem von dir beschriebenen Verhalten auch rein gar nichts. Die meisten (nativen) APIs erwarten Aligned Structs und 4 Byte Enum Typen. Dies kann durch die Compilerdirektiven {$A+} und {$Z4} erzwungen werden.
Dass du UNICODE_STRING sogar noch explizit als "packed record" (also nicht aligned) deklariert hast, zeigt nochmal, dass du absolut keine Ahnung hast, was du da überhaupt machst.

Edit:
1) (korrekte) Typendeklarationen ergänzt
2): Standardrückgabewert geändert
"Do not argue with an idiot. He will drag you down to his level and beat you with experience."

Geändert von Zacherl (26. Apr 2012 um 16:55 Uhr)
  Mit Zitat antworten Zitat
ASM

Registriert seit: 15. Aug 2004
165 Beiträge
 
Delphi 7 Enterprise
 
#13

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

  Alt 26. Apr 2012, 16:21
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.
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
3.794 Beiträge
 
Delphi XE3 Professional
 
#14

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

  Alt 26. Apr 2012, 16:30
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.
"Do not argue with an idiot. He will drag you down to his level and beat you with experience."

Geändert von Zacherl (26. Apr 2012 um 16:50 Uhr)
  Mit Zitat antworten Zitat
brechi

Registriert seit: 30. Jan 2004
789 Beiträge
 
#15

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

  Alt 26. Apr 2012, 19:17
Du kannst den Code der WinAPI übersetzen indem du einfach die in/outs weglässt, das "out" in der MSDN API Beschreibung hat rein gar nichts mit dem Delphi "out" zu tun.
Delphi-Quellcode:
NtQueryObject(
IN HANDLE ObjectHandle,
IN OBJECT_INFORMATION_CLASS ObjectInformationClass,
OUT PVOID ObjectInformation,
IN ULONG Length,
OUT PULONG ResultLength
);
Korrekterweise wird ein "in/out" als "VAR typ" übersetzt, ein "out_opt" als "pointer typ" und ein "out" als "OUT typ" wobei Typ der entsprechende Bezeichner ohne dem P ist.
Indem Fall ist die korrekte Übersetzung ein

ResultLength: PULONG; VAR typ / CONST typ / OUT typ /Ptyp unterscheiden sich rein von der Übergabe nicht voneinander, es sind alles Pointer auf den TYP. Der einzige Unterschied ist, dass Delphi zusätzliche Überprüfungen durchführen kann.

VAR: der Parameter muss vorher initalisiert werden (Warnung)
CONST: der Parameter darf nicht abgeändert werden (Fehler)
OUT: initalisierter Parameter wird nie verwendet (Warnung)

In dem Fall sollte es mit PULONG oder OUT LONG übersetzt werden, richtigerweise aber PULONG, da es optional ist, d.h. eine Übergabe von NIL ist erlaubt! Dies funktioniert aber nicht mit OUT LONG, da dann immer ein Parameter angegeben werden muss.

Logisch wäre also folgender Aufruf:

Delphi-Quellcode:
  ReturnLength: LONG;
  
  NtQueryObject(x, nil, x, x, @ReturnLength); // Laenge ermitteln
  NtQueryObject(x, @Info, x, x, nil); // auslesen, Laenge ist total egal und wollen wir nicht mehr haben
Im übrigen hast du (ASM) es komischerweise ja auch bei der ObjektInformation richtig übersetzt und übergibst im ersten Aufruf auch NIL.

Die AccessViolation kommt, weil bei dir ein zufälliger Wert für die Adresse verwendet wird (da nie initalisiert). Wenn es trotzdem funktioniert (reiner Zufall), dann hast du im Rückgabewert den du überprüfst auch immer etwas <> 0 stehen.
D.h. dein VirtualAlloc funktioniert auch mit hoher Wahrscheinlichkeit (sofern genug Speicher vorhanden). Wäre der Rückgabewert aber zu klein (für die ObjektInformation) dann funktioniert es trotzdem, da VirtualAlloc dir IMMER genügend Speicher reserviert (PageSize, 0x1000).

Das Problem ist ObjectInformationClass, die EnumTyp-Größe. Du kannst nicht einfach ein Enum von Delphi übergeben, entweder passt du das mit dem Compilerschalter an ob der du übersetzt einen Enum als DWORD und castest den Delphi-Enum. Wenn du das bedachtest dann klappt das auch bei dir.

Im übrigen solltest du in dem Fall bei dir mal die Optimierung einschalten und die Bugs beheben. Du wirst bei deinen Übersetzungen bestimmt viele Fehler eingebaut haben (doppelter Pointer, Enums).

Du hast zumindest auch in einem älteren Thread (C Callback)
Callback Funktion aus C DLLdll.html
eine Aussage gemacht
Zitat:
Deshalb können grundsätzlich auch nur die mit cdecl deklarierten Funktionen/Prozeduren Variablenparameter haben, während an die mit stdcall deklarierten Funktionen/Prozeduren ausschließlich Werteparameter übergeben werden dürfen.
die überhaupt nicht stimmt, da bis auf das Aufräumen des Stacks kein Unterschied zwischen CDECL/STDCALL besteht.

Geändert von brechi (26. Apr 2012 um 19:22 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
31.123 Beiträge
 
Delphi XE3 Professional
 
#16

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

  Alt 27. Apr 2012, 00:40
Völlig funktionsfähig und erfolgreich inklusive Codeoptimierung in D7, D2007, D2009, D2010, XE und XE2 getestet.

Delphi-Quellcode:
uses
  Windows, SysUtils, StrUtils;

type
  NTSTATUS = Cardinal;
  TUnicodeString = record
    Length, MaximumLength: Word;
    Buffer: PWideChar;
  end;
  TObjectNameInformation = record
    Name: TUnicodeString;
    NameBuffer: array[0..MAX_PATH-1] of WideChar;
  end;

const
  STATUS_SUCCESS = NTSTATUS($00000000);
  STATUS_INVALID_PARAMETER = NTSTATUS($C000000D);
  STATUS_INFO_LENGTH_MISMATCH = NTSTATUS($C0000004);
  ObjectNameInformation = 1;

function DevicePathToFileName(const DevicePath: string): string;
var
  DeviceList, DosDevice: array[0..MAX_PATH-1] of Char;
  Device: PChar;
  Size: LongWord;
begin
  Result := DevicePath;
  Size := GetLogicalDriveStrings(MAX_PATH, @DeviceList);
  if (Size = 0) or (Size > MAX_PATH) then
    RaiseLastOSError;
  Device := @DeviceList;
  while Device^ <> #0 do begin
    Size := QueryDosDevice(PChar(ExcludeTrailingPathDelimiter(Device)), @DosDevice, MAX_PATH);
    if Size = 0 then
      RaiseLastOSError;
    if StartsText(IncludeTrailingPathDelimiter(DosDevice), Result) then
      Exit(Device + Copy(Result, Length(IncludeTrailingPathDelimiter(DosDevice)) + 1));
    Inc(Device, Length(Device) + 1);
  end;
end;

function GetFilePathFromHandle(hFile: THandle): string;
var
  NtQueryObject: function(Handle: THandle; ObjectInformationClass: Cardinal; ObjectInformation: Pointer;
    ObjectInformationLength: Cardinal; ReturnLength: PCardinal): NTSTATUS; stdcall;
  NameInformation: TObjectNameInformation;
  Status: NTSTATUS;
begin
  Result := '';
  NtQueryObject := GetProcAddress(GetModuleHandle('ntdll.dll'), 'NtQueryObject');
  if not Assigned(NtQueryObject) then
    Exit;
  Status := NtQueryObject(hFile, ObjectNameInformation, @NameInformation, SizeOf(NameInformation), nil);
  if Status <> STATUS_SUCCESS then
    Exit;
  Result := DevicePathToFileName(NameInformation.Name.Buffer);
end;
Ach ja, das Packed ist mit voller Absicht, denn bei kleinen Codeschnippseln versuche ich möglichst nicht an den Compileroptionen rumzuspielen,
denn ich weiß ja nicht, was im restlichen Code für Einstellungen vorgesehn sind.

Und leider bietet Delphi immernoch keine Möglichkeit die aktuellen Einstellen zwischenzuspeichern und nachher wieder zurückzusezten.
Das könnte man sich nur für {$#+} und {$#-} selber basteln, aber für {$A2}, {$A4} und {$A16} ist keine Bestimmung möglich.

TUnicodeString: oder ohne packed, aber mit {$A4} bzw. {$ALIGN 4}

TObjectNameInformation: alternativ ebenfalls mit {$A4} bzw. {$ALIGN 4}
Aber auch ohne packed und mit unkorrekter Ausrichtung, würde es dennoch funktionieren, solange keiner NameBuffer auslesen will.


Achtung: Im Zielprogramm muß eine Speicherausrichtung von mindestens 8 Byte eingestellt sein. (in den Projektoptionen oder über {$ALIGN 8}).
Ein {$ALIGN 16} währe vermutlich aber auch möglich.



Zitat:
Delphi-Quellcode:
if StartsText(IncludeTrailingPathDelimiter(DosDevice), Result) then
  Exit(Device + Copy(Result, Length(IncludeTrailingPathDelimiter(DosDevice)) + 1));
Und wenn es in älteren Delphis damit ein paar Problemchen gibt. (Letzeres geht immer)
Delphi-Quellcode:
if StartsText(IncludeTrailingPathDelimiter(DosDevice), Result) then begin
  Result := Device + Copy(Result, Length(IncludeTrailingPathDelimiter(DosDevice)) + 1);
  Exit;
end;
oder
Delphi-Quellcode:
if AnsiStartsText(IncludeTrailingPathDelimiter(DosDevice), Result) then begin
  Result := Device + Copy(Result, Length(IncludeTrailingPathDelimiter(DosDevice)) + 1, Length(DosDevice));
  Exit;
end;
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (27. Apr 2012 um 09:20 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
3.794 Beiträge
 
Delphi XE3 Professional
 
#17

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

  Alt 27. Apr 2012, 08:48
Hast du deinen Code mal für 64 Bit kompiliert? Dort wird dein packed Unicode String einige Probleme verursachen. Wie gesagt, die API erwartet ein Aligned Struct. Unter 32 Bit passt das Alignment zufällig. Unter 64 Bit war das bei meinen Versuchen nicht der Fall.

Da das Align aber, soweit ich weiß, die Standardeinstellung ist, brauchst du im Grunde nur die packed Direktive entfernen, ohne irgendwelche Compilerflags zu setzen.
"Do not argue with an idiot. He will drag you down to his level and beat you with experience."

Geändert von Zacherl (27. Apr 2012 um 09:08 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
31.123 Beiträge
 
Delphi XE3 Professional
 
#18

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

  Alt 27. Apr 2012, 09:14
Von Standard kann man eben nicht so einfach ausgehn, jedenfalls nicht bei einem ein einzelnen Codestück.

Oder kannst du sicherstellen, daß im Zielprojekt nicht die Projekteinstellungen andersaussehn,
bzw. ob in der Unit, wo der Code dann eingefügt wurde, nicht irgendwo am ALGIN gedreht wurde?
Wenn man Code als eigenständige Unit veröffentlicht, dann sieht die Sache gleich ganz anders aus.
[add] Aber OK, man könnte das ALIGN zu den Systemvoraussetzengen zählen. Oben editiert ... besser so?

Nee, 64 bit, hatte ich noch nicht probiert, hol ich heut Abend aber noch nach.
Nur das Mac kann ich mir ersparen. (hab eh keinen und diese komischen Macs haben irgendeine unverständliche Allergie gegen WinAPI-Aufrufe )
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (27. Apr 2012 um 09:20 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.060 Beiträge
 
#19

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

  Alt 27. Apr 2012, 12:38
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

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.

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
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)

Geändert von Assarbad (27. Apr 2012 um 12:41 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
31.123 Beiträge
 
Delphi XE3 Professional
 
#20

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

  Alt 27. Apr 2012, 12:45
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu (27. Apr 2012 um 12:56 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:57 Uhr.
Powered by vBulletin® Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2016 by Daniel R. Wolf