String mit .dll ohne borlndmm.dll

[berens]

Hallo zusammen,
eigentlich muss ich mich ja schämen mit > 20 Jahren Delphi-Erfahrung so einen Thread zu schreiben, aber jeder hat bei irgendeinem Thema seine Schwachstellen, und zu meinen gehören eindeutig Pointer.

Situation und Hintergrund (für das eigentliche Thema nicht direkt relevant):
Ich verwende JWSCL um eine Access-Control-List zu erstellen, welche Active-Directory-Gruppe bei mir in der Software "was" machen darf. Der Editor kommt von Windows, die Rechte kann ich individuell benennen, die ACL liegt mir als einfach weiterzuverwendender String vor, und die Prüfung darf der-und-der das-und-das ist echt super einfach. Dazu habe ich auch ein Tutorial geschrieben ( https://www.delphipraxis.net/184812-...verwenden.html ).
Das Problem ist, dass JWSCL viel viel viel zu Umfangreich ist, und ich es mit den aktuellen Delphi Versionen immer weniger am Laufen halten kann, weil bei den einzelnen Prozeduraufrufen dann irgendwelche Variablentypen etc. nicht passen - bei Prozeduren/Funktionen, die NICHTS mit der o.g. Aufgabe zu tun haben. Leider kann ich auch nicht die "nur ACL relevanten" Sachen rausziehen, weil die Abhängigkeiten in dem JWSCL Projekt so unfassbar tief/groß sind, dass das de facto nicht möglich ist.
Mit Delphi 10.4 habe ich alleine nach einer Neuinstallion wieder 2 Tage gebraucht, bis ich mein leeres JWSCL-Beispielprojekt wieder compilieren konnte, weil die Bibliotheksreihenfolge falsch war etc.etc.
Die Idee besteht also darin, jetzt einmal eine .dll zu erstellen, und auch in zukunft nur mit dieser zu arbeiten. Rein geht string, raus kommt Bool: Benutzer darf? Ja oder Nein. Eigentlich ganz einfach. Ja, das ganze ist dann nicht zukunftssicher etc, aber das nun mal außen vorlassen. Es geht drum, dass ich alles, was mit JWSCL zu tun hat, aus meinem Kernprojekt raushaben möchte!

Problemstellung generell
Ich möchte die BORLNDMM.DLL nicht mitliefern. Einfach ... weil halt. Im Hauptprojekt soll es dann in einer eigenen Unit nur diese einfachen Prozeduren geben wie: BearbeiteACL(var _ACL: string) und DarfBenutzer(_ACL: string; _BenoetigtesRecht: integer): Boolean. Keine Einbindung der JWSCL etc.
In der .dll gibt es dann die Pendants, die das tatsächlich mit JWSCL umsetzen, und die Ergebnisse zurückliefern. Das ist generell kein Problem und auch hier nicht das Thema.

Problemstellung speziell
Ich habe mich schon "ein wenig" zu dem Thema eingelesen, und verstehe dank ChatGPT auch das Problem, warum man nicht "mal eben" einen String an eine .dll übergeben kann, oder warum kein String aus einer .dll (ohne die BORLNDMM.DLL) zurückkommen kann: Die .dll kann bei -nun größeren Strings- nicht mal eben so den Speicherbereich des Hauptprogramms verändern, in dem der String eigentlich gespeichert ist, und wenn ein String als Result aus der .dll zurückgegeben wird, wird der Speicher mit Ende des Prozedur in der .dll eigentlich auch schon wieder freigegeben. So ungefähr oder ähnlich ist das Problem.

Die Lösung mit PAnsiChar ist unkompliziert, weil die .dll nur mitbekommt "An dieser Stelle im RAM beginnt ein AnsiString", da kann gibt es kein Problem mit dem vergrößern/verkleinern des Arbeitsspeichers des Hauptprogramm. Die .dll bekommt einfach einen PAnsiChar für den Input, den Output und eine Bool-Variable als Platzhalter für einen Rückgabewert, ob die Aktion erfolgreich war.

Das Problem ist nun natürlich, dass ich als Programmierer für das Speichermanagement zuständig bin. Falls an dem pAnsiString nämlich kein Null-Terminator hängt, kann es sein, dass ein BufferOverflow etc. stattfindet, und aufeinmal lustige Daten meines -oder eines anderen Programmes- in dem pAnsiString "stehen" oder große Bereiche des RAMs einfach komplett überschrieben werden, weil die Angabe fehlt "wie lang" denn nun wirklich dieser AnsiString ist.

Das folgende Programm habe ich mit viel hin- und her mit ChatGPT zusammengebastelt, und ich bin sehr unzufrieden damit.
Eigentlich sollte folgendes passieren:
1) Aufruf der Prozeduren ganz normal mit "string" Parametern.
2) Umwandeln der Strings in pAnsiChar
3) Aufruf der .dll-Prozeduren mit pAnsiChar
4) Umwandlung innerhalb der .dll wieder in string
5) Verarbeitung der Strings innerhalb der .dll
6) Rückumwandlung der Ergebnisse in pAnsiChar
7) Hauptprogramm wandelt Rückgabewert pAnsiChar in string um, und gibt diesen zurück.

