DLL: Prozedureinsprungpunkt nicht gefunden

[Angel4585]

Hallo,

ich schreibe gerade ein kleines Programm um diese ShutdownBlockReason Methode für Vista zu testen.
Wie mache ich das denn nur genau, also ich habe die nötigen Funktionen eingebunden und bekomme unter Vista auch die Nachricht wenn das System runtergefahren wird.

Aber wenn ich das gleiche Programm unter Windows XP ausführe kommt die Meldung das der Prozedureinsprungpunkt nicht gefunden wurde.
Klar, die Prozedur gibts dort nochnicht.
Aber wie mach ich das denn, dass das selbe Programm auf beiden läuft ohne es mehrfach kompilieren zu müssen?

Der Fehler kommt denk ich direkt bei der Deklaration der Funktion oder?
Ne Compilerdirektive bringt ja nichts, da müst ichs für jedes System seperat kompilieren. :gruebel:

:angel:

[quendolineDD]

Naja, der Weg führt doch zu den Compilerschaltern. Du musst für bestimmte Sachen, die du in Vista nutzt, es aber in XP nicht gibt, diese mit Schaltern belegen und für XP dann einen anderen Weg nutzen.

[Mithrandir]

Zitat:

Zitat von Angel4585

Der Fehler kommt denk ich direkt bei der Deklaration der Funktion oder?

Müsstest du vielleicht mal debuggen. Von MagicAndre gibt ja ne super Unit, um während der Laufzeit die Windowsversion auszulesen. Es würde also einfach reichen, auf Version > Windows XP zu testen, und erst dann die Funktion auszuführen. Oder habe ich da was falsch verstanden. :stupid:

[Angel4585]

Meinst du so? Mach ich ja, aber das hilft nix. Auf dem Testsystem hab ich leider kein Delphi installiert :(

Delphi-Quellcode:

var LVersion : TWindowsVersionInfo;
begin
LVersion := TWindowsVersionInfo.Create(self);
try
if LVersion.MajorVersion >= 6 then
  begin
  if ShutdownBlockReasonCreate(self.Handle,'Testprogramm für ShutdownBlockReason')then SNLogger.log('Shutdown wird geblockt')
  else SNLogger.log('Blocken nicht möglich'+SysErrorMessage(GetLastError));
  end;
finally
  LVersion.Free;
end;

[hoika]

Hallo,

oder du Methode dynamisch binden und aufrufen (LoadLibrary / GetProcAddress),


Heiko

[Mithrandir]

Hmm... :gruebel:

Vielleicht findet sich ja wer in der DP, der ne Delphi-Version unter Vista laufen hat. Ansonsten müsstest du mal madExcept in deine Anwendung anbauen. Dann könntest du wenigstens schonmal die Codezeile lokalisieren.

Oder so machen, wie hoika das vorgeschlagen hat. ;)

[Angel4585]

Naja mir isses im Endeffekt klar wo das auftritt:

Delphi-Quellcode:

function ShutdownBlockReasonCreate(hWnd:HWND;pwszReason:LPCWSTR):BOOL;stdcall;external user32 name 'ShutdownBlockReasonCreate';
function ShutdownBlockReasonDestroy(hWnd:HWND):BOOL;stdcall;external user32 name 'ShutdownBlockReasonDestroy';
function ShutdownBlockReasonQuery(hWnd:HWND;pwszBuff:LPWSTR;pcchBuff:DWORD):BOOL;stdcall;external user32 name 'ShutdownBlockReasonQuery';

Die werden global deklariert(Query brauch ich iwie garnich :gruebel: ) und da wird auch der Fehler auftreten.
Ich probier das mal mit LoadLibrary, ma schaun wie das geht

[DeddyH]

Wie das geht, kannst Du z.B. bei Olli nachlesen.

[Luckie]

Also, läd man DLLs und exportierte Funktionen aus DLLs überprüft der Loader von Windows beim direkt beim Starten der Anwendung, ob alle Referenzen aufgelöst werden können. Ist dies nicht der Fall, bricht der Loader den Startvorgang mit einer Fehlermeldung ab.

