RTL Fehler beheben - System.pas

[arcticwolf]

Wie kann ich Änderungen an der RTL von Delphi vornehmen?

Ich denke ich habe eine Fehler in der RTL, genauer gesagt in der System.pas, gefunden und würde den gerne beheben.

Code:

Delphi 11.3
"C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\sys\System.pas"

Zumindest erst einmal testweise um zu sehen ob danach die Funktion einwandfrei läuft. Allerdings sind die Dateien der RTL alle schreibgeschützt und Delphi/Windows weigert sich meine Änderungen zu übernehmen. Gibt es da einen best practice Weg wie ich Delphi dazu bewegen kann mit meiner geänderten system.pas zu kompilieren?

[himitsu]

Erstmal: Die RTL/VCL zu kompilieren kann inkompatibilitäten erzeugen,
vor allem mit vorkompilierten FremdPackages.

Außerdem kann man nur die RTL neu kompilieren,
da von der VCL leider viele Sourcen für die IDE fehlen.



Die System.pas und SysInit.pas sind ein kleiner Sonderfall.

https://chuacw.ath.cx/development/b/...in-delphi.aspx
https://de.comp.lang.delphi.misc.nar...im-kompilieren
https://www.delphipraxis.net/90085-s...mpilieren.html


per se gibt es aber inzwischen ein paar Hilfsmittel (ich weiß nur nicht, ob die System.pas darin enthalten ist)
C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\buildrtl.bat
C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\androiddex\java\fmx\build-all.bat
C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\androiddex\java\fmx\build-classesdex.bat
C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\androiddex\java\fmx\build-interfaces.bat

Außerdem werden hier nur die DCU aktualisiert, aber die BPL nicht, also in der IDE oder wenn du mit Laufzeitpackages kompilieren willst, dann hast'e Pech.

schau auch mal in die C:\Program Files (x86)\Embarcadero\Studio\22.0\source\rtl\BuildRTLG roup.groupproj , BuildWinRTL.dproj und RTL.Build.targets
ob dort auch Debug und Release kompiliert wird ... nur Eines von Beiden wäre auch bissl blöd.

[Uwe Raabe]

Um was für einen Fehler handelt es sich denn? Vielleicht gibt es ja schon eine Lösung dafür?

[arcticwolf]

Es geht um das Verhalten von "Write".

Prinzipiell gilt:

Delphi-Quellcode:

i : Integer = 567;
d : Double  = 567.89;

Write(i:5)     -> 'xx567'
Write(d:10:2)  -> 'xxxx567.89'

Wobei x hier für die führenden Leerstellen steht.

Das funktioniert aber nur solage die AlternateWriteUnicodeStringProc aus der System.pas nicht aktiviert ist.

Wenn AlternateWriteUnicodeStringProc aktiviert ist, dann liefert _WriteUString an die AlternateWriteUnicodeStringProc bei Integer-Werten einen String ohne führende Leerstellen.

Write(i:5) -> '567'

--------------------------------------

Der Fehler liegt in der _WriteUString und/oder in der _WriteLong

Delphi-Quellcode:

function _WriteUString(var t: TTextRec; const s: UnicodeString; width: Integer): Pointer;
var
  i: Integer;
  A: _AnsiStr;
begin
  if s = '' then
    Result := _WriteSpaces(t, width )
  else
  begin
    if t.CodePage = 0 then TryOpenForOutput(t);
    if t.CodePage = CP_UTF16 then // Output is UTF16
    begin
      i := Length(s);
      _WriteSpaces(t, width - i);
      Result := _WriteBytes(t, s[Low(string)], i*sizeof(WideChar));
    end
    else
    begin
      if assigned(AlternateWriteUnicodeStringProc) then
        Result := AlternateWriteUnicodeStringProc(t, s)
      else
      begin
        _LStrFromUStr(A, s, t.CodePage);
        i := Length(A);
        _WriteSpaces(t, width - i);
        Result := _WriteBytes(t, A[Low(string)], i);
      end;
    end;
  end;
end;

Delphi-Quellcode:

function _WriteLong(var t: TTextRec; val, width: Integer): Pointer;
var
{$IFNDEF NEXTGEN}
  S: string[31];
{$ELSE}
  S: _ShortStr;
{$ENDIF}
begin
  Str(val:0, S);
  Result := _WriteString(t, S, width);
