Wie patcht man die classes.pas unter XE2?

[Sherlock]

Wegen des altbekannten Bugs 21771 muss ich nun auch die classes.pas von XE2 anpassen. Nur...seit 2007 hat sich da wohl etwas getan, denn die Änderungen wirken sich gar nicht aus. Was muss ich tun, damit "meine" classe.pas verwendet nicht, und nicht die fehlerhafte aus der Auslieferung?

Sherlock
-der nochmal kräftig auf das "linke Hand weiss nicht was die Rechte tut" Problem bei Emba schimpft

[Bernhard Geyer]

Funktionieren die Hooks der TNT-Utilities zum Hooken von VCL-Funktionen den noch?

[Sherlock]

Ähm...Du stellst Fragen...ich behaupte mal folgendes: Keine Ahnung?!
Was machen die TNT-Utilities? wie helfen die beim regulären erzeugen/freigeben von ActiveX-Objekten?

Der Vollständigkeit halber hier noch der Link zu der Geschichte unter D2007: http://www.delphipraxis.net/129713-p...erhindern.html

Sherlock

[himitsu]

Rufst du selber diese Funktion auf?

Wenn ja, dann mach das einfach nicht und erzeug dir selber ein MessageOnlyWindow.

[jaenicke]

Also in XE und XE2 ist der verlinkte Bug aus der QC bei mir gar nicht mehr enthalten. :gruebel:
Und auch die Schritte zum Reproduzieren machen bei mir keinerlei Probleme mehr.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1189035)

Also in XE und XE2 ist der verlinkte Bug aus der QC bei mir gar nicht mehr enthalten. :gruebel:
Und auch die Schritte zum Reproduzieren machen bei mir keinerlei Probleme mehr.

Soll heißen: Kauf die das Bugfix und gut ist.

[Lemmy]

Nein, da er ja schon XE2 hat, braucht er es auch nicht mehr zu kaufen

[Sherlock]

Ich habe XE2 mit den letzten Patches, und der Fehler tritt immer noch auf, wobei man andere Schritte gehen muss, um ihn zu reproduzieren. Der QC-Eintrag ist ja nur eines der Probleme...und bezieht sich eigentlich auf .net

Sherlock

[himitsu]

:oops: das 2007 hatte mich abgelekt.

Nja, dann poste dort doch mal deine Schritte.
Eventuell wird das dann auch irgendwann mal repariert.

Was genau machst du denn nun, bzw. kommst du nicht ohne genau diese Funktion aus?

[Sherlock]

Tja, was ich genau mache, kann ich nicht wirklich sagen. Eigentlich habe ich nur eine handvoll OCX, die unter XP (wohlgemerkt nur da, alles darüber macht keine Probleme) beim Beenden des ladenden Moduls eine Schutzverletzung rauswerfen. Nach mühsamen Debugstunden (!!) fand sich schließlich an dieser Stelle der Übeltäter. Der Quellcode der classes.pas hat sich gegenüber 2007 hier im Übrigen nicht geändert...

Sherlock

[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

[Bernhard Geyer]

Zitat:

Zitat von USchuster (Beitrag 1189519)

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.

Bin hier vom Wissenstand was geht und nicht noch auf D6. AFAIK gabs da diese möglichkeit des neuerstellens gar nicht.
Hab mich bisher mit den Möglichkeiten der TNT's geholfen.

[himitsu]

Es geht nicht nur um das kompilieren der PAS.
Man sollte auch noch die BPLs neu erzeugen und da fängt das Chaos erst richtig an.
OK, es ist zwar sehr unwahrscheinlich, daß es für XE2 überhaupt nochmals ein Update/Hotfix gibt, aber auch da macht es dann Spaß, weil diese Setups meißtens eine gewisse Version voraussetzen und bei gepatchten Dateien voll abrauchen.
Dann gibt es von diesen PAS auch noch je 2 Versionen, einmal mit Debuginfos und nochmals Ohne. (siehe Projektoptionen "mit Debug-DCUs").



[edit]
Dennnoch schön, daß es dafür eine Batch, bzw. Build-Projekte gibt,
aber wo sind die für die VCL?

[USchuster]

Zitat:

Zitat von himitsu (Beitrag 1189526)

Es geht nicht nur um das kompilieren der PAS.
Man sollte auch noch die BPLs neu erzeugen und da fängt das Chaos erst richtig an.

Ich sehe nicht dass das Neukompilieren des VCL Packages gefragt war und dazu gibts auch keine Anleitung, da das Verteilen von gepatchten Embarcadero Packages nicht erlaubt ist. Hier bleibt nur das Runtime-Patching.

Zitat:

Zitat von himitsu (Beitrag 1189526)

Dann gibt es von diesen PAS auch noch je 2 Versionen, einmal mit Debuginfos und nochmals Ohne. (siehe Projektoptionen "mit Debug-DCUs").

Ich kann mich irren, aber meine Schritte erzeugen Release- und Debug-DCU.

[Bernhard Geyer]

Zitat:

Zitat von USchuster (Beitrag 1189532)

Ich sehe nicht dass das Neukompilieren des VCL Packages gefragt war und dazu gibts auch keine Anleitung, da das Verteilen von gepatchten Embarcadero Packages nicht erlaubt ist. Hier bleibt nur das Runtime-Patching.

Man könnte sich behelfen indem man sich eigene Packages zusammenstellt welche die entsprechenden Fixes beinhaltet. Das man die Emba-Packages nicht neu kompilieren kann ist klar. Da hätten man dann einen Wildwuchs an "gepatchten" Packages die sich immer gegenseitig im System32-Verzeichnis (wenn man sie dorthin per Installier kopieren lässt) ersetzen.