DLL Import externe Struktur in Header bekommen

Willst du etwa am Christlichen Glauben zweifeln?
Scherz beiseite, ich meinte damit das ich evtl. gerade an einer Stelle den Ausführung abgebrochen hätte wo der Speicher angelegt aber nicht mehr aufgeräumt wurde und mir das dann "zufällig" immer nur unter Windows 7 passiert ist, und nicht das der PC eigenständig und zufällig reagierte.
Aber das waren ja alles nur vermutungen.

Ich habe diese VI's unter Windows 10 schon seit mehreren Tagen ohne Crash am laufen, ausgenommen bei einem mal, an dem ich versehentlich einen Speicherbereich von 0 einstellte, darum kam mir auch der Gedanke das es etwas mit der Größe des Speicherbrereichs zu tun haben muss. Heute hatte cih auch unter Windows 7 keinen einzigen Crash.

Seit ich dort das Bedienelement gegen eine Konstante austauschte, hatte ich diese Abstürze nicht mehr, zuhause hatte ich das Bedienelemet von 8288 auf 8296Byte erhöht und vergessen diesen Wert als Standard festzulegen, als ich das VI am Windows 7 PC in der Firma startete, stand wieder 8288Byte im Bedienelement.
Ich vermute das dies der Grund für die Abstürze war, die auch nur selten auftraten und der Hinweis von dir war somit wohl auch genau richtig.
Mit einer Konstante kann dieser Fehler nicht mehr passieren.

Nochmal vielen Dank für deine Hilfe

PS: Ich hatte Probleme mit dem lesen des Buffer im HID Device, der Knoten wartete/hängte immer bis sich im Buffer etwas änderte (ergo, erst wenn ein Gerät etwas sendete, wenn mein Empfänger keine Packete erhielt dann hing es beim Read Buffer). Jetzt habe ich mal versucht den Speicherbereich mit den LabView Manager Funktionen (DSNewPClr und DSDisposePtr) anzulegen und siehe da es hängt nicht mehr und liest sauber den Buffer des HID Device.

(27.09.2016 19:29 )hansi9990 schrieb:  PS: Ich hatte Probleme mit dem lesen des Buffer im HID Device, der Knoten wartete/hängte immer bis sich im Buffer etwas änderte (ergo, erst wenn ein Gerät etwas sendete, wenn mein Empfänger keine Packete erhielt dann hing es beim Read Buffer). Jetzt habe ich mal versucht den Speicherbereich mit den LabView Manager Funktionen (DSNewPClr und DSDisposePtr) anzulegen und siehe da es hängt nicht mehr und liest sauber den Buffer des HID Device.

Tja, meine Vermutung hat mit them Clr in DSNewPClr() zu tun. Diese Funktion alloziert then Speicher und initialisiert ihn komplett mit 0 (Clr = Clear). Die CoTaskMemAlloc() Funktion löscht den Speicher nicht, also hat er irgendwelche Randomwerte. Nun hätte ich so gedacht, dass die Funktion HID_Init() ja irgendetwas sinnvolles tun sollte, wenn sie schon nicht den Speicherbereich selber anlegt (Du rufst die doch auf so wie es im Headerfile auch steht?)

Aber scheinbar war auch das eine vergebliche Hoffnung!

Ja, ich habe die beiden Knoten ole32.dll CoTaskMemAlloc() und SebaHID.dll HID_Init() in einem VI zusammengefasst, im Header war der Init so definiert

Code:

/**
\fn      VOID HID_Init(struct strHidDevice* pstrHidDevice);

\brief   Init structure with default values.
         - It is important to call HID_Init before calling HID_Open\n
           to avoid unpredicted behavoir

\param   pstrHidDevice: Structure which contains important data of an HID device

*/
SEBAHID_API INT HID_Init(struct strHidDevice* pstrHidDevice);

natürlich habe ich das struct durch ein int Pointersized ersetzt.
Seltsam ist auch das der Return Wert des Init Knoten exakt dem Wert entspricht der auch vom ole32.dll CoTaskMemAlloc() angelegt wird, ich hätte hier einen Fehlercode, der auch im Header definiert ist erwartet. Scheinbar ist mit dem Init etwas nicht ok.

Code:

