loadlibrary unter W10

[joacim]

@samso ich weiß, daß man mit D6 keine 64 bit DLL laden/verwenden kann. Das mache ich alles nur, um jede Möglichkeit auszuschöpfen.

Auf die DLL selber habe ich keinen Einfluß, die kommt vom Hersteller der Mess-Karten, die ich ansprechen soll.
Ich denke mal, die DLL ist mit C oder C++ erstellt worden. Ein Kontakt mit dem Hersteller gestaltet sich eher
schwierig.

[joacim]

@Frühlingsrolle In meinem Rechner steckt eine PCIe3021. Das ist aber nicht entscheidend.
Ich habe mit dem "normalen" Treiber schon Programme für die Karte entwickelt. Jetzt geht es
um einen neuen sog. Universaltreiber. Ich habe auch eine ausführliche Dokumentation mit
allen Aufrufen usw. Die Sache mit dem statischen Linken hatte ich inzwischen schon verwendet
und der Treiber liegt auch im Verzeichnois der EXE. Jetzt bekomme ich wenigstens Fehlermeldungem.
Erstmal fehlte MSVCR100.DLL (liegt jetzt im Verzeichnis) Dann wurde MSVCP100.DLL nicht gefunden.
Das schein ja - nach vielen Hinweisen im Netz - ein übliches Problem zu sein. Ich habe den MS-Installer
ausgeführt und sehe MSVCP100.DLL jetzt unter c:\windows\system32. Das scheint aber noch nicht ausreichend zu sein.
Beim Start des Programms bekomme ich immer noch eine Fehlermeldung (s. Anhang).

Es scheint ja auch noch Probleme mit div. Verssionen der MSVCP100.DLL zu geben ...

[Dalai]

Wenn die DLL auf das Vorhandensein der msvc*100.dll angewiesen ist, muss die 32-bit (x86) Version der Visual C++ Redistributable 2010 installiert sein/werden. Deren DLLs landen dann in %SystemRoot%\SysWOW64 (\system32 bitte ignorieren für diesen Fall, weil dort 64-bit DLLs liegen).

Alle (halbwegs) aktuellen Visual C++ Redists können bei MS geladen werden: https://support.microsoft.com/en-us/...al-c-downloads (für die 2010 muss man auf das MFC Update zurückgreifen, wenn man kein MS-Konto hat).

Grüße
Dalai

[DieDolly]

Zitat:

Alle (halbwegs) aktuellen Visual C++ Redists können bei MS geladen werden: https://support.microsoft.com/en-us/...al-c-downloads (für die 2010 muss man auf das MFC Update zurückgreifen, wenn man kein MS-Konto hat).

Oder einfach vom Anhang

[himitsu]

Die Fehler aus LoadLibrary (ERROR_MOD_NOT_FOUND) können sich halt auf die DLL selbst beziehen, oder auf eine andere abhängige DLL,
oder es kann aus den Startprozeduren der DLLs kommen und da dann z.B. auch von dynamischen Links.

Wie bereits genannt wurde, kannst du mit gewissen Programmen die statischen Verlinkungen auflisten und prüfen lassen.
Wenn das nichts Hilft, dann entweder mit dem Debugger, der aber nur bei dynamischen Links helfen könnte.
Oder z.B. mit einem FileExplorer/ProcessMonitor, welcher die Dateizugriffe loggt. Dort kannst du dann sehen auf welche Dateien und Verzeichnisse zugegriffen und welche davon nicht gefunden wurden.
https://docs.microsoft.com/en-us/sys...nloads/procmon


Zu den DLLs in Systemverzeichnissen (System32 usw.) brauchst und solltest du kein Verzeichnis beim LoadLibrary und für statische Links angeben.
Windows sucht beim hier zuerst in dem Verzeichnis deiner EXE und später auch im "passenden" System-Verzeichnis. (und weiteren Suchpfaden)

PS: Du kompilierst ein 32-Bit Programm, also sind für dich nur 32-Bit-DLLs interessant, wie bereits richtig erkannt. (abgesehn von OutOfProcessServern, wo die DLL woanders auch in einem 64-Bit-Host geladen sein kann).
Und Achtung, in Windows 64 ist System32 für 64-Bit-DLLs, während die 32-Bit-DLLs im SysWOW64 liegen (System for Windows 32 on Windows 64), aber keine Sorge, denn Windows leitet standardmäßig für dein 32-Bit-Programm auf WoW64 um, falls dein Programm doch einmal auf C:\Windows\System32\... zuzugreifen versucht.
Selbiges Umleitungskonzept gilt auch für einige Verzeichnisse in der Registry.
Und was das WinSxS (Side-by-Side) betrifft, können Andere es besser erklären, aber im Grunde geht es darum, dass man in seiner Anwendung die DLL-Version vorgeben kann und Windows dann im System unter all den gleichnamigen DLLs die Passende für dich raussucht.
https://en.wikipedia.org/wiki/Side-by-side_assembly
Vorallem für gewisse System-DLLs ingoniert Windows gleichnamige DLLs in deinem Verzeichnis oder anderen Suchfragen und geht dennoch auf System32. (Sicherheitsdinges, um billige Hooks zu umgehen) aber ist hier egal.

Und nun noch etwas Werbung: https://www.embarcadero.com/delphi-starter-edition

[joacim]

guten abend und danke für die vielen Tips!

@dieDolly : Nachdem ich die Installation aus Deiner 7z-Datei verwendet habe, startet mein Testprogramm
schon mal ohne Fehlermeldung. Das habe ich bei diversen Versuchen mit anderen Installern für MSVCP100
nicht geschafft. Also nochmal danke!

Für die weitere Programmierung brauche ich nun das handle, welches die Treiber-DLL bei LoadLIbrary
zurückliefert. Das war ja der Ausgangspunkt. LoadLibrary läuft jetzt zwar durch und liefert (angeblich)
auch ein handle (268435456). Das kommt mir aber merkwürdig vor. Außerdem liefert ein GetLastError als Ergenis
eine 5 (access denied). Der Versuch diese Handle in einer der DLL-Funktionen zu verwenden liefert dann
auch gleich wider einen Fehler. (Externe exception E06D7363).