Es gibt zwei Möglichkeiten das Problem zu lösen:
1. Man erstell zwei Anwendungen, für jedes Zielsystem eine. Dies lässt sich unter Delphi relativ leicht mit Compiler-Schalteren erreichen oder
2. Man ermittelt das Betriebssystem zu Laufzeit und läd die DLL und die Funktion, dann abhängig vom Betriebssystem dynamisch.

[sirius]

Nur dynamisch. Die Funktionen gibt es nur unter Wista. Wenn du die statisch einbindest, werden sie in die Importtabelle der Exe compiliert. Ja und da gibt es bereits beim Laden der Exe Probleme und das bevor du irgendwelchen Code ausführen kann.

Und versionsabhängige Compilierung mittels Compilerschalter bringt auch nix. Denn das Problem hängt ja nicht davon ab, auf welcher Maschine du den Code compilierst, sondern auf welcher du ihn ausführst.

[Luckie]

Äh, warum sollte eine versionsabhängige Kompilierung nicht funktionieren? Mittels Compilerschalter kann ich doch bestimmen, ob die DLL und die Funktion gelinkt werden soll oder nicht. Das Entwicklungssystem spielt dabei doch keine Rolle.

[Angel4585]

Delphi-Quellcode:

var
LVersion : TWindowsVersionInfo;
LPath:PChar;
LHandle: THandle;
LCreate : TShutdownBlockReasonCreate;
begin
LVersion := TWindowsVersionInfo.Create(self);
try
if LVersion.MajorVersion >= 6 then
  begin
  GetSystemDirectory(LPath,max_Path+1);
  LHandle:=LoadLibrary(PChar(LPath+'\user32.dll'));
  @LCreate := GetProcAddress(LHandle,PChar('ShutdownBlockReasonCreate'));
  if LCreate(self.Handle,'Testprogramm für ShutdownBlockReason')then SNLogger.log('Shutdown wird geblockt')
  else SNLogger.log('Blocken nicht möglich'+SysErrorMessage(GetLastError));
  end;
finally
  LVersion.Free;
end;

Da kommt jetz en Fehler wegen falschem Parameter, ich denke es liegt daran das ich String übergebe, aber LPCWSTR(PWideChar) gefordert ist. Wie wandle ich das denn um :shock: PChar(derstring) geht jedenfalls nicht

[sirius]

Zitat:

Zitat von Luckie

Äh, warum sollte eine versionsabhängige Kompilierung nicht funktionieren? Mittels Compilerschalter kann ich doch bestimmen, ob die DLL und die Funktion gelinkt werden soll oder nicht. Das Entwicklungssystem spielt dabei doch keine Rolle.

Wenn ich ein Programm mit den oben beschriebenen Funktionen unter Vista Compiliere, dann wird es unter Vista und unter XP mit demselben Code laufen. Und eben unter XP nicht funktionieren.

[sirius]

Zitat:

Da kommt jetz en Fehler wegen falschem Parameter, ich denke es liegt daran das ich String übergebe, aber LPCWSTR(PWideChar) gefordert ist. Wie wandle ich das denn um :shock: PChar(derstring) geht jedenfalls nicht

Delphi-Quellcode:

var s:string;

PWideChar(WideString(s))

[mr_emre_d]

Das Ermitteln des Systempaths ist unnötig, da LoadLibrary sowieso im Applications-Verzeichnis und in diversen anderen Windows Verzeichnissen ala System32 nachsieht. (soweit ich weiß)

Weiterhin würde ich nach GetProcAddress prüfen, ob die Adresse, die ermittelt wurde, NULL (NIL) ist

Code:

If the function fails, the return value is NULL.

MfG

[sirius]

Achja, und weil die user32.dll ganz sicher schon geladen ist, reicht ein "Getmodulehandle" anstatt Loadlibrary auch aus.

[Angel4585]

die Umwandlung funzt, aber kommt immernoch die Meldung "Falscher Parameter"
Hier mal die Deklaration der Methoden:

Delphi-Quellcode:

