Problem mit UpdateResource und XP-Manifest

[MrKnogge]

na guten Abend !

Ich möchte ein kleines tool schreiben, mit dem ich das XP-Manifest nachträglich in compilierte Exe-Files integrieren kann. Also nicht einexternes Manifest namens "Programname.exe.manifest".

Eigentlich klappt das auch schon alles:

Delphi-Quellcode:

function MAKELANGID(const usPrimaryLanguage : WORD;const usSubLanguage : WORD) : WORD; 
begin 
  Result := (usSubLanguage shl 10) or usPrimaryLanguage; 
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  stream: TFilestream;
  hInst: THandle;
  ptr: Pointer;
begin
  stream := TFileStream.Create('C:\test.manifest', fmOpenRead);
  getmem (ptr,Stream.size+1);
  try
    stream.Seek(soFromBeginning, 0);
    stream.read(ptr^, Stream.size);
    hInst := BeginUpdateResource('C:\test.exe', false);
    if hInst > 0 then begin
      UpdateResource(hInst, MakeIntResource(24), '1',
      MAKELANGID(LANG_NEUTRAL,SUBLANG_NEUTRAL), ptr, Stream.size);
      EndUpdateResource(hInst, false);
    end;
  finally
    freemem(ptr, Stream.size+1);
    stream.Free;
  end;
end;

Das XP-Manifest:

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity
     type="win32"
    name="DelphiApplication"
    version="1.0.0.0" 
     processorArchitecture="*"/>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        publicKeyToken="6595b64144ccf1df"
        language="*"
        processorArchitecture="*"/>
    </dependentAssembly>
  </dependency>
</assembly>

Zum testen hab ich einfach kurz ein Delphi-Programm mit verschiedenen Controls erstellt, + das gleiche mit eingebundenem XP-Manifest von Delphi. Anschliesend das ohne XP-Manifest mit meinem Programm modifieziert und im Resource Hacker verglichen, identisch ! Allerdings werden bei dem von mir modifizierten Programm die Controls nicht im XP-Style angezeigt.

Was mach ich falsch ?

gruss

[MathiasSimmack]

Darf ich etwas sachliche Kritik äußern?

1. Die Funktion "UpdateResource" gibt es nur auf NT-Systemen. Okay, das Manifest funktioniert ja auch erst unter XP, und das ist ja eine NT-Plattform. Trotzdem ...

2. Nicht jedes Programm ist auf die Manifest-Unterstützung ausgelegt. Speziell wenn du ein Programm erwischt, das vielleicht von jemandem mit einer älteren und nicht selbst angepassten Delphi-Version geschrieben wurde. Das Problem mit der List-View im vsReport-Modus dürfte ja bekannt sein. Und da kann das nachträgliche Integrieren des Manifestes Probleme verursachen.

Ich will dich nicht von deiner Idee abbringen. Aber du solltest vielleicht immer erst einen "Testlauf" mit einem externen Manifest machen und schauen ob das Programm in jeder Hinsicht funktioniert.

[MrKnogge]

Zu deiner Frage, jadu darfst :mrgreen:

Zu 1. Was für eine Fehlermeldung würde ich unter Windows98 bekommen ?

Zu 2. Wenn ich/bzw. der Benutzer sein Programm vorerst mit einer Manifestdatei testet, mit welchen Fehlermeldungen machen sich die Probleme bemerkbar ?

[MathiasSimmack]

Zitat:

Zitat von MrKnogge

Zu 1. Was für eine Fehlermeldung würde ich unter Windows98 bekommen ?

Wenn die Funktion statisch geladen wird, dann wahrscheinlich die übliche Meldung, dass die Funktion nicht gefunden wurde. Gefolgt vom merkwürdig anmutenden "Ein angeschlossenes Gerät funktioniert nicht" ... oder so ähnlich ...

Zitat:

Zu 2. Wenn ich/bzw. der Benutzer sein Programm vorerst mit einer Manifestdatei testet, mit welchen Fehlermeldungen machen sich die Probleme bemerkbar ?

Na, ein Beispiel nannte ich doch: Nimm an, jemand hat ein recht gutes Freeware-Programm geschrieben, dass irgendwelche Daten in einer List-View anzeigt. Diese LV läuft in der Detailansicht, und wenn das Programm mit einer Version < D7 geschrieben und der Quellcode der "ComCtrl.pas" (wenn ich von der VCL-List-View ausgehe) nicht angepasst wurde, dann siehst du eine Zugriffsverletzung.
IMHO war noch irgendwas mit der Toolbar, was auch nicht klappte, wenn die VCL-Unit nicht gepatcht wurde.

Evtl. ist ein Programm auch ge-UPX-t. Da wäre es IMHO sowieso zweckmäßiger, das Manifest separat beizulegen.

[MrKnogge]

