Neues Thema starten
Beantwortet

Export von TAR-Dateien über die StdCall-DLL

Wir versuchen aktuell den TAR-Export mit der StdCall-DLL umzusetzen.

Leider scheitern wir noch daran. 


 Den DLL-Funktionsaufruf haben wir so deklariert: 

TWorm_export_tar = function(context: Pointer; callback: Pointer; callbackData: PAnsiString): Integer; stdcall;

 Die Callback-Funktion so:

 

TWormExportTarCallBack = function(const chunk: Pointer; const chunkLength: NativeUInt; const callBackData: PAnsiString): Integer; stdcall;

Der Aufruf der Export-Funktion erfolgt so: 

 

 worm_export_tar(context, @exportTarCallback, @callBackData)

 

Die Callback-Funktion wird auch aufgerufen, allerdings ist "chunkLength" immer 0 und als Chunk kriegen wir folgende Werte:

info.csv

Unixt_1573748718_Sig-1398_Log-Tra_No-14_Start_Client-15683-0001-0001-0001.log

Unixt_1573827489_Sig-1462_Log-Sys_LogOut.log


Hat jemand eine Idee woran das liegen kann bzw. was wir falsch machen?


Beste Antwort

Habe heute eine Rückmeldung erhalten, der Fehler konnte nachgestellt werden und ist in der nächsten SDK-Version behoben :)


Antwort

Habe heute eine Rückmeldung erhalten, der Fehler konnte nachgestellt werden und ist in der nächsten SDK-Version behoben :)


2 Personen gefällt dies

@Henrik

Alleine macht es ja auch keinen Spaß  ;)


@Maximilian


 Bei der 32bit-cdecl-dll:

- worm_export_tar schafft er es sogar noch 2x das callback aufzurufen und es werden 128 KB geschrieben, danach folgt eine AccessViolation

- bei den beiden filtered sieht es ca. so aus: das callback wird 5x aufgerufen mit zunächst chunkLength = 0 danach 4x chunkLength=501, dann folgt die AccessViolation. Das tar-file ist zwar nicht wirklich abgeschlossen, lässt sich aber öffnen und beinhaltet die info.csv + X509.pem.


Springe ich im Debugger über die AccessViolation drüber bekomme ich im Wiederholungsfall 0x1016 als Fehlercode (habe noch keine Definition davon gefunden).


Alle anderen Funktionen machen bei allen 3 dlls keine Probleme - zumindest jene die ich getestet habe (Start, Update Finish; Cert, Seriennummern,  Signatur, sonst. Transaktionsdaten holen).


