TOpenDialog/TFileOpenDialog => how to to bypass file system redirection?

[Nigel Thomas 35]

On 64Bit Windows, when a 32bit app calls a file-open dialog, e.g. TOpenDialog or TFileOpenDialog, then browses to the \Windows\System32 directory to select a file in that directory, the dialog actually displays the contents of the SysWow64 directory - even though the dialog title states it is browsing the system32 directory.

 

I assume this is caused by file system redirection. I'd like to bypass it and browse - and select files from - the actual system32 directory.

 

I've tried calling Wow64DisableWow64FsRedirection before creating the dialog but it has no effect.

 

I expected to see at least a few posts about this on Google somewhere, but I've not come across any.

 

Curious point: with the fileopen dialog open, it is possible to drag-and-drop a file from the dialog to the desktop - and the file that is dragged turns out to be the system32 file, and not the SysWow64 file (the filesizes of identically-named dlls are usually different so it is easy to confirm this). Whilst that is interesting, it doesn't help if one wishes to access a file that is in the system32 directory, but has no identically-named counterpart in the SysWow64 directory, as the dialog will not display it (confirmed by creating differently named files in each directory to see what was visible in the dialog).

 

Edit to add: this behaviour is the same on D2007 and D10.4.2.

Edited September 12, 2022 by Nigel Thomas

[David Heffernan 2345]

c# - 32-bit OpenFileDialog --> 64-bit System32? - Stack Overflow

 

tl;dr not possible

[David Heffernan 2345]

FWIW, I'd tackle this by shipping a 64 bit application. 

[Nigel Thomas 35]

1 hour ago, David Heffernan said:

FWIW, I'd tackle this by shipping a 64 bit application. 

Thanks. I suspected that might be the case.

[Fr0sT.Brutal 900]

StringReplace(FilePath, 'SysWOW64', 'System32')

 

😄

[Martin Wienold 35]

Try to use %windir%\sysnative instead of %windir%\system32

https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector

"[..] 32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. [..]"

[Nigel Thomas 35]

12 hours ago, Fr0sT.Brutal said:

StringReplace(FilePath, 'SysWOW64', 'System32')

 

😄

The string returned from the dialog contains "system32", so that is a non-starter. Besides which, the whole point of this query was to determine how to select files in the System32 directory that do not have duplicate-names in the SysWow64 directory. You can't, because you are only shown the contents of the SysWow64 directory.

Edited September 19, 2022 by Nigel Thomas

[Nigel Thomas 35]

9 hours ago, Martin Wienold said:

Try to use %windir%\sysnative instead of %windir%\system32

The dialog has no knowledge of sysnative. For 32Bit applications running on an x64 system, it displays the SysWow64 directory, it just tells you it is the System32 directory, Try browsing for a file or folder in System32 that does not have a duplicate-name in SysWow64 and you'll see the issue.

[David Heffernan 2345]

Out of curiosity, what does your program do that requires users to select files in these directories which are private to the OS? 

[Nigel Thomas 35]

12 hours ago, David Heffernan said:

Out of curiosity, what does your program do that requires users to select files in these directories which are private to the OS? 

It's a Malware scanner. The select dialog is provided to allow the user to exclude specific folders/files from analysis. I suspect it will be rarely used to exclude system32/syswow64 files, and even less likely to land on a file that *is* in SysWow64 but is *not* duplicated in System32 (the only real time it makes a difference). The way the selection dialog lies about what folder you are viewing just irks me.

[David Heffernan 2345]

Excluding files from system directory sounds like a recipe for disaster! But yeah, make a 64 bit process. If you still need to support 32 bit OS then you need to supply one version for each OS.