end;

Korrekt wäre in _WriteLong

Delphi-Quellcode:

  Str(val:width, S);

Oder aber in _WriteUString könnte der Fehler wie folgt behoben werden.

Delphi-Quellcode:

      if assigned(AlternateWriteUnicodeStringProc) then
        Result := AlternateWriteUnicodeStringProc(t, s.PadLeft(width))
      else

In Abweichung zu _WriteLong liefert zum Beispiel _Write2Ext

Delphi-Quellcode:

function _Write2Ext(var T: TTextRec; Val: Extended; Width, Prec: Integer): Pointer;

den korrekten String mit führenden Leerstellen an _WriteUString, sodass der Fehler dort dann nicht zum tragen kommt.

[himitsu]

Klar, zu verraten, was das Problem ist .... stell dir mal vor andere würden dir sagen können joar/nöööö/hmmmm/....



Ach ja, ....

früher konnte man das Schreibgeschützt mal wieder deaktivieren (Editor-KontextMenü, bzw. unten in der Statusleiste des Editors)
Aber Speichern knallt natürlich dennoch. (außer man startet Delphi als Admin)

Oder einfach die Änderungen mit einem anderen editor (als Admin).

Oder die Datei wo anders speichern und dann im Explorer rüber kopieren. (da fragt dann das UAC)



Aber alles egal, denn Der Kompiler nimmt (standardmäßig) niemals diese PAS.
* Delphi-Quellcodes sind nur im Suchpfad des Editors (z.B. für den Debugger)
* nur die vorkompilierten DCUs sind im Suchpfad für den Compiler
* und wenn man mit Packages kompiliert, dann wird nur die BPL genommen (rtl280.bpl)




Die System.pas ins Programmverzeichnis legen hilft auch nur bedingt, denn die anderen vorkompilierten Delphi-DCUs gehen ja quasi dennoch auf die originale System-Unit. (denk ich mal)

[Union]

Code:

SET BDSDIR=C:\Program Files (x86)\Embarcadero\Studio\20.0
REM RELEASE
"%BDSDIR%\bin\dcc32.exe" -$C- -$D- -$L- -$O- -$R+ -$W+ -CG -H -M -Q -V- -W^ -Z -Y --no-config System.pas
REM DEBUG
"%BDSDIR%\bin\dcc32.exe" -$C- -$D+ -$L- -$O- -$R+ -$W+ -CG -H -M -Q -V- -W^ -Z -Y -NUdebug --no-config System.pas

Es entstehen jeweils System, Sysinit. Die Pfade sind ggf. anzupassen, Beispiel ist für 10.3.
Generell rate ich DRINGEND davon ab. Ich habe das inzwischen über Hooks / Adresspatch gelöst (@_Writestring <- @EigenesWritestring).

[arcticwolf]

Da bin ich wohl nicht ganz alleine mit meinem Problem. Ich habe jedoch nichts bei Embarcadero gefunden, dass jemand den Fehler schon mal gemeldet hätte!?

Zitat:

Zitat von Union (Beitrag 1525013)

Generell rate ich DRINGEND davon ab.

Ja, ich habe auch nicht wirklich Lust da rumzupfuschen und am Ende womöglich andere Fehler zu provozieren.

Für mich persönlich ist das keine Problem ich habe dafür auch Workarrounds.

Delphi-Quellcode:

Write(IntToStr(i).PadLeft(5));

Oder was auch immer.

Aber bei meiner "Console Library" kann das zu Problemen führen, wenn alter Legacy-Code damit compiliert wird der eben

Code:

Write(i:5)

o.ä. enthält. Und ich kann nicht jedem Nutzer sagen, dass er sein Delphi patchen soll/muss, wenn er meine Library verwenden möchte.

Zitat:

Ich habe das inzwischen über Hooks / Adresspatch gelöst (@_Writestring <- @EigenesWritestring).

Das hört sich interessant an, wie genau funktioniert das? Wie kann ich mich da dazwischen hängen?

[himitsu]

Zitat:

Write(i:5)

Das hier ist ja auch noch CompilerMagic, wo der Compiler das eine "Write" auf einen/mehrere einzelne Befehle verteilt/umleitet.