Dies sind meine DLLImports:

        [DllImport("WormAPI.dll", CallingConvention = CallingConvention.Cdecl,  CharSet = CharSet.Ansi)]
        public static extern WormError worm_export_tar(IntPtr context, WormExportTarCallback callback, IntPtr callbackData);

        [DllImport("WormAPI.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
        public static extern WormError worm_export_tar_filtered_time(IntPtr context, ulong startDate, ulong endDate, string clientId, WormExportTarCallback callback, IntPtr callbackData);

        [DllImport("WormAPI.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
        public static extern WormError worm_export_tar_filtered_transaction(IntPtr context, ulong startTransaction, ulong endTransaction, string clientId, WormExportTarCallback callback, IntPtr callbackData);

        public delegate int WormExportTarCallback(IntPtr chunk, int chunkLength, IntPtr callBackData);

 

Gruß,

Jan


1 Person gefällt dies

Bezüglich des Problem mit dem gefilterten Export in der stdcall Variante habe ich folgende Antwort von SwissBit bekommen:


"in der stdcall Variante sind alle in der C-Bibliothek als worm_uint deklarierten Typen 32bit, in der cdecl Variante 64bit.

Daher müssen Sie für die stdcall Varianten in Ihren Imports die kleineren Integer Typen verwenden. Dies betrifft übrigens nicht nur die Exportfunktionen, sondern alle Funktionen."


Kann damit das Problem gelöst werden?

Hallo Leute!


Meine bisherigen erfahrungen zum Export mit 5.2.3 belaufen sich auf folgendes (Implementierungskit 2):


x64-dll:

Nachdem mir aufgefallen ist, dass der maxRecords Parameter gegenüber früheren  Versionen in den beiden filtered-Funktionen verschwunden ist klappen alle drei wunderbar.


x86-stdcall - alle ulong-Parameter auf uint adaptiert bei DllImport:

- worm_export_tar: funktioniert einwandfrei

- worm_export_tar_filtered_*: WORM_ERROR_TSE_INVALID_PARAMETER


x86-cdecl - gleiche Parametertypen wie x64:

- alle drei Funktionen machen probleme




@Maximilian:
Bringt nichts - wie bereits von mir irgendwann/-wo schon einmal erwähnt, haben wir ein simples C-Programm mit stdcall gebaut, das ebenfalls nicht funktioniert. Da man dafür zwangsläufig die WormAPI.h -Header-Datei im Original einbaut, kann ich bestätigen, daß es nicht funktioniert.
Auch das bereits kompilierte! Original-Demo aus ....\c\windows32-stdcall\bin\wormGui.exe funktioniert nicht.
@Jan:
Schön, daß es bei Dir auch nicht klappt.. 8-(

Wir starten jetzt noch einmal einen Versuch über einen Ansprechpartner bei Swissbit. Der erste verlief leider enttäuschend...

MfG Henrik

 

@Henrik Die WormGUi.exe funktioniert mit stdcall leider nicht.

 Kannst du mir dein C-Programm zur Verfügung stellen, welches mit stdcall arbeitet, dann frage ich nochmals bei SwissBit nach. Ich bekomme da relativ schnell eine Antwort. 


@Jan:

Was genau funktioniert bei der 32Bit-Dll mit cdecl nicht?


Grüße

Maximilian

Bitte schön...Reicht bis morgen...8-)

Die kompilierte Exe ist mit dabei. Es ist ein Kommandozeilenprogramm mit zwei Parametern: Laufwerk und Kassenname.

Der Aufruf lautet dann z.B. so:  TSESwissbit.exe V: 4

Es wird zuerst der Komplett-Export ausgeführt - dieser funktioniert. Die Daten werden nicht gespeichert.

Danach wird der gefilterte Export nach Transakt.-Nr. ausgeführt - dieser scheppert mit dem bekannten Fehler.

Die Aufrufparameter (Transakt.Nr./Kassenname) kann man leicht ändern.

getestet mit:

- SDK 5.2.3

- MS Visual Studio 2015 (höhere Versionen funktionieren ebenfalls; andere Compiler sollten ebenfalls funktionieren - das Bsp. ist simpel)

- stdcall

- lib-Datei zum Linken steckt mit im WormAPI-Header-Verzeichnis

  Falls du es mit VS versuchst, mußt du die Projekt-Pfade anpassen (u.a. für die Import-Library)


MfG Henrik


zip

@Jan 

Sie dir mal die Code-Samples an. Ich habe das heute erweitert, der FunctionPointer muss auch als cdelc deklariert sein. Einfach "[UnmanagedFunctionPointer(CallingConvention.Cdecl)]" drüberpacken, dann sollte der standard-export funktionieren.

@Maximilian
Gibt's schon was neues von deinem Swissbit-Kontakt bzgl. des C-Demos/Fehlers?
MfG Henrik

 

@Henrik

Leider noch nicht, habe aber soeben nachgefragt. Manchmal muss man ein bisschen nervig sein um Antworten zu bekommen :)

@Maximilian

yep, das war es - jetzt gehen alle drei Funktionen mit cdecl auch.

Damit kann ich bestätigen dass x64 und x86cdecl einwandfrei funktionieren, stdcall ist mir zumindest jetzt nicht gar so wichtig.


Vielen Dank.


Fehler 0x1016 ist übrigens WORM_ERROR_NOT_ALLOWED_EXPORT_IN_PROGRESS - was ja auch in meinem Fall gestimmt hat.


Beste Grüße


Jan




 @Max:

------------

@Jan 

Sie dir mal die Code-Samples an. Ich habe das heute erweitert, der FunctionPointer muss auch als cdelc deklariert sein. Einfach "[UnmanagedFunctionPointer(CallingConvention.Cdecl)]" drüberpacken, dann sollte der standard-export funktionieren.

------------

Genau das ist komisch. In der Header-Datei der 5.2.3. ist nämlich die einzige Änderung die Umstellung der Aufrufkonvention auf WORMAPI_CALL:

typedef int(WORMAPI_CALL *WormExportTarCallback)(...)


D. h., die Callback-Fkt. hat die gleiche Aufrufkonvention wie die übrigen Fkt. Vorher fehlte die Angabe und damit müßte es dann _immer_ cdecl gewesen sein.


MfG Henrik


@Henrik


Deswegen funktionierte auch der tar_export in der stdcall-Dll nicht (also vor Version 5.2.3). Da ergibt dann auch alles mehr Sinn :)

 

Wann wird die nächste SDK-Version denn verfügbar sein?
___________________________________________________________________________________
Maximilian Grießer gesagt vor 6 Tagen

 

Habe heute eine Rückmeldung erhalten, der Fehler konnte nachgestellt werden und ist in der nächsten SDK-Version behoben :)

Anmelden oder Registrieren um einen Kommentar zu veröffentlichen