How to support Windows on ARM platform

Guido · February 26, 2025, 7:15pm

For x64 Windows platform there are two compatible processor options: Intel and AMD.
For Arm64 Windows platform it first seems there is only one processor option: Qualcomm.
We have seen there is lack of suitable hardware with Qualcomm processor.

But there is another option supported by Microsoft:

Options for using Windows 11 with Mac computers with Apple M1, M2, and M3 chips

Windows 11 runs best on a PC designed for Windows. When such an option isn't available, here are two different ways to use Windows with Mac.

The two different ways given by Microsoft have one disadvantage:
They are expensive.
But there are two other ways which Microsoft doesn't mention which are inexpensive:
VMware Fusion and UTM (Universal Turing Machine) Virtual Machines (GitHub).
They are virtualization based like the Parallels Desktop solution mentioned by Microsoft and are not authorized by Microsoft, but seem to work as shown by instructions found on the Web.

MacBook Air is the only suitable hardware option for me, so the virtual machine method seems like the only viable solution.

I have now decided to use the authorized Parallels Desktop solution (with a perpetual license):

This is an 8 GB RAM device, which was the base memory configuration before 30 October 2024.
On 30 October 2024, with introduction of new M4 Macs, Apple raised the base memory configuration for all Macs to 16 GB RAM.

The base storage configuration is 256 GB SSD to date.
This is sufficient for one system, but may be a bit tight for two systems with the virtual machine.
Fortunately, you don't have to assign a fixed partition for each system, but the given volume is shared dynamically between the systems.
In this way, one can live with the given size.
Above you see that only about 100 GB of storage are used so far.
Mac side has installed Xcode IDE, Microsoft Office for Mac, and several other apps.
Windows side uses 26 GB of storage for bare system installed and configured, before installing any other apps:

Notice that SSD is connected via virtual SATA adapter.
Network is connected via virtual Ethernet adapter, MacBook device itself is wireless connected as usual:

Everything works well so far.
Next step: install and run Visual Studio...

Regards
Guido
JPEG developer

Guido · February 28, 2025, 7:15pm

Fixed an issue because I made manual instead of automatic installation.

Have proper Graphics support now:

Moving forward to Visual Studio installation...

Regards
Guido
JPEG developer

Guido · March 3, 2025, 8:40pm

Visual Studio 2022 version 17.4 was the first to run natively on ARM.
Here is current version 17.13 up and running:

You see automatic synchronization happening with Parallels: Desktop icons are automatically shared between Windows and Mac. This is useful when switching to coherence view mode, where Windows desktop is hidden and Windows apps appear directly on the Mac desktop:

You see also a typical Mac menu bar synthesized in this case by Parallels for the Windows application, including About window which you see opened on the left side.

Note also that running Windows applications appear on the Mac dock below (something like the Windows Taskbar) in the same way as and beside the Mac apps.
You can still see GraphicConverter there which I just used for the Labels Under Thumbnails - More Options Please thread.
The Visual Studio icon next to the trash can is from the Visual Studio Setup program in the Downloads folder which is also automatically shared. I downloaded it with the Edge browser in Windows.

Here are shots of the Visual Studio Installer which is used for updates and configuration:

So far, everything looks perfect.

Next and last step: build and run a sample app.

Regards
Guido
JPEG developer

Guido · March 5, 2025, 9:40pm

Side information:

Apple has today released the next generation MacBook Air with M4 chip.

Instead of raising the base storage configuration to the next level, Apple opted to lower the price for the base configuration with the given 256 GB of SSD storage.

This is good news for the cost-sensitive user.

The base configuration is important for the cost-sensitive user, because any higher configuration option has a premium price supplement.

Here is the actual storage situation after Visual Studio installation:

The Windows virtual machine appears as a "document" of the Parallels Desktop application.

Thanks to the dynamic volume sharing of the virtual machine, storage situation is still appropriate.

Microsoft has not yet updated their support statement given above beyond the M3 generation, but Parallels have already stated their commitment for support of all Apple M chip generations up to M5 here.

