C DLL mit Delphi verwenden

[Beowulf01]

Hallo ich habe ein Problem mit einer C-DLL.
Ich arbeite mit Delphi 7 und habe die Header-Dateien der Dll vorliegen.
Nur wie erkenne ich, wann ich cdecl, stdcall oder was auch immer verwenden muss. Ich weiß, dass diese Einstellung sagt, wie die Parameter des Callbacks auf dem Stack behandelt werden sollen. Also wer die aufräumt.
Das Problem direkt:
Ich kann wunderbar die Methoden der DLL aufrufen, aber dort, wo ich ein Callback erwarte, kommt einfach nichts. Daher meine Frage, wie ich prüfen kann, ob die Parameter korrekt übertragen wurden, und nicht zum Beispiel irgendwelche unsinns-Zeiger statt der korreten Zeiger auf die Callbacks übertragen wurden.

[Aphton]

Du könntest per Debugger im disassemblierten Code nachschauen, in welcher Reihenfolge die Parameter gepusht werden. Mehr fällt mir spontan auch nicht ein.

[Beowulf01]

Dankeschön, für den Hinweis. Ich glaub ich muss dann nur schauen, wie der Stackpointer sich währen dem Aufruf der DLL-Methode verhält, oder?

Ich habe gerade einfach mal stdcall gegen cdecl ausgetauscht und da hagelt es schon bei den ersten DLL-Aufrufen Schutzverletzungen, also geh ich mal von stdcall aus. Dennoch bekomme ich kein Callback aus der Dll. Ich werde gleich mal zusammenstellen, wie die Aufrufe im C-Beispielprogramm gemacht werden und wie ich das in Delphi umgesetzt habe. Dauert nur ein Momentchen...

[Beowulf01]

C Beispiel:

Header-File

Code:

#undef ATTR_PACKED
#if defined(_MSC_VER)
 #pragma pack( push, safe_old_packing, 4 )
 #define ATTR_PACKED
...
#endif

#ifdef PASCAL
    #define CODE_ATTR __stdcall
#else
    #define CODE_ATTR
#endif

typedef IOXS    (*CBF_DATA_WRITE) /* write data to IO stack (local ==> remote) */
       (UINT32          DevHndl,       /* Handle for device */
        DEV_ADDR      * pAddr,         /* address */
        UINT32          BufLen,        /* length of input data */
        UINT8         * pBuffer,       /* Ptr to data buffer to write to */
        IOXS            Iocs);         /* remote status */

typedef IOXS    (*CBF_DATA_READ)  /* read data from IO stack (remote ==> local) */
       (UINT32          DevHndl,       /* Handle for device */
        DEV_ADDR      * pAddr,         /* address */
        UINT32          BufLen,        /* length of input data */
        UINT8         * pBuffer,       /* Ptr to data buffer to read from */
        IOXS            Iops);         /* provider status */

/* structure for callback function block */
typedef struct {
    UINT32               size;          // size of struct = sizeof(CBF_FUNCTIONS)
    CBF_DATA_WRITE       cbf_data_write;
    CBF_DATA_READ        cbf_data_read;
} ATTR_PACKED CBF_FUNCTIONS;

UINT32 CODE_ATTR device_open (
        UINT16          DeviceId,       /* [in]  device id */
        CBF_FUNCTIONS * pCbf,           /* [in]  cbf */
        UINT32        * pDevHndl);      /* [out] device handle */

Hätte ich vorher schon genauer hingeschaut, hätte ich gesehen, dass es stdcall ist...(s.o.)

Und hier meine Umsetzung in Delphi:

Code:

{$Z4}

TCbfDataRWProc  =
  procedure(
    DevHndl     : UINT32;
    pAddr       : PTDevAddr;
    BufLen      : UINT32;
    pBuffer     : PTUINT8;
    Ioxs        : EIoXS
  ); EIoXS; stdcall;

TCbfFunctions =
  packed record
    size                : UINT32;
    cbf_data_write      : TCbfDataRWProc;
    cbf_data_read       : TCbfDataRWProc;
  end;

PTCbfFunctions = ^TCbfFunctions;

function device_open(
  DeviceId        : UINT16;
  pCbf            : PTCbfFunctions;
  pDevHndl        : PTUINT32
  ): UINT32; stdcall;

[Beowulf01]

Ich komme irgendwie nicht weiter...
Kann das Problem das Allignment der Daten in den Strukturen sein?
Ich habe eben festgestellt, dass bei einem MethodenAufruf eine C-Struktur 58 Byte groß ist und die dazugehörige Delphi-Struktur nur 56 Byte.

