ShareMem ohne ShareMem.dll und Co.

**himitsu**

Hier habt ihr noch ein kleines "Abfallprodukt" meines Hier im Forum suchen

Es schleift praktisch jeden Speichermanager von einer Delphi-EXE in eine Delphi-DLL durch.

Dabei ist es egal, ob nun der Standard-SpeicherManager verwendet wird oder ein Anderer.

Und es wird auch keine zusätzliche Datei benötigt, wie es bei Delphi-Referenz durchsuchen

ShareMem der Fall ist.

Systemvorausstzung:
die DLL (bzw. die himiSM.pas) benötigt mindestens ein Delphi, wo TMemoryManagerEx verfügbar ist
und die EXE sollte vermutlich mindestens mit Delphi 4 erstellt werden.

Diese Unit muß in die DLL aufgenommen werden:
> erster Uses-Eintrag in deren .DPR

zusammenfalten · markieren

Delphi-Quellcode:

			Unit himiSM_DLLInit;

Interface

Implementation

  {$WARN SYMBOL_DEPRECATED OFF}

  Uses Windows;

  Var Name:    Array[0..29] of AnsiChar = 'himiShareMem_xxxxxxxxxxxxxxxx'#0;

    i, i2:     Integer;

    Map:       THandle;

    View:      PAnsiChar;

    MemMgr:    TMemoryManager;

    MemMgrEx:  TMemoryManagerEx;

    OldMemMgr: TMemoryManagerEx;

Initialization

  GetMemoryManager(OldMemMgr);

  i2 := GetCurrentProcessId;

  For i := 15 downto 0 do Begin

    If Byte(i2 and $0F) <= 9 Then Name[i + 13] := AnsiChar((i2 and $0F) + Ord('0'))

    Else Name[i + 13] := AnsiChar((i2 and $0F) - 10 + Ord('A'));

    i2 := i2 shr 4;

  End;

  Map  := OpenFileMappingA(FILE_MAP_READ, False, @Name);

  View := MapViewOfFile(Map, FILE_MAP_READ, 0, 0, 0);

  If (Map <> 0) and Assigned(View) Then

    If Assigned(PPointer(View + 3 * SizeOf(Pointer))^) Then Begin

      CopyMemory(@MemMgrEx, View, SizeOf(MemMgrEx));

      SetMemoryManager(MemMgrEx);

    End Else Begin

      CopyMemory(@MemMgr, View, SizeOf(MemMgr));

      SetMemoryManager(MemMgr);

    End;

  UnmapViewOfFile(View);

  CloseHandle(Map);

Finalization

  SetMemoryManager(OldMemMgr);

End.

Und zum Laden der DLL wird dann "einfach" nur noch statt LoadLibrary das LoadLibrarySM verwendet

zusammenfalten · markieren

Delphi-Quellcode:

			Function LoadLibrarySM(LibFileName: PChar): HMODULE;

  Var Name: Array[0..29] of AnsiChar;

    i, i2:  Integer;

    Map:    THandle;

    View:   PAnsiChar;

    MemMgr: {$IF Declared(TMemoryManagerEx)}TMemoryManagerEx{$ELSE}TMemoryManager{$IFEND};

    Error:  HRESULT;

  Begin

    Error := ERROR_INVALID_FUNCTION;

    Name  := 'himiShareMem_xxxxxxxxxxxxxxxx'#0;

    i2 := GetCurrentProcessId;

    For i := 15 downto 0 do Begin

      If Byte(i2 and $0F) <= 9 Then Name[i + 13] := AnsiChar((i2 and $0F) + Ord('0'))

      Else Name[i + 13] := AnsiChar((i2 and $0F) - 10 + Ord('A'));

      i2 := i2 shr 4;

    End;

    Map  := CreateFileMappingA(INVALID_HANDLE_VALUE, nil, FILE_MAP_READ, 0, 6 * SizeOf(Pointer), @Name);

    View := MapViewOfFile(Map, FILE_MAP_READ or FILE_MAP_WRITE, 0, 0, 0);

    _DLL := 0;

    Try

      If (Map <> 0) and Assigned(View) Then Begin

        GetMemoryManager(MemMgr);

        ZeroMemory(View, 6 * SizeOf(Pointer));

        CopyMemory(View, @MemMgr, SizeOf(MemMgr));

        Result := LoadLibrary(LibFileName);

        Error  := GetLastError;

      End Else Begin

        Result := 0;

        Error  := ERROR_ACCESS_DENIED;

      End;

    Finally

      UnmapViewOfFile(View);

      CloseHandle(Map);

      SetLastError(Error);

    End;

  End;

