Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Probleme mit Datentypen bei einer DLL (https://www.delphipraxis.net/168978-probleme-mit-datentypen-bei-einer-dll.html)

mcinternet 21. Jun 2012 11:24

Probleme mit Datentypen bei einer DLL
 
Moin,

ich habe eine DLL die mir laut Buch eine Adresse auf einen Null-Termierten String zurückgibt
( returns the address of a null-terminated character string ). Habe da bereits alle möglichen Datentypen ausprobiert und komme auf keinen grünen Zweig. Vielleicht hat hier jemand einen Tip?

Die dll ist aus dem Jahre 2004 und wird seitdem nicht mehr verändert -

ich arbeite hier mit Delphi XE unter Windows 7.

der Aufruf ist:

function xyzErrMsg ( errorCode : Word
) : String; stdcall; external xyzdll name 'ErrMsg';

Der Datentyp String passt hier leider nicht

Gruss

McInternet

p80286 21. Jun 2012 11:39

AW: Probleme mit Datentypen bei einer DLL
 
Hast Du es mal mit
Delphi-Quellcode:
PAnsiChar
versucht ?

Gruß
K-H

mcinternet 21. Jun 2012 12:04

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von p80286 (Beitrag 1171906)
Hast Du es mal mit
Delphi-Quellcode:
PAnsiChar
versucht ?

Gruß
K-H

aufruf dann:

var Meldung : PAnsichar;

Meldung := yxzErrMsg(errornummer);

Gruss
McInternet

mcinternet 21. Jun 2012 12:35

AW: Probleme mit Datentypen bei einer DLL
 
ne - kommt nur Blödsinn :(


Gruss

McInternet

NickelM 21. Jun 2012 12:39

AW: Probleme mit Datentypen bei einer DLL
 
Nein, ich glaube du hast ihn falsch verstanden, du musst sozusagen, wie du die Funktion importierst ändern.
Delphi-Quellcode:
function xyzErrMsg ( errorCode : Word
) : String; stdcall; external xyzdll name 'ErrMsg';
zu:
Delphi-Quellcode:
function xyzErrMsg ( errorCode : Word
) : PAnsiChar; stdcall; external xyzdll name 'ErrMsg'; //Man verwendet ungern Strings, also den DatenTyp String von Delphi. PAnsiChar ist nur eine Adresse auf den Anfang eines Textes im Speicher.
Und um im Speicher zu wissen, wann er aufhört, setzt man ein 0 Byte (#0 in Char) am Ende.
D.h. wenn du auf den Datentyp PAnsiChar zugreifst, wird alles gelesen bis zum 0 Byte.
Gruß NickelM

mcinternet 21. Jun 2012 12:43

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von NickelM (Beitrag 1171917)
Nein, ich glaube du hast ihn falsch verstanden, du musst sozusagen, wie du die Funktion importierst ändern.
Delphi-Quellcode:
function xyzErrMsg ( errorCode : Word
) : String; stdcall; external xyzdll name 'ErrMsg';
zu:
Delphi-Quellcode:
function xyzErrMsg ( errorCode : Word
) : PAnsiChar; stdcall; external xyzdll name 'ErrMsg'; //Man verwendet ungern Strings, also den DatenTyp String von Delphi. PAnsiChar ist nur eine Adresse auf den Anfang eines Textes im Speicher.
Und um im Speicher zu wissen, wann er aufhört, setzt man ein 0 Byte (#0 in Char) am Ende.
D.h. wenn du auf den Datentyp PAnsiChar zugreifst, wird alles gelesen bis zum 0 Byte.
Gruß NickelM

das hab ich schon so nach PAnsiChar geändert.

Ich rufe dann diese Funktion so auf:

var Meldung : PAnsiChar;
Fehlernummer : Word;
Begin
Meldung := xyzErrMsg(Fehlernummer);
...
...
end;

nur leider steht da nur Blödsinn drin ( wenn ich schon mit dem Debugger reinschaue)
=> $495ABA{"} ....
und drin stehen muß z.B. => success etc.

Achso: Das Gleiche compiliert unter Delphi 2007 - einwandfrei!

Gruß
McInternet

DeddyH 21. Jun 2012 12:50

AW: Probleme mit Datentypen bei einer DLL
 
Der Funktionskopf ist schon ungewöhnlich für eine Funktion in einer DLL. Normalerweise übergibt man einen Speicherbereich, den man selbst reserviert hat, welcher dann durch die Funktion befüllt wird. Ist die DLL in Delphi geschrieben? Falls in C/C++, hast Du da Header-Dateien dafür? Wie sähe dann da der Originalaufruf aus?

mcinternet 21. Jun 2012 12:57

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von DeddyH (Beitrag 1171921)
Der Funktionskopf ist schon ungewöhnlich für eine Funktion in einer DLL. Normalerweise übergibt man einen Speicherbereich, den man selbst reserviert hat, welcher dann durch die Funktion befüllt wird. Ist die DLL in Delphi geschrieben? Falls in C/C++, hast Du da Header-Dateien dafür? Wie sähe dann da der Originalaufruf aus?

Die DLL ist in C geschrieben - welche Version, keine Ahnung. Kommt von Intel und dient der Kommunikation mit einer TK-Anlage. Es gibt keine neuere Version, auch keine grossartige weitergehende Doku. Zum Coden für eine Komponente mit D2007 war es wohl auch ausreichend. Es gibt dafür auch keinen weitergehenden Support. Leider :shock:

Headerdateien gibt es auch keine :evil:

Gruß

McInternet

Bernhard Geyer 21. Jun 2012 13:12

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von mcinternet (Beitrag 1171922)
Die DLL ist in C geschrieben - welche Version, keine Ahnung. Kommt von Intel und dient der Kommunikation mit einer TK-Anlage. Es gibt keine neuere Version, auch keine grossartige weitergehende Doku.

...

Headerdateien gibt es auch keine :evil:

Kann ich mir nicht vorstellen?
Wie heißt das Produkt? Kann man sich diese DLL/API-Beschreibung noch von Intel herunter laden?

shmia 21. Jun 2012 13:12

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von DeddyH (Beitrag 1171921)
Normalerweise übergibt man einen Speicherbereich, den man selbst reserviert hat,...

In dem konkreten Fall wäre die Art der Datenübergabe aber schon plausibel.
Es gibt ja offensichtlich mehrere Fehlermeldungen, die über einen errorCode ausgewählt werden.
Die Strings liegen in dem Fall hartcodiert im Speicherbereich der DLL und der Aufrufer bekommt lediglich einen Zeiger zurück.
Delphi-Quellcode:
function xyzErrMsg(errorCode : Word): PAnsiChar; stdcall; external xyzdll name 'ErrMsg';

var
  Meldung : AnsiString; // nicht PAnsiChar !
  Fehlernummer : Word;
Begin
  Fehlernummer := 42; // nicht vergessen die Fehlernummer zu setzen!!!
  Meldung := xyzErrMsg(Fehlernummer); // Zeiger auf 0-terminierten String wird automatisch in einen Delphi-String umgewandelt. (Compiler Magic)
  ShowMessage(Meldung);

mcinternet 21. Jun 2012 13:30

AW: Probleme mit Datentypen bei einer DLL
 
Zitat:

Zitat von shmia (Beitrag 1171927)
Zitat:

Zitat von DeddyH (Beitrag 1171921)
Normalerweise übergibt man einen Speicherbereich, den man selbst reserviert hat,...

In dem konkreten Fall wäre die Art der Datenübergabe aber schon plausibel.
Es gibt ja offensichtlich mehrere Fehlermeldungen, die über einen errorCode ausgewählt werden.
Die Strings liegen in dem Fall hartcodiert im Speicherbereich der DLL und der Aufrufer bekommt lediglich einen Zeiger zurück.
Delphi-Quellcode:
function xyzErrMsg(errorCode : Word): PAnsiChar; stdcall; external xyzdll name 'ErrMsg';

var
  Meldung : AnsiString; // nicht PAnsiChar !
  Fehlernummer : Word;
Begin
  Fehlernummer := 42; // nicht vergessen die Fehlernummer zu setzen!!!
  Meldung := xyzErrMsg(Fehlernummer); // Zeiger auf 0-terminierten String wird automatisch in einen Delphi-String umgewandelt. (Compiler Magic)
  ShowMessage(Meldung);

Bei dieser Version bekomme ich immer eine Zahl ( immer die gleiche, egal welchen Code ich übergebe ) zurück => 1180672

Gruss
McInternet

NickelM 21. Jun 2012 18:08

AW: Probleme mit Datentypen bei einer DLL
 
Liegt dir nicht der Original export vor?
In dem Buch wird doch sicher irgendwie ein Beispiel oder sonstwas stehen, oder wenn sie von C++ kommt poste mal die Dekleration von dort.
Das Ding ist nämlich, bei PAnsiChar's gibt es 2 Mögliche aufrufe.
- Erstens du übergibst die Variable, wo der Pointer "gespeichert" bzw. hinterlegt wird. Die DLL legt ggf. den Speicher fest und übergibt dir den Pointer (Adresse);
- Du musst einen Speicher festlegen. Dazu müsstest du die Größe wissen, also wie Lang der Text sein wird. Du legst den Speicher fest und übergibst die Variable an die Funktion. Diese schreibt in die Adresse die Daten.

In deinem Fall würd ich auf das erste Tippen. Versuch mal folgendes:
Delphi-Quellcode:
function xyzErrMsg(errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
//oder mal das
function xyzErrMsg(errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//oder mal einen von den Beiden
function xyzErrMsg(const errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
function xyzErrMsg(const errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//noch eine Möglich aber unwahrscheinlich
function xyzErrMsg(var errorCode : Word): Pointer; stdcall; external xyzdll name 'ErrMsg';
function xyzErrMsg(var errorCode : Word): Pointer; cdecl; external xyzdll name 'ErrMsg';
//Bei allen Möglchkeiten lass das Pointer mal hintendran.

var
  Meldung : PAnsiChar;
  P : Pointer;
  ErrorCode : Word;
Begin
  for ErrorCode := 0 to High(Word) do
  begin
    P := xyzErrMsg(ErrorCode);
    If P <> nil then
    begin
      Meldung := P; //Setz mal hier ein Breakpoint
      ShowMessage(Meldung);
    end;
  end;
So bei irgendeinem Wert muss er ja einen Text zurückgeben. Und alle Imports mal durchgehen mit diesem Code.

EDIT: Sorry, überlesen, hast ja schon gesagt, dass es keine Doku oder sonstwas gibt. Das sie in C geschrieben ist, sollte einer der cdecl; oben vielleicht eher funken.
Vielleicht Funkt dan irgendwas.

Gruß NickelM

himitsu 21. Jun 2012 18:27

AW: Probleme mit Datentypen bei einer DLL
 
CONST bringt bei Word nicht viel (ändert garnichts).

"ErrMsg" ... C++ baut gerne auch die Parametersignatur in den Exportnamen ein. Eventuell heißt es ja nicht "ErrMsg". ( ist das eigentlich CaseSensitiv? )

Statt Pointer kann man auch gleich PAnsiChar nehmen.
PWideChar wird es mit großer Wahrscheinlichkeit nicht sein.

Neben cdecl und stdcall gibt es noch ein paar Varianten mehr, aber Anderes hab ich hier auch noch nicht gesehn. (außer selten mal savecall und in Delphi natürlich pascal)

NickelM 21. Jun 2012 18:48

AW: Probleme mit Datentypen bei einer DLL
 
@himitsu : Ich weis, wegen Pointer. Wollte nur mal gugen, ob sich der Pointer immer ändert, ob er ungleich nil ist und wenn der Pointer existiert, ich die Adresse dann erst übertrage.
Wenn es dan funkt mit irgendeinem Funktionsaufruf, kann man immernoch Pointer durch PAnsiChar ersetzten.
Stimmt CONST bringt bei PWideChar,PAnsiChar oder sonstwo nur was, wenn sie als Paramter übergeben werden richtig? Was macht das dan eigentlich für einen Unterschied? Ich denke mal CONST bringt, das bei PAnsiChar,PWideChar z.b. der Text im Speicher der Funktion liegt und nicht die Adresse des Textes oder?
@Thread : Was mir gerade einfällt, so beim schreiben grad, wegen dem Namen der Funktion.
Ich kenn die Dll nicht vielleicht heist die Funktion ja "ErrMsgA".
Zumindest ist es oft bei WinAPIs so. Neuere Dlls, so ab Win2000 haben dann eine "ErrMsgA" und eine "ErrMsgW". Das "A" steht für ANSI und das "W" für Wide also PWideChar.

Das wären jetzt meine einizg letzen Ideen.

Gruß NickelM

Blup 22. Jun 2012 08:33

AW: Probleme mit Datentypen bei einer DLL
 
Raten bringt hier nicht viel.
Entweder mit dem Debugger in die DLL-Funktion springen und sich den Code anschaun oder gleich die ganze DLL diassemblieren (Windasm o.ä.).

mcinternet 2. Jul 2012 09:23

AW: Probleme mit Datentypen bei einer DLL
 
Problem ist gelöst.
da ich in die dll definitiv nicht hereinschauen kann, habe ich eine eigene Fehlercodetable aufgebaut :oops:

danke an alle für die Tipps.

Gruss

mc


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:03 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz