Other than to say that it's 64-bit. I don't think there's any functional reason for it. Or am I missing something?
-mwb1100
There are only minimal, for most user not relevant reasons, like:
- you can't browse to folder "sysnative" (the 64-bit-"system32" folder from the view of a 32-bit program on 64-bit OS)
- you can't allocated more than 3,5GB RAM for processes launched from a 32-bit program (as in starting a program from within the 32-bit app, which in turns needs many RAM for processing)
- every app started from an 32-bit app will only see the 32-bit environment (as in launching Regedit and you will not see "Syswow6432node")
For such tasks you will have to utilize WinExplorer.
Most user this may not affect, it could only led to confusions if you would look for something above mentioned from within a 32-bit app.
All in all no real reason from standing back from a 32-bit app on 64-bit OS. Most user will never see any differences.
-AbteriX
These issues either have been solved by XY or they just don't apply to XY in the first place:
- Even though it's a 32-bit application, XY will show the 'real' System32 directory without having to use the sysnative alias hack (there are APIs a 32-bit application can use to tell Windows to stop the redirection). There's a configuration option to turn this behavior on/off ("Show the real System32 directory"), but it's on by default, I think. So when you navigate to the System32 directory, you will see the same files that are actually in the System32 directory just as if a 64-bit file manager were browsing that directory.
- being limited to 3.5GB of virtual memory is unlikely to be a limitation to XY. In fact, I'm sure most users would be up in arms if they noticed it using more than a few hundred MB (mine is using around 70MB at the moment). The virtual memory limitation of a 32-bit process has no bearing on the virtual memory available to processes launched - they get their own allocation of virtual memory that is completely separate from the launching process.
- again, an app launched from XY has it's own virtual memory allocation and the WOW64 redirection that the OS imposes on 32-bit process has nothing to do with the process that launches an app. If the newly launched process is 32-bit, then it will get the WOW64 redirections whether or not it is launched from a 64-bit or 32-bit app. Similarly, a 64-bit app launched from a 32-app will *not* have those redirections applied, and will have the full terabytes-large virtual address space available to it.
So the bottom line is that with XY configured to show 64-bit shell extensions, it's functionally equivalent to a 64-bit file manager as far as I know. Doing a ton of work to make it a true 64-bit application would be a compete waste of effort for no gain other than to be able to say "XY is a 64-bit app".
And to waste Don's efforts on that would be a shame.
