Zitat von
Balu der Bär:
Nein, auch mit eingebundener ShareMem bleiben die bösen Fehler am Ende.
Im Gegensatz zu Packages sind DLLs eigenständige Binaries. Sie
enthalten also ihre eigene Implementierung eines MemoryManagers[1] und wenn nicht anders angegeben enthalten sie ihre eigene Version der
RTL, aller verwendeten
Unit und eigentlich allem was Delphi zu Delphi macht.
Wenn du ein Form aus einer
DLL lädst hast du 3 Möglichkeiten.
- Du referenzierst die benötigten Packages (RTL,VCL,XXX) in Exe und DLL extern. Dadurch ist ein TObject für Echse und DLL das gleiche. Genau wie TObject und alles andere in den extern gelinkten Packages.
Das bedeutet aber, dass du die DLL immer mit der gleichen Compilerversion wie bei der Echse kompilieren musst.
- Du benutzt Interfaces.
Damit bist du kompatibel zwischen Sprachen und Delphi Versionen, da sich Interfaces in Delphi generell an COM-Pflichten halten und somit zwangläufig kompatibel sind.
Du kannst damit auch easy die Abhängigkeit auf ShareMem los werden. Indem du anstatt Strings, WideStrings nimmst.
WideString werden von Windows selbst verwaltet.
IMHO sind Interfaces in Delphi32 fast immer die netteste Art Funktionalität bereit zu stellen.
Dank autom. Referenzzählung muss sich der konsumierende Code auch nicht mehr mit widerlichen try-finally Blöcken ärgern. 
- Du gibst nur ein Handle auf dein Fenster zurück und arbeitest nur mit API-Funktionen.
Dadurch gibt es keine Vermischung von unterschiedlichen Implementierungen der RTL.
Verion1 ist die, die am einfachten ist. Aber sie zwingt dich mindestens
RTL und
VCL extern mitzugeben.
Lösung 2 erfordert einen Wrapper, der ein Interface implementiert. Aber nach diesem Mini-Schnipsel bist absolut unabhängig und kannst auch D7 kompilierte DLLs mit 2006 benutzen und vice versa.
Lösung 3 ist
IMHO absolut furchtbar, auch wenn die
WinAPI-Fritzen da sicherlich anderer Meinung wären.
[1]den Punkt hast du mit ShareMem schon gelöst