Probleme mit DLLs

[Peter Werner]

<p>
Hi,<br>
Ich habe mehrere Probleme mit DLLs unter Windows.
</p>
<p>
<b><i>Problem #1:</i></b><br>
Ich versuche, eine globale Variable aus der DLL zu exportieren.<br>
Diese ist in einer anderen Quellcodedatei enthalten.<br>
Schreibe ich nun
<pre>
__declspec(dllexport) Type* MyVar;
</pre>
funktioniert das logischerweise nicht, da die Variable an anderer Stelle
bereits definiert ist.<br>
Der code
<pre>
__declspec(dllexport) extern Type* MyVar;
</pre>
wird vom compiler aber auch nicht akzeptiert.<br>
Es wäre auch möglich, die Variable im DLL-Hauptmodul mit __declspec(dllexport) zu deklarieren
und dann im anderen Modul mittels extern einzubinden, aber dann entsteht
die gleiche Fehlermeldung, dass sich die beiden Deklarationen unterscheiden.<br>
Wie muss ich das ganze schreiben, damit alles funktioniert?
</p>
<p>
<b><i>Problem #2:</i></b><br>
Ich möchte Klassen in einer art Forward-Declaration aus dem Hauptmodul meiner DLL exportieren.<br>
Diese sind explizit in einem eigenen Header ausgeschrieben.<br>
Schreibe ich nun:
<pre>
class __declspec(dllexport) MyClass;
</pre>
scheint der compiler das nicht zu exportieren.<br>
Offensichtlich funktioniert das nur, wenn ich schreibe
<pre>
class __declspec(dllexport) MyClass
{
MyClass(void);
void Foo(void);
};
</pre>
Muss das sein? Dann könnte man nämlich die exporte bequem und ohne Makros wie DLL_IMPORT_EXPORT, die
nicht mehr funktionieren, wenn man die DLL in einer anderen DLL nutzt, im Hauptmodul steuern.
</p>
<p>
<b><i>Idee:</i></b><br>
Mich würde mal (nur zum Spar&szlig interessieren, ob es eine Möglichkeit gibt, Klassen dynamisch zu laden,
ohne auf Compilertricks wie Borlands Packages zurückzugreifen.<br>
Mittels LoadLibrary/GetProcAddress unter Windows und dlopen/dlsym unter Linux kann man Funktionen
dynamisch laden. Aber Klassen werden ja nicht als Klassen, sondern als Set von Funktionen
exportiert. Kann man eine art Metaklasse schreiben, die die Klasse lädt und sich ähnlich wie eine
normale Klasse verhält? z.B.:
<pre>
MetaClass mc;

mc.Load("MyLib.dll", "ClassName");
(*(mc.Proc("FooProc")))(1, 2, 3);
</pre>
Das ganze müsste praktisch einen This-Pointer verwalten, und die Proc-Methode müsste einen Funktionszeiger auf einen
Assembler-Chunk liefern, der dynamisch erzeugt wird, den this-pointer auf den Stack pusht, und die Originalfunktion
aufruft. Und die Namensergänzung müsste auch irgendwie beachtet werden.<br>
Hat irgedjemand eine Idee, wie sowas praktisch und plattformunabhängig aussehen könnte?
</p>
<p>
Ich wäre echt sehr dankbar, wenn irgendjemand eine Lösung hätte.<br>
Ciao,<br>
Peter
</p>

[Rober]

Hi,

sorry falls meine Antwort jetzt total am Thema vorbei geht ,
aber ich hab heute noch keinen Kaffee bekommen - sprich
zu müde deine Frage wirklich aufmerksam zu lese
geschweigedenn zu verstehn ,))

Also habe vor einigen Wochen ein Plugin interface
programmiert. Ein Plugin entspricht einer bestimmten
Klasse. Die Plugin's liegen als DLL's in einem Verzeichnis
und werden dynamisch mit LoadLibrary geladen. Um ein
Object der Pluginklasse zu erhalten, exportieren die dll's
eine funktion ( Plugin __export getPlugin(void); ), welche
genau dieses object an das Hauptprogramm zurück gibt.
So muß ich im Hauptprogramm bloß den Plugin Header
einbinden und brauche nicht die entsprechende cpp datei
compilieren und linken... Ich befürchte allerdings das genau
das mit dem header einbinden etwas ist was du vermeiden
möchtst ??

mfg Robe

[Irmgard Sartor]

Hallo Peter!

Ich hatte vor Kurzem auch ein Problem ähnlich wie dein Erstes. In der Deklaration

__declspec(dllexport) Type* MyVar;
mußt du MyVar weglassen, und da, wo die Funktion steht

function(Type* MyVar)

und die Variable vom aufrufenden Programm als Parameter übergeben.

(Hoffe, das war jetzt richtig so)

Gruß

Irmgar