Die Struktur besteht aus :

Byte-Array (26 Bytes)
Byte-Array (21 Bytes)
Word ( 2 Bytes)
Byte ( 1 Byte )
Word ( 2 Bytes)
Word ( 2 Bytes)
Word ( 2 Bytes)

In Delphi habe ich ein Packed Record draus gemacht, aber in C wir die Direktive

#pragma pack( push, safe_old_packing, 4 )

verwendet. Heißt das jetzt ich muss

{$A4}

verwenden?

[Assarbad]

Welcher Typ ist denn IOXS? ... du hast bspw. keinen Rückgabewert in deiner Delphi-Funktionsdeklaration.

Ansonsten hilft hier nur sich das Projekt (oder die Make-Datei) anzugucken. MSVC erlaubt es einzustellen welche Aufrufkonvention standardmäßig verwendet wird.

Delphi-Quellcode:

TCbfDataRWProc =
  function(
    DevHndl    : UINT32;
    pAddr      : PTDevAddr;
    BufLen     : UINT32;
    pBuffer    : PTUINT8;
    Ioxs       : EIoXS
  ): IOXS; EIoXS; stdcall;

Ob stdcall hier korrekt ist, kann man ohne den Kontext zu kennen nicht sagen. Hast du bspw. die Projektdatei (MSVC) parat?

Nachtrag: Alignment ist bei diesem Record unter Annahme von 32bit (immerhin gibt es noch keinen offiziellen 64bit Delphi-Compiler) irrelevant.

[Beowulf01]

Zitat:

Welcher Typ ist denn IOXS? ... du hast bspw. keinen Rückgabewert in deiner Delphi-Funktionsdeklaration.

Wie müsste denn das mit Rückgabewert aussehen?



IOXS ist von folgendem Typ:

Code:

  EIoXS = (S_GOOD = 0,
           S_BAD  = 1); //represents IO status

Zitat:

Ob stdcall hier korrekt ist, kann man ohne den Kontext zu kennen nicht sagen. Hast du bspw. die Projektdatei (MSVC) parat?

Ich habe für das Beispiel C-Projekt alles um es zu übersetzen, also auch die Projektdatei.
Wenn du mir beschreiben kannst, wo ich die Daten finde, schaue ich nach, ansonsten das ganze Projekt ist etwas mächtiger und es ist ein Copyright drauf...

Ist es unter "Konfigurationseigenschaften -> C/C++ -> Erweitert -> Aufrukonvention" zu finden. Dort steht im Beispielprojekt "cdecl"...

@Assarbad P.S.: Dein Delphi Tutorial zu DLLs is echt klasse, nur zu der Sache mit den Callback-Funktionen konnte ich da leider nicht viel finden...

[Assarbad]

Zitat von Beowulf01:

Wie müsste denn das mit Rückgabewert aussehen?

Hatte ich oben schon

Aber was ich nicht verstehe ist dann dein Code:

Delphi-Quellcode:

TCbfDataRWProc =
  procedure(
    DevHndl    : UINT32;
    pAddr      : PTDevAddr;
    BufLen     : UINT32;
    pBuffer    : PTUINT8;
    Ioxs       : EIoXS
  ); EIoXS; stdcall;

Hier müßte eindeutig vor dem EIoXS ein Doppelpunkt stehen, kein Semikolon und natürlich wäre es dann function und nicht procedure in Delphi. Kann mir im Moment nicht vorstellen, daß die Übersetzung mit EIoXS so auf einsamer Flur überhaupt syntaxtechnisch korrekt ist.

Zitat von Beowulf01:

Ich habe für das Beispiel C-Projekt alles um es zu übersetzen, also auch die Projektdatei.
Wenn du mir beschreiben kannst, wo ich die Daten finde, schaue ich nach, ansonsten das ganze Projekt ist etwas mächtiger und es ist ein Copyright drauf...

Welches Format ist es denn? .vcproj? Wenn ja, gucke ich mal flott wie die Parameter im XML heißen.

Zitat von Beowulf01:

Ist es unter "Konfigurationseigenschaften -> C/C++ -> Erweitert -> Aufrukonvention" zu finden. Dort steht im Beispielprojekt "cdecl"...

Dann sollte rein theoretisch, nach dem Original zu urteilen, die Callbackfunktion ebenfalls cdecl sein. Denn bei denen wurde explizit nix angegeben.

Zitat von Beowulf01:

