Du hast da aber ein "kleines" Problem:
Und zwar wenn in der
DLL Initialisations-Abschnitte anderer Units existieren.
z.B. wenn die SysUtils oder andere Units in der
DLL eingebunden sind, dann würde der Speicher-Manager der
DLL schon vor Aufruf deiner Init-Prozedur verwendet und du würdest einfach diesen Manager mit dem anderen überschreiben.
> also es ist im "alten" Manager schon Speicher reserviert, welcher eventuell versucht wird über den "neuen" Manager zu verändern.
Wenn du nun nicht sicherstellen kannst, daß deine Änderung des Speichermanagers korrekt abläuft, dann solltest du vorher wenigstens, z.B. via GetMemoryManagerState (seit FastMM), feststellen, ob die "alte" Speicherverwaltung noch ungenutzt ist und dann entweder nicht diese ersetzen und/oder eine Fehlermeldung ausgeben.
Ach ja, warum Borland es in einer
DLL verlagert hat:
- diese
DLL wurde statisch geladen
- sie wird also schon vor der EXE geladen
und ebenfalls vor einer anderen
DLL, wo sie eingebunden wurde
- sie wird auch als Letztes wieder entladen
- und da diese
DLL immer als Erstes geladen und Letzes entladen wird, kann man ihre Speicherverwaltung ohne Probleme für alles Andere verwenden
- ein winziger Nachteil ist, daß man dann alles, was die Speicherverwaltung betrifft, in diese
DLL auslagern muß,
welches nun auch eventuell in der EXE verwendete Fehlerüberwachungen anginge ... drum hab ich auch versucht die Verwaltung der EXE in die
DLL durchzuschleifen, wärend Borlands ShareMem den Manager der
DLL in die EXE einfügt
PS: so wild ist es garnicht ... es wird nur vor dem Start der
DLL ein gemeinsamer Speicherbereich besorgt (in diesem Fall eine MMF) und dort der Speichermanager der EXE gespeichert
und der Rest st eine Prüfung, ob auch wirklich ein externer Manager vorhanden ist und nur dann wird er ersetzt und außerdem wurde auf die unterschiedlichen Manager-Verwaltungen eingegangen ... heißt, man kann die
DLL genauso mit einer Delphi7-EXE (TMemoryManager) laufen lassen, wie mit z.B. einer EXE von Delphi 2009 (TMemoryManagerEx).