> 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?

> 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.

Another 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...

> 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 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