TTaskDialog und mehrere commctl32

[christophspaeth]

Hallo,
in einem Projekt (MMC-SnapIn) wollte ich einen TTaskDialog verwenden und war etwas verwundert, dass ich bei TTaskDialog.Execute immer false zurückbekomme.

Nach einer Debug-Session bin ich darauf gestoßen, dass GetProcAddress(ComCtl32DLL, 'TaskDialogIndirect') fehlschlägt.
Die Ursache dafür ist, dass Delphi sich die Commctl32.dll mit GetModuleHandle holt, und die MMC.exe laut Process Explorer zwei verschiedene Versionen der commctl32.dll geladen hat:
C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.16299.492_none_d02c a6ed5f31dad7\comctl32.dll und C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.16299.492_none_5d760 a37a7e0e2b6\comctl32.dll

Die MSDN schreibt ja auch deutlich "If lpModuleName does not include a path and there is more than one loaded module with the same base name and extension, you cannot predict which module handle will be returned."

Hat jemand eine Idee, wie ich das trotzdem zum Laufen bekommen kann? Idealerweise ohne die komplette VCL auseinanderzurupfen.

[KodeZwerg]

Versuche doch einfach mal eine der DLLs ins .exe Verzeichnis zu kopieren, ich würde die v6 als erstes Probieren.

[EWeiss]

Ich würde versuchen deine Commctl32 die du verwenden möchtest explicit in deine Anwendung zu importieren bzw.. Windows mitteilen welche du verwenden möchtest.
Eine gute Möglichkeit dafür wäre diese in dein Manifest mit einzubinden.
Ob es was bringt keine Ahnung aber ein versuch wäre es wert.

bsp.

Code:

<dependency>
-<dependentAssembly>
<assemblyIdentity language="*" publicKeyToken="6595b64144ccf1df" processorArchitecture="*" version="6.0.0.0" name="Microsoft.Windows.Common-Controls" type="win32"/>
</dependentAssembly>
</dependency>

gruss

[Fritzew]

Emil ist auf dem richtigen Weg.....
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx
Wie Du aber in Delphi das Flag
ISOLATION_AWARE_ENABLED unterbringst erschließt sich mir gerade nicht.

[himitsu]

Zitat:

Zitat von KodeZwerg (Beitrag 1405373)

Versuche doch einfach mal eine der DLLs ins .exe Verzeichnis zu kopieren, ich würde die v6 als erstes Probieren.

NEIN!

Windows schützt sich inzwischen selber vor derartigen Angriffen und lässt es nicht zu, dass SystemDLLs aus anderen Verzeichnissen geladen werden.
(ich weiß jetzt allerdings nicht, wie es bei expliziter Angabe des kompletten Pfades ist, aber dynamisches Laden kommt hier eh nicht in Frage)

[christophspaeth]

Hallo,

danke für die Antworten.

@KodeZwerg: Die Anwendung ist die (32 bittige) mmc.exe, die unter C:\windows\SysWOW64 liegt. Und in diesem Verzeichnis liegt schon die commctl32, aber in Version 5.8. Und an den Windows-Systemdateien will ich nicht rumpfuschen - ich weiß ja nicht, ob das Schlamperei oder Absicht ist, dass da die ältere Version liegt...

Zu dem ISOLATION_AWARE_ENABLED unter Delphi habe ich aufstackoverflow etwas gefunden, es aber noch nicht ausprobiert.

[KodeZwerg]

Zitat:

Zitat von KodeZwerg (Beitrag 1405373)

Versuche doch einfach mal eine der DLLs ins .exe Verzeichnis zu kopieren, ich würde die v6 als erstes Probieren.

So geh ich halt vor wenn ich Probleme mit externen Dll habe die multiple vorhanden sind.
Das sollte kein Dauerzustand sein, nur halt um herauszufinden womit was wie funktioniert um eventuelle Konflikte zu analysieren.

Das man keine System Dlls umkopieren darf hat zwar auch eine Daseinsberechtigung und ich gebe generell Recht aber das Erinnert mich an mein jetzt wieder in Kraft getretenes Windows 10 Dll problem mit DirectX v9.
Ohne eine bestimmte System-Dll ins Programmverzeichnis zu kopieren ist es grottenhaft langsam.

(Bei nicht top up-to-date Windows 10, das neuere Versionen das bereits gefixt haben wurde erwähnt, aber Rechtfertigt es sich dieses Update anzutun nur um DirectX zu reparieren, in meinem Falle eher nein, also kopiere ich bewusst eine Dll dahin wo sie die Fehlerhafte Originale ersetzt.

Ja ihr mögt keine Datengrößen Vergleiche aber erwähnt haben will ichs mal:
Windows 10 Original-Version = um die 3.5GB
DirectX v9 fix = 1.7MB, fix einspiel-zeit = <1sec
Windows Updates um das gleiche Resultat zu erzielen = tausende MB, Zeitfaktor/kann Tage dauern)

[EWeiss]

@KodeZwerg
Die DirectX DLL ist keine SystemDLL so wie @himitsu sagte und wo er drauf hingewiesen hat.

@himitsu
Aber auch das ließe sich durch Einbindung im Manifest umgehen zumindest unter Windows 7
Siehe msvcr90.dll

Code:

  <description>Emil's MediaPlayer</description> 
  <!-- Mildrop Visualisation support -->
  <dependency>
    <dependentAssembly>
       <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" 
                      version="9.0.21022.8" 
                      processorArchitecture="x86" 
                      publicKeyToken="1fc8b3b9a1e18e3b">
      </assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
     <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
                        version="6.0.0.0" processorArchitecture="X86" 
                        publicKeyToken="6595b64144ccf1df" 
                        language="*">
      </assemblyIdentity>
     </dependentAssembly>
  </dependency>

EDIT:
Aber glaube das ist auch keine System DLL

gruss

[himitsu]

@EWeiss: Ja, man kann eine Version angeben, welche man verwenden möchte,
Aber die Datei durch "irgendeine" andere Datei/Version zu ersetzten, indem man jene Datei neben die EXE legt oder in Suchpfaden vorher platziert, das wird standardmäßig unterbunden und Windows nimmt dennoch seine eigenen Dateien, statt deiner.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1405447)

@EWeiss: Ja, man kann eine Version angeben, welche man verwenden möchte,
Aber die Datei durch "irgendeine" andere Datei/Version zu ersetzten, indem man jene Datei neben die EXE legt oder in Suchpfaden vorher platziert, das wird standardmäßig unterbunden und Windows nimmt dennoch seine eigenen Dateien, statt deiner.

Richtig :)
Ein no go!

gruss