DLL die für Visual C++ geschrieben ist, beim C++ Builder einbinden
-
Hallo zusammen,
ich versuche gerade eine DLL die für VC++ geschrieben ist, beim BCB 2010 einzubinden. Ich habe schon etliche Stunden gegoogelt und getestet(sogar eine eigene DLL geschrieben), um da weiter zu kommen.(Habe mich noch nie mit dll's beschäftigt)
Größtest Problem: die beiliegenden Header-Dateien sind C++(und ich glaube iwo gelesen zu haben das C++-Dateien(von VC++) im BCB nicht eingebunden werden können) Bitte berichtigt mich wenn es doch geht.
Allerdings liegen dem Paket Wrapper-Dateien(.h) bei, ich habe jedoch kp wie die einzubinden sind.
Wie ich die dll schließlich einbinde(statisch oder dynamisch) ist mir letztlich egal, hauptsache ich kann iwie damit arbeiten.
Hoffe mir hilft da jmd.
lg
-
Schau dir mal das Tool
implib
an, das liegt imbin
Verzeichnis deiner RAD Studio Installation. Damit kannst du mit der .dll und den .h Dateien eine .lib für das RAD Studio erzeugen.
-
mcam77 schrieb:
Größtest Problem: die beiliegenden Header-Dateien sind C++(und ich glaube iwo gelesen zu haben das C++-Dateien(von VC++) im BCB nicht eingebunden werden können) Bitte berichtigt mich wenn es doch geht.
Wenn es wirklich C++ ist, dort also class in Verbindung mit __declspec(dllexport) vorkommt, dann kann man die DLL nur in genau der VC++ Version verwenden, mit der sie erstellt wurde.
Exportiert die DLL nur C-Funktionen sollte das gehen, wie von DocShoe beschrieben.
Eventuell mal mit dem Dependency Walker nachschauen, was die DLL exportiert. Sie könnte auch dynamisch gelinkt sein und von einer Visual C++ Runtime abhängig sein ...
http://www.dependencywalker.com/
-
hat etwas länger gedauert, da ich erst win7 x86 inst. musste(Habe hearusbekommen, die dll soll nur unter win 7 x86 laufen)
@docshoe: implib habe ich versucht, bekomme aber immer noch "unresolved external..."
@nn: dependencywalker habe ich probiert, und er meckert(bei 64bit Systemen gewaltig, bei x86 meckert er 3 abhängige dll's (z.B. IEFRAME.DLL) an, die aber def. da sind)
In den header-dateien sind die klassen ganz normal definiert(also nix mit:)
dort also class in Verbindung mit __declspec(dllexport)
, außer das vor der klasse immer der dll-name(iwas_EXPORTLIB) steht(kp warum).
Der Aufruf der eig. Funktion sieht eig ganz normal aus(mit obiger Außnahme und ebent der Klasse als Ergebnis), und ich könnte ja die Header-Dateien umschreiben, wenn ich wüßte, wie ich dem BCB beibringe daß als ERG eine Klasse zurückgeliefert werden solllg
-
mcam77 schrieb:
@nn: dependencywalker habe ich probiert, und er meckert(bei 64bit Systemen gewaltig, bei x86 meckert er 3 abhängige dll's (z.B. IEFRAME.DLL) an, die aber def. da sind)
Über irgendwas meckert der immer.
Ich kenne eigentlich kaum eine DLL, wo nicht irgendwas kommt. Das liegt aber daran, dass er die ganze Kette der Abhängigkeiten (DLL lädt DLL, die wieder eine DLL lädt, die ...) durchgeht.
Wichtig ist eigentlich nur, dass die, in der Baumansicht, direkt von der DLL verwendeten DLLs alle da sind.
mcam77 schrieb:
, außer das vor der klasse immer der dll-name(iwas_EXPORTLIB) steht(kp warum).
Das dürfte dann ein Makro sein, dass u.a. das __declspec enthält.
Nun ja, damit ist die Frage eigentlich geklärt: Nein, die DLL kann so nicht mit dem Builder verwendet werden. Du brauchst eine Version der DLL, die mit dem (passenden) Builder gebaut wurde.
Sorry.