type
TShutdownBlockReasonCreate = function (hWnd:HWND;pwszReason:LPCWSTR):BOOL;
TShutdownBlockReasonDestroy = function (hWnd:HWND):BOOL;


{
Das ist die Deklaration der Methoden vom Anfang

function ShutdownBlockReasonCreate(hWnd:HWND;pwszReason:LPCWSTR):BOOL;stdcall;external user32 name 'ShutdownBlockReasonCreate';
function ShutdownBlockReasonDestroy(hWnd:HWND):BOOL;stdcall;external user32 name 'ShutdownBlockReasonDestroy';
function ShutdownBlockReasonQuery(hWnd:HWND;pwszBuff:LPWSTR;pcchBuff:DWORD):BOOL;stdcall;external user32 name 'ShutdownBlockReasonQuery';
}

Die habe ich doch richtig übertragen oder?
Also ich erkenn grad keinen Fehler :( (Was aber nix heissen muss :duck: )


@Roter Kasten:

Delphi-Quellcode:

var
LVersion : TWindowsVersionInfo;
LPath:PChar;
LHandle: THandle;
LCreate : TShutdownBlockReasonCreate;
begin
LVersion := TWindowsVersionInfo.Create(self);
try
if LVersion.MajorVersion >= 6 then
  begin
  LHandle:=GetModuleHandle(PChar('user32.dll'));//TODO: Was wenn nicht eingeloggt?
  @LCreate := GetProcAddress(LHandle,PChar('ShutdownBlockReasonCreate'));
  if Assigned(LCreate) then
    begin
    if LCreate(self.Handle,PWideChar(WideString('ShutdownBlockReason Test')))then SNLogger.log('Shutdown wird geblockt')
    else SNLogger.log('Blocken nicht möglich'+SysErrorMessage(GetLastError));
    end;
  end;
finally
  LVersion.Free;
end;

Hab mal die Sachen berücksichtigt. die zwei if's hab ich damit ich beim debuggen besser seh wo ich bin.
Hab den aufruf von LCreate(self....) mal zu den überwachten Ausdrücken gemacht und dort bekomm ich ein true angezeigt. hier springt das ganze dann aber ins else :wall:

[mr_emre_d]

@sirius
Ansich ist es eigentlich eh völlig egal, da LoadLibrary - falls die zu Ladende Library schon vorhanden ist - intern einfach nur einen Counter erhöht und die Adresse, in der die Library gemappt ist, zurückgibt!

EDIT:
EDIT2: ups .. sorry

MfG

[Luckie]

Zitat:

Zitat von sirius

Zitat:

Zitat von Luckie

Äh, warum sollte eine versionsabhängige Kompilierung nicht funktionieren? Mittels Compilerschalter kann ich doch bestimmen, ob die DLL und die Funktion gelinkt werden soll oder nicht. Das Entwicklungssystem spielt dabei doch keine Rolle.

Wenn ich ein Programm mit den oben beschriebenen Funktionen unter Vista Compiliere, dann wird es unter Vista und unter XP mit demselben Code laufen. Und eben unter XP nicht funktionieren.

Deswegen sollst du es ja auch mit Compilerschaltern kompilieren, einmal mit der Vista Funktion und einmal ohne die Vista Funktion für XP.

[DeddyH]

Verstehe ich ehrlich gesagt aber auch nicht, wozu 2 Versionen kompilieren? Mit dynamischer Bindung lässt sich doch feststellen, ob die Funktion vorhanden ist. Wenn nicht, kann sie eben nicht benutzt werden, aber ich komme mit einem einzigen Kompilat aus.

[Luckie]

Mein Posting bezog sich auf sirius.

Welchen Weg man wählt, ob mit Compilerschlater oder dynamisch linken, bleibt einem selbst überlassen, beide Wege führen zum Ziel.

[Angel4585]

In diesem Thread hat jemand das gleiche Problem und es damit gelöst, das er stdcall auch beim dynamischen Prozeduraufruf genutzt hat. Wie mache ich das da? :cyclops: :gruebel:

Edit: Achso, bei der Deklaration der Methodentypen :wall: :dp: