Monterey M1 > Parallels Windows 11 > Visual studio > compiling JUCE

I’ve just got an M1 mac mini for compiling juce projects and thought I’d give running W11 a go in the parallels desktop a go. I’m really surprised how well it works and integrates, I’ve installed sound Forge and it’s almost as though it’s native to the MAC.

So I installed MSVS and it gave a warning that it isn’t supported but I went ahead anyway, I gave the juce test GUI project a try and in debug mode it didnt work, it asked to download some symbols which didn’t help. I was expecting it not to work, then I tried the Release configuration and to my surprise that compiled and ran without a problem. I haven’t tried running it on an Intel machine yet though.

Has anyone else messed around with this? It would seem a good move for Microsoft to start selling license for the arm version of windows you’d think. The whole concept of these 2 OS’s running at the same time and fully interacting is just mind blowingly good for end users that need to work on both.

I’ll have another mess around over the weekend to test MSVC further when I have a bit more time.

1 Like

Which VS version are you using?
I’m running VS 2022 on Parallels with Windows 11arm on an MacBook Pro 14 M1 Max 32GB.
It kind-of works, I’m able to run/debug standalone applications, debugging a plugin through a host can be more tricky. I mostly use it as an editor, because I’m very used to the Visual Assist plugin, the productivity advantage is much higher than the slower compilation time + I have the same project simultaneous open in Xcode and Visual Studio (using a shared folder) which is kind-of amazing.


VS 2022 Community. Yeah, I’m a windows person who is currently discovering how naff Xcode is in comparison. That’s promising that you have debug working, any tips on how you got it going? It suggested downloading a load of symbols which I said yes to but it didn’t help. I’ve only spent around 20 minutes with it so far, but even without the debugging being able to compile windows versions in the same session is amazing.

I still haven’t quite got my head around how the integration works yet, it’s so weird it uses the same MAC documents folder as My Documents.

One of the biggest issues I have with using a MAC as a primary PC is no sound forge support, I use it all the time and can’t do without it’s scripting engine. Having it sitting there as though it belongs on a silicon based Mac is just crazy. I’m really impressed with this machine so far, only had it 2 days, but I think it will become my main work machine now.

What happens when debugging, does it freeze? Maybe not enough resources, RAM for the windows instance?

I still haven’t quite got my head around how the integration works yet, it’s so weird it uses the same MAC documents folder as My Documents.

That the first thing switched off in the configuration. I only share the development folder from Mac, as separate drive in windows.

It came up with an error. I do only have the 8GB miniMac, I’ll have another mess around at the weekend to see if I can get any further. It’s good to have validation that it works.

I did copy the project I’m working on across and it couldn’t find juce even though the paths were correct in projucer, it was early hours so that’s the point I went to bed.

Some years ago I followed the same route of having the same codebase accessible from macOS and Windows through a shared folder, and that proved to be the cause of the (much) slower compilation time on Windows.

Just in case, you may try to clone a local copy of your repo into the Windows VM and see if it build faster from there than from the shared folder.


For the fact that the compiler itself is x64 emulated on windows arm virtualized on mac arm i think it’s relatively acceptable.

1 Like

The biggest improvement I saw in compilation time on Windows besides using an SSD for my VM via Thunderbolt 3 was to exclude all the temporary folders VS uses and all processes and the project folder from Windows Defender.