Ich hatte erst vor, die Möglichkeit dem Benutzer zu überlassen, ob das Manifest in die Exe-File integriert, oder eben extern beigelegt wird. Allerdings hatte ich bisher Packer alá UPX nicht bedacht.

[Muetze1]

Moin!

Meiner Meinung nach klappt das so nicht, weil du das Manifest ja zur Laufzeit hinzufügst und Windows aber beim Laden der EXE die jeweilige Common Controls initialisiert und daher nicht mehr nachträglich schaut bzw. die Common Controls abändert - das wird IMHO beim starten erledigt, daher hast du IMHO keine Chance, weil die Controls zur Laufzeit schon alle benutzt werden...

MfG
Muetze1

[MrKnogge]

Aber es funktioniert ja mit anderen Resourcen auch, und das Manifest ist dann ja sogar als Resource verfügbar (vor dem Start !), aber irgendwie wird es ignoriert. Als müsste man ne art flag setzen "arbeite das mal ab".

Ich hab schon Programme gesehen, bei denen das geklappt hat.

[MasterC]

Das ist mehr als komisch, die Resource ist vorhanden. Nur wenn man es mir ResHack macht gehts. :-/

Hat jemand eine Ahnung warum?

[Pseudemys Nelsoni]

fügst du die manifest ans ende der datei an oder wo?

[MasterC]

Jo ans Ende.

[Zacherl]

Jemand ne Lösung parat? Habe dsa selbe Problem.

[MrKnogge]

Ich habs damals nicht hinbekommen.

[OldGrumpy]

Dann reich mal eine Exe rüber bei der es nicht geht, und zwar in zwei Geschmacksrichtungen:

a) Mit Deinem Tool gepatcht (geht nicht)
b) Mit Resource Hacker gepatcht (geht)

Dann kann ich Dir vermutlich sagen woran es liegt :)

[Zacherl]

Okey, moment, dann muss ich das erst kurz umschreiben ..

[Zacherl]

So, hier beide Exen .. nicht wundern, wenn die Firewall meckert: Es handelt sich um Hagens SRP Demo Server.

[Zacherl]

Sorry, wenn ich nerve, aber hats jemand?

[OldGrumpy]

Ja, sorry, der Orkan gestern hat mich etwas aufgehalten. Die Strasse hier ist immer noch gesperrt :)

[Zacherl]

Okey, kein Problem :D Ich warte einfach mal ..

[OldGrumpy]

Also die gesamte Resource-Section sieht unterschiedlich aus, dazu kommt noch dass Deine gepatchte Exe eine VSize von $7120 für .rsrc ausweist, die ResHacker-Variante nur $711A. Ab dem Beginn der Section .rsrc sehe ich z.B. immer wieder:

[Manifest_Patched.exe]
5D000: 00 00 00 00 00 00 00 00
5D008: 04 00 00 00 00 00 07 00

[Manifest_ResHacker.exe]
5D000: 00 00 00 00 C7 05 45 33
5D008: 00 00 00 00 00 00 07 00

Wobei die rot markierten Bereiche sich öfter wiederholen. Ohne jetzt noch nach dem Format der Resourcen in .rsrc gewühlt zu haben sieht mir das ganz nach falschen Offsets aus. Vielleicht könntest Du Deinen Patchersource ja mal posten, dann dürfte sich das Problem finden lassen.

Ab $5D570 gehts dann ähnlich weiter, wobei sich hier (alle Werte zuerst aus der gepatchten, dann aus der ResHacker-Exe) immer Werte $E4/$04 und $00/$00 mit unterschiedlichen Einzelbytes abwechseln, die sich aber immer um 4 unterscheiden (z.B. $24/$20).

Bei $5D81D stehen dann in Deiner Exe vier Bytes die in der ResHacker-Exe nicht vorhanden sind - der Rest ist dann in Deiner Exe um vier Bytes verschoben:

5D81D: 00 01 00 31

Entfernt man diese vier Bytes, bleiben von 127 Unterschieden noch 51 übrig. Die meisten davon gehören zu den oben beschriebenen, bleiben noch 2-3, die mir sehr seltsam vorkommen, und wohl Überreste eines Paddings sind, in der ResHacker-Exe steht dort $00/$00, in Deiner Exe $50/$41 ("PA"). Am Ende des Files schließlich kommt noch ein grosser Block Nullbytes (ResHacker) bzw. "PADDING" (Deine Exe). Hier solltest Du unbedingt auch mit Nullbytes füllen statt mit Ascii-Werten. Sicher ist sicher. Interessant ist auch noch der Anfang dieses Blocks, dort steht "PPADDINGXX" (und es setzt sich endlos fort mit "PADDINGPADDINGXX"), so aus dem Bauch heraus würde ich hier auf mehrfach überschriebenen Speicher tippen.

Fazit: Ohne sich genau Deinen Patcher anzuschauen ist Abhilfe vermutlich nicht so ganz trivial.

HTH :)

[MrKnogge]

Die Funktion zum patchen steht im ersten Post.

