Entwickler-Ecke

Windows API - Leere DLL-Initialisierung?


tommie-lie - Do 28.08.03 22:41
Titel: Leere DLL-Initialisierung?
Hallo,

Ich habe hier irgendwie ein Problem mit DLLs (oder ist tatsächlich der Compiler dran schuld?).
Folgender DLL-Code:

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
library Project1;

uses
  Dialogs;

begin
  ShowMessage('Hello, world');
end.

Kompilieren, und dynamisch einbinden (mit LoadLibrary) klappt einwandfrei. Jetzt will ich aber nicht, daß die Message angezeigt wird, also kommentiere ich die Zeile aus:

Delphi-Quelltext
1:
2:
3:
begin
//  ShowMessage('Hello, world');
end.
.
Kompilieren klappt immer noch, aber LoadLibrary erzeugt den Fehlercode 127, welcher auf Deutsch besagt: "Die angegebene Prozedur wurde nicht gefunden.".
Egal was ich in der DLLMain() mache (die ja hinter dem begin-end einer library steckt), solange ich überhaupt was mache, funktioniert es, lasse ich die DLLMain leer, will er nicht mehr (dabei steht sogar im SDK, daß DLLMain() nur optional ist).

Das Modulhandle, daß von LoadLibrary zurückgegeben wird, ist seltsamerweise trotzdem gütig (nicht 0 und die Funktionen lassen sich auch importieren), aber trotzdem hätte ich gerne eine DLL, die mit meinem C-Debugger funktioniert, denn der weigert sich nach LoadLibrary weiterzulaufen.
Außerdem hätte ich gerne DLLs, die keine Fehler verursachen *g*

Ein leerer begin-end-Block wird sogar in einem Beispiel aus der Delphi-Onlinehilfe verwendet und ich brauche für meine DLL keine Initialisierung, welche Möglichkeiten gibt es also in Delphi, eine DLL ohne Initialisierung zu schreiben?


BungeeBug - Fr 29.08.03 10:12

Hi,

ich würd einfach die DLL weglassen :) was bringt den bitte ne leere DLL ausser das sie fehlen kann und Fehler produziert?


UC-Chewie - Fr 29.08.03 10:34

Nicht die DLL ist "leer" (sie soll ja Funktionen exportieren), sondern die DLLMain-Funktion enthält keine Anweisungen.


CenBells - Fr 29.08.03 10:53

hallo,
hast du den code immer noch auskommentiert? also meine Dlls haben immer die form...

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
library...
...
{$R *.res}

exports
  executeAboutDlg;


begin
end.


Und bei mir funktionieren die ohne probleme.

Gruß
Ken


tommie-lie - Fr 29.08.03 13:42

Ich wollte euch nicht mit 748 Zeilen DLL-Quelltext belasten, deswegen habe ich als Beispiel eine leere DLL genommen. Aber ob ich jetzt andere Funktionen exportiere, oder nicht, das Problem besteht weiterhin.

@Cen: Ja, meine sieht auch so aus, nur daß ich keine Ressource einbinde, weil ich keine brauche (liegt da vllt der Fehler? Probier' ich gleich mal aus :-)) . Das ganze funktioniert ja auch, wie ich geschrieben habe, die exportierten Funktionen lassen sich importieren, das Modulhandle ist gültig usw, nur gibt GetLastError mir die oben genannte Fehlermeldung zurück.

Wer jetzt ankommt und meint, GetLastError gibt nicht unbedingt den Fehler von LoadLibrary zurück: Natürlich habe ich dran gedacht vorher den Prozess-Error auf 0 zu setzen.


Also nochmal: Das Problem besteht nicht darin, daß ich die DLL nicht laden kann oder deren Funktionen nicht aufrufen kann. Das Problem besteht darin, daß ein Fehler zurückgegeben wird, sobald die DLLMain leer ist.


tommie-lie - Fr 29.08.03 14:33

Ich hab's.
Es liegt an der Unit Dialogs, ist sie eingebunden, klappt's nicht mehr.
So gibt's keinen Fehler:

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
library Project1;

// uses
//  Dialogs;

end.
, kommentiere ich die Dialogs-Unit wieder ein, meldet er den Fehler (unabhängig von den anderen eingebundenen Units und unabhängig davon, ob eine Ressource eingebunden ist).

Weiß irgendwer warum das so ist?
Ich brauche nur ShowMessage(), da kann ich ja noch die API nehmen, aber was wenn man mal andere Dialoge braucht und nicht auf die VCL verzichten möchte?

Nachtrag: Und wenn man die SysUtils benutzen will, muss man auch die Classes einbinden.
Ich hasse die VCL...