| Date: | March 21, 2013 / year-entry #80 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20130321-00/?p=4883 |
| Comments: | 23 |
| Summary: | A customer reported that when their program called SHGetFileInfo to get the icon for a folder, the call failed. "It works on some machines but not others. We don't know what the difference is between the working and non-working machines." They included the offending function from their program, but everything in the function looked good.... |
A customer reported that when their program called Eventually, the customer confessed that they had called the That's right, because, like impersonation, nothing works when file system redirection is disabled unless it is specifically documented as supporting disabled redirection. This is even called out in the documentation for
Whenever you use one of these "global solutions to a local problem" types of solutions that change some fundamental behavior of the system, you have to make sure that everybody is on board with your decision. The local solution would be to use the |
Comments (23)
Comments are closed. |
What if you're performing a lengthy process that touches a lot of files, perhaps enumerating some section of the file system? How expensive is it to call the Disable/Revert pair for every single file access?
[The local solution would be to use the C:WindowsSysÂNative virtual directory for files you want to look up in the native system directory rather than the emulated system directory.]
Requires a patch for Windows Server 2003 x64 that is not on Windows Update and is marked as not redistributable.
support.microsoft.com/…/942589
This is the sort of information that desperately needs to be included with all such "global solutions!" Disparaging developers for foolishly using global solutions to local problems when there isn't information discussing a better, local alternative, is a bit like blaming foreigners for not knowing nuances of local custom. How would anyone know about C:WindowsSysNative? I'd never heard of it before now, having been a Windows developer for about 16 years (not that I've had need to use Wow64DisableWow64FsRedirection either, so maybe if I had I'd have stumbled upon it – though I notice that the MSDN documentation for Wow64DisableWow64FsRedirection fails to mention C:WindowsSysNative).
[Requires a patch for Windows Server 2003 x64 that is not on Windows Update and is marked as not redistributable.]
So what? Mark it as a dependency in your MSI and link the Support Ticket (which you were somehow able to find) for your legacy customers to apply. What is so hard about this? Solutions to these problems have been well known for years, its amazing the amount of laziness on developers parts to help themselves out, instead its a game of how can we blame Microsoft for our own shortcomings?
@ @Joshua:
That was a little harch wasn't it? I didn't see where Joshua was critical of anyone. I read that more as an FYI for the readers.
I see that 12BitSlab understands that I too have the social skills of a thermonuclear device.
On the very tangentially related subject of file systems, I've been trying to find the post where Raymond describes why C:Documents and Settings gets Access Denied on Vista/7/8. I know why, but I'm trying to find the post for reference. I could have sworn he posted about it and I see he references it in a response here (blogs.msdn.com/…/9900082.aspx) but I just cannot find this post!
I suppose, TheFunctionWithSuperLongName just sets a flag in the thread block (offset in FS:), and is so cheap that you can flip it around your CreateFile calls all day long.
@alegr1: That's what I assumed as well, but you know what happens when you assume. Although in this case it turns out to be correct.
[Because it's on the other site. -Raymond]
…Well that explains it. Doesn't help when I was restricting searches to just this blog. Thanks Raymond!
WOW64 as it was implemented is an epic overarchitecture designed to solve minor problems by cost of major mess of overcomplication that subsequently caused major problems.
"Wow64ÂDisableÂWow64ÂFsÂRediÂrection" (along with its siblings) is a strong contender in the "most awkwardly named function" competition. It's not just long, it's redundant and arrhythmical.
@Joshua
Just do what 99% of competent programmers who didn't read this blog and don't know about the SysNative trick would do: See that redirect is disabled on a per thread basis and move whatever needs to be done without it to a new thread that doesn't do anything else.
Of course, that the redirection happens at all could be considered a global solution to a local problem. "Say, we have a few apps that are broken. I know, I'll fix this by changing how the filesystem works from underneath them!" I guess somebody took a look at this question and either didn't see that this is a weird thing to do, or they made the assesment that the benefits outweigh the ickiness.
Does Explorer itself disable the redirection and display you the "real" filesystem?
@AC: Explorer is 64-bit so doesn't have to worry about Wow64 redirection.
I wonder why C:Windowssystem64 was not used in the first place, but it's too late to worry about that now.
@JM:
Re: the "most awkwardly named function" competition, how about a function named disable_periodic_flows()? I kid you not.
"WOW64 as it was implemented is an epic overarchitecture designed to solve minor problems by cost of major mess of overcomplication that subsequently caused major problems."
Minor problems? IA64 still had a 32-bit layer, and it failed. Alpha, MIPS builds of Windows NT that had no x86 emulation layers at all? Failed.
64-bit Windows would be a historical footnote if it didn't have a 32-bit compatibility layer.
"See that redirect is disabled on a per thread basis and move whatever needs to be done without it to a new thread that doesn't do anything else."
Seriously? Make the program multi-threaded over this? Just do what MSDN says: switch it off, open the file, revert it. Leaving it turned off for an entire thread is just asking for it – sooner or later, someone's going to do something complicated in the thread and make a mess. The MSDN approach is nice: especially with a comment, it's very clear to the reader how localized the operation is and nobody's going to mess it up by accident.
Hmm, I see to remember running x86 code on an Alpha workstation around the time of NT 3.1.
Maybe it was a DEC-internal thing.
%PATH% hates your guts. It turned out that having a separate /bin and /lib was an idea so far ahead of its time that nobody grasped it, probably not even the UNIX guys.
/*Minor problems? IA64 still had a 32-bit layer, and it failed./*
I already wrote at some comment couple of years ago other way how WOW64 could be implemented – leave 32 system binaries and registry and put all 64 bit stuff into _new_ folders – system64 and new KEY_LOCAL_MACHINE contant definition for x64 part of SDK that would contain own Software subkey and same hive mounted ad 'SYSTEM' subkey (or even using registry symlinks). At least this would be more logical and natural instead of moving 32bits into syswow64 and doing context-dependent redirections cuz its more declarative approach while every given path point to same location, but not redirected. The only minor (of course IMHO) problem with this solution that when somebody need to port 32 bit app to 64 bit- you need to query if there any hardcoded file path references and used hardcoded integer constant instead of HKEY_LOCAL_MACHINE.
So this would not break x86 code more than existing wow64, this theoretically would make process of porting x32->x64 a bit more complicated (if you use hardcoded C:WindowsSystem32 or prefer to write (HKEY)0x80000002 instead of HKEY_LOCAL_MACHINE. Is anybody here doing so)? And all his things BTW could be checked by simple static code analyzer or even by app verifier.
/*This is part of the emulation – hiding the 64-bit system from them*/
but:
1) 32 bit apps still see some 64 binaries in %WINDIR% and C:Program Files
2) they see but can't touch 64 processes
3) Finally, MS added functionality for emulator to disable emulation
[Hmm, I see to remember running x86 code on an Alpha workstation around the time of NT 3.1.]
Non-x86 NT included an x86 emulator for 16-bit Windows and DOS programs, but you couldn't run 32-bit x86 Windows programs with it. At some point FX!32 was released for Alpha, which allowed Windows NT on Alpha to run 32-bit x86 programs.
How does SysNative work? It seems it only exists in WOW64, but even then it's invisible in file dialogs opened in C:Windows (you have to type explicitly its name to enter it) despite my machine being configured to display "super-hidden" files…