LoadLibrary() unter D11 ist THandle immer 0

[Steffer]

Hi,

bei einer Umstellung auf D11 stelle ich fest das eine eine benötigte DLL nicht laden kann. Handle ist immer 0.
Es geht nicht um die weitere Verarbeitung sondern nur um das Laden der DLL.

Handle:= LoadLibrary('mydll.dll');

Die DLL ist mit D7 erstellt und beinhaltet nur eine Function von 7 Zeilen.
Sharemem ist da noch die erste uses.
Eine vollkommene harmlose Geschichte.

Habe eine Testanwendung erstellt um diese und andere DLLs via LoadLibrary() zu laden.
Auch ganz einfache Geschichte: RadioGroup mit mehreren Optionen und einem Button und 2 Labels als Ausgabe
ob die DLL gefunden wird und ob Handle <> 0 ist.

Diese Testanwendung unter D7, XE und D11 erstellt.
D7 und XE können die DLL laden.
D11 nicht. Hier kommt Errorcode 1114, siehe Anlage.

Das Problem bleibt bestehen:
Wenn ich das ganze auf mehreren Rechnern teste.
Auch wenn in diese Testexe Sharemem als erste uses integriert wird.
Wenn die DLL im Verzeichnis der Testexe liegt oder mit einem Pfad gesucht wird.

Hat jemand dazu einen Ansatz?

[TiGü]

Lädt die DLL noch andere Abhängigkeiten (BPLs, DLLs)?

[Andreas13]

Vielleicht liegt es daran, daß System.ShareMem, die Datei borlndmm.dll benötigt und letztere nicht gefunden wird?

[jaenicke]

Du solltest einmal mit dem Process Monitor schauen, ob da versucht wird, auf etwas anderes zuzugreifen, z.B. wie schon genannt auf eine andere DLL. Dafür setzt du dort einfach den Filter auf Process Name is DeineExe.exe und lässt die Fehlermeldung offen. Dann kannst du die letzten Meldungen prüfen.

Zitat von Steffer:

Sharemem ist da noch die erste uses.
Eine vollkommene harmlose Geschichte.

Sharemem würde ich nicht als harmlos bezeichnen, sondern als Notlösung.

[hoika]

Hallo,
die D11-Anwendung ist nicht zufällig 64-Bit?

Was liefert LastError?
siehe hier
https://stackoverflow.com/questions/...does-this-mean

[Steffer]

Danke für die Antworten.

Zitat von TiGü:

Lädt die DLL noch andere Abhängigkeiten (BPLs, DLLs)?

Nein, nichts.

Zitat von Andreas13:

Vielleicht liegt es daran, daß System.ShareMem, die Datei borlndmm.dll benötigt und letztere nicht gefunden wird?

borlndmm.dll liegt in C:\Windows\SysWOW64 und würde ja dann auch beim Test mit D7, XE Probleme machen.

Zitat von jaenicke:

Du solltest einmal mit dem Process Monitor schauen, ob da versucht wird, auf etwas anderes zuzugreifen, ...

Da ist nichts.
Die Exe hat ein kleines Form mit

uses
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ExtCtrls;

Die DLL
uses
Sharemem,
SysUtils,
Classes,

Und mit D7 und XE eben keine Probleme.

Zitat von hoika:

Hallo,
die D11-Anwendung ist nicht zufällig 64-Bit?

Was liefert LastError?
siehe hier
https://stackoverflow.com/questions/...does-this-mean

Die 64-Bit Geschichte war auch so über Nacht mein Gedanke, ist aber nicht.

Last Error ist "Eine DLL-Initalisierungsroutine ist fehlgeschlagen".
Nur wird keine Initialisierung verwendet.

[dummzeuch]

Mal so in die Runde geworfen: Ist denn Sharemem von Delphi 7 (DLL) und Delphi 11 (Executable) überhaupt kompatibel? Ersteres benutzt die borlndmm.dll letzteres FastMM ohne DLL.

Ich habe noch nie versucht, diese beiden Versionen zu kombinieren.

[himitsu]

EXE und DLL jeweils mit dem "selben" Delphi kompiliert?


Ja, erstmal sollte jemand natürlich alle Rückgaben von LoadLibrary auswerten.
Eine Exception beim Laden der DLL seint es nicht zu sein, aber GetLastError/RaiseLastOSError werden bestimmt irgendwas sagen.



ShareMem und SimpleShareMem (weiß nicht mehr seit wann es das gab) gibt es weiterhin.
Und es müsste auch egal sein ob FastMM oder BorlandMM/DelphiMM. Die Schnittstelle des ShareMem hat sich ja praktisch nicht geändert (glaub ich).

* ShareMem (benötigt BorlndMM.dll)

* SimpleShareMem (nutzt intern AttemptToUseSharedMemoryManager/ShareMemoryManager und verwendet den Speichermanager des zuerst geladenen Moduls EXE/DLL/BPL)



Aber zusätzlich kommt noch. Wozu das ShareMem?
Du willst doch nicht etwa Delphi-Strings oder Objekte mit der DLL teilen?
Im Delphi 2009 wurde die interne Struktur der LongStrings (vor allem AnsiString) verändert. (und ein/zwei Jahre danach nochmal ein bissl)



Nja, natürlich könnte man auch mal die DLL debuggen. (am Einfachsten im Delphi 7, aber rudimentär ginge es auch im neuen Delphi, wenn man Assembler mag)

[Steffer]

Zitat von dummzeuch:

Mal so in die Runde geworfen: Ist denn Sharemem von Delphi 7 (DLL) und Delphi 11 (Executable) überhaupt kompatibel? Ersteres benutzt die borlndmm.dll letzteres FastMM ohne DLL.

Ich habe noch nie versucht, diese beiden Versionen zu kombinieren.

Danke. Das ist für mal so "geworfen" wenigstens ein Ansatz. Job für morgen.
Die DLL D7 ist ja so fertig und ich schaue mal ob dann D11 beim dynamischen / statischen laden mit der Sharemem ein Problem hat.

Zitat von himitsu:

EXE und DLL jeweils mit dem "selben" Delphi kompiliert?


Ja, erstmal sollte jemand natürlich alle Rückgaben von LoadLibrary auswerten.
...


... Die Schnittstelle des ShareMem hat sich ja praktisch nicht geändert (glaub ich).

Aber zusätzlich kommt noch. Wozu das ShareMem?

Rückgabe loadLibrary siehe oben.

An der ShareMem hat sich einiges geändert. Dachte auch es wäre eine Leiche die durchgeschleppt wird.

Wozu Sharemem ist keine Frage weil einfach vorhanden.
Und es geht nicht um Rückgaben etc. sondern einfach nur um LoadLibrary

[hoika]

Hallo,
wird ShareMem überhaupt gebraucht?

Wie sieht das Interface der DLL aus?
Vielleicht was mit Unicode?