DLL Import externe Struktur in Header bekommen

Hi

Ich vesuche schon einige Zeit eine DLL in LabView zu importieren was mir zu Teil auch schon gelungen ist, einige Dinge konnte ich erfolgreich testen, nur habe ich ein Problem mit einem define (OVERLAPPED) das scheinbar nochmal eine externe Funktion ist.

Ich selbst bin kein bischen C kompatibel darum habe ich von einem Kollegen die Zusammenstellung dieser Unterstruktur bekommen

Code:

namespace System.Threading
{
    // Zusammenfassung:
    //     Stellt ein explizites Layout bereit, das für nicht verwalteten Code sichtbar
    //     ist und dem Layout der OVERLAPPED-Win32-Struktur entspricht, jedoch zusätzliche
    //     reservierte Felder am Ende aufweist.
    [ComVisible(true)]
    public struct NativeOverlapped
    {
        // Zusammenfassung:
        //     Gibt das Handle für ein Ereignis an, das beim Abschluss der Operation auf
        //     den signalisierten Zustand festgelegt wird.Der aufrufende Prozess muss diesen
        //     Member vor dem Aufruf überlappender Funktionen entweder auf 0 oder auf ein
        //     gültiges Ereignishandle festlegen.
        public IntPtr EventHandle;
        //
        // Zusammenfassung:
        //     Gibt die Länge der übertragenen Daten an.Reserviert für die Verwendung durch
        //     das Betriebssystem.
        public IntPtr InternalHigh;
        //
        // Zusammenfassung:
        //     Gibt einen systemabhängigen Status an.Reserviert für die Verwendung durch
        //     das Betriebssystem.
        public IntPtr InternalLow;
        //
        // Zusammenfassung:
        //     Gibt das höherwertige Word des Byteoffsets an, an dem die Übertragung begonnen
        //     werden soll.
        public int OffsetHigh;
        //
        // Zusammenfassung:
        //     Gibt eine Dateiposition an, an der die Übertragung begonnen werden soll.
        public int OffsetLow;
    }
}

Ich habe aber keine Ahnung wie ich das in das .h File bekomme damit mir der DLL Import Assistent mir die DLL korrekt erstellt.
Ich habe in den Anhang ein Bild mit dem Aufbau der DLL angehängt, das Header File habe ich umbenannt mit .txt Erweiterung da hier scheinbar keine .h Dateien im Anhang zugelassen sind.
Hat evtl. jemand eine Ahnung wie ich dieses OVERLAPPED in das Header bekomme um die DLL korrekt importieren zu können?

Anzeige

(03.09.2016 08:56 )hansi9990 schrieb:  Hi

Ich vesuche schon einige Zeit eine DLL in LabView zu importieren was mir zu Teil auch schon gelungen ist, einige Dinge konnte ich erfolgreich testen, nur habe ich ein Problem mit einem define (OVERLAPPED) das scheinbar nochmal eine externe Funktion ist.

Ich habe aber keine Ahnung wie ich das in das .h File bekomme damit mir der DLL Import Assistent mir die DLL korrekt erstellt.
Ich habe in den Anhang ein Bild mit dem Aufbau der DLL angehängt, das Header File habe ich umbenannt mit .txt Erweiterung da hier scheinbar keine .h Dateien im Anhang zugelassen sind.
Hat evtl. jemand eine Ahnung wie ich dieses OVERLAPPED in das Header bekomme um die DLL korrekt importieren zu können?

OVERLAPPED ist keine externe Funktion sondern ein struct von den Windows low level Systemtreibern wenn diese asynchon aufgerufen werden. Aber dieses API ist definitive etwas obskur in dieser Hinsicht.

Die Windows Deklaration sieht als folgt aus:

Code:

typedef struct _OVERLAPPED {
  ULONG_PTR Internal;
  ULONG_PTR InternalHigh;
  union {
    struct {
      DWORD Offset;
      DWORD OffsetHigh;
    };
    PVOID  Pointer;
  };
  HANDLE    hEvent;
} OVERLAPPED, *LPOVERLAPPED;

