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.
#XYPLORER COM FULL#
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. 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. 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.
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. 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). being limited to 3.5GB of virtual memory is unlikely to be a limitation to XY. 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.
There's a configuration option to turn this behavior on/off ("Show the real System32 directory"), but it's on by default, I think.
#XYPLORER COM WINDOWS#
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). These issues either have been solved by XY or they just don't apply to XY in the first place:
0 kommentar(er)
