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.