Wie patcht man die classes.pas unter XE2?

[Stevie]

Für 32-bit sähe das ungefähr so aus (Unit als erstes ins Project einbinden)

Delphi-Quellcode:

unit AllocateHWndPatch;

interface

implementation

uses
  Classes,
  SysUtils,
  Windows;

function PatchedAllocateHWnd(AMethod: TWndMethod): HWND;
begin
  {...}
end;

procedure RedirectFunction(OrgProc, NewProc: Pointer);
type
  TJmpOp = packed record
    Jmp: Byte;
    Offset: Integer;
  end;
var
  JmpOp: TJmpOp;
  n: {$IF COMPILERVERSION < 23}Cardinal{$ELSE}NativeUInt{$IFEND};
begin
  JmpOp.Jmp := $E9;
  JmpOp.Offset := PByte(NewProc) - (PByte(OrgProc) + SizeOf(TJmpOp));
  if not WriteProcessMemory(GetCurrentProcess, OrgProc, @JmpOp, SizeOf(TJmpOp), n) then
    RaiseLastOSError;
end;

initialization
  RedirectFunction(@Classes.AllocateHWnd, @PatchedAllocateHWnd);

end.

[Sherlock]

Ooh! Das sieth ja genial aus, danke Stevie. Gebe das mal an den Kollegen weiter, der sich gerade beide Ohren dabei gebrochen hat, die classes.pas neu zu kompilieren.

Sherlock

[himitsu]

Eventuell muß noch die Protection von dem Speichern geändert werden, damit man da schreiben darf.
WriteProcessMemory bräuchte man eigentlich nicht, da man sich ja schon in seinem eigenen Speicher befindet und direkten Zugriff hat.

Und man darf nicht vergessen, daß man die Originalfunktion nicht mehr aufrufen kann, da dort ja die ersten Bytes überschrieben wurden.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1189104)

Eventuell muß noch die Protection von dem Speichern geändert werden, damit man da schreiben darf.
WriteProcessMemory bräuchte man eigentlich nicht, da man sich ja schon in seinem eigenen Speicher befindet und direkten Zugriff hat.

Dann müsste man mit VirtualProtect und Move arbeiten, da man ansonsten eine AV bekommt. Da erschien mir der Einzeiler mit WriteProcessMemory einfacher und er erledigt den gleichen Job.

[himitsu]

Sagen wir es mal so:

Zitat:

Delphi-Quellcode:

  if not WriteProcessMemory(GetCurrentProcess, OrgProc, @JmpOp, SizeOf(TJmpOp), n) then
    RaiseLastOSError;

Ob nun das Move eine Excepition (Zugriffsverlezung) auslöst,
oder ob man manuell eine Exception (konnte nicht schreiben) auslöst,
ist am Ende auch egal. :lol:

Und VirtualProtect braucht man doch sowieso?
Ich hoffe mal, daß WriteProcessMemory nicht einfach so in geschützte Bereiche reinschreiben kann.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1189215)

Ich hoffe mal, daß WriteProcessMemory nicht einfach so in geschützte Bereiche reinschreiben kann.

Doch, allerdings sind bestimmte Zugriffsrechte erforderlich (siehe Remarks unter WriteProcessMemory ), welche man in diesem Fall hat, da man ja im eigenen Prozess bleibt.

Ich patche damit in DSharp schon seit Monaten zur Laufzeit zahlreiche Bugs rund um die RTTI.

[himitsu]

Klar, daß man diese Recht hat. Ich meinte ja auch die Dinge, welche eventuell über VirtualProtect gesperrt sind. :wink:

[USchuster]

Zitat:

Zitat von Sherlock (Beitrag 1189103)

...Gebe das mal an den Kollegen weiter, der sich gerade beide Ohren dabei gebrochen hat, die classes.pas neu zu kompilieren.

Wo genau ist eigentlich nochmal das Problem System.Classes neu zu kompilieren?

[Bernhard Geyer]

Zitat:

Zitat von USchuster (Beitrag 1189511)

Zitat:

Zitat von Sherlock (Beitrag 1189103)

...Gebe das mal an den Kollegen weiter, der sich gerade beide Ohren dabei gebrochen hat, die classes.pas neu zu kompilieren.

Wo genau ist eigentlich nochmal das Problem System.Classes neu zu kompilieren?

Der Rattenschwanz an Units die ebenfalls neu kompiliert werden müsste.
Eigentlich dann die gesamte gelieferten VCL-Units bis auf System.pas.

[USchuster]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1189513)

Zitat:

Zitat von USchuster (Beitrag 1189511)

Zitat:

Zitat von Sherlock (Beitrag 1189103)

...Gebe das mal an den Kollegen weiter, der sich gerade beide Ohren dabei gebrochen hat, die classes.pas neu zu kompilieren.

Wo genau ist eigentlich nochmal das Problem System.Classes neu zu kompilieren?

Der Rattenschwanz an Units die ebenfalls neu kompiliert werden müsste.
Eigentlich dann die gesamte gelieferten VCL-Units bis auf System.pas.

Und genau das kann ich nicht nachvollziehen, denn das Neukompilieren von anderen Units ist nur bei Interface Änderungen notwendig und die sollte man nicht machen.

Die RTL, zu der auch System.Classes gehört, kann man mittels $(BDS)\source\rtl\buildrtl.bat neu erstellen, aber das muss man gar nicht.

Warum geht denn nicht prinzipiell folgendes:
1. System.Classes.pas in ein Testprojekt tun
2. dieses in Debug und Release Konfiguration kompilieren für die gewünschte Platform
3. System.Classes.dcu in $(BDSLIB)\<platform>\Release und $(BDSLIB)\<platform>\Debug sichern und austauschen durch DCUs aus 2.
4. $(BDS)\source\rtl\common\System.Classes.pas sichern und durch Version aus Testprojekt austauschen, damit die Zeilen bei Debuggen mit Debug-DCUs passen

Ich mache 2. etwa so auf der Kommandozeile (statt $(BDSBIN) und $(BDSLIB) verwende ich die tatsächlichen Pfade):
$(BDSBIN)\DCC32.EXE -$D+ -$O- System.Classes.pas --no-config -u$(BDSLIB)\win32\debug -N0Debug
$(BDSBIN)\DCC32.EXE -$D- -$O+ System.Classes.pas --no-config -u$(BDSLIB)\win32\release -N0Release