Never had a problem with event viewer on mine running latest dev build so yours should be fine I reckon
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Parallels tech preview for M1
- Thread starter faffoo
- Start date
- Sort by reaction score
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.
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.)
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.
I hadn't tried that yet. Good advice though, and something I don't usually remember is possible.
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.
Oops my bad.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
Long story short, ACVM currently only supports ARM64 virtualization.
My question was more related to the aarch64 version of OpenJDK - and not some x86/x64 versions.
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.
Last edited:
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.
Last edited:
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.
Not sure if this was already posted or not.
New WoA dev channel build is out
blogs.windows.com
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
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.
Last edited:
This is from the Arm Developer site:
A-Profile Architectures
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.
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?
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:
Last edited:
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.
Last edited:
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?
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.
Last edited:
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.
Last edited: