Prefer 32-Bit with Any CPU Platform Target - Visual Studio 2012 Enhancements

Visual Studio allows us to compile our code targeting x86 or x64 platforms by clearly specifying platform targets. We can also compile against Any CPU option. This allows the run-time to JIT the assembly in 32 or 64-bit code based on the type of process it is loaded in. Compiling an application against 32-bit would not stop it from running on a 64-bit windows platform, it would just use WOW64. We have discussed about WOW64 long back here.

In order to target an application to 32 or 64-bit, we can just specify the platform target for the start-up project in its property page. I am sure the readers, of this blog, have seen this page a lot of times. Here you seen the Any CPU target. In Visual Studio 2010 the Build tab in project's property page looks as follows:



With other various updates, Visual Studio 2012 has improved on Any CPU a little. Now selecting Any CPU allows us to further qualify our selection. Please notice Prefer-32 bit option here.



Let's see how the IL looks like. You can see that the assembly is compiled differently.



The new framework should be able to handle this option. This is why you see the option greyed out when we select any such framework including .net framework 4.0. It should be available for .net framework 4.5.



This option is only for executable type of projects(*.EXE). For all other project types as well, you should find this option greyed out.

Compiling with 32-bit Preferred
Setting the option in Visual studio causes the new compiler switch to be used for the project. The project is compiled using C# compiler (csc.exe) with switch anycpu32bitpreferred You can find further details about the compiler switch here on msdn.

CorFlags 32-bit
As we know we can set / reset 32-bit flag using CorFlags tool available with Visual Studio. Well the tool has also been updated to support this extra details for such assemblies. Now there are two flags instead. They are 32BITREQ and 32BITPREF.



We can verify the setting of flag by opening an assembly compiled with this option selected. You can see that 32BITPREF flag has been set.



Effects of Setting 32BITPREF
Now we have see how to set this flag and how it would be reflected in the generated assembly. We still haven't discussed what it actually does. Or what it tells to the host framework running the application.

The difference in setting the switch or avoiding Any CPU would make all the difference when the executable is run on a 64-bit operating system. For an application compile without the switch would run it as a 64-bit process. Setting the option would still run it as a 32-bit process even on a 64-bit operating systems. As we know, we can identify a 32-bit process in Task Manager if we find a *32 with its name in Task Manager. We should continue to see them as 32-bit process in Task Manager. As we discussed before, this is exactly how our application should run if we are compiling it with x86 platform target.



The other difference is when the executable is run on ARM Windows system. The ones compiled using Any CPU wouldn't run on an ARM machine (Advanced RISC Machine). With 32-bit preferred, they run as a 32-bit process.

WPF - Porting applications to 64-bit (WOW64)

Many of the WPF projects are technology upgrade projects. After advent of WPF, everyone wants to get rid of old Win32 based display to cool WPF display with rich graphics. It is not just an upgrade of technology from Winform to Windows Presentation Foundation, but it is also upgrade in the underlying hardware architecture. New operating systems are 64-bit operating systems. While developing applications for these new operating system, we should be aware of the differences in the frameworks because of the architecture.

So desktop applications are going rich (using WPF) and they are being 64-bit. They will eventually be causing phase-out for 32-bit desktop applications. It also happens that these systems are not rolled off in a single shot. They are retired gracefully. I have even seen these systems co-exist for some duration before the old system is gotten rid of completely. So we have our 32-bit and 64-bit systems running on a 64-bit operating system.

Now the main question which might arise is, why should we go 64-bit. There are several benefits of developing 64-bit application. The maximum number for default thread pool thread increases from 1024 to 32768 in .net framework 4.0. 32-bit applications have a default address space limitation of 2 GB so going 64-bit increases the available address space for our applications.

When you look at Task Manager, you would find a few processes with *32 as part of their names. What is that?? Basically they are 32-bit processes running on 64-bit Windows. They are given special status in 64-bit OS and they are handled differently than their 64-bit counterparts.