Im Grunde erstellt man eine neue Funktion, mit dem gewünschten Inhalt.

Dann werden die ersten Bytes (meistens 5) in der originalen Funktion überschrieben, z.B. mit einem JMP (Assembler-Jump) zur neuen Funktion.
(vorher noch den Schreibschutz des Arbeitsspeichers, an dieser Stelle deaktivieren und nachher wieder herstellen)

Es gibt dafür auch mehrere Hook-Frameworks/Funktionen/..., von verschiedensten Leuten, falls man es nicht manuell machen will.

Aufwändiger wird es z.B. bei "externen" Funktionen der WinAPI, wo man stattdessen die Importtabelle (Zeiger) umschreiben kann, anstatt die Funktion selbst zu überschreiben. (muß man nur aufpassen, wenn man auch noch andere DLLs/Packages hat, die auch darauf zugreifen sollen)
Oder eben auch, wenn man selber mit Laufzeitpackages arbeitet, dann das sind ja auch nur DLLs, wo @DieGewünschteFunktion auf die ImportTabelle zeigt (welche aus vielen JMP-Befehlen besteht) und eben nicht direkt auf die Funktion.

[Union]

Zitat:

Zitat von arcticwolf (Beitrag 1525023)

Das hört sich interessant an, wie genau funktioniert das? Wie kann ich mich da dazwischen hängen?

1. Adressen der alten und neuen Funktion referenzieren (z.b. @System._writestring, @MyUnit.MyWriteString)
2. offset ermitteln (Integer(@MyUnit.MyWriteString) - Integer(@System._writestring) - 5). Die 5 sind der JMP Befehl sowie die vier Byte des Pointers.
3. $E9 + (offset and 255) + ((offset shr 8) and 255) + ((offset shr 16)) and 255 + ((offset shr 24) and 255) bilden. Das ergibt dann ein JMP rel32 auf die neue Funktionsadresse
4. Diese Bytefolge an die Adresse der alten Funktion setzen (move)

Den Aufruf in die initialization setzen, oder wenn das zu spät ist eine statische Klasse erstellen die das im class constructor macht.

Siehe auch https://c9x.me/x86/html/file_module_x86_id_147.html

[Stevie]

Hab ein paar Runtime Patches in Spring4d - kann man sich hier angucken (auch, wie das für x64 funktioniert, allerdings nur unter Windows so machbar)
Wie man die Adresse von ansonsten nicht referenzierbaren Funktionen aus System.pas bekommt, kann man hier auf Stackoverflow nachlesen.
In ganz seltenen Fällen kommt man nicht direkt an eine Funktion, wenn sie nur im Implementationteil einer Unit ist, da muss man sich dann mit nem bytecode Scan helfen - das findet man auch im oben verlinkten Sourcecode.

[Union]

Stefan, geil! Du hast Sogar die virtual Jumps ($25FF) gehandelt!

[Stevie]

Zitat:

Zitat von Union (Beitrag 1525084)

Stefan, geil! Du hast Sogar die virtual Jumps ($25FF) gehandelt!

Ehre, wem Ehre gebührt, das hat mir Andreas Hausladen mal vor Jahren beigebracht 8-)

[arcticwolf]

Vielen Dank Stefan!

Es ist tatsächlich so, dass sich die Funktionen aus der System.pas, wie zum Beispiel "_WriteLong" oder "_WriteString", nicht direkt aufrufen lassen. Also habe ich es wie folgt versucht und das scheint auch zu funktionieren.

Delphi-Quellcode:

function GetWriteLongAddress: Pointer;
asm
  {$ifdef CPU64}
    mov rax,offset System.@WriteLong
  {$else}
    mov eax,offset System.@WriteLong
  {$endif}
end;

function GetWriteStringAddress: Pointer;
asm
  {$ifdef CPU64}
    mov rax,offset System.@WriteString
  {$else}
    mov eax,offset System.@WriteString
  {$endif}
end;

Ich möchte einen Fehler in der Funktion _WriteLong korrigieren:

Delphi-Quellcode:

function _WriteLong(var t: TTextRec; val, width: Integer): Pointer;
var
  S: _ShortStr;
begin
  // Str(val:0, S);     Fehler
  Str(Val:width, S); // Korrigiert
  Result := _WriteString(t, S, width);