Wenn ich jetzt das Thema richtig verstanden habe, muss ich mir als Programmierer schon vorher eine fixe Grenze überlegen, die ein gefüllter String maximal haben darf. Der .dll sollte ich dann (besser als das u.g. Beispiel) die Input-Variable übergeben, zusammen mit der Input-Größe des pAnsiChar, sowie eine Output-Variable (10'000 oder 65'000 Zeichen oder was auch immer) und deren Größe, die bereits initialisiert ist.

In der .dll sollte ich dann Prüfen, ob Input und Output zu den übergebenen Größen passen, dann in Strings umwandeln, und Rückzus, wenn ich das Ergebnis vom OutputString in die Output pAnsiChar-Variable speichere muss ich halt schauen, dass nicht über die X-Zeichen maximale Größe drübergeschrieben wird, und dass am Ende der tatsächlichen Nutzdaten (wahrscheinlich nur so 250 Zeichen?) dann auch wirklich der Null-Terminator steht.

Im Hauptprogramm wird ja dann über den Typcast "reversedStr := string(outputAnsi);" aller unnötiger Ballast entfernt, und die z.B. 65kb Arbeitsspeicher sind nur für die Dauer des .dll-Aufrufs tatsächlich blockiert(?).

Sehe ich das generell richtig, was ist zu beachten, wie würdet ihr das lösen?

Delphi-Quellcode:

unit uHauptprogramm;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ExtCtrls;

type
  TForm1 = class(TForm)
    LabeledEdit1: TLabeledEdit;
    LabeledEdit2: TLabeledEdit;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

  procedure ReverseString(input: PAnsiChar; var output: PAnsiChar; var success: Boolean); stdcall; external 'pDLL.dll';
var
  Form1: TForm1;

implementation

{$R *.dfm}


const
  MAX_STRING_LENGTH = 10000;


procedure TForm1.Button1Click(Sender: TObject);
var
  inputStr, reversedStr: string;
  inputAnsi, outputAnsi: PAnsiChar;
  success: Boolean;
begin
  try
    inputStr := LabeledEdit1.Text;

    if Length(inputStr) > MAX_STRING_LENGTH then
    begin
//      Writeln('Der eingegebene String ist zu lang.');
      Exit;
    end;

    inputAnsi := PAnsiChar(AnsiString(inputStr));
    GetMem(outputAnsi, MAX_STRING_LENGTH + 1); // Speicherzuweisung für den outputAnsi
    try
      ReverseString(inputAnsi, outputAnsi, success);

      if success then
      begin
        reversedStr := string(outputAnsi); // Konvertierung von PAnsiChar nach string
        LabeledEdit2.Text := reversedStr;
      end
      else
      begin
