Pointer oder Protected Memory ?

[paule32.jk]

Hallo,
gibt es sowas wie Protected Memory in Delphi und FPC ?
Also so, das ich mir eine globale Variable anlege, die sagen wir mal 32 Bit groß ist - egal welcher Art, weil, Daten sind im Computer ja alle samt bestehend nur aus 0 und 1, okay, jedenfalls bräuchte ich eine "nicht" platformspezifiesche Programmierlogik, bei der ich die Daten eines Datentyps; sagen wir mal BYTE in den protected Memory space kopiere/speichere, und dann an eine DLL Funktion übergeben kann, um dann den Datentyp (also den Wert aus der globalen Variable) weiterverarbeiten kann.
Dazu wird dann natürlich die passende Funktion geliefert - also die Funktion aus der DLL bekommt den Pointer auf die globale Variable (die solange gültig ist, wie das Programm läuft), so dass ich dann genau weiß, welcher Pointer wie abgearbeitet werden muss ?

Gibt es da was fertiges ?
Gerne auch kurzes Beispiel, fürs nachbauen...

[Rollo62]

Sowas in der Art, ungetested:

Verwendung von VirtualAlloc/VirtualProtect (nur Windows)

VirtualAlloc: Kann verwendet werden, um einen Speicherblock im virtuellen Adressraum eines Prozesses zu reservieren. Dieser Speicher kann dann mit spezifischen Zugriffsrechten markiert werden.

VirtualProtect: Erlaubt es, die Zugriffsrechte auf einen Speicherbereich nachträglich zu ändern (z. B. von lesbar auf nicht lesbar).

Delphi-Quellcode:

var
  ProtectedMemory: Pointer;
  Size: DWORD;
begin
  Size := 32; // 32 Bytes
  ProtectedMemory := VirtualAlloc(nil, Size, MEM_COMMIT or MEM_RESERVE, PAGE_READWRITE);
  if ProtectedMemory <> nil then
  begin
    // Daten in den geschützten Speicher schreiben
    PBYTE(ProtectedMemory)^ := 123; // Beispiel: einen Wert speichern
    
    // Zugriffsschutz ändern
    VirtualProtect(ProtectedMemory, Size, PAGE_READONLY, nil);

    // Pointer an eine DLL-Funktion übergeben
    // Beispiel: DLLFunction(ProtectedMemory);

    // Nach Nutzung: Speicher freigeben
    VirtualFree(ProtectedMemory, 0, MEM_RELEASE);
  end;
end;

Vorteile: Direkter Zugriff auf die Speicherverwaltung des Betriebssystems.
Nachteile: Plattformabhängig (nur für Windows), fehleranfällig, wenn nicht korrekt implementiert.


Eventuell geht es auch per TMemoryStream oder TBytes, ich bin jetzt nicht der DLL-Experte.

TMemoryStream: Kann zur Verwaltung von Speicherblöcken genutzt werden. Man kann den Stream lesen und schreiben,
aber den Pointer auf die Daten extrahieren, um ihn an eine DLL zu übergeben.

TBytes: Ein dynamisches Array von Bytes, das als Zwischenspeicher fungieren kann.

Delphi-Quellcode:

var
  MemoryBuffer: TBytes;
begin
  SetLength(MemoryBuffer, 32); // 32 Bytes

  // Daten in den Speicher schreiben
  MemoryBuffer[0] := 123; // Beispiel: einen Wert speichern

  // Pointer an eine DLL-Funktion übergeben
  // Beispiel: DLLFunction(@MemoryBuffer[0]);
end;

Vorteile: Plattformunabhängig, einfach zu implementieren.
Nachteile: Kein echter Schutz des Speichers (kein Schutz vor Schreibzugriffen).

[Der schöne Günther]

Ich verstehe das "protected" aus der Frage noch nicht. Was genau soll das in dem Kontext bedeuten?

[TomyN]

Meine Meinung nach kommen DLLs im 'Delphi Kosmos' eigentlich nicht vor, man muss halt manchmal auf welche zugreifen weil es nicht anders geht.
Aber eine Anwendung aus Delphi Programm + 'Delphi' DLL macht für mich eigentlich keinen Sinn.

