Parallels tech preview for M1

[SquealingCustard]

One question, can you get Event Viewer to work? I haven't spent any time on it yet, but not having that makes it harder to figure out what's going on.

Never had a problem with event viewer on mine running latest dev build so yours should be fine I reckon

 

[bobcomer]

Why not just get a router with a vpn server at home then? Problem solved. I switched from a MBP 16" with 2TB and 32 ram to a M1 MBP. What a great relief. I hate when the computer is hot, keyboard etc etc. I just VPN home and start RDP.

Comcast in a word. They keep switching on their advanced security which blocks external IP addresses that try incoming connections. I do have a VPN setup, just can't trust it. I can, and do, use my work VPN, but I also have to watch the bandwidth as the connection is a fairly slow one.

I use Parallels Access for quick stuff, but the browser interface isn't good enough to "work".

I'm thinking I probably should have went with the MBP too for the cooling, but didn't want to risk it not working for anything. Normally the MBA runs cooler than any of my Windows laptops, but running UTM gets it quite warm and it starts throttling pretty quick.

 

[bobcomer]

Never had a problem with event viewer on mine running latest dev build so yours should be fine I reckon

Interesting. It doesn't work at all for me, it just disappears. Oh well, it was doing an OS update last night, so hopefully it will work when I test it again. (I had just switched to the dev build to get that update last night.)

 

[SquealingCustard]

Comcast in a word. They keep switching on their advanced security which blocks external IP addresses that try incoming connections. I do have a VPN setup, just can't trust it. I can, and do, use my work VPN, but I also have to watch the bandwidth as the connection is a fairly slow one.

I use Parallels Access for quick stuff, but the browser interface isn't good enough to "work".

I'm thinking I probably should have went with the MBP too for the cooling, but didn't want to risk it not working for anything. Normally the MBA runs cooler than any of my Windows laptops, but running UTM gets it quite warm and it starts throttling pretty quick.

I found running ACVM from https://github.com/ubenmackin/ACVM along with install the virtio-gpu drivers much better than UTM and it uses your Mac hardware cursor so no messing about clicking buttons to get the mouse to interact between windows and osx.

However you do sacrifice shared folders (not got that to work yet under ACVM)

 

[SquealingCustard]

Interesting. It doesn't work at all for me, it just disappears. Oh well, it was doing an OS update last night, so hopefully it will work when I test it again. (I had just switched to the dev build to get that update last night.)

If you run mmc.msc then add/remove the event viewer snap-in does that work?

 

[bobcomer]

I found running ACVM from https://github.com/ubenmackin/ACVM along with install the virtio-gpu drivers much better than UTM and it uses your Mac hardware cursor so no messing about clicking buttons to get the mouse to interact between windows and osx.

However you do sacrifice shared folders (not got that to work yet under ACVM)

Does it run x86 OS's? I might give it a look, thanks! Shared folders isn't a concern for me.

 

[bobcomer]

If you run mmc.msc then add/remove the event viewer snap-in does that work?

I hadn't tried that yet. Good advice though, and something I don't usually remember is possible.

 

[SquealingCustard]

Does it run x86 OS's? I might give it a look, thanks! Shared folders isn't a concern for me.

It's basically like UTM a front end app to Qemu with the patches from Alexander Graf for the M1 so will also run x86 OS's

 

[KingOfPain]

It's basically like UTM a front end app to Qemu with the patches from Alexander Graf for the M1 so will also run x86 OS's

According to its GitHub log work has been started to be able to use ACVM for x86 emulation as well, but I don‘t know if it‘s finished yet and it certainly isn‘t part of the latest release:

Comparing v1.5...main · ubenmackin/ACVM

GUI frontend for qemu for Apple Silicon based Macs - Comparing v1.5...main · ubenmackin/ACVM

github.com

Long story short, ACVM currently only supports ARM64 virtualization.

 

[SquealingCustard]

According to its GitHub log work has been started to be able to use ACVM for x86 emulation as well, but I don‘t know if it‘s finished yet and it certainly isn‘t part of the latest release:

Comparing v1.5...main · ubenmackin/ACVM

GUI frontend for qemu for Apple Silicon based Macs - Comparing v1.5...main · ubenmackin/ACVM

github.com

Long story short, ACVM currently only supports ARM64 virtualization.

Oops my bad.

 

[Gerdi]

That's a really stupid question.
-edit:
Sorry, a first reaction, but, of course I know you have to install Java, I do on every PC I set up and it's part of my job!

My question was more related to the aarch64 version of OpenJDK - and not some x86/x64 versions.

 

[Gerdi]

1. Powershell commands I use for scripting throw back errors about missing libraries
2. Pretty much every Windows store app including the Windows store app itself crash out (not used but annoying)
3. Teams refuses to work (works fine in qemu) so probably an issue with Parallels itself (not tried the java suggestion)

As a balance