Ich gehe mal davon aus dass Du auf die Elemente sowohl in der struct strHidDevice als auch in diesen OVERLAPPED überhaupt nicht direkt zugreifen musst. Dann könnte man es einfach als ein Pointersized Integer behandeln.

Und selbst wenn Du diese struct in den Header mit aufnimmst kann der DLL Import Wizard NICHT den korrekten Code erzeugen da es ziemlich undeutlich ist wer den Speicher für diese OVERLAPPED Strukturen anlegen soll. Zudem enthält diese Struktur HANDLES und eben diese Pointers zu OVERLAPPED und das bewirkt, dass die entsprechenden Strukturen qua Memorylayout völlig verschieden werden, je nachdem ob man dies für 32 bit oder 64 bit versucht zu machen.

Am einfachsten wäre halt einfach um eine weitere DLL in C zu machen die diese Struktur anlegt und korrekt initialisiert und dann einfach den Zeiger darauf als Pointersized Integer zurückgibt und Du diesen dann auch entsprechend an jede Funktion übergibts. Eine zweite Funktion in dieser Hilfs-DLL gibt den Speicher für diese Struktur wieder frei. Dummerweise hätte der ursprüngliche DLL Programmierer genau das so machen können indem die HANDLE HID_Init() Funktion genau diesen Pointer einfach als HANDLE oder void* zurückgeben könnte und alle Funktionen würden dann auch ein HANDLE oder void* als ersten Parameter erhalten. Daneben hätte noch eine weitere Funktion exportiert werden müssen wie HID_Free(HANDLE hid) oder so die den entsprechenden Speicher wieder dealloziert. Das wäre korrekte Programmierung gewesen.

Das alles in LabVIEW selber zu machen versuchen wird sehr viel Handarbeit erfordern (der Import Wizard kann das nicht) und Zeigerarithmetik und 32 bit/64 bit Gegrumschel in einem LabVIEW Diagram ist hässlich, kaum zu warten auf längere Dauer da nur extrem wenig Leute so was auf LabVIEW Niveau überhaupt machen können und ein C Programmierer der dies begreifen könnte meist keinerlei Kenntnisse auf LabVIEW Gebiet hat und Dir oder wer es dann auch eventuel modifizieren oder debuggen muss, nicht helfen kann und will.

(06.09.2016 22:21 )rolfk schrieb:  

(03.09.2016 08:56 )hansi9990 schrieb:  Hi

Ich vesuche schon einige Zeit eine DLL in LabView zu importieren was mir zu Teil auch schon gelungen ist, einige Dinge konnte ich erfolgreich testen, nur habe ich ein Problem mit einem define (OVERLAPPED) das scheinbar nochmal eine externe Funktion ist.

Ich habe aber keine Ahnung wie ich das in das .h File bekomme damit mir der DLL Import Assistent mir die DLL korrekt erstellt.
Ich habe in den Anhang ein Bild mit dem Aufbau der DLL angehängt, das Header File habe ich umbenannt mit .txt Erweiterung da hier scheinbar keine .h Dateien im Anhang zugelassen sind.
Hat evtl. jemand eine Ahnung wie ich dieses OVERLAPPED in das Header bekomme um die DLL korrekt importieren zu können?

OVERLAPPED ist keine externe Funktion sondern ein struct von den Windows low level Systemtreibern wenn diese asynchon aufgerufen werden. Aber dieses API ist definitive etwas obskur in dieser Hinsicht.

Die Windows Deklaration sieht als folgt aus:

Code:

typedef struct _OVERLAPPED {
  ULONG_PTR Internal;
  ULONG_PTR InternalHigh;
  union {
    struct {
      DWORD Offset;
      DWORD OffsetHigh;
    };
    PVOID  Pointer;
  };
  HANDLE    hEvent;
} OVERLAPPED, *LPOVERLAPPED;

Ich gehe mal davon aus dass Du auf die Elemente sowohl in der struct strHidDevice als auch in diesen OVERLAPPED überhaupt nicht direkt zugreifen musst. Dann könnte man es einfach als ein Pointersized Integer behandeln.

