C DLL mit Delphi verwenden

[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 ...

[Beowulf01]

Sorry ich bezog mich auf dieses theoretisch beschrieben Struct:

Zitat:

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.

Hier ist der C-Quellcode

Code:

typedef struct {
    UINT8  deviceType [MAX_DEVICE_TYPE_LENGTH + 1];
    UINT8  orderId [MAX_ORDER_ID_LENGTH + 1];
    UINT16 hwRevision;
    UINT8  swRevisionPrefix;
    UINT16 swRevision1;
    UINT16 swRevision2;
    UINT16 swRevision3;
} ATTR_PACKED ANNOTATION;

und hier ist mein Delphi-Code dazu:

Delphi-Quellcode:

  TAnnotation =
    packed record
      deviceType  : array[0..MAX_DEVICE_TYPE_LENGTH] of UINT8;
      orderId     : array[0..MAX_ORDER_ID_LENGTH] of UINT8;
      hwRevision  : UINT16;
      swRevisionPrefix : UINT8;
      swRevision1 : UINT16;
      swRevision2 : UINT16;
      swRevision3 : UINT16;
    end;

Wie oben gesagt, hatte ich schon mit dem alignment "gespielt", aber bin zu keinem Ergebnis gekommen... nur nen Haufen Schutzverletzungen

[Assarbad]

Das packed muß hier definitiv raus. Wegen orderId und swRevisionPrefix.
Du kannst es auch so deklarieren (hier ist dann packed oder nicht egal):

Delphi-Quellcode:

  TAnnotation =
    packed record
      deviceType : array[0..MAX_DEVICE_TYPE_LENGTH] of UINT8;
      orderId : array[0..MAX_ORDER_ID_LENGTH] of UINT8;
      padding1 : UINT8;
      hwRevision : UINT16;
      swRevisionPrefix : UINT8;
      padding2 : UINT8;
      swRevision1 : UINT16;
      swRevision2 : UINT16;
      swRevision3 : UINT16;
    end;

[Beowulf01]

Danke, das hatte ich mir schon gedacht und gestern angefangen alle Structs zu suchen, wo ich das padding einführen muss. Echt fies diese Sache...
Ich hab angefangen in C mit sizeof und offsetof die Daten zu prüfen. Mal sehen, ob dann sich das Callback zurückmeldet...