asignRKCOM DLL

[Emwykey]

Hallo zusammen!

ich habe ein Problem bei der Verwendung von Funktionen aus der DLL der im Titel genannten Bibliothek.
Es handelt sich um eine C/C++ Dll.

Ich habe einige Funktionen bereits in mein Delphi Projekt (Delphi XE 5 Embarcadero RAD Studio) eingebunden, welche auch problemlos aufzurufen sind.

Hier ein Beispiel:
Funktionsaufruf lt. Schnittstellenbeschreibung:

Code:

long Certificate( void* handle , char* buffer , long * buffersize ) ;

Zitat:

Paramter:
handle: Handle welches von Initialize zurückgeliefert wurde (siehe 4.2.2)
buffer: Bereits reservierter Speicher für die Zertifkat, wenn dieser Parameter NULL
ist wird nur die Gröÿe des benötigten Speichers zurückgegeben
buffersize: Speichergröße von buffer bzw. benötigte Speichergröÿe
Rückgabewert:
0: OK
100: Buffer ist NULL
101: Buffer zu klein

Ich habe das ganze wie folgt umgesetzt:

Code:

type
  THandle_PAnsiChar_PAnsiChar__Integer = function( aHandle : THandle; Buffer : PAnsiChar; BufferSize : PAnsiChar ) : Integer; cdecl;

[...]

var
  fCertificate : THandle_PAnsiChar_PAnsiChar__Integer;

[...]


implementation

procedure TForm1.FormShow(Sender: TObject);
var IntLaenge : PAnsiChar;
begin
  hDll := LoadLibrary('asignRKCom.dll');
  if HDll >= 32 then begin
  
    fCertificate := GetProcAddress(hDll, 'Certificate');

    [...]

    bufferCertificate := nil; // PAnsiChar
    IntLaenge := PAnsiChar(AllocMem(1));  // PAnsiChar
    fCertificate( aHandle, bufferCertificate, IntLaenge ); // dieser Aufruf liefert die benötigte Speichergröße
    bufferCertificate := PAnsiChar(AllocMem(Integer(IntLaenge^)));

    case fCertificate( aHandle, bufferCertificate, IntLaenge ) of // dieser Aufruf schreibt den gewünschten Wert in meinen Buffer
     0 : begin //OK
       //showmessage( 'Certificate Serial: OK' );
     end;
     100 : begin  // Buffer ist NULL
         //showmessage( 'Certificate Serial: Buffer ist NULL' );
     end;
     101 : begin // Buffer zu klein
         //showmessage( 'CertificateSerial:  Buffer zu klein' );
     end;
    end;
    [...]

  end else
    MessageDlg('Error: could not find asignRKCom.dll', mtError, [mbOk], 0);
  end;

Hier funktioniert alles. Genauso wie in vielen Weitern genau so definierten Funktionen.


Die Funktion "fGenerateKey" habe ich identisch behandelt (natürlich auf die neuen Übergabeparameter angepasst).
Hier bekomme ich beim Aufruf eine Zugriffsverletzung.
Nachdem ich den Längenwert von PAnsiChar in Typ Pointer ( @LongInt ) angepasst hatte bekam ich keine Fehlermeldung mehr, die Methode lieferte jedoch beim 2. Auftruf nicht den gewünschten Wert in "Buffer" zurück. Buffer blieb leer.
Der Rückgabewert der Funktion lautete 0 für OK.

Ich habe bereits viele Varianten versucht. Übergabewerte vom Typ Pointer, PChar und PLongInt, PAnsiChar und PLongInt, PAnsiString und PLongInt, oder auch AnsiString und Integer/LongInt ...

Des Weiteren stieß ich auf folgenden LInk http://www.coding-board.de/threads/c...rwenden.20639/ --> Hier wird beschrieben, dass es sein kann, dass die Übergabeparameter in umgekehrter Reihenfolge übergeben werden, also habe ich die o.g. Varianten alle Rückwärts ebenfalls versucht.
Leider erfolglos

Die Funktion ist lt. Schnittstellenbeschreibung wie folgt definiert:

Code:

long GenerateKey ( char* newkey , long *newkeyLen ) ;

Zitat:

Paramter:
newkey: Bereits reservierter Speicher für den AES Schlüssel, wenn dieser Parameter
NULL ist wird nur die Größe des benötigten Speichers zurückgegeben
newkeyLen: Länge des AES Schlüssel bzw. benötigte Speichergröÿe
Rückgabewert:
0: OK
1: Fehler
102: newkeyLen zu klein

Hat hier jemand Erfahrungen mit C/C++ Dll s in Delphi? Oder noch besser mit der verwendeten Bibliothek?
Woran könnte es liegen, dass der Aufruf schreitert?
Was könnte ich noch versuchen?

Danke!

[HolgerX]

Hmm..

Wieso nimmst Du ein PAnsiChar bei long?

Delphi-Quellcode:

type
  TCertificateFunc = function (Handle : THandle; Buffer : PAnsiChar;var BufferSize : DWORD):DWORD;stdCall;

var
  FCertificate : TCertificateFunc;

Hier bitte die Aufrufkonvention anpassen (register/cdecl/stdcall).

[Emwykey]

Ich habe einige Datentypen versucht und bin da hängen geblieben. Ich hatte auch bei der Certificate Funktion nicht von Anfang an gleich einen funktionierenden Aufruf zusammen. ich hab aber wie erwähnt auch schon PLongInt verwendet (bei GenerateKey) und leider dasselbe Ergebnis erhalten. Bei Certificate funktioniert ja alles...

[Emwykey]

ABER! Der Hinweis hat das Problem gelöst!!!
VIELEN VIELEN DANK!!!!!!!!!!

[stalkingwolf]

ah noch jemand der dort dran ist.
Ich verzweifle hier auch gerade ein wenig.

Was ich den ganzen Funktionen nachher mitgeben muss weiß ich auch noch nicht


Österreicher ich hab euch gern ... ganz ehrlich

[TiGü]

Alles vom Grunde auf selber programmieren ist ja auch Horror. Wir nutzen dafür die Lösung von fiskaltrust. Wäre das für euch eine Option?

[stalkingwolf]

Nuna ja ich muss eh ein Server Programm schreiben und die Clientimplementierung in unsere Kassen inkl Ausdruck des QR Codes auf unsere Belege.
die a.sign DLL nimmt einem schon sehr viel Arbeit ab. Ich muss mich nun nur durchfuchsen was ich benötige.
Datenaufbau habe ich mittlerweile auch raus.

Interessanter finde ich die diversen Beiträge im Netz das die Startbelege nicht vom Finanzamt in Österreich erkannt werden, obwohl alle Prüftools sie als ok zurückgeben.

[TiGü]

Na ja, der fehlerlose Aufbau des DEP ist ja auch nicht ohne.

Mit der fiskaltrust-Lösung haste einen lokalen Windows-Dienst als Webservice, der mit der Karte redet und das DEP führt.
WSDL importieren. Interface mit drei Methoden verwenden. Datencontainer mit den wichtigsten Sachen füllen. Fertig.

[stalkingwolf]

Für das DEP werden wir den e-Tresor von A-Trust einsetzen.