Und selbst wenn Du diese struct in den Header mit aufnimmst kann der DLL Import Wizard NICHT den korrekten Code erzeugen da es ziemlich undeutlich ist wer den Speicher für diese OVERLAPPED Strukturen anlegen soll. Zudem enthält diese Struktur HANDLES und eben diese Pointers zu OVERLAPPED und das bewirkt, dass die entsprechenden Strukturen qua Memorylayout völlig verschieden werden, je nachdem ob man dies für 32 bit oder 64 bit versucht zu machen.

Am einfachsten wäre halt einfach um eine weitere DLL in C zu machen die diese Struktur anlegt und korrekt initialisiert und dann einfach den Zeiger darauf als Pointersized Integer zurückgibt und Du diesen dann auch entsprechend an jede Funktion übergibts. Eine zweite Funktion in dieser Hilfs-DLL gibt den Speicher für diese Struktur wieder frei. Dummerweise hätte der ursprüngliche DLL Programmierer genau das so machen können indem die HANDLE HID_Init() Funktion genau diesen Pointer einfach als HANDLE oder void* zurückgeben könnte und alle Funktionen würden dann auch ein HANDLE oder void* als ersten Parameter erhalten. Daneben hätte noch eine weitere Funktion exportiert werden müssen wie HID_Free(HANDLE hid) oder so die den entsprechenden Speicher wieder dealloziert. Das wäre korrekte Programmierung gewesen.

Das alles in LabVIEW selber zu machen versuchen wird sehr viel Handarbeit erfordern (der Import Wizard kann das nicht) und Zeigerarithmetik und 32 bit/64 bit Gegrumschel in einem LabVIEW Diagram ist hässlich, kaum zu warten auf längere Dauer da nur extrem wenig Leute so was auf LabVIEW Niveau überhaupt machen können und ein C Programmierer der dies begreifen könnte meist keinerlei Kenntnisse auf LabVIEW Gebiet hat und Dir oder wer es dann auch eventuel modifizieren oder debuggen muss, nicht helfen kann und will.

Mit Labview muss ich nicht direkt auf das strHidDevice zugreifen, das wird nur zwischen den einizelnen vi's durchgereicht, beim Import der .dll wurde dies als Cluster angelegt, als Typ wurde im Knoten ein "An Typ anpassen" angelegt der so wie im Bild aussieht.

Meinst du das ich einfach den ganzen struct strHidDevice als Pointersized Integer deklarieren, so wie in Bild strHidDevice.jpg?

(07.09.2016 23:11 )hansi9990 schrieb:  Meinst du das ich einfach den ganzen struct strHidDevice als Pointersized Integer deklarieren, so wie in Bild strHidDevice.jpg?

Nein, nicht ganz so! Nicht vorzeichebehafteter 64-bit Integer sondern vorzeichenbehafteter pointersized (oder was das auf Deutsch heissen mag) Integer. Und nicht als Zeiger auf Wert sondern direkt.

Und vergiss es um diese Struktur als LabVIEW Cluster erstellen zu wollen, da ist ein 8192 byte grosser Buffer drin, so dass die ganze Struktur mindestens etwas 9000 Byte gross wird. Das würde einen Megaprontosaurus-Cluster geben.

Stattdessen musst Du diese Struktur erst im Speicher anlegen, etwa durch aufrufen der LabVIEW Managerfunktion void* DSNewPClr(int32_t size) mittels einer weiteren Call Library Node. Als size gibst Du dort eine Zahl die gross genug ist. Um auch Für 64-Bit korrekt zu funktionieren müsste das 8192 + 96 Bytes sein. Den Zeiger den Du davon zurückbekommst, verwendest Du dann bei allen anderen Funktionen als strHidDevice* Parameter. Nicht vergessen zuerst die Funktion HID_Init() darauf auszuführen. Und am Ende wenn Du diesen Speicher nicht mehr benötigst, ganz nett aufräumen durch Aufruf von DSDisposePtr(void *ptr).

