Program Files (x86) and SysWOW64 folders explained
1–9 of 9 posts
Re: Program Files (x86) and SysWOW64 folders explained
#2Just remember MS names everything bass-ackwards and it all makes sense. Or incredibly verbose bordering on insane... "Documents and Settings" anyone? How about no permissions implemented but "Don't look in here" banners in Explorer. :-D
Re: Program Files (x86) and SysWOW64 folders explained
#3> you should always install files with a specific bitness to the correct Program Files folder.
I’m pretty sure there’s some API or environment variable to tell you where to install files. Instead of codifying the past yet again.
Re: Program Files (x86) and SysWOW64 folders explained
#4> 64-bit computer with a 64-bit Windows can handle so much RAM memory as 192 GB!
Can anyone explain from where this number comes from?
on 32bits you can address 4GiB, but using 64bits you are able to address 16EiB 38bits is enough to address 256GiB so 192GiB doesn't look like any technical limitation
Re: Program Files (x86) and SysWOW64 folders explained
#5> you should always install files with a specific bitness to the correct Program Files folder. I’m pretty sure there’s some API or environment variable to tell you where to install files. Instead of codifying the past yet again.
[deleted]
Re: Program Files (x86) and SysWOW64 folders explained
#6> But what about 32-bit applications that have the system path hard coded and is running in a 64-bit Windows? How can they find the new SysWOW64 folder without changes in the program code, you might think. The answer is that the emulator redirects calls to System32 folder to the SysWOW64 folder transparently so even if the folder is hard coded to the System32 folder (like C:\Windows\System32), the emulator will make sure that the SysWOW64 folder is used instead. So same source code, that contains a path with the System32 folder included, can be compiled to both 32-bit and 64-bit program code without any changes.
This always rubbed me the wrong way. We can’t rename “System32” because it’ll break apps. So we intercept 32 bit apps into SysWOW64? Why not intercept 64 bit accesses to System32 and rewrite them to System64 or whatever?
Re: Program Files (x86) and SysWOW64 folders explained
#7Another fun caveat to this that's extremely poorly documented:
If you have a 32-bit process that needs to be redirected into the 64-bit namespace, you have to use C:\Windows\sysnative. The folder only exists when you use 32-bit cmd.
https://www.samlogic.net/articles/sysnative-folder-64-bit-wi...
Re: Program Files (x86) and SysWOW64 folders explained
#8> 64-bit computer with a 64-bit Windows can handle so much RAM memory as 192 GB! Can anyone explain from where this number comes from? on 32bits you can address 4GiB, but using 64bits you are able to address 16EiB 38bits is enough to address 256GiB so 192GiB doesn't look like any technical limitation
Just licensing from what I understand, historically if you patched the licensing limitations higher amounts of RAM always worked fine.
Re: Program Files (x86) and SysWOW64 folders explained
#9> 64-bit computer with a 64-bit Windows can handle so much RAM memory as 192 GB! Can anyone explain from where this number comes from? on 32bits you can address 4GiB, but using 64bits you are able to address 16EiB 38bits is enough to address 256GiB so 192GiB doesn't look like any technical limitation
Just licensing from what I understand, historically if you patched the licensing limitations higher amounts of RAM always worked fine.
Honestly, the idea of licensing influencing how much of your hardware you can actually use seems like an ass-backwards concept to me.