Prozedureinsprungpunkt nicht gefunden

[lkz633]

Hallo,

habe folgende Deklaration:

Delphi-Quellcode:

procedure InitOCR; stdcall; external 'ocr.dll';
  procedure UnInitOCR;stdcall; external 'ocr.dll';

Bekomme aber eine Fehlermeldung, "Prozedureinsprungpunkt nicht gefunden",

die Deklaration der C++ Funktion ist
void InitOCR(); Was mache ich falsch?

Danke und Gruss
lkz633

[glkgereon]

gibt es auch die UnInitOCR?

[Mephistopheles]

*kram* *wusel* Voila, habe da mal was aus der Zauberkiste geholt. Damit kannst du gucken, wie die Exporte der DLL wirklich heißen, oder ob es vielleicht nur Ordinals sind.

[lkz633]

Hallo,

da bekomme ich folgenden Auszug, die Funktionen existieren also.......

[Dax]

Setze mal einen Unterstrich vor deine Funktionsnamen, dann wird es funktionieren. Im dem Fall, bei dem beim statischen einbinden einer DLL weder Funktionsname noch -index angegeben werden, sucht der Compiler nach einer Funktion mit dem deklarierten Namen, der bei dir ja anders ist als in der DLL.

[Mephistopheles]

Alternativ

procedure Bla(); stdcall; external 'bla.dll' name 'EchterExportName'; Nachtrag: Ich sehe gerade, daß wir es mit maskierten Namen zu tun haben. Du mußt also vermutlich auch '@0' mit angeben. Also vermutlich:

Delphi-Quellcode:

procedure InitOCR; stdcall; external 'ocr.dll' name '_InitOCR@0';
procedure UnInitOCR; stdcall; external 'ocr.dll' name '_UnInitOCR@0';

Tip: Danach mit depends.exe mal nachschauen, ob deine Delphi-EXE die Namen korrekt importiert.

[lkz633]

Zitat von Mephistopheles:

Nachtrag: Ich sehe gerade, daß wir es mit maskierten Namen zu tun haben. Du mußt also vermutlich auch '@0' mit angeben. Also vermutlich:

Delphi-Quellcode:

procedure InitOCR; stdcall; external 'ocr.dll' name '_InitOCR@0';
procedure UnInitOCR; stdcall; external 'ocr.dll' name '_UnInitOCR@0';

Danke, jetzt klappts einwandfrei. Was bedeutet genau das @0 ?

Gruss
lkz633

[Mephistopheles]

Das bedeutet, daß insgesamt 0 Bytes an Parametern auf den Stack gelegt werden. Bei 4 kann es zB ein Pointer oder DWORD sein. Sobald du mit Reverse-Engineering anfängst, wirst du es genauer verstehen lernen

Nachtrag: Borland's C++ verwendet einen anderen Code um die Funktionsnamen zu maskieren. Bei Watcom bin ich nicht sicher. Wenn man in C eine Funktion exportiert, und nicht explizit eine .DEF-Datei angibt, in der die Namen ohne Maskierung angegeben sind, werden sie vom Linker automatisch maskiert.
Bei C++ gibt es dann noch so feine Sachen, wo sogar die Typennamen und andere interessante Dinge mit im maskierten Namen verborgen sind. Depends.exe kann die aber alle demaskieren.