Ich bin zur Zeit dabei ein Analog/Digital Karte von Gage zu programmieren. Leider liefert Gage alle Beispiele und Treiber nur für MS Visual C. Ich bin grundsätzlich schon ganz gut vorrangekommen. Aber es scheint Probleme zu geben bei den Datentypen. Ich habe einen Daten record der aus diversen Longword's und Int64's besteht. Scheinbar gibt es da aber Probleme bei der Übergabe zwischen der DLL und meiner Delphi Anwendung.
Ich habe das Gefühl das die Datentypen nicht exakt gleich verarbeitet werden. Kennt sich damit jemand aus?
Gibt es da bekannte Probleme zwischen C und Delphi Integer Datentypen?

Jede Hilfe ist willkommen.

Danke
Sven

Vielleicht gibt es Unterschiede bei der Ausrichtung der Record-Felder. Delphi richtet Felder in Records standardmässig an 8-Byte Grenzen aus - hinter Felder, die kleiner als ein Int64 sind, werden also unbenutzte Leer-Bytes eingefügt. Da kann man abschalten, indem man die Struktur als packed record definiert. Ab Delphi 7 kann man die Ausrichtung auch per Compiler-Option genauer festlegen.Wie das entsprechende Verhalten bei MS Visual C ist, weiss ich leider nicht.

Stefan

Stefan.Buchholtz hat folgendes geschrieben:

Wie das entsprechende Verhalten bei MS Visual C ist, weiss ich leider nicht.

Für C muss man auch packed records nehmen, jedenfalls sofern man vom ANSI-C Standard ausgeht, ob MS da was anderes macht, WEISS ich zwar nicht, kann es mir aber nicht vorstellen.
Deshalb: @Stefan.Buchholtz: Du hast schon recht, das Problem dürfte genau dieses sein, mit packed record statt record sollte alles gehen.

Jedenfalls hat es bei mir so bisher immer funktioniert (wenn ich mich recht entsinne auch bei C-DLLs von MS Visual C++)...

Leider arbeite ich schon mit packed records, hatte ich vergessen zu erwähnen.

Danke schon mal soweit.

Sven

Dann bräuchten wir mal den Record in C-Code und deine Umsetzung in Delphi sowie die Definition der DLL-Methode in C-Code und ebenso die Delphi-Umsetzung.

Vielleicht liegt ja dort ein Fehler...
(Die verschiedenen Integers in Delphi und C sind beispielsweise teilweise nicht gleich groß, vielleicht hast du den falschen Typ genommen...)

Zudem wären weitere Hinweise zur Art des Fehlers gut. Du schreibst nur, dass es da scheinbar Probleme gibt, aber wie äußern sich diese? Gibt es eine Fehlermeldung, passiert nix, oder was?

Hi,

also anbei ein Datei mit meiner Declaration des records sowie dem Auszug der Origianl C Struktur.

Der Fehler äussert sich so, das beim Auslesen dieses Records einige Werte in den Felder vollkommen
unlogisch sind und genauso beim schreiben der Werte einige richtige Werte von der DLL als fehlerhafte Angaben
bemängelt werden.
z.B. Das Feld i64SampleRate sollte beim Auslesen den Wert 200000000 enthalten, hat aber den Wert 858993459200000000
(das sieht für mich so aus als ob da zwei 32 bit werte hintereinader liegen, da die 200000000 drin steckt)

Also ohne den Record anzusehen (das mach ich gleich):
Die Werte lassen vermuten, dass du den Record nicht korrekt initialisiert hast, bevor du ihn an die DLL übergeben hast (beispielsweise mit FillChar).

Und warum sollte die DLL den oberen 32-Bit-Wert beschreiben, wenn dort nur die 0 stehen soll? Deshalb muss vorher alles mit 0 initialisiert sein...
Dass es sich um zwei 32-Bit-Werte handelt, ist ja klar, denn es ist ja ein 32-Bit-Compiler und 32-Bit-Code...

Ich leere jetzt das ganze record vorher mit FillChar und es ist auch alles auf Null vor dem Auslesen, nach dem Auslesen der gleiche Wert wie vorhin beschrieben.

Tja, also der Record scheint korrekt übersetzt zu sein. Da fällt mir auch nix mehr ein.

Das wird jetzt langsam abwegig, aber kann es sein, dass die DLL bei 64-Bit Integern eine andere Reihenfolge der enthaltenen Longwords verwendet? D.h., stimmt es, wenn du bei Int64-Werten immer die oberen und unteren 32 Bits vertauschst? Bei dem Beispiel, das du genannt hast, passt das ja.

Stefan

Abwegig ist das nicht, passt aber nicht zu dem Beispiel, das er genannt hat. (Daran gedacht hatte ich auch schon)
Das nennt sich BigEndian bzw. LittleEndian...

Jedenfalls würde dann aus 858993459200000000 200000000858993459 statt nur 200000000...

jaenicke hat folgendes geschrieben:

Abwegig ist das nicht, passt aber nicht zu dem Beispiel, das er genannt hat. (Daran gedacht hatte ich auch schon) Das nennt sich BigEndian bzw. LittleEndian... Jedenfalls würde dann aus 858993459200000000 200000000858993459 statt nur 200000000...

Doch, das passt. 200000000 ist Hex $000000000BEBC200, 858993459200000000 ist Hex $0BEBC20000000000 - durch Vertauschen der oberen und unteren 32 Bits kommt es hin.

Stefan

Hallo,
die Idee hört sich gar nicht schlecht an, ich werd das mal mit den restlichen Werten durchrechnen und dann einfach mal
in 32 Bit Stücken auslesen und tauschen.

Danke erstmal, ich werds mal versuchen

Hallo Leute,

vielen Dank für die Tipps. Problem gelöst.
Das Problem waren die 'packed records'. Ich hab jetzt einfach normale 'records' draus gemacht und schon läufts.

Danke nochmal für die Hilfe.
Sven