x86 apps Office 365 , NotePad++ (I swear by this) , Edge , Teamviewer 9 (yuck) , and all my works remote monitoring and management apps all work amazingly well with very few if no crashes whatsoever and this is a good sign of things to come, I just expected "more" after the seamless experience on my M1 MacBook Pro.

You have to understand, that Windows ARM also supports ARM32 executables. So the compatibility is somewhat restricted on M1 due to the fact, that M1 does not support ARM32. There are quite a few applications, including the Windows Store itself for example, which are ARM32 and would run nicely whenever the HW supports it. Also many store apps are ARM32.
So yes, app compatibility is lower on M1 than on native Windows ARM devices - but it is not a flaw of Windows ARM but rather limited ARM32 compatibility on M1.

 

[Gnattu]

So yes, app compatibility is lower on M1 than on native Windows ARM devices - but it is not a flaw of Windows ARM but rather limited ARM32 compatibility on M1.

It's true that is not a flaw, but such situation should not happen given all officially supported Windows ARM devices are using arm64 Socs.

Microsoft just want to be lazy to use the Windows RT era stuff hence the arm32 binaries.

 

[Gerdi]

It's true that is not a flaw, but such situation should not happen given all officially supported Windows ARM devices are using arm64 Socs.

Microsoft just want to be lazy to use the Windows RT era stuff hence the arm32 binaries.

Supporting ARM32 is a feature in the first place. Its not just about Microsoft apps - which are just a few -but many 3rd party apps as well - but i guess it is "en vogue" to bash Microsoft for implementing a feature. Besides all supported ARMv8 devices (and even most unsupported like the Raspberry PI) do have an ARM32 mode, which is part of the ARMv8 spec.
There is just no incentive to port an existing ARM32 app to ARM64 if your OS and all supported SoCs are compatible.

 

[Gnattu]

an ARM32 mode, which is part of the ARMv8 spec.

arm32 mode is optional for armv8, not required, the assumption of all armv8 Socs will have 32bit compatibility mode is wrong in the first place.

 

[UCDHIUS]

Not sure if this was already posted or not.

New WoA dev channel build is out

Announcing Windows 10 Insider Preview Build 21292

UPDATE 1/15/21: We are starting to roll out Cumulative Update Build 21292.1010 (KB4601937). This update does not include anything new and is designed to test our servicing pipeline.

blogs.windows.com

 

[SquealingCustard]

You have to understand, that Windows ARM also supports ARM32 executables. So the compatibility is somewhat restricted on M1 due to the fact, that M1 does not support ARM32. There are quite a few applications, including the Windows Store itself for example, which are ARM32 and would run nicely whenever the HW supports it. Also many store apps are ARM32.
So yes, app compatibility is lower on M1 than on native Windows ARM devices - but it is not a flaw of Windows ARM but rather limited ARM32 compatibility on M1.

Thank you for the explanation.

 

[Gerdi]

arm32 mode is optional for armv8, not required, the assumption of all armv8 Socs will have 32bit compatibility mode is wrong in the first place.

I do not believe that Aarch32 execution state is optional in the ARMv8-A architecture specification. If you do believe so, please point me to the part in the spec, which states that Aarch32 execution state is optional.

Quick Quote from the ARMv8-A spec (chapter A1.1):

"An important feature of the Armv8 architecture is backwards compatibility, combined with the freedom for optimal implementation in a wide range of standard and more specialized use cases. The Armv8 architecture supports:
• A 64-bit Execution state, AArch64.
• A 32-bit Execution state, AArch32, that is compatible with previous versions of the Arm architecture.

Note
The AArch32 Execution state is compatible with the Armv7-A architecture profile, and enhances that profile to support some features included in the AArch64 Execution state.
Features that are optional are explicitly defined as such in this Manual."

Likewise there is also no feature-ID register (which exists for all optional features), where a SW implementation could detect the absence of Aarch32. This is considering architecture updates up to ARMv8.5-A.

 

[jdb8167]

I do not believe that Aarch32 execution state is optional in the ARMv8-A architecture specification. If you do believe so, please point me to the part in the spec, which states that Aarch32 execution state is optional.

Quick Quote from the ARMv8-A spec (chapter A1.1):

"An important feature of the Armv8 architecture is backwards compatibility, combined with the freedom for optimal implementation in a wide range of standard and more specialized use cases. The Armv8 architecture supports:
• A 64-bit Execution state, AArch64.
• A 32-bit Execution state, AArch32, that is compatible with previous versions of the Arm architecture.

Note
The AArch32 Execution state is compatible with the Armv7-A architecture profile, and enhances that profile to support some features included in the AArch64 Execution state.
Features that are optional are explicitly defined as such in this Manual."

Likewise there is also no feature-ID register (which exists for all optional features), where a SW implementation could detect the absence of Aarch32. This is considering architecture updates up to ARMv8.5-A.

This is from the Arm Developer site:
A-Profile Architectures

Armv8-A is the only profile that supports AArch64 execution, where the relationship between AArch64 and AArch32 is known as interprocessing. In addition, the Armv8-A architecture allows different levels of AArch64 and AArch32 support, for example:

