Moin,

ich habe hier einen dll-Aufruf

markieren

Code:

GetProcAddress(dllhandle,'_INIPC_initialize_board@4')

GetProcAddress möchte einen PAnsiChar haben. Wie findet hier die Übergabe in D2009 statt? Wird das gecastet oder muss ich das explizit tun?
Basis ist eine D6-Anwendung

Grüße, Messie

Hallo,

GetProcAddress(dllhandle,PAnsiChar(AnsiString('_INIPC_initialize_board@4')))
So kann eigentlich nichts schief gehen.

Zitat von Unit Windows:

markieren

Delphi-Quellcode:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; stdcall; overload;
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC; stdcall; overload; // das ist eine überladene Version vom Delphi, welche das in einen AnsiString umwandelt und weitergibt.

Fazit: Man kann also problemlos durchgehend mit String und PChar arbeiten.

Das hättest du aber auch selber nachsehen/ausprobieren können


Dank Multiplatform würde ich aber irgendwo langsam mal eine gemeinsame Schnittstelle erwarten, welche direkt einen String entgegennimmt.

Ist das eine Fremd-DLL?

Die Funktion ist nicht in der DEF-Datei der DLL eingetragen bzw. hat die DLL keine DEF-Datei.
Dadurch hat man so Gelumpe wie @4 an den Funktionsnamen.

Siehe auch:
http://msdn.microsoft.com/de-de/library/d91k01sh.aspx

Zitat von himitsu:

Zitat von Unit Windows:

markieren

Delphi-Quellcode:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; stdcall; overload;
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC; stdcall; overload; // das ist eine überladene Version vom Delphi, welche das in einen AnsiString umwandelt und weitergibt.

Fazit: Man kann also problemlos durchgehend mit String und PChar arbeiten.

Das hättest du aber auch selber nachsehen/ausprobieren können

Öhm, in meiner D2009-Doku finde ich das nicht, da ist nix overload:

markieren

Code:

GetProcAddress

Retrieves the address of an exported function or variable from the specified dynamic-link library (DLL).


FARPROC WINAPI GetProcAddress(
  HMODULE hModule,
  LPCSTR lpProcName
);

weder in der API-Doku noch im CodeInsight.

@TiGü: das ist eine D6-Wrapper-dll, die auf eine CAN-dll zugreift. Zur Abwärtskompatibilität hat der Lieferant eine eigene Wrapper-dll zur Verfügung gestellt. Also von hinten durch die Brust ins Auge. Funzt aber mit dem Delphi-Testprogramm. Das Benutzerprogramm ist aber in LabView geschrieben und da läuft die dll nicht unter Win7/64. Da LabView nur Ansi und 32 bit kann bin ich auf der Suche nach der Ursache. Und da kommen die Aufrufe und Übergaben recht schnell in den Focus.
Vielleicht gibt es ja noch andere Unterschiede beim dll-Aufruf zwischen XP und Win7/64

Grüße, Messie

Zitat:

API-Doku

Als wenn die OH jemals richtig oder gar vollständig war.

In der WinAPI gibt es natürlich immernoch nur die ANSI-Version.
Delphi hat inzwischen eine überladene Version mit Konvertierung, aber ich hätte damit gerechnet, daß die schon bei 2009 eingebaut worden ist. (spätestens in XE gibt es sie jedenfalls schon)

Was sind denn für Versionen in der Windows.pas zu finden?

Zitat von himitsu:

Zitat:

API-Doku

Was sind denn für Versionen in der Windows.pas zu finden?

Gute Idee da mal nachzusehen

Noch nicht überladen weil noch nicht unicodefähig

markieren

Code:

function GetProcAddress(hModule: HMODULE; lpProcName: LPCSTR): FARPROC; external kernel32 name 'GetProcAddress';
function GetProcAddress(hModule: HMODULE; lpProcName: LPCWSTR): FARPROC;
begin
  if ULONG_PTR(lpProcName) shr 16 = 0 then // IS_INTRESOURCE
    Result := GetProcAddress(hModule, LPCSTR(lpProcName))
  else
    Result := GetProcAddress(hModule, LPCSTR(AnsiString(lpProcName)));
end;

Aber das sollte damit geklärt sein. Mein Problem muss ich wohl anders lösen. Ich habe einen signed int mit 16 bit im Labview gefunden und vermute, dass dessen Übergabe ans Win64 Späne macht. Das werde ich als nächstes debuggen.

Grüße, Messie