0

I'm trying to build a 32-bit program that can run correctly on 64-bit Windows; that is, if it needs to open a text file for the user, the file needs to not be redirected from C:\Program Files to C:\Program Files (x86). However, if I just call Wow64DisableWow64FsRedirection, then my program fails to load at all because some system libraries call LoadLibrary when portions of the GUI are loading, which tries to load a 64-bit version of a system DLL into my program.

How do I solve this problem?

Edit:

See the problem in the screenshot below:

Edit 2:

Here's another question that'll solve the problem: Is there any way to disable WOW64 redirection for an arbitrary thread in your process, or for your process as a whole?

user541686
  • 205,094
  • 128
  • 528
  • 886

1 Answers1

3

Easy, call Wow64DisableWow64FsRedirection just before you call CreateFile, and then call Wow64RevertWow64FsRedirection just as soon as it is done.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • That's easier said than done, because `CreateFile()` is getting called from *inside* `GetOpenFileName`. And so, if I disable WOW64, then the dialog won't show at all (because of `LoadLibrary`), and if I don't, then it shows but I get virtualized data. (I guess I should've mentioned the dialog, but the point was that I don't have control over where `CreateFile` is getting called.) – user541686 Jan 20 '11 at 20:07
  • Why is CreateFile being called inside GetOpenFileName? Are you doing that in a hook? – David Heffernan Jan 20 '11 at 20:11
  • Sorry, I realized my explanation was a bit unclear... so what happens is, I call `CreateFile` in other points in the program (and so I can disable redirection like you stated for these points), but the dialog internally calls the file functions like `FindFirstFile`, `FindNextFile` to enumerate directories (and probably also `CreateFile`), which all internally call the lower-level file functions in the system (like `NtCreateFile`). I just summarized all of those into "CreateFile" instead of mentioning the different functions, but the general idea was that I can't control every single call. – user541686 Jan 20 '11 at 20:18
  • So, in summary, the problem is that I need to somehow disable redirection for regular files but enable it for `LoadLibrary` calls. Sorry I didn't explain this very clearly. – user541686 Jan 20 '11 at 20:20
  • @Lambert Surely the dialog handles all this for you? Doesn't it offer you both Program Files and Program Files (x86)? That's what happens on my 64 bit system? – David Heffernan Jan 20 '11 at 20:22
  • It "offer"s both, but they're both the same folder! The (x86) version is obviously not redirected, so it's returned; the 64-bit version is redirected to the 32-bit version, but still enumerated. (Edit: Wait, I take that back. Apparently Program Files works correctly but System32 doesn't.) – user541686 Jan 20 '11 at 20:23
  • @Lambert Er, they are distinct folders. – David Heffernan Jan 20 '11 at 20:25
  • Sorry, Program Files works but System32 doesn't... lemme check it one more time but I swear I wasn't hallucinating!!! :) – user541686 Jan 20 '11 at 20:26
  • Yes, so that's what happens. Program Files works fine (it's not redirected), but System32 is still redirected to SysWOW64 (verified by hand, by creating files from Explorer and seeing that they aren't visible in the app's Open File dialog). Any idea why this might happen? (Hopefully this works the same way on your machine, right? Or am I hallucinating...) – user541686 Jan 20 '11 at 20:27
  • @Lambert could you try and state this more clearly, I don't yet fully follow – David Heffernan Jan 20 '11 at 20:30
  • @David: Take a look at my edit with the screenshot; hopefully it'll make sense. (You might notice that I was trying to edit Notepad++'s source code to make it open files correctly from System32...) – user541686 Jan 20 '11 at 20:42
  • @Lambert GetOpenFileName disables redirection and so can return system32 or syswow64. You then need to disable redirection when you try to open the file whose name has been returned by GetOpenFileName. – David Heffernan Jan 20 '11 at 20:45
  • @David: Did you look at the screenshot's address bars? System32 in Notepad++ is really SysWOW64 in Explorer; the System32 folder in explorer is different... redirection isn't disabled by GetOpenFileName. – user541686 Jan 20 '11 at 20:50
  • @Lambert The file dialogs in my app don't behave that way. I think this is an issue with Notepad++. Perhaps it isn't properly manifested. Try with Notepad and see if it behaves differently? Try the one in syswow64 too which is the 32 bit version. – David Heffernan Jan 20 '11 at 20:53
  • @David: I never thought of manifests; I'll definitely try it, thanks. – user541686 Jan 20 '11 at 21:00
  • @Lambert No, my app behaves the same as Notepad++. It's bizarre, it offers both but system32 is actually syswow64 - sorry for being so slow. Do you know about C:\Windows\sysnative? That's a way to get to the 64 bit system32 folder from a 32 bit app. – David Heffernan Jan 20 '11 at 21:03
  • @David: Nope; same problem in Notepad... System32 is redirected but Program Files isn't. – user541686 Jan 20 '11 at 21:03
  • @David: Yes, I knew about SysNative, but the point is to let the user be able to browse folders correctly, and SysNative doesn't help unless the user is aware of it. :\ – user541686 Jan 20 '11 at 21:04
  • @Lambert it's a bit of a conundrum isn't it?!! – David Heffernan Jan 20 '11 at 21:12
  • @David: Yes, indeed it is... hence why it was annoying enough for me to post it here. Thanks for your help anyway. :) – user541686 Jan 20 '11 at 21:19
  • @David: Looking at the documentation, it seems that Program Files was never redirected at all! The *only* redirected folder is System32, and apparently, the dialog is in another thread, and calling `Wow64DisableWow64FsRedirection` can't change anything. Any idea how to get the UI thread to call this function? – user541686 Jan 22 '11 at 06:47