' schrieb:Wieso nicht? Genauso habe ich es vor. Die Adresse liefert mir die DLL zurück. Für die 32-Bit Versionen ist die halt 32 Bit lang, für 64 Bit dementsprechend. Aber das könnte man auch hardcodieren. Solange ich weiß wieviele Bytes ich ab der Adresse lesen soll/muss, gebe ich die Anzahl an Bytes und die Adresse an dei Move Funktion und die besorgt mir dann den Inhalt. Sollte (von der Theorie zumindest) ohne Probleme machbar sein. Gibt jetzt (leider) erst mal was anderes zu tun, war gerade so schön dabei...
Das geht zwar im Prinzip so, ist aber ein absoluter Horror. Erstens ist es zigmal mehr Arbeit dann in C eine gescheite Wrapper DLL zu schreiben, die LabVIEW freundlichere Datentypen als Parameter verwendet. Zweitens ist es ein Gefriemel vom sovielsten bis das alles wirklich perfekt stimmt. Drittens ist es qua Unterhaltbarkeit des Programmes schlichtweg ein Alptraum. Nächstes Jahr kommt Vektor villeicht mit Version 6.5 der DLL, mit ein paar "kitzekleinen" Änderungen und Du kannst Dich wieder Stunden- so nicht Tagelang damit rumschlagen um alle Offsets, Bufferlängen und und und wieder korrekt zu bekommen. Mit einer intelligenten WrapperDLL ist das eine Sache von einer Rekompilierung und der C Compiler macht das alles automatisch für Dich.
Zitat:Für dein Tutorial: mach in die DLL ein Struct mit diversen Datentypen, evtl. auch struct im struct (oder noch mit einem union gewürzt) und mach aus den einzelnen Bytes halt wieder die Datentypen, verpack die in einen Cluster und gut ist. Eigentlich simpel (wenn man weiß wie) ;=)
Macht nicht viel Sinn. Die, die C begreifen gehen spätestens hier dazu über um eine Wrapper-DLL zu schreiben und die anderen begreifen es auch mit zig Beispielen nicht, wie man das in LabVIEW ohne potentielle General Protection Fault errors machen kann.
Und hier gehe ich ganz knallhart davon aus dass es besser ist wenn jemand nichts tut, dann etwas das scheinbar funktioniert. Wenn Du die Pointer, Offsets, oder Längen nur ein kleines Bisschen falsch bekommst kann so ziemlich alles passieren von einem unmittelbaren Crash, zu einem Crash irgendwann mal später wenn Du etwas ganz anderes in Deinem Programm tust oder wenn LabVIEW abgeschlossen wird, bis zu korrumpierten VIs die wenn sie auf die Disk zurückgeschrieben werden, nie mehr ladbar sind. Hoffentlich hast Du dann noch ein gutes Backup
Zitat:P.S. kleines Problem habe ich noch bei anderen Stucts: Strings dürfen dort bis zu 200 Zeichen lang sein, aber auch entsprechend kürzer. Dumm nur, wenn man über Array Subset 200 Bytes abschneidet und die dann mit Byte Array to String umwandelt... Aber da sollte man auch die "Nullterminierung" des Strings im Bytearray vorher finden können.
Das mache ich indem ich solche structs sowieso als Bytearray definiere. Eine kleine Helperfunktion bekommt dieses Bytearray, einen Startoffset und liefert dann das Arraysubset vom Startoffset bis zum nächsten NULL Byte zurück. Geht nicht anders und C macht das eigentlich auch so, nur hast Du da stdlib Funktionen die direkt NULL terminated Strings lesen können.
Aber ein grosser Teil der heutigen Bufferoverflow Exploits und so weiter geht ja gerade auf solche impliziten Bufferterminationtechniken zurück. Die Art und Weise wie es LabVIEW tut mit expliziten Bufferlänge vorangestellt erlaubt was das betrifft viel sicheren Code, so man dann diesen Längenparameter auch korrekt behandelt, was auch wieder eine Kunst für sich ist, aber damit musst Du Dich eben nur herumschlagen wenn Du auf C Nivau arbeitest.
Rolf Kalbermatter
/
Vector Informatik: CAN Anbindung mit XL Treiber v6.4 (über DLL)
