loadlibrary unter W10

[Dalai]

Zitat:

Zitat von DieDolly (Beitrag 1453423)

Das ist meiner Meinung nach schon das Problem.
DLL erzeugt mit modernem Delphi und du arbeitest mit einem alten. Das Problem hatte ich umgekehrt schon.

Das sollte kein Problem sein, jedenfalls nicht für LoadLibrary. DLLs sind ja gerade dafür da, von einem beliebigen Programm geladen und benutzt zu werden, völlig egal, womit die beteiligten Teile kompiliert wurden. Trotzdem ist dein Einwand grundsätzlich berechtigt, wenn es um Rückgaben von Funktionen aus der DLL geht (Stichwort Strings/PChar und Unicode). Aber das kommt erst nach dem LoadLibrary.

@joacim:
Den (relevanten) Fehlercode aus dem OP beschreibt MS so:

Zitat:

ERROR_MOD_NOT_FOUND
126 (0x7E)
The specified module could not be found.

Schau dir die DLL genauer an, z.B. mit einem der schon genannten Programme (Dependency Walker, DLL Export Viewer) und prüfe, welche Funktionen deine DLL aus anderen DLLs importiert. Bevor eine DLL erfolgreich geladen werden kann, müssen alle (statischen) Import-Abhängigkeiten aufgelöst werden. Und samso sagte ja schon richtig, dass du die Win64-Variante der DLL ignorieren kannst, denn dein Programm ist in jedem Fall 32-bittig.

Grüße
Dalai

[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).

[DieDolly]

Zitat:

Das habe ich bei diversen Versuchen mit anderen Installern für MSVCP100
nicht geschafft.

Auf Seite 1 glaube ich hatte ich bereits geschrieben, dass man dieses Redist installieren muss.

Zitat:

Zitat von DieDolly (Beitrag 1453417)

Zitat:

Im D.Walker sehe ich auch MSVCP100.DLL. ich verstehe nur nicht, warum ich diese DLL mit LoadLibrary auch nicht laden kann.

Installier doch einfach das passende Microsoft Windows Redistributable Package dann musst du nix selber laden.

Noch ein Tipp für die Zukunft: wenn man zum Beispiel MSVCP100.dll bei Google eingibt, sind die ersten Seiten oft irgendwelche sehr dubiosen DLL-Download und -Fix-Seiten.
Bei sowas niemals runterladen!

Stattdessen einfach hier nachfragen, wo diese DLL herkommt und was man braucht, damit alles funktioniert.

[jaenicke]

Zitat:

Zitat von joacim (Beitrag 1453485)

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).

Wie meinst du das "in einer der DLL-Funktionen zu verwenden"? Das Handle, das LoadLibrary liefert, ist das Handle der DLL und kann verwendet werden um die Funktionen der DLL dynamisch zu laden.
Das hat aber nichts mit dem Handle zu tun, das du an eine der Funktionen der DLL übergeben kannst (in den Beispielen z.B. ph_DeviceHandle genannt).

[joacim]

Nach verschidenen Tests bekomme ich jetzt die ersten Ergenisse. Versuche die Funktionen des Treibers
zu verwenden, klappten aber immer noch nicht. Das Problem lag in einer fehlenden FAR Deklaration beim
Import der Funktionen.
@jaenicke
Es gibt aber immer noch Unklarheiten. Die Funktionen des Treibers verlangen im Aufruf ein Handle. Ich habe
bisher gedacht (und es bei dem Vorläuferprojekt auch so gemacht), das dort das Handle eingetragen werden
muss, dass bei LoadLibrary zurückkommt. Das funktioniert zwar, aber ich kann genauso gut Null eintragen und
bekomme z.B. sinnvolle Ergebnisse beim Lesen der digitalen Eingänge. Ich erwarte nicht, diese Eigenschaft
hier zu klären, da werde ich mal mit dem Hersteller Kontakt aufnehmen.

Nachdem nun die größten Hürden genommen sind, kann ich mit der eigentlichen Verwendung des Treibers
beschäftigen. Nochmals denke an alle und schon mal frohe Weihnachten.