Wenn Dir die LabVIEW Manager Funktionen suspekt erscheinen, kannst Du stattdessen auch die Windows API Funktionen void* CoTaskMemAlloc(SIZE_T size) und CoTaskMemFree((void* ptr), beide in Ole32.dll.

SIZE_T ist ein Datentyp der ein 32-Bit unsigned integer unter 32 bit ist, und ein 64-Bit unsigned Integer in 64-Bit. In LabVIEW musst Du das als Vorzeichenloser Pointersized Integer konfigurieren, und als Wert, nicht als Zeiger auf Wert.

Sorry aber ich verstehe nicht besonders viel von dem was du mir erklärst, zum einen weiß ich nicht wo und wie ich eine LabVIEW Managerfunktion erstelle und so ganz verstehe ich auch die zweite Alternative mit der ole32.dll.
Könntest du mir evtl. ein paar Bilder zeigen damit ich es verstehe?
Ich habe es selbst schon versucht (siehe Anhang) bin mir aber nicht sicher ob das so richtig ist, aber ich denke nicht denn es funktioniert auch nicht.

                   

(15.09.2016 19:23 )hansi9990 schrieb:  Sorry aber ich verstehe nicht besonders viel von dem was du mir erklärst, zum einen weiß ich nicht wo und wie ich eine LabVIEW Managerfunktion erstelle und so ganz verstehe ich auch die zweite Alternative mit der ole32.dll.
Könntest du mir evtl. ein paar Bilder zeigen damit ich es verstehe?
Ich habe es selbst schon versucht (siehe Anhang) bin mir aber nicht sicher ob das so richtig ist, aber ich denke nicht denn es funktioniert auch nicht.

Das ist alles nicht ganz richtig:

1) CoTaskMemAlloc() hat als Parameter einen Unsigned Pointersized Integer, als Wert übergeben wo man als Eingangswert angibt wie gross der Speicherbereich sein soll der angelegt werden soll. Die Funktion hat als Rückgabewert einen Pointersized Integer der den Pointer darstellt. In LabVIEW wird das als 64 Bit Integer gehandhabt aber an der Call Library Node wird das korrekt nach 32 Bit oder 64 Bit konvertiert je nach dem welche LabVIEW Version Du verwendest.

2) CoTaskMemFree() funktioniert so wie Du es im Moment anlegst zwar für 32 Bit LabVIEW vielleicht, ist aber eigentlich auch falsch. Hier solltest Du den Paremeter ebenfalls als Pointersized Integer, als Wert übergeben konfigurieren, genauso wie den Rückgabewert der vorigen Funktion.

3) Und wenn Du schon dabei bist, mache alle Controls für diesen struct Pointer in Deinen VIs einen 64 Bit Integer und konfiguriere die entsprechenden Call Library Node Parameter ebenfalls als Pointersized Integer, als Wert übergeben.

Grundsätzlich liesse sich aber sagen, dass dieses Problem Dir eindeutig über den Kopf wächst, und Du solche Dinge durch einen Experten machen lassen solltest. Denn auch wenn es nicht mehr crasht, ist das noch lange keine Garantie, dass es gut ist, und mit Deinen Kenntnissen hast Du keinerlei Möglichkeiten zu überprüfen ob es dann wirklich richtig ist. Bei sowas vertrete ich die Meinung, dass gar keine Software besser ist, dann eine von der man nicht weiss ob sie richtig ist. Und bei Pointern und dergleichen ist es halt so, dass auch wenn es nicht mehr kracht und Blue Screen of Death und Speicherverletzungsausnahmedialoge auftauchen, die ganze Sache noch immer schrecklich falsch sein kann.

Hi Rolf

Trotz meiner eingeschränkten Kenntnisse habe ich es dennoch hin bekommen das HID Device anzusprechen und auch Daten zu senden und zu empfangen.
Ich habe mir jetzt noch zwei vi's erstellt (HID Init pstrHidDevice und HID Free pstrHidDevice) mit dem ich via ole32.dll das pastrHidDevice struckt ersetze.
Ebenso habe ich dienen Rat befolgt und alle Controls geändert.
Einige Dinge hatte nicht verstanden da in LabView die Deutsche Übersetzung etwas anders ist und auch die Darstellung etwas anders ist.
Gestatte mir nur noch eine Frage, aus einer vorherige ANtwort von dir habe ich entnommen das der SIZE_T Wert 8192 + 96 Bytes sein sein sollte um auch für 64-Bit korrekt zu funktionieren, habe ich das so richtig verstanden und üwrde es dann genügen an den SIZE_T eine Konstand mit dem Wert 8288 anzulegen?