end;

Im Anschluß muss der richtige Wert wieder an die nicht direkt aufrufbare Funktion _WriteString aus der System.pas übergeben werden. Also dachte ich, nichts leichter als das und habe folgendes versucht:

Delphi-Quellcode:

Type TFuncWriteString = Function(var t: TTextRec; const s: ShortString; width: Integer) : Pointer;

Const FuncWriteString : TFuncWriteString = Nil;

// Fixed Function WriteLong form System.pas
function WriteLongFixed(var t: TTextRec; val, width: Integer): Pointer;
var
  S: ShortString;
begin
  Str(val:width, S);
  Result := FuncWriteString(t, S, width);
end;

procedure RedirectFunction(OrgProc, NewProc: Pointer);
type
  TJmpBuffer = packed record
    Jmp: Byte;
    Offset: Integer;
  end;
var
  n: UINT_PTR;
  JmpBuffer: TJmpBuffer;
begin
  JmpBuffer.Jmp := $E9;
  JmpBuffer.Offset := PByte(NewProc) - (PByte(OrgProc) + 5);
  if not WriteProcessMemory(GetCurrentProcess, OrgProc, @JmpBuffer, SizeOf(JmpBuffer), n) then
    RaiseLastOSError;
end;

procedure ApplyPatch;
begin
  FuncWriteString := GetWriteStringAddress;
  RedirectFunction(GetWriteLongAddress, @WriteLongFixed);
end;

Bei folgender Zeile wirft der Compiler den Fehler "E2009 Inkompatible Typen: 'Liste der Parameter ist unterschiedlich'" aus.

Delphi-Quellcode:

FuncWriteString := GetWriteStringAddress;

Delphi-Quellcode:

    // Aus System.pas
    function _WriteString(var t: TTextRec; const s: _ShortStr; width: Integer): Pointer;
    begin
      Result := _WriteLString(t, s, width);
    end;

    // Meine Deklaration (siehe oben)
    Function(var t: TTextRec; const s: ShortString; width: Integer) : Pointer;

Wobei _ShortStr nur ein Alias für ShortString ist. Ergo sehe ich das Problem nicht!?

Delphi-Quellcode:

FuncWriteString := @GetWriteStringAddress;

Funktioniert (lässt sich compilieren) und im Debug-Modus springt Delphi dann auch in meine Funktion WriteLongFixed (Redirect funktioniert also). Der Aufruf von FuncWriteString wird dann jedoch mit einem IoError 103 quittiert.

Wie muss ich die Funktion _WriteString aus der System.pas richtig aufrufen/addresieren, damit das funktioniert? Ich stehe auf dem Schlauch.

[himitsu]

Oder dieses komische Zeugs lassen wie es ist
und statt dieser "uralten" Pascal-Funktionen z.B. den TStringStream oder TFile.WriteAllText oder TStringList oder TFileStream oder oder oder ... verwenden. :duck:


Jupp, _ShortStr ist ein "Ersatz" in der System.pas, da es in den Mobilen Compilern (iOS, Android) keinen ShortString gibt/gab.

[arcticwolf]

Zitat:

Oder dieses komische Zeugs lassen wie es ist

Das funktioniert leider nicht wenn man alten "Legacy-Code", mit meiner "Playcom Console Library" compilieren möchte, welcher System.Write oder System.Writeln verwendet. Wenn man nicht den kompletten Legacy-Code umschreiben möchte, dann müssen solche Funktionen richtig arbeiten.

Ich habe das Problem jetzt umschifft, in dem ich den Patch auf die Procedure System._WriteUString anwende und somit nicht gezwungen bin eine weitere Funktion aus der System.pas aufzurufen.

Lange Rede kurzer Sinn. Ich habe, Dank Eurer Hilfe und mit dem Code von Stefan, das Problem gelöst und die System.pas gepatched. Wer an der Lösung interessiert ist kann diese unter folgendem Link finden:

https://github.com/playcom-de/Consol...ly.Patches.pas

[Stevie]

Delphi-Quellcode:

procedure ApplyPatch;
begin
  @FuncWriteString := GetWriteStringAddress;
  RedirectFunction(GetWriteLongAddress, @WriteLongFixed);
end;