/// HID Device return codes
/// HID read buffer contains old data
/// former Read buffer was too small
#define HID_DEVICE_RBUFF_OLD_DATA        1
/// HID action/transfer was successful
#define HID_DEVICE_SUCCESS                0
/// HID device was not found
#define HID_DEVICE_NOT_FOUND            -1
/// HID device is not opened
#define HID_DEVICE_NOT_OPENED            -2
/// HID device is allready opened
#define HID_DEVICE_ALREADY_OPENED        -3
/// Timeout occurs during transfer
#define HID_DEVICE_TRANSFER_TIMEOUT        -4
/// HID transfer failed
#define HID_DEVICE_TRANSFER_FAILED        -5
/// HID transfer report lost
#define HID_DEVICE_REPORT_LOST            -6
/// HID Read buffer overflow
#define HID_DEVICE_RBUFF_OVERFLOW        -7
/// HID Write buffer overflow (could not handle so much data with this protocol)
#define HID_DEVICE_TBUFF_OVERFLOW       -8
/// Invalid handle
#define HID_DEVICE_HANDLE_ERROR            -9
/// Unknown error
#define HID_DEVICE_UNKNOWN_ERROR        -100

Lib ist angehängt.

(28.09.2016 19:51 )hansi9990 schrieb:  Ja, ich habe die beiden Knoten ole32.dll CoTaskMemAlloc() und SebaHID.dll HID_Init() in einem VI zusammengefasst, im Header war der Init so definiert

[code] /**
\fn VOID HID_Init(struct strHidDevice* pstrHidDevice);

Siehst Du das VOID vor der Funktion? Das ist ein Microsoft alias für void und bedeutet, dass diese Funktion GAR NICHTS zurückgibt.

C ist tückisch: void alleine ist nichts, void* ist ein Pointer auf eine Speicherstelle ohne Typedefinition. Das heisst für einen C Compiler ist void* mit allen anderen Pointern kompatibel ohne dass man Typecasts machen muss. Ein nicht void* Pointer ist mit keinem anderen nicht void* Pointer kompatibel, und erfordert einen expliziten Cast um doch zugewiesen werden zu können.

Wenn vor der Funktion LPVOID oder PVOID stehen würde, hiesse das dass die Funktion einen void Pointer zurückgibt. Da die Funktion deklariert ist ohne Rückgabewert, setzt sie das EAX Register nicht explizit. Das heisst wenn Du LabVIEW sagst dass die Funktion etwas zurückgibt, dann liest LabVIEW halt das EAX Register das dann halt mit irgendeinem Wert beschrieben ist, hier scheinbar mit dem Pointer den Du als Parameter übergeben hast da die Funktion diesen scheinbar ins AEX Register kopiert um damit zu arbeiten. Nur kann eine Recompilation der DLL dies durchaus veränderen, entweder durch Änderungen im C Code selber, so dass der Compiler diesen Zeiger in ein anderes Register kopiert da das plötzlich effizienter ist mit Berücksichtigung von Cache, Multithreading und CPU Technologie und ein paar Dutzend andere Low-Level Details von denen Du nie im Leben etwas hören willst. Oder der DLL Bauer verwendet schlicht und einfach einen anderen Compiler oder Compilerversion, die andere Ideen hat wie der Code für optimale Performance erzeugt werden soll. Nur wenn die Funktion auch explizit deklariert und implementiert ist um einen Wert zurückzugeben kannst Du auch erwarten dass dort etwas sinnvolles zurückkommt.

Ich denke dass die Funktion im Prinzip schon etwas richtiges tut, nur scheinbar initialisiert sie nicht den ganzen Speicherbereich sondern nur ein paar Elemente die dem Entwickler wichtig erschienen. Schade dass er dabei vergessen hatte um auch gleich die OVERLAPPED Strukturen mitzuinitialisieren, wenn er denn schon von so einem Feature wie OVERLAPPED Gebrauch machen will.

Hi Rolf

Ich habe dazu auch einen Kollegen befragt der diese dll etwas kennt (bevor ich deinen Beitrag hier gelesen habe) und er hat mir im Prinzip das gleiche gesagt wie du, kein Return.
Wenn ich es weiß dann ist das auch ok denn ich benötige da keinen Rückgabewert.
Das Init soll im Prinzip den pstrHidDevice Bereich initialisieren, macht das aber scheinbar nicht vollständig. Benötigt wird das Init aber auf jeden Fall den ohne geht auch mit der LabView Manager Funktion nichts.
Für mich ist das jetzt nicht wirklich ein Problem und mir ist es auch lieber wenn ich dazu nicht extra die ole32.dll einbinden muss.
Fakt ist, das bisher alles Fehlerfrei läuft und ich keinen Crash mehr hatte (den ich nicht selbst verschuldete )

Vielen lieben Dank nochmal, es hat mich zwar nicht zu einem Experten für den dll Import gemacht, aber dank deiner freundlichen Unterstützung habe ich in diesen Beitrag wieder sehr viel dazugelernt.