@Assarbad P.S.: Dein Delphi Tutorial zu DLLs is echt klasse, nur zu der Sache mit den Callback-Funktionen konnte ich da leider nicht viel finden...

Vor allem ist es ziemlich in die Jahre gekommen ...

[Beowulf01]

Ok, bei dem Rückgabewert ist mir eine Fehler unterlaufen. Hab gerade mal nachgeschaut. Die aktuelle Version ist jetzt:

Delphi-Quellcode:

  TCbfDataRWProc =
    function (
      DevHndl     : UINT32;
      pAddr       : PTDevAddr;
      BufLen      : UINT32;
      pBuffer     : PUINT8;
      Ioxs        : EIoXS
    ): EIoXS; stdcall;

Wegen der Aufrufkonvention:

In der Headerdatei steht

Code:

#ifdef PASCAL
    #define CODE_ATTR __stdcall
#else
    #define CODE_ATTR
#endif

und Visual Studio ist so freundlich den Bereich von #ifdef..#else..#endif, der aktuell nicht relevant ist, auszugrauen und in der obigen Anweisung ist der Teil mit stdcall nicht ausgegraut(also PASCAL irgendwo definiert). "CODE_ATTR" wir bei allen exportierten Funktionen verwendet, deshalb gehe ich davon aus, dass ich mit stdcall arbeiten muss. Oder ist der Parameter, der dem Compiler in der "Kommandozeile" mitgegeben wird stärker?

Ich vermute dass doch noch irgendwo das Problem in den Datenstrukturen liegt. Ich hatte ja unten schon ein Beispiel genannt, wo das C-Struct 2 Byte größer wie mein Delphi-Record ist. Werden die Übergabe-Strukturen bei der Übergabe and die DLL-Methode in 32 Bit Wörter zerhackt und auf den Stack gelegt, oder wird jeder Primitive Typ aus eine struct(record) für sich auf vollständige 32 Bit aufgefüllt und dann auf den Stack gelegt?
Denn im einen Fall hätte ich ja dann auf jeden Fall ein Problem mit dm Data-alignment.

[Assarbad]

Zitat von Beowulf01:

Wegen der Aufrufkonvention:

In der Headerdatei steht

Code:

#ifdef PASCAL
    #define CODE_ATTR __stdcall
#else
    #define CODE_ATTR
#endif

und Visual Studio ist so freundlich den Bereich von #ifdef..#else..#endif, der aktuell nicht relevant ist, auszugrauen und in der obigen Anweisung ist der Teil mit stdcall nicht ausgegraut(also PASCAL irgendwo definiert). "CODE_ATTR" wir bei allen exportierten Funktionen verwendet, deshalb gehe ich davon aus, dass ich mit stdcall arbeiten muss. Oder ist der Parameter, der dem Compiler in der "Kommandozeile" mitgegeben wird stärker?

Sie müssen jedenfalls nicht identisch sein, sind es aber in den meisten Fällen. Würde also auch erstmal von stdcall ausgehen.

Zitat von Beowulf01:

Ich vermute dass doch noch irgendwo das Problem in den Datenstrukturen liegt. Ich hatte ja unten schon ein Beispiel genannt, wo das C-Struct 2 Byte größer wie mein Delphi-Record ist. Werden die Übergabe-Strukturen bei der Übergabe and die DLL-Methode in 32 Bit Wörter zerhackt und auf den Stack gelegt, oder wird jeder Primitive Typ aus eine struct(record) für sich auf vollständige 32 Bit aufgefüllt und dann auf den Stack gelegt?

Es wird ein Pointer übergeben.

Allerdings hast du nur eine struct angegeben:

Code:

typedef struct {
    UINT32               size;         // size of struct = sizeof(CBF_FUNCTIONS)
    CBF_DATA_WRITE      cbf_data_write;
    CBF_DATA_READ       cbf_data_read;
} ATTR_PACKED CBF_FUNCTIONS;

Da nun UINT32 in deiner Übersetzung hoffentlich ein DWORD oder ähnliches ist, und CBF_DATA_WRITE sowie CBF_DATA_READ Pointertypen sind, sollte der Record exakt 12 Bytes groß sein. Und das unabhängig davon ob er gepackt wird oder nicht. Hakeln kann es hier aber bspw. bei UINT32 ... wie haste das übersetzt? Bzw. wie definiert das eine Unit welche es übersetzt?

Zitat von Beowulf01:

Denn im einen Fall hätte ich ja dann auf jeden Fall ein Problem mit dm Data-alignment.

Könnte ich mit den verfügbaren Informationen nicht nachvollziehen ...