loadlibrary unter W10

[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 von DieDolly:

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 von joacim:

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.

[jaenicke]

Zitat von joacim:

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.

Wie das geht sieht man eigentlich schon in den Parametern der Funktionen. Du hast dort z.B. bei einem Board eine Funktion i_PCI3016_OpenBoardViaIndex, die den Boardindex bekommt und als var-Parameter die Variable mit dem Handle. Dementsprechend ist zu erwarten, dass die Funktion das Handle in eben diese Variable hineinschreibt (sonst müsste es ja kein var-Parameter sein).

Sicher, wenn du da vorher deinen Handle-Wert hineinpackst, wird der einfach überschrieben, deshalb merkst du das ohne es zu debuggen nicht.

[joacim]

Ich habe hier - nur als Beispiel - zwei Funktionen

Delphi-Quellcode:

function b_ADDIDATA_GetNumberOfDigitalInputs(dw_DeviceHandle : DWord; var w_NumberOfChannels : word) : byte; far; stdcall; external 'ADDIDATA.DLL';
function b_ADDIDATA_Read4DigitalInputs(dw_DeviceHandle : DWord; b_port : byte; var b_portValue : byte) : byte; far; stdcall; external 'ADDIDATA.DLL';

Wie schon geschrieben, wurde im Vorläuferprojekt immer das Handle an die Funktion übergeben.
Die beiden Funktionen erwarten auch hier die Übergabe von dw_DeviceHandle, nicht als var, also nicht als Rückgabewert!

In der Dokumentation steht z.B.
<return value> = b_ADDIDATA_Read4DigitalInputs(DWORD dw_DeviceHandle,
BYTE b_port : byte,
PBYTE pb_portValue)

Ich interpretiere PBYTE als Pointer auf ein Byte, daher VAR im Delphi. dw_DeviceHandle ist aber DWORD also kein VAR,
also auch kein Rückgabewert. Warum ist es völlig gleichgültig, was ich da übergebe? Das Lesen der digitalen Eingänge funktioniert jerdenfalls, auch mit dw_DeviceHandle = 0. Die Antwort kann wahrscheinlich nur der Hersteller geben.

[Luckie]

DeviceHandle! Das Handle des Geräts und nicht das Handle der DLL. Die Funktion muss ja wissen von welchem Gerät du die Infos willst.

[jaenicke]

Zitat von joacim:

Wie schon geschrieben, wurde im Vorläuferprojekt immer das Handle an die Funktion übergeben.
Die beiden Funktionen erwarten auch hier die Übergabe von dw_DeviceHandle, nicht als var, also nicht als Rückgabewert!

Und wie sieht es mit i_ADDIDATA_OpenWin32Driver und i_ADDIDATA_GetCurrentDriverHandle aus?