64Bit DLL mit Wizard importieren

Hallo @ all,

ich habe eine DLL und das dazugehörige H-File. Mit Hilfe des DLL-Import-Wizards habe ich bis jetzt immer die DLL importiert. Dies jedoch nur unter Windwos XP (32Bit)

Jetzt benutze ich ein 64Bit Windows 7 Betriebssystem und Labview 2010 64Bit. Zudem will ich jetzt eine 64Bit DLL importieren. Hierzu verwende ich wieder den Wizard. Dann wähle ich erneut meine DLL und mein H-File und erstelle eine Bibliothek. Bis jetzt habe ich keinen Präprozessorbefehl verwendet. Das erstellen der Bibliothek erfolgte ohne Fehler. Wenn ich jedoch die Funktionen verwenden möchte erzeugte diese einen Fehlercode (ungültiges Argument).

Mir ist aufgefallen das die Datentypen immer noch 32Bit sind. Wenn ich die Datentypen durch 64Bit Datentypen manuell austausche dann bekomme ich keine Fehlermeldung mehr.

Demnach muss ich dem Wizard mitteilen das es sich um ein 64Bit Betriebssystem handelt nur weis ich leider nicht den passenden Präprozessorbefehl.


Ich poste am besten mal eine Funktion aus der DLL:


extern cudaError_t cudaMalloc(void **devPtr, size_t size);

extern cudaError_t cudaMemcpy(void *dst, const void *src, size_t count, enum cudaMemcpyKind kind);


So viel habe ich bis jetzt in Erfahrung gebracht: Der Datentype size_t ist ein Systemspeziffiser Datentype. Jetzt ust halt die Frage wenn ich ein 64Bit Betriebssystem habe ist der Datentype auch 64Bit groß

und was ist mit void ** devPtr ????

---

Ich habe mal die stddef.h Datei geöffnet. Dort ist der Typedef definiert. Ich habe eine Labview 2009 32 Bit Version installiert und eine Labview 2010 64Bit Version. Jedoch finde ich im Labview 2010 verzeichnis keine stddef.h Datei sondern nur im Labview 2009 Ordner

In diesem Verzeichnis habe ich die stddef.h gefunden

C:\Program Files (x86)\National Instruments\Shared\LVDB\include\ansi


Und dies steht in der Datei drin:

#ifndef _SIZE_T_DEFINED
#define _SIZE_T_DEFINED
#ifdef _NI_mswin64_
typedef unsigned __int64 size_t;
#else
typedef unsigned int size_t;
#endif
#endif

Also muss ich den Compilerschalter _NI_mswin64_ setzen?

Warum gibt es keine stddef.h mehr unter Labview 2010?

Anzeige

Ich denke mal dass Du auf dem Holzweg bist. Das LVDB.exe Utility ist der LabVIEW DLL Builder. Das ist zuständig um eine DLL aus LabVIEW VIs zu bauen und ist im wesentlichen eine reduzierte LabWindwos CVI Umgebung. Der Umstand dass es in der Program Files (x86) Directory liegt gibt auch an dass es sich um die 32 Bit Variante handelt. Dass es immer noch dasselbe Utility ist in LabVIEW 2010 ist ganz einfach darum weil es scheinbar keine neue Version braucht.

Der Library Import Wizard braucht meines Wissens keine externen C Compiler sondern ist ganz in LabVIEW implementiert. Zudem werden keinerlei Header mitgeliefert, die müssen schon von Deinem System geliefert werden. Ob der Import Library Wizard voll 64 Bit kompatibel ist wirst Du bei NI Support nachfragen müssen. Grundsätzlich sollte das keine Issue sein aber Deine DLL mit Pointerreferenzen stellt sowieso eine Knacknuss dar für dieses Tool. Auch wenn es nicht crasht ist noch abzuwarten ob es wirklich gut funktioniert. Wenn Du denn Inhalt der Pointer im LabVIEW Diagram nicht ansprechen musst, kannst Du diese Referenzen in der Tat als Integer konfigurieren, aber dann würde ich Pointer sized Integer verwenden anstelle eines expliziten 32 oder 64 Bit Integers.

Labview kenn den Typedef size_t nicht. Daher kann Labview auch keinen Datentype zuordnen. Erst wenn ich die stdlib.h und einbinde (diese lädt dann wieder die stddef.h) Dort ist der Typedef angegeben.

Wenn ich den Compilerschalter _NI_mswin64_ setze dann ist die Fehlermeldung weg und ich kann die importierte funktion nutzen.

Es funktioniert leider immer noch nicht. Der Import Wizard erzeugt da 32Bit Datentypen (long). Jedoch werden Quads (64Bit) benötigt. Es ist egal ob ich den Compilerschalter setze oder nicht.

Wie kann ich denn eine 64Bit DLL mit Hilfe des Import-Wizards in Labview 64 importieren?

Mit Quads gab es auch hier Probleme:
http://www.labviewforum.de/Thread-DLL-C-...w-schicken

Wenn es gar nicht anders geht, dann musst du jede Funktion von Hand editieren und die Übergabeparameter selber anpassen.

Gruß, Jens

(25.08.2011 14:10 )pimbolie1979 schrieb:  Es funktioniert leider immer noch nicht. Der Import Wizard erzeugt da 32Bit Datentypen (long). Jedoch werden Quads (64Bit) benötigt. Es ist egal ob ich den Compilerschalter setze oder nicht.

Wie kann ich denn eine 64Bit DLL mit Hilfe des Import-Wizards in Labview 64 importieren?

Hallo zusammen,


kleine Workaround-Lösung für alle: Im Header-File der zu importierenden DLL alle VOID* durch einen sonst ungenutzten Typen wie z.B. INT8 ersetzen und die DLL dann wie gewohnt importieren. Danach dann angefügtes kleines Scripting-VI über das Verzeichnis laufen lassen.

Das VI schnappt sich jedes VI aus dem gewählten Ordner, sucht darin alle numerischen Controls/Indicators deren Datentyp I8 ist und ändert ihn in U64 um, bevor das VI dann unter dem gleichen Namen wieder abgespeichert wird.

Viel Spaß damit,
Sebastian

Anzeige

(25.08.2011 16:42 )sfk010477 schrieb:  

(25.08.2011 14:10 )pimbolie1979 schrieb:  Es funktioniert leider immer noch nicht. Der Import Wizard erzeugt da 32Bit Datentypen (long). Jedoch werden Quads (64Bit) benötigt. Es ist egal ob ich den Compilerschalter setze oder nicht.

Wie kann ich denn eine 64Bit DLL mit Hilfe des Import-Wizards in Labview 64 importieren?

Hallo zusammen,


kleine Workaround-Lösung für alle: Im Header-File der zu importierenden DLL alle VOID* durch einen sonst ungenutzten Typen wie z.B. INT8 ersetzen und die DLL dann wie gewohnt importieren. Danach dann angefügtes kleines Scripting-VI über das Verzeichnis laufen lassen.

Das VI schnappt sich jedes VI aus dem gewählten Ordner, sucht darin alle numerischen Controls/Indicators deren Datentyp I8 ist und ändert ihn in U64 um, bevor das VI dann unter dem gleichen Namen wieder abgespeichert wird.

Viel Spaß damit,
Sebastian

Wenn Du schon die Header Datei anpasst warum nicht gleich ein int64 davon machen und diesen als long long am Anfang deklarieren? Würde das Scripting Tool sparen.