Weil eine .LIB-Datei fehlt, lässt sich die zu verwendende IRBGRAB.DLL nicht
in Visual C statisch einbinden, und man hat eine Menge Arbeit
mit GetProcAddress()-Aufrufen.
Die mitgelieferte Header-Datei IRBGRAB.H enthält keine _stdcall-Aufrufkonventionsfestlegung
und ist damit in Projekten mit _cdecl- oder _fastcall-Aufrufkonvention
nicht verwendbar (d.h. das Programm wird korrekt compiliert, stürzt aber
„rätselhafterweise“ irgendwo ab). Ein typischer Fremdkörper mal wieder.
Hier die notwendigen Dateien für statisches Binden zur IRBGRAB.DLL:
- irbgrab.h, die angepasste Header-Datei
- irbgrab.lib, die Importbibliothek für IRBGRAB.DLL
- irbgrab.def, die Moduldefinitionsdatei,
zum Erstellen von Importbibliotheken bspw. für Borland C++ Builder
- GrabDll.zip, alles zusammen
Außerdem hilft _declspec(dllimport), Kode zu sparen.
Die Verknüpfungen zur DLL sind allesamt nach Nummer, nicht nach Name.
Die resultierende Kodegröße ist zudem geringer.
Allerdings darf Infratec die Ordinalzahlen nicht ändern!
Richtige Lösung:
- Ein DLL-Projekt erstellen
- Eine Datei
irbgrab.c schreiben,
die eine Funktion X exportiert: void X() {}
(_declspec(dllexport) ist nicht erforderlich!)
- Eine Moduldefinitionsdatei
irbgrab.def schreiben,
die unter EXPORTS lauter Zeilen der Form exportname=X enthält
- übersetzen, entstehende .LIB-Datei verwenden, entstehende .DLL-Datei wegwerfen
Da frage ich mich die ganze Zeit, warum der MSVC-Linker nicht gleich
DLLs linken kann, anstelle diese umständlichen LIB-Dateien zu handhaben.
Hat man eine .EXE compiliert, die statisch mit IRBGRAB.DLL verbunden ist,
muss diese DLL:
- neben der .EXE-Datei liegen oder
- im aktuellen Verzeichnis liegen oder
- sich im Suchpfad befinden
Die wenigsten Probleme bereitet die erste Lösung.
Zu beachten ist, dass die davon abhängigen DLLs VARIOCAM.DLL und C3POWER.DLL
sich ebenfalls im o.a. Verzeichnissen befinden müssen!
Die Datei MSVCP60.DLL befindet sich oftmals schon im Windows-Verzeichnis.