//        Writeln('Ein Fehler ist aufgetreten.');
      end;
    finally
      FreeMem(outputAnsi);
    end;

  except
    on E: Exception do
    begin
//      Writeln(E.ClassName, ': ', E.Message);
    end;
  end;
end;
end.

Delphi-Quellcode:

library pDLL;

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss die erste
  Unit in der USES-Klausel Ihrer Bibliothek UND in der USES-Klausel Ihres Projekts
  (wählen Sie 'Projekt-Quelltext anzeigen') sein, wenn Ihre DLL Prozeduren oder Funktionen
  exportiert, die Strings als Parameter oder Funktionsergebnisse übergeben. Dies
  gilt für alle Strings, die an oder von Ihrer DLL übergeben werden, auch für solche,
  die in Records und Klassen verschachtelt sind. ShareMem ist die Interface-Unit zur
  gemeinsamen BORLNDMM.DLL-Speicherverwaltung, die zusammen mit Ihrer DLL
  weitergegeben werden muss. Übergeben Sie String-Informationen mit PChar- oder ShortString-Parametern, um die Verwendung von BORLNDMM.DLL zu vermeiden.
 }

uses
  AnsiStrings;

{$R *.res}

const
  MAX_STRING_LENGTH = 10000;

function MyStrReverse(const S: AnsiString): AnsiString;
var
  P1, P2: PAnsiChar;
  Temp: AnsiChar;
  Len: Integer;
begin
  Len := Length(S);
  SetLength(Result, Len);

  P1 := PAnsiChar(S);
  P2 := @Result[Len];
  while Len > 0 do
  begin
    Temp := P1^;
    P1^ := P2^;
    P2^ := Temp;

    Inc(P1);
    Dec(P2);
    Dec(Len);
  end;
end;


procedure ReverseString(input: PAnsiChar; var output: PAnsiChar; var success: Boolean); stdcall; export;
var
  inputStr, reversedStr: AnsiString;
begin
  success := False;

  // Sicherstellen, dass der Zeiger gültig ist
  if input = nil then
    Exit;

  try
    inputStr := AnsiString(input);

    // Überprüfen, ob die Eingabe sicher zu handhaben ist
    if Length(inputStr) > MAX_STRING_LENGTH then
      Exit;

    reversedStr := MyStrReverse(inputStr);

    // Speicher für den Ausgabe-String zuweisen
    GetMem(output, Length(reversedStr) + 1);
    ansistrings.StrPCopy(output, reversedStr);

    success := True;
  except
    // Hier könnte ein Fehlerprotokoll hinzugefügt werden
  end;
end;

exports
  ReverseString;

begin
end.

Achtung: Ja, der Code hat noch viele Probleme die mir bekannt sind, es geht mehr um's Prinzip als jetzt in dieser Demo um die 100% richtige Speicherverwaltung.

Alternativ: Einfachere Möglichkeit zum Transfer von Strings in .dlls?

Zitat:

Memory Leak: In Ihrer DLL-Prozedur ReverseString haben Sie mit GetMem Speicher für output zugewiesen, aber dieser Speicher wird nie freigegeben. Dies führt zu einem Memory-Leak. Sie sollten in Ihrer Hauptanwendung diesen Speicher mit FreeMem wieder freigeben, nachdem Sie die Rückgabe aus der DLL verarbeitet haben.

Möglicher Zugriff auf ungültigen Speicher: In der Hauptanwendung haben Sie GetMem für outputAnsi aufgerufen und dann diesen Zeiger an die DLL weitergegeben. In der DLL haben Sie dann erneut Speicher für output zugewiesen. Das führt dazu, dass der ursprüngliche in der Hauptanwendung zugewiesene Speicher "verloren" geht und nie freigegeben wird.