[DeddyH]

Nicht plattformspezifisch und DLL passt irgendwie auch nicht zusammen.

[Rollo62]

Ich vermute, es geht auch um eine Kopplung von Delphi mit externen C++ DLLs in irgendeiner Form, richtig?

[paule32.jk]

auch andere Platformen unterstützen DLL Fähigkeiten (was nicht unbedingt durch den Dateinamen begrenzt sein muss).
mit Delphi kann man auch DLL oder .so Dateien erstellen.
die vorliegende DLL ist mit C++ Compiler erstellt worden (also auch nicht unbedingt begrenzt auf das Produktivsystem/Compiler-Model).

[dummzeuch]

Zitat von TomyN:

Meine Meinung nach kommen DLLs im 'Delphi Kosmos' eigentlich nicht vor, man muss halt manchmal auf welche zugreifen weil es nicht anders geht.
Aber eine Anwendung aus Delphi Programm + 'Delphi' DLL macht für mich eigentlich keinen Sinn.

Sagen wir mal sie kommen in Deinem Delphi Kosmos nicht vor.
Es gibt durchaus Anwendungsfälle für DLLs in Delphi, sei es, um bestimmte Funktionalität für Programme aus anderen Programmiersprachen zur Verfügung zu stellen oder auch nur um sie zu kapseln, ohne dabei auf Packages zurückgreifen zu müssen (was ja leider immer bedeutet, dass man die RTL- und VCL-Packages ebenfalls verwenden muss).

Aber zugegebenermaßen habe ich auch schon lange keine DLLs mehr geschrieben, weil wir intern nur Delphi als Entwicklungstool einsetzen. Bei meinem früheren Arbeitgeber war das noch anders. Da hatten wir zwei in vielen Programmen genutzte DLLs:

1. Internationalisierung via gnugettext (mittels einer DLL, die dxgettext verwendete)
2. Anmeldung und Rechteverwaltung

Beides hätte man natürlich auch in allen 3 verwendeten Programmiersprachen (Visual Basic (pre dotNET), Visual C++ und Delphi) parallel entwickeln können, aber warum sollte man?

Es gab noch Pläne für weitere DLLs, aber das war dann, nachdem ich schon neue Stelle hatte.

Heutzutage kann man evtl. auch auf DLLs zurückgreifen, wenn man von Delphi weg zu einer "moderneren", "weiter verbreiteten", "anderer Grund des Tages" Programmiersprache wechseln will, indem man Funktionalität in DLLs kapselt und diese nach und nach portiert. Ob das der beste Weg ist, ist allerdings zweifelhaft.

[dummzeuch]

Zitat von paule32.jk:

Hallo,
gibt es sowas wie Protected Memory in Delphi und FPC ?
Also so, das ich mir eine globale Variable anlege, die sagen wir mal 32 Bit groß ist - egal welcher Art, weil, Daten sind im Computer ja alle samt bestehend nur aus 0 und 1, okay, jedenfalls bräuchte ich eine "nicht" platformspezifiesche Programmierlogik, bei der ich die Daten eines Datentyps; sagen wir mal BYTE in den protected Memory space kopiere/speichere, und dann an eine DLL Funktion übergeben kann, um dann den Datentyp (also den Wert aus der globalen Variable) weiterverarbeiten kann.
Dazu wird dann natürlich die passende Funktion geliefert - also die Funktion aus der DLL bekommt den Pointer auf die globale Variable (die solange gültig ist, wie das Programm läuft), so dass ich dann genau weiß, welcher Pointer wie abgearbeitet werden muss ?

Das hört an als ginge es um eine Art von mehreren Programmen gemeinsam genutzten Speicher. Unter Windows könnte man das mit einem Memory-mapped File lösen. Aber plattformunabhängig wäre mir da nichts bekannt.

[himitsu]

Zitat von dummzeuch:

Aber plattformunabhängig wäre mir da nichts bekannt.

(File)Streams, Sockets, TCP/IP, IPC, MMF (Named oder per Handle), GlobalAlloc, VirtualAlloc (prozessübergreifend wenn nur mit PhysicalPages, aber sowas macht man nicht!!!!), ...