Herzlichen Dank für deine Gedult und Unterstützung.

(21.09.2016 08:38 )hansi9990 schrieb:  Gestatte mir nur noch eine Frage, aus einer vorherige ANtwort von dir habe ich entnommen das der SIZE_T Wert 8192 + 96 Bytes sein sein sollte um auch für 64-Bit korrekt zu funktionieren, habe ich das so richtig verstanden und würde es dann genügen an den SIZE_T eine Konstand mit dem Wert 8288 anzulegen?

Ja, für die 32 Bit Version benötigst Du zwar eigentlich ein paar Bytes weniger, aber das ist kein Problem. Ob man da jetzt 16 oder so Bytes verschwendet bei einer so grossen Struktur macht wirklich nichts aus. Wichtig ist dass der Speicherbereich gross genug ist für alle möglichen Fälle und das ist hier, wenn Du je nach 64 Bit LabVIEW wechselt dieser Fall, da dann alle HANDLEs und Pointer in der Struktur 64 Bit statt 32 Bit belegen.

Aber ich habe noch mal nachgeschaut. Wegen alignment und so müsste das effektiv 8192 + 104 Bytes sein.

Hi Rolf

Vielen Dank für die Informationen.
Soweit läuft alles prima, allerdings habe ich unter Windows7 manchmal einen Crash des LabView Developer Environment, unter Windows 10 hatte ich das bisher nicht.
Entweder ist es Zufall, da ich manchmal die Umgebung mit dem roten Knopf stoppe und der angelegte Speicher nicht aufgeräumt wird, oder es liegt am System, oder an der ole32.dll die sich evtl. zwischen Windows 7 und 10 unterscheidet.

(22.09.2016 22:06 )hansi9990 schrieb:  Hi Rolf

Vielen Dank für die Informationen.
Soweit läuft alles prima, allerdings habe ich unter Windows7 manchmal einen Crash des LabView Developer Environment, unter Windows 10 hatte ich das bisher nicht.
Entweder ist es Zufall, da ich manchmal die Umgebung mit dem roten Knopf stoppe und der angelegte Speicher nicht aufgeräumt wird, oder es liegt am System, oder an der ole32.dll die sich evtl. zwischen Windows 7 und 10 unterscheidet.

Computer und Zufall ist etwa das gleiche wie eine Jungfrau und schwanger. Es kommt nur im Märchen vor! Dummer Zufall ist, dass es unter Windows 10 SCHEINBAR funktioniert. Das tut es aber auch nicht wirklich, nur siehst Du den Fehler JETZT noch nicht. Irgendwann, am wahrscheinlichsten wenn Dein Chef hinter Dir steht und Du das Programm vorführst oder etwas anderes Katastrophales anliegt, macht es vielleicht auch unter Windows 10 mal Bumms.

Deshalb, DEBUGGEN und noch mal DEBUGGEN. Alles noch einmal und noch einmal kontrollieren! Und hier kommt nun das was ich schon eher sagte. Da Du eigentlich nicht ganz weisst, was Du hier genau getan hast ist das mit dem Kontrollieren so eine Sache.

Auch wenn die ole32.dll garantiert verschieden ist zwischen Windows 7 und Windows 10, ist das API das Du hier hoffentlich korrekt anrufst, offiziel dokumentiert und deshalb völlig unveränderlich. Sofern die Funktion korrekt aufgerufen wird, kann die nicht auf dem einen System einen Crash machen und auf dem anderen nicht. Das würde die Idee eines offiziellen APIs völlig ad absurdum führen.

Du hast die Bemerkung, dass der Speicherbereich halt schon mindestens 8192 + 104 Bytes sein sollte aber beachtet, oder?