C DLL mit Delphi verwenden

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

[Beowulf01]

Also das Padding hat schon mal weiter geholfen, aber jetzt bekomme ich bei dem Callback ziemlich viel Müll in den Parametern übergeben.
Ich hab mich bis jetzt noch wenig mit dem CPU-Fenster der Delphi 7 IDE beschäftigt. Wie kann ich sehen, welche Daten von Delphi an die DLL übergeben und welche von der DLL zurückkommen?
Kann mir da jemand weiterhelfen (Link auf nen Post aus dem Forum oder so...)

[Beowulf01]

Selbst gefunden...
http://www.delphipraxis.net/41047-tu...ortgeschr.html