Gruß

[OldGrumpy]

Zitat:

Zitat von MrKnogge

Die Funktion zum patchen steht im ersten Post.

Er schrieb irgendwas von Umschreiben, daher nahm ich an er hätte da noch was geändert. :)

[Zacherl]

Ja in der Tat. Ich mache es so:

Delphi-Quellcode:

 PTemp :=
      '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>' + #13#10 +
      '<assembly' + #13#10 +
      '   xmlns="urn:schemas-microsoft-com:asm.v1"' + #13#10 +
      '   manifestVersion="1.0">' + #13#10 +
      ' <dependency>' + #13#10 +
      '  <dependentAssembly>' + #13#10 +
      ' <assemblyIdentity' + #13#10 +
      '   type="win32"' + #13#10 +
      '   name="Microsoft.Windows.Common-Controls"' + #13#10 +
      '   version="6.0.0.0"' + #13#10 +
      '   publicKeyToken="6595b64144ccf1df"' + #13#10 +
      '   language="*"' + #13#10 +
      '   processorArchitecture="x86"' + #13#10 +
      ' />' + #13#10 +
      '   </dependentAssembly>' + #13#10 +
      ' </dependency>' + #13#10 +
      '</assembly>';

      hFile := BeginUpdateResource(PChar(Target), true);
      UpdateResource(hFile, PChar(24), '1', 0, PTemp, length(PTemp) +1);
      EndUpdateResource(hFile, false);

PTemp ist ein PChar.

Vielen Dank
Florian

[OldGrumpy]

Das allererste was mir an Deinem neuen Source auffiel, war das TRUE bei BeginUpdateResource. Die MSDN schreibt zu diesem Parameter:

Zitat:

Zitat von MSDN

bDeleteExistingResources
[in] Specifies whether to delete the pFileName parameter's existing resources. If this parameter is TRUE, existing resources are deleted and the updated file includes only resources added with the UpdateResource function. If this parameter is FALSE, the updated file includes existing resources unless they are explicitly deleted or replaced by using UpdateResource

Da sollte also wohl besser FALSE statt TRUE stehen :)

Ich bin mir auch nicht sicher ob PChar(24) hier zielführend ist. Warum benutzt Du nicht MakeIntResource(RT_MANIFEST)?

[himitsu]

PChar(24) <=> MakeIntResource(RT_MANIFEST)

ist eigentlich egal, da es genau das Selbe ist, denn

Delphi-Quellcode:

Type MakeIntResource = PChar;

//und 

Const RT_MANIFEST = 24;

[OldGrumpy]

Allerdings wird es viel verständlicher wenn man die vorgesehenen Typen usw. benutzt, dazu gibts die drei Millionen Defines ja überhaupt. Es gibt wenig schlimmeres als API-Aufrufe mit irgendwelchen Zahlen statt sprechenden Defines. Ein (Pseudocode) GetShellFolder(14) sagt mir erstmal gar nix, bei GetShellFolder(CSIDL_MY_VIDEOS) kann mans wenigstens sinnvoll ergooglen :) Ich warte jetzt erstmal ne neue Exe zum Vergleichen ab, mal sehen was sich ändert wenns auf FALSE gesetzt wird.

Edit: Typo gefixt.

[Zacherl]

So, also RT_MANIFEST ist leider nicht deklariert, weshalb ich die 24 einfach mal so genommen habe. Dann zum zweiten Parameter von BeginUpdateResource: das ist so von mir gewünscht, sollte ja eigentlich auch nichts mit dem Manifest Problem zu tun haben, oder? Zumindest macht es keinen Unterschied, wenn der Parameter false ist.

Woran könnte es nocht liegen?

[OldGrumpy]

Naja, Du killst damit explizit alle Resourcen die vorher vorhanden waren, Resourcestrings, Icons, Bitmaps, uvm. - das kann nicht wirklich gewollt sein, oder? :) Kann ich bitte noch die Test-Exe vor der Behandlung für den 3-Wege-Vergleich bekommen? Wenn Delphi RT_MANIFEST nicht direkt selber kennt, dann schreibs wenigstens als Kommentar dazu. Alternativ gibts z.B. bei den Jedis jede Menge Defines zum mitbenutzen - Geschmackssache. Ich schau mir das morgen nochmal genauer an, ich hab momentan etwas Probleme mit meinem XP, hab mir irgendeinen Teil des Devicestacks für optische Laufwerke zerschossen beim Experimentieren, und selbst nach Vergleich mit einem heilen XP und entsprechenden Registryreparaturen zickt mein XP hier immer noch - zuviel rumgespielt am Entwicklersystem :) Muss es doch wohl oder übel mal neu aufsetzen *g*

[Zacherl]

:D ja also das Entfernen aller Resourcen ist doch wirklich gewollt. Die EXE ist selbstgeschrieben und hat auch nur die Standard Delphi RCDATA Resourcen, die man nicht braucht.