LabVIEW on Windows 11 ARM inside Parallels on M1 Mac

[Michael Aivaliotis]

Does anyone have any experience running LabVIEW on Parallels on the new M1 Macs?

I need to upgrade my Intel Mac to an M1 and was wondering if there are any gotchas. I already know that I need Windows11 ARM. But will that work ok with LabVIEW and how about the drivers? Will Windows emulation cover all the issues?

[LogMAN]

I don't have any experience with Macs, but there is a topic in the LabVIEW 2021 Beta Forum related to Apple M1 chips: [New Feature] macOS Big Sur Support - NI Community

[hooovahh]

That thread looks promising.

I experimented with Windows 10 ARM by putting it on a Raspberry pi, then trying to run LabVIEW programs.  At the time the x86 emulation built into Windows 10 didn't support several SSE extended CPU instructions, and LabVIEW EXEs wouldn't run.  After rolling back to LabVIEW 2016 I was able to disable those instructions, make a build, and run the EXE.  I didn't attempt to run the IDE because even installing the runtime was difficult with various MSI installers needing to be manually installed. 

[Michael Aivaliotis]

16 hours ago, LogMAN said:

I don't have any experience with Macs, but there is a topic in the LabVIEW 2021 Beta Forum related to Apple M1 chips: [New Feature] macOS Big Sur Support - NI Community

Thanks for that link. However, that post is for running LabVIEW on MacOS natively, not inside of parallels with Windows.

[Neko]

I would love to get this going myself. I've been developing in Parallels on Intel Macs for years. The problem I see currently is drivers for pretty much everything. I use FTDI-based devices and they have some ARM drivers in beta-ish format. But I also use a lot of ARM-based Arduino boards, and there is no support for the Arduino IDE or for recognizing the boards. So sort of stuck for now.

[emcware]

I have been using Parallels on my Mac to develop LabVIEW (for Windows) code for years and have been very happy with it.  I have been trying for some time to get this working with the M1 chip.   I have an Apple M1 Mac mini and more recently, an M1 MacBook Pro.   Installing Windows 11 ARM is straightforward.   LabVIEW does install and I am able to partially open my projects but I have a lot of packages as dependancies and am not able to get VI Package Manager to work.  But more significantly, every time I install NI-Max, it kills Windows and I am no longer able to boot.    I recommend you keep ‘Snapshots’ of your Parallels VMs as you get thinks working.   Hopefully you will have more success than me.  

[hooovahh]

This looks similar to the issue I mentioned earlier with SSE instructions.  The guess at the time was that the translation layer of Windows for ARM for running x86 applications, didn't fully support all the instructions.  This is why in my experimentation with LabVIEW on Windows 10 on a Pi, I had to go with LabVIEW 2016.  With 2016  there is settings in the application builder that can turn SSE optimizations off.  Since VIPM is built using LabVIEW using those SSE instructions, it can't run.  MAX corrupting Windows is a new one.

[Jacob7]

On 1/6/2022 at 12:58 PM, emcware said:

I have been using Parallels on my Mac to develop LabVIEW (for Windows) code for years and have been very happy with it.  I have been trying for some time to get this working with the M1 chip.   I have an Apple M1 Mac mini and more recently, an M1 MacBook Pro.   Installing Windows 11 ARM is straightforward.   LabVIEW does install and I am able to partially open my projects but I have a lot of packages as dependancies and am not able to get VI Package Manager to work.  But more significantly, every time I install NI-Max, it kills Windows and I am no longer able to boot.    I recommend you keep ‘Snapshots’ of your Parallels VMs as you get thinks working.   Hopefully you will have more success than me.  

 

On 1/6/2022 at 12:58 PM, emcware said:

I have been using Parallels on my Mac to develop LabVIEW (for Windows) code for years and have been very happy with it.  I have been trying for some time to get this working with the M1 chip.   I have an Apple M1 Mac mini and more recently, an M1 MacBook Pro.   Installing Windows 11 ARM is straightforward.   LabVIEW does install and I am able to partially open my projects but I have a lot of packages as dependancies and am not able to get VI Package Manager to work.  But more significantly, every time I install NI-Max, it kills Windows and I am no longer able to boot.    I recommend you keep ‘Snapshots’ of your Parallels VMs as you get thinks working.   Hopefully you will have more success than me.  

Did you figure out how to get it installed? I'm currently experiencing the same problems. I was able to install base LV with the math toolbox but nothing else. Bricks my machine every other time. I've gone through ~25 Windows 11 snapshots trying to get at least some basic add-ons installed like DAQ, but haven't had any luck  

[X___]

This is why I switched to a ThinkPad in Dec. 2020. No regrets whatsoever.

[Justin Goeres]

I took a crack at this when I got my M1 back in December and got nowhere, but now I have progress.

TL;DR it doesn't work yet, though.

I've been working to get Windows x86 to stand up on UTM (which I gather is really just a fancy frontend to QEMU). I'll write things up better when I have something real to show for it, but so far:

• I can't get it to install Win11 x86, because it seems to insist there's an architecture mismatch. I suspect this is an error on my end, since it was the first thing I tried and I may have misunderstood some of the config.
• I did get it to boot and install Win10 x86. However, when I rebooted after install, Windows gets angry about not being able to find the "Desktop" for the user, and kind of loses its mind. This is also possible my error somewhere, but I haven't gone back to figure it out.

I'm not super optimistic about this, since ultimately it'll be running emulated, not under virtualization. So speed is likely to be not great. But it's at least a potential way forward and if somebody else wants to give it a shot, UTM may be an option.

[Rafael R]

On 1/27/2022 at 12:20 AM, Justin Goeres said:

I took a crack at this when I got my M1 back in December and got nowhere, but now I have progress.

TL;DR it doesn't work yet, though.

I've been working to get Windows x86 to stand up on UTM (which I gather is really just a fancy frontend to QEMU). I'll write things up better when I have something real to show for it, but so far:

• I can't get it to install Win11 x86, because it seems to insist there's an architecture mismatch. I suspect this is an error on my end, since it was the first thing I tried and I may have misunderstood some of the config.
• I did get it to boot and install Win10 x86. However, when I rebooted after install, Windows gets angry about not being able to find the "Desktop" for the user, and kind of loses its mind. This is also possible my error somewhere, but I haven't gone back to figure it out.

I'm not super optimistic about this, since ultimately it'll be running emulated, not under virtualization. So speed is likely to be not great. But it's at least a potential way forward and if somebody else wants to give it a shot, UTM may be an option.

 

Do you managed to get this working? I'm not looking at LabView but 488.2 drivers, that are not available for windows arm, just x86,  I was thinking in running QEMU/UTM to get x86 windows and use usb passthrough to get NI software in this ""VM"". 

Thanks 

[Sascha]

Hi, I think all the formerly happy Mac-Parallels-Windows-LabVIEW developers, me included, are trapped on the INTEL platform.
I don't see NI going anywhere with ARM. Get prepared to buy a Windows-INTEL-laptop in the future. 🤢

[Rolf Kalbermatter]

On 1/26/2022 at 5:56 AM, Jacob7 said:

 

Did you figure out how to get it installed? I'm currently experiencing the same problems. I was able to install base LV with the math toolbox but nothing else. Bricks my machine every other time. I've gone through ~25 Windows 11 snapshots trying to get at least some basic add-ons installed like DAQ, but haven't had any luck  

Any hardware driver is almost certain to not work. Those hardware drivers depend on kernel drivers that must run in the Windows kernel. And it is almost certainly not possible to fully emulate the x86 hardware in ring1, which is the CPU mode in which the kernel executes. Emulating that part with all the ring context switches that must occur whenever the code execution transitions between kernel and user space is something that no CPU emulator does get fully right to this day.

Same issue exists when you try to run x64 LabVIEW on a M1 Apple. LabVIEW itself works with minor tweaks to some MacOSX configuration settings for the LabVIEW application but don't try to get any hardware driver installed if you do not like to brick your MacOSX installation. Rosetta2, which is the Apple equivalent for emulating an x64 CPU on the M1 does a remarkable job for user space code but Apple explicitly states that it can NOT emulate an x64 CPU in kernel space and actively tries to prevent the system from trying to install one anyhow.\

