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.
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.
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.
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.
I did have an issue with that, I think I ended up putting Windows juce on the root of C:// which was the expected path and it worked after that.
There is something strange about Projucer and paths across the two, Each time I compile in windows, the Mac paths become invalid and the projucer project needs saving on the mac side which then corrects it.
Yes! That’s exactly what I’m seeing. It seems like saving a project on the Mac messes up the Windows JUCE paths, and then saving the project in Windows messes up the Mac paths, or something like that.
This is a sad situation as it was a very powerful way to work cross-platform, with only one Juce installation shared between Mac and Windows.
@reuk, can someone please take a look at this? It seems like it’s a Projucer issue. Maybe it doesn’t like the paths that Parallels uses to point the Windows installation. They look like this in my installation:
Path to JUCE: \\Mac\Dropbox\Programming\JUCE
JUCE Modules: \\Mac\Dropbox\Programming\JUCE\modules`
(Yes, that’s really 2 back slashes at the start of the path.)
I don’t use global paths. Instead I configure every module with a relative path, works even with shared filesystem in parallels. (path are relative to the jucer file, in this example the shared juce-folder is one directory level above the project folders)
tbh, it hasn’t really bothered me much, it only takes a second to save project and x-code updates instantly. It would be better if it didn’t do it though Although I currently only use VS for exporting release versions and so don’t use it much, I do all my developing in x-code. Overall I’m still pretty much in awe that it can be done at all.
I started a new project and I’m having a sort of ghost paths problem, all juce references in the headers in VS are highlighted in red and the source files say ‘cannot open’ however the project compiles fine. I’ve tried global paths, local releative to the jucer for each individeual module and even copy to project and none of it makes any difference. Even using my local windows C:\JUCE folder doesn’t clear it. But it always compiles without errors. weird.
Well I spent a few hours trying to get to the bottom of what was happening with VS, all of my projects had the same issue of none of the juce files being recognised. I also discovered that the File browser in my compiled apps weren’t working either, yet worked on an actual PC.
I tried everything I could think of and in the end started again with a new virtual machine. That’s solved the issue, and on another plus I can now debug too which was never possible for me on the other VM. I have this setup with everything i need and have made a copy of it so I can easily get back to this nice working state. All in all, a frustrating day but worth it.
I have no idea why this suddenly happened, I only use the VM for Sound Forge, Winrar, Visual Studio and 2-3 other tasks.
As for the paths, I’ve ended up using per module paths, relative for xcode & full path to C:\JUCE\modules & this seems to have stopped the having to resave issue I’ve always had.