Ich werfe mal als Stichworte LoadLibrary und GetProcAddress in den Raum. Außerdem möchte ich Dir Ollis
DLL-Tutorial ans Herz legen.
Aaaah. Damit willst du mich nur zwingen es endlich zu aktualisieren, oder?
War lange geplant, aber es finden sich weder Mitstreiter (trotz SF.net-Projekts als unabhängige Platform) noch Zeit.
Das was ich am meisten als Mißverständnis bei der Benutzung von DLLs sehe ist, daß die Leute DLLs oft als eigenständige Programme sehen. Das stimmt natürlich nicht. Aber um das zu verstehen muß man den Zusammenhang zwischen dem Code, einem Prozeß und den Threads in einem Prozeß erstmal begreifen. Da hakt es oftmals.
Ein Prozeß führt keinen Code aus, eine
DLL auch nicht. Die
DLL (wie auch die EXE) ist Container für Code und der Prozeß Container für Threads ... und die Threads führen den Code (quasi-)parallel (je nach Anzahl CPUs) aus. Im Endeffekt ist es absolut egal ob der Code der ausgeführt wird (sagen wir mal Quicksort) nun im Abbild der EXE oder im Abbild der
DLL im Speicher liegt. Dennoch gibt es natürlich Einschränkungen, aber da muß ich auch auf ein leider etwas in die Jahre gekommenes Tutorial von mir verweisen, wie DeddyH auch schon.
Im Prinzip geht es doch darum, das alle Teile möglichst unabhängig von einander funktionieren.
Darum würde ich Interface einsetzen.
Ich nehme an du meinst basierend auf
IUnknown und Konsorten? Unterstütze ich in dem Fall voll.
Das ist Aufgabe der
GUI. Die
GUI fragt alle beim Anwendungskern registrierten Interface ab und prüft für jedes, ob ein Interface suportet wird, das Informationen zu zusätzlichen Menüpunkten bereitstellt. Diese werden angelegt und mit der Funktion aus dem Interface verknüpft.
Die
GUI könnte sich beim Anwendungskern auch als Observer für die registrierten Interface anmelden, um gegebenenfalls auf Änderung reagieren zu können.
Hier würde ich eher noch weiter differenzieren und die Logik dazu welche Interfaces unterstützt werden eine Ebene unter der
GUI ansiedeln.
Man könnte sogar so weit gehn, jeweils eine
DLL für die fachliche Logik und eine für die Oberfläche zu dieser Logik einzusetzen.
Das läßt sich a.) nicht für jeden Anwendungs-/
GUI-Typ machen und b.) ist es nicht so clever wie es anfänglich klingt jeweils immer einzelne DLLs anzubieten. Für die Kernkompetenzen der Anwendung kann auch eine
DLL mehrere Interfaces anbieten (über
COM oder einen Mechanismus der den in
COM nachbildet) für Erweiterungen würde ich wiederum mitgehen mit mehreren einzelnen DLLs ...
Dann wäre die Oberfläche komplett austauschbar (z.B. Web-Darstellung), ohne die eigentliche Anwendung zu beeinflussen.
Jetzt sind wir wieder beieinander.