• AArch64 only designs.
• AArch64 designs that also support AArch32 operating systems/virtual machines.
• AArch64 support with AArch32 at (unprivileged) application level only.

AArch64 only designs is one of the options. I think this was a relatively recent change in requirements--I doubt it goes back to 2011.

 

[Gnattu]

I do not believe that Aarch32 execution state is optional in the ARMv8-A architecture specification.

It is. This is discussed in the LinuxCon 2012:

This is again referenced in the ARM community:
It's quite interesting that the speculation from 6 years ago becomes true. ARM developers knew that not all ARMv8 processors will run 32-bit code 6 years ago, and I do believe Microsoft knew that as well.

If you don't believe the presentation made by ARM on events of Linux Foundation, @jdb8167 pointed a source directly from arm document. Is this convincing enough to you now?

SW implementation could detect the absence of Aarch32

The OS can detect the absence of aarch32. If you run lscpu in a linux VM on M1 you will notice that there is no 32-bit in op-mode,:


But 32-bit does appear on raspberry pi:

 

[jdb8167]

It is. This is discussed in the LinuxCon 2012:
View attachment 1712651
This is again referenced in the ARM community:
It's quite interesting that the speculation from 6 years ago becomes true. ARM developers knew that not all ARMv8 processors will run 32-bit code 6 years ago, and I do believe Microsoft knew that as well.
View attachment 1712652

If you don't believe the presentation made by ARM on events of Linux Foundation, @jdb8167 pointed a source directly from arm document. Is this convincing enough to you now?


The OS can detect the absence of aarch32. If you run lscpu in a linux VM on M1 you will notice that there is no 32-bit in op-mode,:
View attachment 1712649

But 32-bit does appear on raspberry pi:
View attachment 1712647

So apparently it does go back to at least 2012.

Edit: Highlighted Microsoft speculation. Microsoft sure loves to give themselves architectural headaches. I can't figure out what they were thinking for the latest Windows on Arm to compile some applications for AArch32 and some for AArch64. What was the point?

 

[Gnattu]

So apparently it does go back to at least 2012.

Edit: Highlighted Microsoft speculation. Microsoft sure loves to give themselves architectural headaches. I can't figure out what they were thinking for the latest Windows on Arm to compile some applications for AArch32 and some for AArch64. What was the point?

To my understanding, they can directly use the Windows RT era stuff, which is pre-ARMv8, and save some work to rewrite code.

Same applies to 3rd party apps, there are tons of Window RT era apps in the store, which is arm32 exclusive.
This is also a big difference between Apple and Microsoft: Apple will remove the app from App store if it is not 64-bit.

 

[jdb8167]

To my understanding, they can directly use the Windows RT era stuff, which is pre-ARMv8, and save some work to rewrite code.

Same applies to 3rd party apps, there are tons of Window RT era apps in the store, which is arm32 exclusive.

Are there really any important 3rd party apps that are AArch32 that wouldn't be easily updated to AArch64? I thought the hit on RT was that no one wrote any software for it and if you were so motivated that you did, how much work would it be to move to 64-bit? Still seems strange. I guess by the same token, not many care about Windows RT and WoA so why put in the effort?

 

[Gerdi]

It is. This is discussed in the LinuxCon 2012:
View attachment 1712651
This is again referenced in the ARM community:
It's quite interesting that the speculation from 6 years ago becomes true. ARM developers knew that not all ARMv8 processors will run 32-bit code 6 years ago, and I do believe Microsoft knew that as well.
View attachment 1712652

If you don't believe the presentation made by ARM on events of Linux Foundation, @jdb8167 pointed a source directly from arm document. Is this convincing enough to you now?


The OS can detect the absence of aarch32. If you run lscpu in a linux VM on M1 you will notice that there is no 32-bit in op-mode,:
View attachment 1712649

But 32-bit does appear on raspberry pi:
View attachment 1712647

Look, the ARM architecture specification is the reference, not some random Linux conference and neither some Power Point slides. It is the one place where ARMv8 is de facto defined.
It is very clearly stated there: "Features that are optional are explicitly defined as such in this Manual." So if it is optional, it must be in the ARMv8-A architecture specification.

So does your claim of optionality of AArch32 matches the ARMv8-A spec? I do not think so.

 

[Gerdi]

Are there really any important 3rd party apps that are AArch32 that wouldn't be easily updated to AArch64? I thought the hit on RT was that no one wrote any software for it and if you were so motivated that you did, how much work would it be to move to 64-bit? Still seems strange. I guess by the same token, not many care about Windows RT and WoA so why put in the effort?

Most of the store apps of that time where available as ARM32 binaries and they are still available in the store today. I have more than 20 apps personally, which are ARM32 from third parties, which still work today.
In fact apps for AArch32 execution state do have some advantages when it comes to memory footprint, when they are compiled for T32 - which all Windows ARM32 Apps are.