How to develop 64-bit applications:
When we develop WPF applications, we can specify the intended platform for our application. Just take the properties of Startup project and go to Build tab. There are multiple options available for Platform Target. You can select the platform target of your choice. It can be 32-bit (x86), 64-bit (x64), Itanium or Any CPU (architecture-neutral). Here Any CPU is an interesting option. This is basically leaving the decision for run time. If the application is being run a 32-bit architecture, it would run as a 32-bit system, otherwise it would be running as per the architecture of the runtime. It is also possible that we have different target platform for Debug and Release configuration but that is rarely the case.



There has also been a little debate in the .net developer community about which option should be the default one. I would recommend reading this post discussing about why Any CPU should not be the default option. Currently, I find x86 as the default option for WPF application (.net 4.0) in VS2010 Ultimate.

http://blogs.msdn.com/b/rmbyers/archive/2009/06/08/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx

Handling of 32-bit applications by 64-bit Windows Operating System:
Windows OS handles 32-bit applications with WOW technology. This is acronym for Windows-32 on Windows 64. This is basically a 32-bit OS emulator for 32-bit applications running on 64-bit Windows Operating System. Its main purpose is to create an artificial environment for 32-bit applications so that they could run on 64 bit Operating Systems without any changes. I have seen people using both WOW64 and WOW. I don’t know what is the official name. In this post, I have noticed myself using both. But wherever you see it, now you should know that I am referring to the same thing. . Basically WOW is the similar layer in 32-bit Operating Systems for 16-bit applications. So I would recommend using the term WOW64 in order to understand the desired architecture as 64-bit architecture.

http://en.wikipedia.org/wiki/Windows_on_Windows

http://msdn.microsoft.com/en-us/library/aa384249(v=VS.85).aspx



As is evident from the figure above, it is just a compatibility layer for 32-bit operating systems.

Mapping System32 folder to sysWow64 folder



If a 32-bit application requests access to the system32 folder, file system redirector redirects the request to sysWow64 folder instead. This folder contains the 32-bit versions of dlls. In case we want to bypass this direction, we should be usign %windir%\Sysnative instead.

Registry Redirection:
Wow maps all Registry operations to Wow6432Node. When a 32-bit app creates, updates or deletes a registry key, all of these operations are mapped to Wow6432Node by default by WOW. This redirection is performed by a special component of Wow64, called Registry Redirector. This copying of registry values is called Registry Relecton or Registry Mirroring.



This is a special pain-point when 32-bit and 64-bit application co-exist on the same machine. Both of these applications would be specifying same registry values to access the relevant registry keys. But since WOW maps the operations to Wow6432Node, the 64-bit application wouldn’t be able to find those registry keys. We have to specially specify Wow6432Node in registry path for 64-bit applications if we are planning to use same registry values for both. Later, when 32-bit application is phased off, we need to make sure that we have updated the path for these registry keys. We also need to make sure that we have tested the system thoroughly for this change. This is basically an observed behavior for one of our application. As a matter of fact, Windows is documented to be mapping /mirroring registry keys to Wow6432Node registry folder. In .net framework 4.0, this problem is specially addresses by providing special OpenSubKey support in RegistryKey class. Here we can specify if we want to get this value as a 32-bit application or 64-bit application. If we get it using 32-bit application, it would be using Wow64 in order to get the value, otherwise it would directly get the value of the registry key.

http://msdn.microsoft.com/en-us/library/microsoft.win32.registrykey.openbasekey.aspx

http://en.wikipedia.org/wiki/WoW64

HKEY_LOCAL_MACHINE\Software is mapped to HKEY_LOCAL_MACHINE\Software\Wow6432Node.

Program Files Directory:
A special program files directory is also created for 32-bit applications in the directory where OS is installed (Generally C:\). This is available as Program Files (x86).


IsWow64Process Function
We can also determine if an application is running under WOW64 technology using IsWow64Process function.
http://msdn.microsoft.com/en-us/library/ms684139(v=vs.85).aspx

Additional properties in Environment:
If we are building our application for a particular platform or Any CPU, we might still want to determine if the current process is a 64 bit process or not. There are two additions is Environment to determine:

Whether it is a 64-bit Operating System:
http://msdn.microsoft.com/en-us/library/system.environment.is64bitoperatingsystem.aspx

Whether it is a 64-bit process:
http://msdn.microsoft.com/en-us/library/system.environment.is64bitprocess.aspx