Regards
Guido
JPEG developer

Guido · March 12, 2025, 12:25am

Before we build and run a sample application to check the proper function of the Visual Studio IDE:

We will cover both ARM and non-ARM (x64/x86) host and target platforms with a single solution/project, so everyone can follow the procedure.

As shown above, we need the Desktop development with C++ workload in the Visual Studio Installer.

Our application uses MFC (Microsoft Foundation Classes), so we need to install additional components.

MFC depends on ATL (Active Template Library). While ATL is enabled in the workload by default, MFC is not.

The ARM version of Visual Studio installs the build tools and ATL by default for both ARM and non-ARM (x64/x86) platforms, so we only need to enable the MFC for ARM and non-ARM (x64/x86) platforms by checking the selectors in the Optional components section of the workload:

The non-ARM (x64/x86) version of Visual Studio installs only the non-ARM (x64/x86) build tools and ATL by default.
Here we first enable MFC for non-ARM (x64/x86) platforms by checking the selector in the Optional components section of the workload, and then we select the build tools, ATL, and MFC for ARM64/ARM64EC from the Individual components tab beside the Workloads tab, which then appear in a separate Individual components section below in the workload:

The Individual components list may appear a bit confusing, so take care to select the proper items.
Notice that 32-bit ARM build tools et cetera are also available in the Individual components list, but the recent Windows 11 SDK build 26100 drops support for 32-bit ARM, so we can ignore it.

The Windows SDK installed by Visual Studio by default (above in the list) is not the most recent version, that's why I have disabled it.
You find the item for the newer SDK build 26100 below in the Optional/Individual components list, but even that is not the most recent (sub-)version, therefore I currently manage the Windows SDK installation manually outside Visual Studio.
For the purpose here you can use any SDK version provided by Visual Studio, so you don't need to modify the default setting regarding the Windows SDK version.

On x64/x86 systems you can also use Visual Studio 2019, which is a 32-bit x86 application. In this case the ARM64EC components are separate from the ARM64 components and are marked as experimental, so the selection looks as follows:

On initial start of the Visual Studio IDE, it prompts you to make two choices: The Visual Studio environment configuration or so - I use Visual C++ here, and the Theme - I choose Blue here.

Now we are prepared to build and run the sample application to check the proper function of the Visual Studio IDE...

Regards
Guido
JPEG developer

Guido · March 13, 2025, 8:00pm

Now we can build and run a sample application to check the proper function of the Visual Studio IDE:

SimpleImage.zip (20.8 KB)

Open the solution file SimpleImage.sln in the Visual Studio IDE.
On the menu bar, choose Build > Batch Build...
Select the check boxes for the desired configurations as follows and then hit the Build button or Enter key:

We get following alert during build but we can ignore it:

_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)

The build procedure works on all host systems in the same way.
In the respective subfolder you can now start the exe program:

You see the ARM64 version running.
On the Windows 11 ARM (virtual machine) system, all versions are running: The ARM64 and ARM64EC versions run natively, the Win32 and x64 versions run emulated.

When you try to run the ARM64 version on an x64 system, you get following error message:

That is the reason why we need all this effort: we cannot run ARM code on x64.

Running the ARM64EC version on Windows 11 x64 will do nothing, while Windows 10 x64 creates following error message:

The source of the sample program is a legacy from Microsoft here, pointing to repository here.
I did only minimal changes to make it work somewhat properly, and then added the ARM configurations.
To avoid DLL (Dynamic Link Library) complications during runtime, MFC is linked statically during build.
This makes the executable program files larger, but better portable.

Conclusion:

QuUCK Falcomm!

Sorry, I know this is disrespectful, but I couldn't resist.

I'm all for freedom, so people can use whatever they want as long as they don't do harm and let me use what I want.

It's not the fault of Qualcomm alone, but also the device manufacturers not being able to provide suitable hardware.

Kudos to Apple, Microsoft, and Parallels for providing an alternative solution!

And can support two different platforms (macOS and Windows) with one device, so killing two birds with one stone.

Regards
Guido
JPEG developer