ShellExecuteEx mit Verb properties und x64

[Dalai]

Hallo Leute ,

ich muss mir mal wieder externen Input von euch holen, da ich auf ein Phänomen gestoßen bin und sich mir die Frage nach der "richtigen" Lösung stellt.

Es geht hierbei nur um Windows x64 (egal ob XP oder 7 oder höher).

Simple Testapplikation:

Delphi-Quellcode:

unit Main;

interface

uses
  Windows, Messages, SysUtils, Classes, Controls, Forms, Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    CheckBox1: TCheckBox;
    CheckBox2: TCheckBox;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

uses ShellAPI, MyLibrary;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var SEI: TShellExecuteInfo;
begin
    FillChar(SEI, SizeOf(SEI), 0); // Wipe the record to start with
    SEI.cbSize:= SizeOf(SEI);
    if Checkbox2.Checked then
        SEI.fMask:= SEE_MASK_NOCLOSEPROCESS
    else begin
        SEI.fMask:= SEE_MASK_INVOKEIDLIST;
        SEI.lpVerb:= 'properties';
    end;
    SEI.Wnd:= Self.Handle;
    SEI.lpFile:= PChar(Edit1.Text);
    SEI.nShow:= SW_SHOWNORMAL;
    {$IFDEF WIN32}
    if (Checkbox1.Checked) then
        SwitchX64Redirection(True);
    {$ENDIF}
    ShellExecuteEx(@SEI);
    {$IFDEF WIN32}
    if (Checkbox1.Checked) then
        SwitchX64Redirection(False);
    {$ENDIF}
end;

end.

In dem Edit1 steht beispielsweise "C:\Windows\system32\msiexec.exe". Egal, ob die Checkbox angehakt ist oder nicht, es kommt immer der Eigenschaften-Dialog der Datei "%SystemRoot%\syswow64\msiexec.exe". Wenn ich die Datei starte (Verb open) statt dessen Eigenschaften anzuzeigen, wird je nach Haken die richtige Datei ausgeführt (sichtbar im Taskmanager) - bei deaktivierter Redirection (Checkbox aktiviert) %SystemRoot%\system32\msiexec.exe und bei aktivierter Redirection (Checkbox deaktiviert) ist es %SystemRoot%\syswow64\msiexec.exe. "Nette" Sache bis hierhin - eher lästig, aber egal.

Nun, wie bekomme ich jetzt den Eigenschaften-Dialog der richtigen Datei? Da es keine Funktion GetNativeSystemDirectory o.ä. gibt, kam mir bisher nur der Gedanke, GetWindowsDirectory zu rufen und "\Sysnative" anzuhängen und dann mit StringReplace "%SystemRoot%\system32" zu ersetzen. Gibt's da nicht was besseres?

MfG Dalai

[himitsu]

Das ist die Abwärtskompatibilitätsvirtualisierung vom Windows.
Genauso, wie das UAC deine Schreibzugriffe in den VirtualStore umleitet, wenn ein schrottiges Programm versucht in C:\Programme oder C:\Windows zu schreiben,

werden 32-Bit-Programme in einem 64-Bit-Windows auf die 64-Bit-Pfade umgeleitet. Und das nur weil mal dachte es wäre doch sooooo viel Besser wegen schrottiger 64 Bit-Programme die alten Pfade so belassen.
Genauso wie in neueren Delphis die Unicode-String-Funktionen alle noch ANSI heißen.

Wow64DisableWow64FsRedirection

[Dalai]

Ich kenne die Funktionen Wow64*. Und wenn du richtig schaust, siehst du, dass genau die benutzt werden, aber für das Verb properties nutzlos sind (eigentlich logisch, denn es finden keine Dateisystemzugriffe statt).

MfG Dalai

[himitsu]

Nö.

Da gibt es nur ein SwitchX64Redirection und ich weiß ja nicht was das macht und ob es z.B. auch die Rückgabewerte auswertet.


Du könntest auch mal versuchen dein Programm als Kompatibel zur Windows-Version auszuweisen.
Viele Abwärtskopatibilitätsdinge sind nur aktiv, wenn das Programm als "alt" angesehn wird.

ManifestCreator -> unterstütztes BS

[himitsu]

[del]

[Dalai]

Zitat von himitsu:

Nö.

Da gibt es nur ein SwitchX64Redirection und ich weiß ja nicht was das macht und ob es z.B. auch die Rückgabewerte auswertet.