Info:
Es macht übrigens auch nichts aus, wenn in einem von Beiden (EXE und DLL) keiner der Codes eingebaut ist ... in diesem Falls wird einfach nur keine Umleitung eingerichtet.

Also wenn die DLL mit deim "einfachen" LoadLibrary geladen wird oder die DLL den Code nicht enthält.

Anhang:
himiSM_DLLInit.pas * » * kommt in die DLL
himiSM_LoadLibrary.pas * » * kommt in die EXE (oder eine andere DLL) und enthällt die LoadLibrarySM

**Apollonius**

Gute Idee!

Nach LoadLibrary könntest du noch GetLastError speichern und am Ende der Funktion wieder setzen (die Funktionen im Finally-Block könnten sonst am Fehlercode herumpfuschen).

**himitsu**

Stimmt, hab ich garnicht dran gedacht

(kommt davon, wenn man im eigenem Code eine Exception wirft und es extra hierfür mit als eigenständige Funktion umbaut)

Und schon geändert

**igel457**

Es geht auch einiges einfacher, auch wenn dann manuell eine Funktion aufgerufen werden muss. Allerdings entstehen so auch keine "wilden" Abhängigkeiten zur Windows-API.

Dll:

zusammenfalten · markieren

Delphi-Quellcode:

			var

  old_mgr: TMemoryManagerEx;

  new_mgr: TMemoryManagerEx;

  mem_mgt: Boolean = false;

procedure InitMemMgr(mgr: TMemoryManagerEx);

begin

  if not mem_mgt then

  begin

    mem_mgt := true;

    GetMemoryManager(old_mgr);

    new_mgr := mgr;

    SetMemoryManager(new_mgr);

  end;

end;

exports

  InitMemMgr;

initialization

finalization

  if mem_mgt then

    SetMemoryManager(old_mgr);

Host:

zusammenfalten · markieren

Delphi-Quellcode:

			type

  TInitMemMgrProc = procedure(mgr: TMemoryManagerEx);

var

  proc: TInitMemMgrProc;

  handle: THandle;

  mgr: TMemoryManagerEx;

[...]

handle := LoadLibrary('foo');

@proc := GetProcAddress(handle, 'InitMemMgr');

if Assigned(proc) then

begin

  GetMemoryManager(mgr);

  proc(mgr);

end;

PS: Ich frage mich ja, warum Borland das mit einer extra DLL gelöst hat... Gibt es da einen Grund? Die DLL-Daten und somit die Pointer auf die Memorymanagement-Funktionen werden bei jedem Laden der DLL doch instanziert und somit an die aufrufende Anwendung angepasst... Gibt es da einen guten Grund?

**himitsu**

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).

**himitsu**

Hab 'nen kleinen Fehler behoben (da war noch 'ne alte Variable im Code, welche nicht mehr deklariert war)

Außerdem wurde die Unit himiSM_LoadLibrary so geändert, daß die nun auch in älteren Delphis läuft, welche noch kein TMemoryManagerEx kennen.

Und zusätzlich hab ich noch eine weitere Prozedur eingefügt.

entweder man läßt seine DLL via LoadLibrarySM

oder initialisiert Einiges mit PreLoadSM
- hier kann man dann seine DLL mit LoadLibrary laden
- allerdings bleibt dann der SharingSpeicher erhalten (sind aber nur 24 Byte)

ach ja, es gibt im Anhang auch eine kleine Demo dazu

ShareMem ohne ShareMem.dll und Co.

ShareMem ohne ShareMem.dll und Co.

Re: ShareMem ohne ShareMem.DLL

Re: ShareMem ohne ShareMem.dll und Co.

Re: ShareMem ohne ShareMem.dll und Co.

Re: ShareMem ohne ShareMem.dll und Co.

Re: ShareMem ohne ShareMem.dll und Co.

Forumregeln

himitsu Registriert seit: 11. Okt 2003 Ort: Elbflorenz 43.150 Beiträge Delphi 12 Athens	#3 Re: ShareMem ohne ShareMem.dll und Co. 13. Jun 2009, 15:51 Stimmt, hab ich garnicht dran gedacht (kommt davon, wenn man im eigenem Code eine Exception wirft und es extra hierfür mit als eigenständige Funktion umbaut) Und schon geändert Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher. my Delphi wish list : BugReports/FeatureRequests
	Zitat