I suppose Apple might have been able to create a Rosetta version that even works for kernel mode code but I have a strong suggestion that they wanted this to work before the end of this decade, so purposefully limited the scope to only emulate user space code. 😁

Edited June 22, 2022 by Rolf Kalbermatter

[Rolf Kalbermatter]

5 hours ago, Sascha said:

Hi, I think all the formerly happy Mac-Parallels-Windows-LabVIEW developers, me included, are trapped on the INTEL platform.
I don't see NI going anywhere with ARM. Get prepared to buy a Windows-INTEL-laptop in the future. 🤢

Actually, supporting the M1/M2 chip would not be such a big deal for NI as far as LabVIEW goes. The LLVM compiler backend they use already supports that chip for quite some time. And the MacOSX version of LabVIEW itself shouldn't really give to many problems to compile with XCode for targetting the M1 hardware since they already did that for quite some versions before and the 64-bit version of LabVIEW for Mac did away with quite a few of the older Carbon compatibility interfaces.

What will be trickier is support for DAmx, NI-488.2 and other hardware interface drivers. Not impossible but quite a bit of work to get right and the most intense part is probably all the testing needed.

[Sascha]

Yep, NI won't do this work. They majorly of the developers are on Windows/INTEL and will be in the foreseeable future. 

macOS LabVIEW is quite nice, actually. I use it for some basic development on component level. But I'll always need to do some block diagram beautifying and front panel rework if I want to use it in Windows. 

[Rolf Kalbermatter]

1 hour ago, Sascha said:

Yep, NI won't do this work. They majorly of the developers are on Windows/INTEL and will be in the foreseeable future. 

Actually they might, but the Mac does form an extra obstacle. For Linux they were pretty much on track to provide finally a real DAQmx driver since they had to develop it for their cRIO platform anyhow. The only problem is the packaging as there are not only at least three different package formats out there (rpm, deb and opkg, with the last one used for the NI embedded platforms) but also many other egregious differences between distributions that make installing a hardware support package a complete pain in the ass. And that is not even mentioning the kernel folks war to fight against allowing non-open sourced kernel drivers to run in their kernel.

Quote

macOS LabVIEW is quite nice, actually. I use it for some basic development on component level. But I'll always need to do some block diagram beautifying and front panel rework if I want to use it in Windows. 

That is in the nature of the beast. These platforms have fairly differing ideas about layout composition in the underlying graphics subsystem and to make matters not to easy there always remains the issue about fonts and their licensing which makes transfering a layout pixel accurate across systems pretty much impossible. Unfortunately the LabVIEW folks choose to implement a pixel based UI system rather than an arbitrary graphics coordinate system but that is understandable. The only platform back in those days that had some form of more abstract coordinate system was Quickdraw on the Mac (and XWindow also has some more abstract coordinates as it was from begin designed to be a remote API where the client did not know, nor care, about the actual graphics hardware used on the server, and sometimes the server has no graphics hardware of its own). Windows GDI was purely pixel oriented and that cost Microsoft a lot of hacks later on to support high resolution displays in Windows. GDI still in essence is pixel based to the current day and that is the API LabVIEW uses to this day to draw to the screen.

Edited June 23, 2022 by Rolf Kalbermatter

[X___]

As mentioned earlier, I have happily left the Apple eco-system at the end of 2020, but one of my users is a die-hard macOS fan and has decided to try running my 2021 SP1 64 bit executable on a M1 MBP running Parallels Desktop 18 (Windows 11 VM).

The code looks like it works fine, until some weird differences with the native Windows app start popping up.

For instance, a variable loaded from an XML file is internally converted to a value that is ever so slightly different than the one it adopts on a PC (as seen in a printout of the value converted to ASCII). In an another instance, the comparison of two floating point values, loaded from two different files, which "passes" a preset criterion on PCs, fails the test on the VM...

I don't see that there is any way to easily predict this type of problems and foolproof the code against them, so I believe I will just not recommend trying to use Parallels Desktop VMs to use my code on a Mac.