Also mal ernsthaft: Ich schrieb, dass ein Starten der EXE mit ShellExecuteEx funktioniert (also die richtige EXE ausführt), aber das Öffnen/Anzeigen der Eigenschaften das nicht tut. Wo glaubst du nun, wäre ein Fehler? Die Funktion SwitchX64Redirection tut genau das, was sie soll, auch beim Auslesen von Dateieigenschaften mit FindFirst & Co (Größe, Datum etc). Probier's selbst aus (hab den Code im OP mal etwas erweitert, damit sich das einfacher testen lässt). Aber der Vollständigkeit halber:

Delphi-Quellcode:

var OldWow64RedirectionValue        : LongBool;
{$IFDEF WIN32}
function SwitchX64Redirection(bDisable: Boolean): Boolean;

 type TWow64DisableWow64FsRedirection = Function(var Wow64FsEnableRedirection: LongBool): LongBool; StdCall;
      TWow64RevertWow64FsRedirection = Function(OldValue: LongBool): LongBool; StdCall;

  var
    hHandle                         : THandle;
    Wow64DisableWow64FsRedirection  : TWow64DisableWow64FsRedirection;
    Wow64RevertWow64FsRedirection   : TWow64RevertWow64FsRedirection;

begin
    Result:= true;
    try
        hHandle:= GetModuleHandle(KERNEL32);
        @Wow64DisableWow64FsRedirection := GetProcAddress(hHandle, 'Wow64DisableWow64FsRedirection');
        @Wow64RevertWow64FsRedirection := GetProcAddress(hHandle, 'Wow64RevertWow64FsRedirection');

        if bDisable then
        begin
            if ((hHandle <> 0) AND
               (@Wow64DisableWow64FsRedirection <> nil)) then
                   if NOT Wow64DisableWow64FsRedirection(OldWow64RedirectionValue) then
                       RaiseLastOsError;
        end
        else
        begin
            if ((hHandle <> 0) AND
               (@Wow64RevertWow64FsRedirection <> nil)) then
                   if NOT Wow64RevertWow64FsRedirection(OldWow64RedirectionValue) then
                       RaiseLastOsError;
        end;
    except
        Result:= false;
        raise;
    end;
end;
{$ENDIF WIN32}

Zitat:

Du könntest auch mal versuchen dein Programm als Kompatibel zur Windows-Version auszuweisen.
Viele Abwärtskopatibilitätsdinge sind nur aktiv, wenn das Programm als "alt" angesehn wird.

Spielt keine Rolle, weil ich das im eigentlichen Programm eh nicht beeinflussen kann, weil es eine DLL ist.

MfG Dalai

[Dalai]

Testweise hab ich nun ein Manifest mit Kompatibilität für Windows bis hoch zu Version 10 eingebaut, aber wie erwartet macht das keinen Unterschied. Ich wäre dankbar, wenn jemand mal den Code im OP testen könnte und hier mitteilt, ob das Problem nachvollziehbar ist. Das kann auch gern unter Verwendung eigener Implementationen der Wow64*FsRedirection-Funktionen passieren.

Momentan sieht's aber so aus, als wäre das ein "normales" Verhalten, denn auch Total Commander verhält sich so. Dort kann man mit cm_SwitchX64Redirection die Redirection abschalten, wechselt ins Verzeichnis %SystemRoot%\system32 und sucht dort die Datei msiexec.exe, merkt sich Größe und Datum und öffnet nun die Eigenschaften der Datei mit Alt+Enter (oder via Kontextmenü) und stellt fest: der Eigenschaften-Dialog sagt etwas anderes als TC zeigt - dasselbe Verhalten wie in obigem Testprogramm.

Windows ist doch immer wieder ein Quell neuer Phänomene ...

MfG Dalai

[mm1256]

Hast du die 32-Bit Version des Commanders, oder die 64-Bit-Version?

Meine 64-Bit-Version (8.51a) des TC zeigt alles richtig an und somit würde das meines Erachtens korrekt sein.

Weil mich das Thema gerade auch interessiert hab ich dein Beispiel als 32-Bit und als 64-Bit-App compiliert. Auch wahlweise mit kompletter Pfadangabe der msiexec.exe.

Werte identisch mit dem TC. Vielleicht ist das Verhalten von 32-Bit-Apps ja von MS so gewollt

[himitsu]

ShellExecute startet doch ein weiteres Programm, eventuell wird aus einem 32-Bit-Programm heraus auch eine 32-Bit-Version des Properties-Anzeigen-Codes ausgeführt, welches dann ebenfall von dieser DS-Umleitung betroffen wäre.

[mm1256]

das wäre eine logische - und auch sinnvolle - Erklärung