Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
As a Consultant I love using my Macs for any daily business and all Cloud based projects (Salesforce et al), but still need to run MS Access or Excel for some of my projects. As both are really not available/compatible for Mac OS (I know there is Excel, but with many limitations) and my customers are all in very MS centric environments I really need a stable VM like Parallels to switch to Windows when needed. This works very well currently, so I would really have to wait before I get an M1 Mac until Parallels will run stable and will be able to run a "normal" Windows 10 copy with all the MS Office stuff on it.
 
Exactly! And I would add ... run them well. That second part is as critical as the first IMO.

A lot of people on here who seemed to be jacked up about Windows on ARM Macs seem to be missing this very critical point: Their regular Windows games and programs will NOT work on those systems!

Except many of those apps ARE working on those systems. I don't get what your regular beef is with Apple Silicon. In three years time, that will be all you'll be able to order (save for maybe one or two Intel models kept in the line for those that REALLY need them). In eight year's time, it will be all that macOS supports. I'm not jazzed about the move necessarily either (removing x86 removes a lot of compatibility with a lot of things outside of the usual Mac platform niceties), but hell if I'm going to dismiss it the way you do.

Here’s what they said: “avoid having to physically partition the disc (wasteful - with a VM you can have a virtual disc file that starts small and grows on demand)”.

Here’s what you said: “APFS and dynamic disk partitioning renders your concerns here moot.”

No, it doesn’t. That feature isn’t going to work with Windows. Bringing up FAT32 doesn’t change that.

What I'm saying is that the move to Apple Silicon doesn't change what's needed to get an NTFS volume in an APFS formatted drive. It's the same partition type and it's the same trickery needed to get it working. Incidentally, I'm pretty sure that APFS containers work in similar fashion. But even if Boot-Camp-created NTFS volumes don't work that way, it's not THAT wasteful unless you give yourself a much bigger volume than you originally thought you were going to need to begin with.

Sure; the drivers aren’t there, the installer doesn’t know Apple’s boot loader, etc.

Those would be rather small efforts compared to porting to a new ISA, though.

Much bigger efforts than what was needed to get Windows to work on Intel Macs. Also, it's Microsoft that would have to write a new bootloader for Apple's firmware. The bootloader is an operating system component, not a firmware component. The booter is the firmware component.

Also, where Apple pretty much provided commodity hardware components (up until T2 Intel Macs, for the most part) that they wouldn't need to work terribly hard to provide drivers for in Windows via the Boot Camp Assistant, this time Apple makes all of the components (as they're all on that SoC). So, Apple would need to write drivers for their Apple Silicon Macs for Windows 10 for ARM64. SOMEONE, be it Parallels, VMware, or Apple, will need to write drivers for Windows 10 for ARM64 for the Hypervisor as those definitely don't exist yet.

...which gives you a fixed-size NTFS partition that can only be changed by faffing about with disc utilities and so has to include enough free space for everything you're likely to do in Windows, from day one. That's hugely space inefficient - especially if you want to keep it on super-expensive Mac internal SSD. Whereas a hypervisor will use a sparse virtual disc image that starts tiny, grows only as space is actually used, has a point-and-drool utility to recover unused space and shrink the image, and can moved between drives just like a regular file. Not quite as fast but vastly more convenient.

Depends on how you define convenience. From the standpoint of space management, sure, I'll grant you that a dynamically expanding virtual disk is more convenient than something like Boot Camp. However, Boot Camp is dirt simple to set up. Virtual machines, not so much. At least, not for someone who isn't a technical person by nature.

I never claimed it did work for everybody. The point is that not only will virtualization suffice for many, it will be the best tool for the job for many.

I really think that's highly debatable and highly dependent on workflow. If you assume that the vast majority of people wanting to run Windows on their Mac are doing so for Microsoft Access, then sure, it'll be the best tool for many. If you're assuming that same majority want Windows on their Mac to run one or two financial apps that will never make their way to the Mac, then sure, it'll be the best tool for many. However, it will suck for anyone wanting to make full use of the hardware to accomplish heavier tasks such as gaming and high end CAD/engineering applications that really do demand every ounce of system resources and I'm sure that there ARE MANY people (if not just as many [if not more] as the former groups) that fit those categories).

The question is whether the remaining users are sufficient to justify the work of supporting Bootcamp.



We were discussing Apple's incentives to support Windows so Apple's agenda is kinda what it is all about.

Apple is a hardware company, first and foremost. For every Intel Mac that has existed, Apple has created Windows drivers so that Mac can run Windows. Continuing to do so with Apple Silicon for the ARM64 version of Windows doesn't present a big enough change to their business model to change that doing so doesn't hurt them. At worst, maybe they don't want to open up the Apple Silicon iBoot firmware to outsiders (much in a similar way that it's a total pain to get Linux natively booting on a T2 Mac), but I fail to see why Microsoft wouldn't be an exception now the way they were with the T2. Again, it benefits Apple by continuing to say that Macs will run Windows. That was a HUGE selling point for Intel Macs circa 2006 and beyond. It still is today! Doing this does nothing to hurt Apple's Mac business. Putting out the fastest Macs by a long shot AND the fastest Windows 10 PCs by a long shot helps further the narrative that M1 is a paradigm shift in Apple's favor.

Also, Apple has always been more worried about profitability than market share - e.g. Spotify may have a huge number of users but it still makes a loss most quarters (...all those free, ad-supported users where all the ads are for Spotify...).

Native booting Windows 10 for ARM64 on Apple Silicon Macs doesn't HURT Apple's profitability. If anything, it seriously would HELP it.

I think they were talking about virtualisation.

I have no doubt that they were talking about virtualization. But it wouldn't be the first time that Apple outright said that they wouldn't support direct booting of Windows on the Mac and then reversed course. Do recall that Intel Macs were on sale for a good three months before Apple took the wraps off of Boot Camp (and the necessary firmware updates that enabled CSM support to be able to boot Windows XP at the time). There is ABSOLUTELY reason for both Apple and Microsoft to collaborate on making this happen.

Except (as you then went on to point out) it was a far easier job on Intel (...so much so that hackers solved the problem before Bootcamp appeared).



...and a lot of that will also be achieved by virtualization. Plus, never under-estimate the inertia of the Windows world, which is anchored by huge, conservative industrial and corporate customers - Mac users running Windows are a tiny, tiny drop in the ocean.

I don't believe you have data that supports that. I worked for many companies that heavily relied on Boot Camp for their Mac users. I'm not talking one or two users. I'm talking whole fleets of Mac users that needed Windows on their Mac.

Plus, Apple simply don't offer a wide enough range of hardware to compete with generic PC components.

I don't know that this detail matters. It never did during the Intel Mac era. I imagine it will matter less during the Apple Silicon Mac era, especially since the M1 is currently dominating on native single core performance over pretty much every x86-64 CPU out there. Similarly, M1 is on the lower-end of Apple's GPU capabilities and it's still outperforming mid-range discrete cards from a couple years ago. They'll easily beat the competition when their higher-end offerings materialize.

There have been a string of attempts to launch Windows-on-not-Intel (alpha/mips/PPC/Itanium and the first stab at Windows-on-ARM) so Windows on ARM64 succeeding is still a very, very long shot.

It's only failing because there's no developer incentive. If you say that M1 is outperforming contemporary Intel CPUs when comparing native code of one to native code of the other, that's the kind of thing developers will be interested in. Microsoft isn't SWITCHING to ARM64 from x86-64 the way Apple is. They're providing it as another option, which means that developers won't bite unless there's an additional carrot at the end of the stick. Native performance of Windows 10 for ARM64 on something like an M1 could be that additional carrot, if both parties played along. I would absolutely buy a specc'ed out M1 Mac mini tomorrow if I knew that (a) Apple and Microsoft would partner to make direct booting of Windows 10 for ARM64 possible on Apple Silicon, and (b) Windows software developers that I care about started offering ARM64 versions too. It'd be a much better PC than most PCs I could buy at that point.


...and I can wake a Parallels Windows VM from sleep in seconds, run Excel-for-Windows perfectly, have it share the desktop with MacOS apps, access the same files on the same drive as MacOS apps and even cut a region from Excel-for-Windows and paste it into Word-for-MacOS as a table.
See, I actually hate the file/folder integration that VMware/Parallels/Connectix has because I think it's beyond messy. But that's just my personal preference. Then again, I think you're still operating under the assumption that the average Windows-on-Mac user is only using one or two apps and not a slew of them.

...or, with BootCamp, I can save and close down everything I'm doing on Mac, make sure everything I need is on the FAT32 partition/NAS/cloud drive/whatever that I can actually read from Windows (unless I've installed something like Paragon NTFS and trust it...), reboot into Windows/BootCamp, do stuff in Excel, save it, reboot....

Honestly, not a problem for MOST workloads. Is virtualizing more convenient in some cases, sure. I never denied that it was! But it won't be for all of them. Certainly if one is using cloud storage to store their important stuff (which is more people these days than not), then that concern is moot considering that all of the cloud storage providers have clients for both platforms that work just as well.

Seriously, if CAD users will laugh at the idea of using Parallels, users of Excel, Outlook etc. (or, basically, anything that isn't 3D graphics or video editing) will absolutely have kittens at the idea of using BootCamp. Reboot to check email? Yeah....

Or just install Office in both places. It's not super difficult to do these things, you know. 🤣

Or check e-mail on their phone (like most people do)?

Or use built-in e-mail clients on both OSes (super easy to do for both platforms).

Again, you are operating under the incorrect assumption that the average Windows-on-Mac user is only Boot Camping for one or two apps. If it's one or two light apps, then, I'll agree, virtualization is totally fine; even with the speed hit that it entails. But many people use their Windows partition like it's a second computer, and for those users, virtualization CAN suffice for some, but often doesn't.
That's the point. Virtualization isn't a toy - it can run serious software (I've even played 3D games in Parallels in the past). It's only a small niche of software that actually needs bare-metal performance - and even then many people would probably still be better off getting a PC with a decent discrete GPU and lashings of cheap RAM and fast SSD. Or a console.

Mileage will vary. Suffice it to say that direct booting does have its merits and the only reason for Apple to not want to have that kind of collaboration with Microsoft on the Apple Silicon end of this transition is because they want Apple Silicon Mac firmware to be as locked down and proprietary as possible (though, even then, I'd still argue that they could write Microsoft's bootloader for Windows 10 for ARM64 and be involved enough in the entire effort to the point where they publish Windows 10 for ARM64 on the Mac App Store (having been directly involved enough on the project to feel like they have enough control in doing so). The installer would effectively replace the Boot Camp Assistant.

This was the story when MS first started selling the Surface range:


...and that's a situation where the OEMs were free to build competing hardware using the same generic components. MS actively supporting Apple Silicon technology that only Apple can use? Not gonna play well.

Right, that article is very dated. Since then, the Surface line has expanded and OEM partners have still remained. Having Apple Silicon Macs native boot Windows 10 for ARM64 would do no more to affect this than Intel Macs being able to run x86 Windows ever did.

AFAIK the Apple Hypervisor kit just provides the barebones, CPU virtualisation "engine" - headless VMs with basic networking. Great for Docker etc. but the Hypervisor software (Parallels etc.) provides all the trimmings such as video drivers. The "guest" OS Parallels/VMWare/whatever tools installs paravirtualised drivers that know zip about MacOS or Metal and just call the hypervisor. The hypervisor then calls the standard MacOS drivers. Obviously that's a gross simplification, but "Apple drivers for the hypervisor" aren't involved - none of that mechanism has substantially changed from Intel - it's all there in Parallels/VMWare etc. - which is why we have an almost-working Parallels preview a month or so after M1 launched. That's a far cry from the bare metal Apple Silicon drivers that would be needed for Bootcamp.

I'd believe that. But my point is that drivers still need to be produced for Windows 10 for ARM64 one way or another. A Parallels or VMware VM running on Apple Silicon is still technically a new hardware configuration for which drivers didn't already exist. Furthermore, I don't imagine that bare metal Apple Silicon drivers for the ARM64 Windows 10 wouldn't be that hard for Apple to produce. Apple wouldn't have to optimize their Silicon for Windows the way that they want to with the macOS, but it's not to say that is even required to still have M1 Macs be highly performant ARM64 Windows 10 machines.


Unfortunately, that ship has sailed with Apple Silicon. Making Intel Macs boot Windows was low-hanging-fruit. Making ASi Macs boot Windows, especially "legacy" software that may not get an ARM64 port, is nothing like so straightforward.

Native booting Windows 10 for ARM64 and running legacy 32-bit x86 apps via Microsoft's emulator have nothing to do with each other.

Virtualisation is far easier and will meet a lot of people's needs - but the Mac as a high-performance Windows x86 box for CAD, 3D etc. is probably over.

That might be the case, but there's no reason why it would HAVE to be the case unless Microsoft and Apple couldn't come to a deal. The problem is that a greater collaborative effort is required between the two companies here where such a need didn't exist with Intel Macs. But it's nothing insurmountable. I'd say getting Windows NT 4 for PowerPC running on a PowerPC Mac would've been WAY more of a challenge.

No reason to run Windows on an M1 Mac as long as games aren't optimized for ARM, right?
Uh...no. There are MANY reasons to run Windows. If your one or two or thirty games are the only reason you're using Windows and they run like crap on Windows 10 for ARM64 due to emulation sucking, then that's one thing. But there are MANY apps that will ALWAYS be Windows only and it is for those apps that Boot Camp and virtualization exists as solutions for Mac users to begin with. You shouldn't have to buy two computers because you need to use two platforms if one set of hardware will handle both.
 
18.85% is nowhere near to the 200% you would expect with a doubling of cores. I think that was the point.
Four performance cores and four low power cores...

The low power cores make your battery last forever when you don't use much power. Plus they give you 20% more power. By the way, your maths is off. With doubling _identical_ cores, you wouldn't expect more than 100% gain.
 
  • Like
Reactions: chucker23n1
See, I actually hate the file/folder integration that VMware/Parallels/Connectix has because I think it's beyond messy.
...the automatic home folder sharing, windows apps showing up in finder etc. is a matter of taste (and can be turned off) but the basic shared folder system is straightforward and useful - and if that's too "messy" there's nothing stopping you from just using SMB over a virtual network. With bootcamp, your only choices are keeping your files on a physically separate machine/NAS or trusting a third party implementation of either APFS/HFS+-for-Windows or NTFS-for-Mac with low-level access to your disc.

Then again, I think you're still operating under the assumption that the average Windows-on-Mac user is only using one or two apps and not a slew of them.

Neither of us knows for sure what the "average Windows-on-Mac user" does. My reasonable assumption, though, is that the "average Windows-on-Mac user" buys a Mac because they use both MacOS & Windows software. It doesn't matter whether its one-or-two of one and a "slew" of the other - the deal-breaker for BootCamp is that you have to reboot to switch from one to the other and jump through hoops to exchange files. Only applications that really need the extra performance of bare metal justify that inconvenience.

Boot Camp is dirt simple to set up. Virtual machines, not so much. At least, not for someone who isn't a technical person by nature.

Sorry, but did your VM experience come from building QEMU from a source tarball or something!?
Sure, when I set up a new VM in Parallels I dive straight in to the advanced options, but there's a large friendly "Get Windows from Microsoft" button for a click and drool experience that is even simpler than BootCamp (if only because there's no disc partitioning involved and almost everything can be tweaked after the fact).
 
Going from 4 to 8 cores showed an insignificant increase in the benchmarks, and here might be the reason why.

Unlike Intel, not all cores are equal in M1. There are 4 high performance cores and 4 low performance (aka high efficiency).

It's better to just keep these cores for macOS at this point.
Most people refer to the M1 as 4+4 cores, not 8 cores, for that reason. There have also been screenshots from Geekbench, which quite obviously gets a bit confused by the fact that there are two very different sets of cores. I think they report eight cores, with the clock speed of the performance cores, and the L1 and L2 cache of the low power cores.
 
Microsoft has put team of chip designers to come up with it's own ARM chip like Apple M1. It would have been better that Microsoft simply ported Windows natively on M1 and call off the headache,failure of past examples.
"Windows on M1" means "Windows on Mac", and that is a tiny, tiny bit of the market for Microsoft. "Windows on a powerful ARM processor" would be worth ten times more for Microsoft.
 
Much bigger efforts than what was needed to get Windows to work on Intel Macs.

Yes, that's fair. Apple used far more typical x86 components on their Intel Macs. (Though the T1/T2 did change that a fair bit.)

Also, it's Microsoft that would have to write a new bootloader for Apple's firmware. The bootloader is an operating system component, not a firmware component. The booter is the firmware component.

Whether Microsoft or Apple writes it doesn't matter. Either Apple documents how to interface with iBoot, and Microsoft implements that, or Microsoft documents how to write a Windows-compatible bootloader shim, and Apple implements that.

(The scenario where it's not documented and one of the two reverse-engineers stuff is unlikely for a commercial product.)

This is also only relevant for native boot, not for a VM.

Also, where Apple pretty much provided commodity hardware components (up until T2 Intel Macs, for the most part) that they wouldn't need to work terribly hard to provide drivers for in Windows via the Boot Camp Assistant, this time Apple makes all of the components (as they're all on that SoC). So, Apple would need to write drivers for their Apple Silicon Macs for Windows 10 for ARM64.

True, but largely irrelevant for a VM. Parallels, QEMU, etc. simply emulate or shim missing pieces. A virtual network adapter, for example, only needs to roughly behave like a real one; on the host side, it then becomes a bridge or a NAT (or a separate interface of its own).

SOMEONE, be it Parallels, VMware, or Apple, will need to write drivers for Windows 10 for ARM64 for the Hypervisor as those definitely don't exist yet.

But this is largely unnecessary. We already have Windows running inside QEMU or Parallels, and presumably, VMware has it running in their labs. (ESXi already boots ARM. Public builds of Fusion don't, yet.)

What's left are some convenience features (folder sharing, drag & drop, etc.) and possibly some performance enhancements (e.g., emulating a graphics adapter that can show 1080p isn't quite the same as emulating a graphics adapter that also supports Direct3D 11).

Depends on how you define convenience. From the standpoint of space management, sure, I'll grant you that a dynamically expanding virtual disk is more convenient than something like Boot Camp. However, Boot Camp is dirt simple to set up. Virtual machines, not so much. At least, not for someone who isn't a technical person by nature.

When was the last time you tried? You take a Windows installer ISO or a USB stick with the installer on it, drag that to VMware, and it asks you to create a VM. Pick a disk size (which doesn't by default allocate eagerly, so it saves space with the trade-off of performance issues), optionally adjust stuff like CPU cores or RAM, and you're good to go. You don't even have to go through Windows's setup; by default, it'll run all that automatically, including creating a user, entering the serial number, etc.
"Windows on M1" means "Windows on Mac", and that is a tiny, tiny bit of the market for Microsoft. "Windows on a powerful ARM processor" would be worth ten times more for Microsoft.
I don't know if that's true. Most Surface devices don't run ARM, and few third-party computers use ARM.

The Mac will probably rather quickly become the biggest desktop target for Windows on ARM.

The embedded and server markets look different, but Windows IoT Core doesn't seem to have taken off, TBH.
 
Yes, that's fair. Apple used far more typical x86 components on their Intel Macs. (Though the T1/T2 did change that a fair bit.)



Whether Microsoft or Apple writes it doesn't matter. Either Apple documents how to interface with iBoot, and Microsoft implements that, or Microsoft documents how to write a Windows-compatible bootloader shim, and Apple implements that.

(The scenario where it's not documented and one of the two reverse-engineers stuff is unlikely for a commercial product.)

This is also only relevant for native boot, not for a VM.



True, but largely irrelevant for a VM. Parallels, QEMU, etc. simply emulate or shim missing pieces. A virtual network adapter, for example, only needs to roughly behave like a real one; on the host side, it then becomes a bridge or a NAT (or a separate interface of its own).



But this is largely unnecessary. We already have Windows running inside QEMU or Parallels, and presumably, VMware has it running in their labs. (ESXi already boots ARM. Public builds of Fusion don't, yet.)

What's left are some convenience features (folder sharing, drag & drop, etc.) and possibly some performance enhancements (e.g., emulating a graphics adapter that can show 1080p isn't quite the same as emulating a graphics adapter that also supports Direct3D 11).



When was the last time you tried? You take a Windows installer ISO or a USB stick with the installer on it, drag that to VMware, and it asks you to create a VM. Pick a disk size (which doesn't by default allocate eagerly, so it saves space with the trade-off of performance issues), optionally adjust stuff like CPU cores or RAM, and you're good to go. You don't even have to go through Windows's setup; by default, it'll run all that automatically, including creating a user, entering the serial number, etc.

I don't know if that's true. Most Surface devices don't run ARM, and few third-party computers use ARM.

The Mac will probably rather quickly become the biggest desktop target for Windows on ARM.

The embedded and server markets look different, but Windows IoT Core doesn't seem to have taken off, TBH.
I believe he’s referring to future and not existing machines. Personally, I’m very curious to see what will be Microsoft move on the ARM SoC unified architecture. After the M1 sample, it seems to be the only way to go if you want to match performance, so can’t imagine surface evolution out of that built frame...
 
Its interesting that all the companies are jumping so quickly to make an ARM version of their software when the M1 user base is like extreme minority of the minor marketshare MacOS. Especially Microsoft that doesn't seem to make money off windows on the Mac platform.

I am making a big huge guess and say Microsoft is planning for a stable Windows release on an ARM chip especially after Apple demonstrated what it can do, and the M1 macs are their testing grounds. This also mean more software on Windows will be adopt the ARM architecture, but does that mean better MacOS support too with this shared architectures between the 2 systems?

I would sell my Intel stocks honestly, and buy Nvidia. It was a good run Intel, I do remember the late 90s.
 
  • Like
Reactions: 09872738
Its interesting that all the companies are jumping so quickly to make an ARM version of their software when the M1 user base is like extreme minority of the minor marketshare MacOS.

The biggest-selling Mac, the MacBook Air, is now ARM. It's a small slice now, but it's gonna grow very quickly.

This also mean more software on Windows will be adopt the ARM architecture,

Right.

but does that mean better MacOS support too with this shared architectures between the 2 systems?

A little, but not much. Most ARM stuff is just a recompile away, and recompiling for Windows on ARM doesn't really help with macOS.
 
  • Like
Reactions: 09872738
Yes, that's fair. Apple used far more typical x86 components on their Intel Macs. (Though the T1/T2 did change that a fair bit.)
Right. Still minor by comparison to M1. T1 was minimal from the standpoint of driver creation by comparison to T2.

Whether Microsoft or Apple writes it doesn't matter. Either Apple documents how to interface with iBoot, and Microsoft implements that, or Microsoft documents how to write a Windows-compatible bootloader shim, and Apple implements that.

Microsoft wouldn't document how to write a bootloader shim. That's not applicable to this scenario at all. Regardless of whether it's Apple or Microsoft doing it, someone would need to make a different bootloader FOR Windows (not for the Apple Silicon Mac booter). Odds are decent that it would probably be a collaborative effort (as Apple is not going to completely hand over the keys to Microsoft, but it IS Microsoft's OS and not Apple's).

True, but largely irrelevant for a VM. Parallels, QEMU, etc. simply emulate or shim missing pieces. A virtual network adapter, for example, only needs to roughly behave like a real one; on the host side, it then becomes a bridge or a NAT (or a separate interface of its own).



But this is largely unnecessary. We already have Windows running inside QEMU or Parallels, and presumably, VMware has it running in their labs. (ESXi already boots ARM. Public builds of Fusion don't, yet.)

What's left are some convenience features (folder sharing, drag & drop, etc.) and possibly some performance enhancements (e.g., emulating a graphics adapter that can show 1080p isn't quite the same as emulating a graphics adapter that also supports Direct3D 11).

No, this has all been done for the x86 and x86-64 VMs running x86 and x86-64 Windows. This HAS NOT been done for ARM64 VMs running ARM64 Windows. Drivers have only been made for existing ARM64 hardware, which, again, is only on proper Windows 10 for ARM64 OEM devices because that's Microsoft's model for that variant of Windows 10. This is why, on top of Parallels for Apple Silicon being in a technical preview, and on top of using an Insider Preview release of Windows 10 for ARM64, there are so many glitches happening for everyone attempting to get Windows running on their Apple Silicon Mac via virtualization.

The best I'll grant you is that Parallels and qemu at least seem to be utilizing the correct firmware type for ARM64 Windows 10 right out of the gate. But it's not like drivers just magically materialize for Windows of one architecture just because they've always existed for Windows of the other.


When was the last time you tried? You take a Windows installer ISO or a USB stick with the installer on it, drag that to VMware, and it asks you to create a VM. Pick a disk size (which doesn't by default allocate eagerly, so it saves space with the trade-off of performance issues), optionally adjust stuff like CPU cores or RAM, and you're good to go. You don't even have to go through Windows's setup; by default, it'll run all that automatically, including creating a user, entering the serial number, etc.

I'm not saying it's difficult for me. I make VMs for breakfast. It's literally why I'm pending clicking the buy button on a new Intel MacBook Pro (and not an M1 MacBook Pro instead).

I'm saying that the average user doesn't know about CPU cores or RAM. Most average users get the word "memory" confused and think it pertains to storage, when it actually pertains to RAM. Most don't even know the consequences of assigning a VM with too little RAM (or, contrastingly, too much RAM). I'm not saying it's difficult, but it's certainly still more to-do than Boot Camp which is literally just a single slider of disk space and that's it.
 
Last edited:
Neither of us knows for sure what the "average Windows-on-Mac user" does.

I know what I've seen and I've seen PLENTY of Windows-on-Mac users prefer Boot Camp. Also, there are plenty of Windows applications that just run better bare metal than virtualized. Hell, there is still a 200 point speed hit on single-core performance measured using Geekbench 5 and a 2000 point speed hit on multicore performance measured using Geekbench 5. Let's not forget that Parallels Desktop isn't free. Nor is VMware Fusion for that matter. You're not going to sell me on the argument that we don't need direct booting anymore while there are still plenty of use cases for it even if they are not ones YOU are not directly familiar with.


My reasonable assumption, though, is that the "average Windows-on-Mac user" buys a Mac because they use both MacOS & Windows software. It doesn't matter whether its one-or-two of one and a "slew" of the other - the deal-breaker for BootCamp is that you have to reboot to switch from one to the other and jump through hoops to exchange files. Only applications that really need the extra performance of bare metal justify that inconvenience.

Right. And there are plenty of those applications out there and plenty of Mac users preferring not to buy a PC in addition to their Mac. Again, Parallels Desktop and VMware Fusion are not freeware applications by any stretch. They cost money. You tell someone who has a license of Windows 10 ready to go that they need to spend $80-130 on another piece of software, they'll ask if there's a free way to do it. Also, I'm not entirely sure that I'd add that having to reboot your computer is a "deal-breaker". If you don't need to do it, then great. And if your Windows 10 (or Linux for that matter) workloads are such that you are fine with virtualization, then awesome! But don't sit here and tell me that will suffice for most use cases when you're also sitting here and telling me that 'Neither of us knows for sure what the "average Windows-on-Mac user" does'.

Sorry, but did your VM experience come from building QEMU from a source tarball or something!?
Sure, when I set up a new VM in Parallels I dive straight in to the advanced options, but there's a large friendly "Get Windows from Microsoft" button for a click and drool experience that is even simpler than BootCamp (if only because there's no disc partitioning involved and almost everything can be tweaked after the fact).
No, I actually make VMs for breakfast. Admittedly, it's been a while since I've used Parallels Desktop (I'm much more of a VMware Fusion guy, myself). But I'm pending clicking the "Buy" button on an Intel MacBook Pro BECAUSE x86 virtualization is a big component of my Mac usage. The UI is certainly friendly on both interfaces (frankly, TOO friendly at times for my tastes). But, you and I know what "RAM" is and what "CPU Cores" are. We also understand the consequences of allocating too little or too much of those to any given VM. Those are still decisions that have to be made when making a virtual machine. With Boot Camp, the only decision you are making is how much of your internal storage you are devoting to Windows. That's it. You really don't get more idiot-proof than that.

Also, if we're really being honest here, the average user understands the concept of splitting a drive and dual-booting Windows and macOS on the same computer FAR BETTER than they do the idea of running a fake computer within your actual computer. I'm not saying they aren't jazzed or mind-blown when they see the virtualization in action. But if we're talking average users who are not techies by any stretch, it's not as natural of a concept for them to grasp automatically and usually requires explanation from someone else more familiar with the concept.

I say this as someone who translates geekspeak to English all the time, both on and off the clock to friends, family, co-workers, and higher-ups all the time.
 
Microsoft wouldn't document how to write a bootloader shim. That's not applicable to this scenario at all.

I don't see why you keep saying variations of "that's not it at all", but, OK.

Regardless of whether it's Apple or Microsoft doing it, someone would need to make a different bootloader FOR Windows (not for the Apple Silicon Mac booter). Odds are decent that it would probably be a collaborative effort (as Apple is not going to completely hand over the keys to Microsoft, but it IS Microsoft's OS and not Apple's).

Well, Apple would simply have to document how to boot from iBoot. And then they'd sign the resulting bootloader. They either want to, or they don't.


No, this has all been done for the x86 and x86-64 VMs running x86 and x86-64 Windows. This HAS NOT been done for ARM64 VMs running ARM64 Windows. Drivers have only been made for existing ARM64 hardware, which, again, is only on proper Windows 10 for ARM64 OEM devices because that's Microsoft's model for that variant of Windows 10. This is why, on top of Parallels for Apple Silicon being in a technical preview, and on top of using an Insider Preview release of Windows 10 for ARM64, there are so many glitches happening for everyone attempting to get Windows running on their Apple Silicon Mac via virtualization.

Drivers either exist or they don't. If there are "glitches", that's a sign that drivers do exist, but are currently unreliable. This either means Apple doesn't correctly implement whatever hardware is being virtualized, or Parallels has made a hacky attempt at implementing something somewhat compatible with Apple's hardware.

If it were a case of drivers not existing, that would be far clearer. Virtual hardware such as the graphics driver would be flat-out missing altogether.

I'm saying that the average user doesn't know about CPU cores or RAM.

And I'm saying most users don't have to worry about that at all. Use the default settings, and you're good to go to run most apps.

Most average users get the word "memory" confused and think it pertains to storage, when it actually pertains to RAM. Most don't even know the consequences of assigning a VM with too little RAM (or, contrastingly, too much RAM). I'm not saying it's difficult, but it's certainly still more to-do than Boot Camp which is literally just a single slider of disk space and that's it.
Yes, this I'll grant you. A former coworker, who's a front-end dev, made a Windows VM with 14 GB RAM on a host system with 16 GB RAM (I don't believe Parallels defaults to that amount, so he must've explicitly set it?), and was surprised at how poor performance was. It wasn't very intuitive to him that the VM suddenly ran much faster when I decreased the allocation to 6 GB.
 
I know what I've seen and I've seen PLENTY of Windows-on-Mac users prefer Boot Camp.

Just guessing here, but perhaps their tech advisor has told them that virtualisation is rubbish and really really complicated?

Also, there are plenty of Windows applications that just run better bare metal than virtualized. Hell, there is still a 200 point speed hit on single-core performance measured using Geekbench 5 and a 2000 point speed hit on multicore performance measured using Geekbench 5.

I'll give you that: Geekbench is a very popular app, and lots of people obviously use it for everything, since they seem to be obsessed with benchmark scores over everything else. Now, I don't have GeekBench installed but if I did, I could just pause in the middle of typing this sentence on MacOS, open Geekbench for Windows from a Dock icon, run it alongside Safari, then copy and paste the result directly here. The score would be a bit rubbish, but the amount of my time taken would be a fraction of the time it would take to reboot into "bare metal" Windows.

OK, I'm joking about Geekbench - apart from the obsession with raw speed over practicality thing - and I totally get that if you (say) spend the working day slaving over AutoCAD and your evenings cutting grooves with Logic that BootCamp would be a good solution.

OTOH, if you spend the day happily working in MacOS but your employer periodically insists on sending you documents in MS Publisher or weird Excel sheets that only work in Windows, then BootCamp is next to useless, while something like Parallels makes it almost transparent - just double-click on the file (if its Excel, Open With -> and choose the Windows version).

The question is not which scenario you or I resonate with the most, it is whether Apple (who have better market research than us) think BootCamp is worth supporting on M1 which is far more effort since they'd have to write and maintain drivers and/or share technical details with MS and others, sign third-party operating systems.

"Plenty" of people want an XServe. "Plenty" of people want to run 32-bit MacOS Apps on Big Sur. "Plenty" of people liked Aperture... "Plenty" of people liked Target Display Mode... "Plenty" of people want a PCIe tower xMac... Plenty of people have been disappointed by Apple, who have always been prepared to throw certain groups of users under the bus, especially if they thought they might stick with Mac anyhow. I'd say that virtualization kills more birds with one stone, and Apple need the hypervisor framework to support web and MacOS developers anyway (and no, they don't need to write Windows drivers for VMs).

No, I actually make VMs for breakfast. Admittedly, it's been a while since I've used Parallels Desktop (I'm much more of a VMware Fusion guy, myself). But I'm pending clicking the "Buy" button on an Intel MacBook Pro BECAUSE x86 virtualization is a big component of my Mac usage.
...which probably means that you are a fairly advanced user of VMWare and dive headfirst into the settings. Heck, the first thing I do when I create a Parallels VM is go into the advanced network settings and sort out the MAC address so it inherits the IP of an older VM from my DHCP server... That doesn't represent the average user experience which is click-and-drool to create a Windows VM with sensible defaults, shared networking etc. I don't think Parallels even asks for the number of CPUs or RAM size unless you click on "advanced".

...and, of course, with a VM. things like RAM, number of CPUs, VRAM can be fixed later.

Also, if we're really being honest here, the average user understands the concept of splitting a drive and dual-booting Windows and macOS on the same computer FAR BETTER than they do the idea of running a fake computer within your actual computer.
Then you may have experienced a better class of "average user" than me because I wouldn't expect them to understand either - and if yours truly is going to end up picking up the pieces I'd much rather that they don't go within a million miles of their disc partition table. Fixing the number of CPUs, RAM allocation, or even maximum virtual disc size in a VM is trivial.

They shouldn't need to understand: don't get me wrong, if they want an explanation I'll do my best, but mostly they just want to be able to open (e.g.) MS Project files. Which (if someone sets up a VM for them) simply consists of double-clicking the file...

Drivers have only been made for existing ARM64 hardware, which, again, is only on proper Windows 10 for ARM64 OEM devices because that's Microsoft's model for that variant of Windows 10. This is why, on top of Parallels for Apple Silicon being in a technical preview, and on top of using an Insider Preview release of Windows 10 for ARM64, there are so many glitches happening for everyone attempting to get Windows running on their Apple Silicon Mac via virtualization.
BootCamp on Apple Silicon would need bare-metal Windows drivers for Apple Silicon graphics, SSD, WiFi etc.

Windows running on a VM does not. It just needs paravirtualised drivers that pass calls to the hypervisor. Since the hypervisor is a Mac OS app, it can call on MacOS drivers and frameworks to do the rendering (...as well as handlng things like dynamically resizable windows and "coherence" mode).

When you install a Windows VM on (e.g) Parallels for an x86 Mac, you don't install video drivers for Intel Iris or AMD Radeon, you install video drivers for Parallels. Without these you just get a generic, fixed-size VESA emulation. If the "technical preview" is offering dynamically resizeable windows etc. then the Parallel drivers must be mostly done.

(Yes, some hypervisors can do hardware device mapping and support bare-metal drivers, but it is not essential and probably wouldn't work on the M1/Big Sur security model, or the App Store version of Parallels ).

I don't know whether the structure of Windows-on-ARM64 drivers is different from Windows-on-x86, but its possible that the Parallels/VMWare drivers were a fairly straight translation of x86 to ARM64 code (assuming they weren't just written in C). Likewise, the rendering code in the Parallels hypervisor could be a port of the existing x86 version (along with changes needed anyway for Big Sur). I doubt that it was a trivial "check the ARM box in XCode" job, but it's not starting from scratch the way that bare metal M1 drivers would have been.
 
A little, but not much. Most ARM stuff is just a recompile away, and recompiling for Windows on ARM doesn't really help with macOS.

I remember when they transitioned to Intel it took some time, it wasn't just a recompile. Is this different?
I specifically remember QuarkExpress which I think too years, maybe 4?
 
I don't see why you keep saying variations of "that's not it at all", but, OK.

Because you are demonstrating that you don't know what a bootloader is. Nor that you grasp what the difference is between a booter and a bootloader, let alone how that pertains to Apple hardware.
Well, Apple would simply have to document how to boot from iBoot. And then they'd sign the resulting bootloader. They either want to, or they don't.

That's a drastic oversimplification of what is likely a way more complicated issue.
Drivers either exist or they don't. If there are "glitches", that's a sign that drivers do exist, but are currently unreliable. This either means Apple doesn't correctly implement whatever hardware is being virtualized, or Parallels has made a hacky attempt at implementing something somewhat compatible with Apple's hardware.

If it were a case of drivers not existing, that would be far clearer. Virtual hardware such as the graphics driver would be flat-out missing altogether.

This block of text above what I am currently typing here shows that you don't understand how drivers in Windows really work. Microsoft has what's called "Generic Drivers" for when a more specific driver is not available. It's not a simple binary of "drivers either exist or they don't" like it is for macOS. If Windows doesn't see a specific driver for something, it will employ the use of a generic driver so as to avoid serious kernel panics (otherwise known as the blue screen of death; or in this case, the green screen of death). These issues are currently happening on VMs running the Parallels technical preview. Why? Because, on top of that version of Parallels being in beta, there are no drivers for the Parallels VM in existence. In all hypervisors that aren't Hyper-V, drivers need to be installed in the form of software packages on the guest OS. At best, the one for Parallels is missing a fair amount of drivers, if not all of them.

And I'm saying most users don't have to worry about that at all. Use the default settings, and you're good to go to run most apps.

Please elaborate on your experience with "most users" using Parallels. I don't discourage VMs. Hell, I'm in agreement that it's less messy on the system drive. However, I don't dole out licenses of Parallels Desktop or VM Fusion for free, most people don't want to pay extra for another piece of software on top of the license for Windows. Discounting that like it's not a factor is missing the big picture. Boot Camp is built-in and fewer clicks. You cannot dispute that.

Yes, this I'll grant you. A former coworker, who's a front-end dev, made a Windows VM with 14 GB RAM on a host system with 16 GB RAM (I don't believe Parallels defaults to that amount, so he must've explicitly set it?), and was surprised at how poor performance was. It wasn't very intuitive to him that the VM suddenly ran much faster when I decreased the allocation to 6 GB.

You can sell me on the fact that for all performance and costs being equal, virtualization is a preferable ride. You can't sell me on the fact that performances and costs are equal though. You can try to convince me that I don't need more performance than the subset of M1's performance that I will get in a Parallels for Apple Silicon VM, but I'm sure that there are enough use cases out there (and enough people supporting them) where that is not the case.

Just guessing here, but perhaps their tech advisor has told them that virtualisation is rubbish and really really complicated?

Seriously? Like, are you freakin' serious with that? Come on. Like, get out of here with that nonsense, please and thank you.

Why on Earth would I try to sway someone away from a technology I'm evangelizing to the point of buying an Intel Mac when there's no other decent reason to buy an Intel Mac other than to virtualize the ever-loving crap out of x86 OSes? I get that you're being cheeky here, but come on!

Like most technical advisors, I tend to advise things that most users find complicated. If anyone is outright rejecting virtualization it's the users, not me. Though, if we're really being honest, it's the user's pocketbooks more than it is anything else.

I'll give you that: Geekbench is a very popular app, and lots of people obviously use it for everything, since they seem to be obsessed with benchmark scores over everything else. Now, I don't have GeekBench installed but if I did, I could just pause in the middle of typing this sentence on MacOS, open Geekbench for Windows from a Dock icon, run it alongside Safari, then copy and paste the result directly here. The score would be a bit rubbish, but the amount of my time taken would be a fraction of the time it would take to reboot into "bare metal" Windows.

Your last experience booting bare metal Windows must've been on a 5400RPM 2.5" hard drive and with Windows 7. It boots FASTER than macOS does on average. Mind you, I say that with specific regards to Intel Macs. I haven't gotten my hands on an M1 Mac just yet. Though, I'd imagine that the time it takes to reboot into bare metal Windows 10 for ARM64 on an Apple Silicon Mac would be similarly nowhere near as slow as the molasses you make it out to be.

OK, I'm joking about Geekbench - apart from the obsession with raw speed over practicality thing - and I totally get that if you (say) spend the working day slaving over AutoCAD and your evenings cutting grooves with Logic that BootCamp would be a good solution.

Yes, those scenarios are more common than you give credit for and they do exist. I guarantee you a fair amount of 16" MacBook Pro users are in this boat. If your argument is that the M1, representing Apple's low-end segment likely doesn't have that many people with these needs, I'd say you're probably onto something. But given that Intel Macs' days of being sold brand new are numbered, eventually users of the higher-end Macs will need a solution and virtualziation (as awesome as it is) will not be practical, even with an M1X, M2, or M2X being insanely performant.

OTOH, if you spend the day happily working in MacOS but your employer periodically insists on sending you documents in MS Publisher or weird Excel sheets that only work in Windows, then BootCamp is next to useless, while something like Parallels makes it almost transparent - just double-click on the file (if its Excel, Open With -> and choose the Windows version).
I would wholeheartedly agree that, for this scenario, virtualization is 10000% more preferable. But I refute the notion that this represents the vast majority of Windows-on-Mac use cases. If anything, I'd bet that it's closer to the minority of them. Hell, VMware almost decided to drop support for Apple with Apple Silicon altogether! A version of Fusion for Mac was not a guaranteed thing for a hot minute there!


The question is not which scenario you or I resonate with the most, it is whether Apple (who have better market research than us) think BootCamp is worth supporting on M1 which is far more effort since they'd have to write and maintain drivers and/or share technical details with MS and others, sign third-party operating systems.

Writing Drivers for Apple Silicon Macs for Windows 10 for ARM64 would be an effort, I'll grant you that. Though, I'd imagine they'd only have to do it once per SoC, meaning that they'd only need one for M1, one for M2, one for M1X, and so forth. Signing the Operating System is nothing. Hell, if they're signing the OS bootloader in the same fashion on Apple Silicon Macs as they were on Intel Macs (which isn't unlikely), that would probably be, at most, a two hour call between an Microsoft engineer and an Apple engineer to make sure that the right certificates were signed and being used.

"Plenty" of people want an XServe.

No. That's why they were discontinued. No one bought them because Apple didn't know what they were doing with Server products. That's why macOS Server is relegated to an app that runs only Profile Manager and Open Directory today.

"Plenty" of people want to run 32-bit MacOS Apps on Big Sur.

Yes, however, Apple dropped it, presumably because Rosetta 2 wouldn't emulate 32-bit x86 and Apple Silicon has no 32-bit ARM instruction sets (and hasn't since A11 first came out in 2017). And moving to Apple Silicon was more important than satisfying users of apps Apple considers to be legacy.

"Plenty" of people liked Aperture...

Yes, however Apple moved to integrate its features into Photos. Plus, Apple doesn't care about Pro users. You know that.

"Plenty" of people liked Target Display Mode...

It was only available on iMacs from 2009 and 2010. Original Thunderbolt killed that. I'd hardly call the following of people mourning its loss "plenty" relative to the populace of Mac users at large.

"Plenty" of people want a PCIe tower xMac...

Not enough compared to the amount of Mac users who opt for a notebook instead or who are fine with Apple's other desktop offerings (or a Windows PC for that matter).

Plenty of people have been disappointed by Apple, who have always been prepared to throw certain groups of users under the bus, especially if they thought they might stick with Mac anyhow.

Not sure what your end point is here. Other than Apple doesn't care about anyone other than Apple (save for the potential for large droves of users not buying their products [as was about to be the case with their notebooks with the butterfly keyboards]).
I'd say that virtualization kills more birds with one stone, and Apple need the hypervisor framework to support web and MacOS developers anyway (and no, they don't need to write Windows drivers for VMs).

Virtualization only suffices for the use cases that support it. To say that it suffices for enough people to not need a direct boot option entails a lack of knowledge of what one can use a Windows PC for and the use cases in which virtualization isn't and never will be preferable.

Also, drivers need to be written for Windows 10 for ARM64 as they only exist for supported hardware at present (and an Apple Silicon Parallels Desktop VM is not supported hardware). Whether Apple is writing those drivers or whether Parallels is writing those drivers, it's almost moot. Those drivers do not exist and they need to exist in order for virtualizing Windows 10 for ARM64 on an Apple Silicon Mac to be viable at all. The same is true of direct booting. The only difference is that with direct booting, a special bootloader also needs to be engineered (as Apple is not using UEFI in the same fashion that all other ARM64 OSes seem to be).

...which probably means that you are a fairly advanced user of VMWare and dive headfirst into the settings. Heck, the first thing I do when I create a Parallels VM is go into the advanced network settings and sort out the MAC address so it inherits the IP of an older VM from my DHCP server... That doesn't represent the average user experience which is click-and-drool to create a Windows VM with sensible defaults, shared networking etc. I don't think Parallels even asks for the number of CPUs or RAM size unless you click on "advanced".

Are you trying to tell me that not customizing RAM and CPU cores on a Windows VM is a GOOD idea?

Do note that the base configuration for the Windows VM when running the automatic assistant on this very version of Parallels produces a VM that is significantly slower than the M1's native performance. The ~200 less single core hit and ~2000 multi core hit to performance came after those settings were adjusted. For Windows Excel or Publisher or the one or two simple Windows apps a Mac user might be forced to use, sure, that won't matter. But for any use case more complicated than that, it will suffer and at that point, you might as well just buy an actual PC.


...and, of course, with a VM. things like RAM, number of CPUs, VRAM can be fixed later.

I'd LOVE to see you try to explain all of that to a computer novice that just needs to run AutoCAD but is otherwise computer illiterate. I don't discourage such things. Hell, I encourage users to become more proficient. But when they're trying to get work done is not necessarily the best time to give them a crash course on virtualization. They often just need it to work.
Then you may have experienced a better class of "average user" than me because I wouldn't expect them to understand either - and if yours truly is going to end up picking up the pieces I'd much rather that they don't go within a million miles of their disc partition table.

With Boot Camp, they DON'T go within a million miles of their disc partition table. They just use a dirt simple slider. That's it!

Fixing the number of CPUs, RAM allocation, or even maximum virtual disc size in a VM is trivial.

...for you, as someone who knows what those things are! For a novice, it really isn't trivial at all.

They shouldn't need to understand: don't get me wrong, if they want an explanation I'll do my best, but mostly they just want to be able to open (e.g.) MS Project files. Which (if someone sets up a VM for them) simply consists of double-clicking the file...

If you're the guy setting it up for them, that's one thing. If they're setting it up themselves, there will be confusion. Not for all users, not by a long shot. But for enough of them that you can't say it's a one-size-fits-all solution. Because it's not.

BootCamp on Apple Silicon would need bare-metal Windows drivers for Apple Silicon graphics, SSD, WiFi etc.

Windows running on a VM does not. It just needs paravirtualised drivers that pass calls to the hypervisor. Since the hypervisor is a Mac OS app, it can call on MacOS drivers and frameworks to do the rendering (...as well as handlng things like dynamically resizable windows and "coherence" mode).

Windows drivers need to be written one way or the other. Windows doesn't care whether a driver is "paravirtualized", whether it's bare metal or otherwise. That's not how Windows (or any other guest operating system in any other situation that doesn't entail Microsoft Hyper-V) works. The only difference is that you need MORE drivers written if it's bare metal, and you need a custom bootloader written as Microsoft (and I believe every other ARM64 OS) uses UEFI and Apple no longer does on Apple Silicon Macs. Apple either needs to introduce a mode that emulates UEFI or they need to collaborate with Microsoft on a compatible boot loader. Not trivial, but not an insane engineering effort either.
When you install a Windows VM on (e.g) Parallels for an x86 Mac, you don't install video drivers for Intel Iris or AMD Radeon, you install video drivers for Parallels.

I understand how drivers for virtualized OSes work, thanks.

Without these you just get a generic, fixed-size VESA emulation. If the "technical preview" is offering dynamically resizeable windows etc. then the Parallel drivers must be mostly done.

Parallels doesn't have drivers for an OS they're not allowed to even run on their virtual machines to begin with!

Microsoft only allows this OS on OEMs! Only OEMs are producing drivers for this operating system!

The best I can offer is that Parallels knows how to work well with the generic Microsoft driver. Otherwise, they're writing drivers for an OS their product isn't even allowed to run!

(Yes, some hypervisors can do hardware device mapping and support bare-metal drivers, but it is not essential and probably wouldn't work on the M1/Big Sur security model, or the App Store version of Parallels ).

I don't know whether the structure of Windows-on-ARM64 drivers is different from Windows-on-x86, but its possible that the Parallels/VMWare drivers were a fairly straight translation of x86 to ARM64 code (assuming they weren't just written in C). Likewise, the rendering code in the Parallels hypervisor could be a port of the existing x86 version (along with changes needed anyway for Big Sur). I doubt that it was a trivial "check the ARM box in XCode" job, but it's not starting from scratch the way that bare metal M1 drivers would have been.
Windows is still Windows. Drivers are still drivers, whether running on virtualized hardware or bare metal. They are either integrated into the kernel (as is the case with Linux and Windows VMs running in Hyper-V) or they're required to be installed after the fact as a package that contains the drivers. But either way, this concept isn't different just because we're on a new architecture. If you go to Device Manager, it will still report what you have, and what drivers you have installed for it, whether you have an ARM64 SoC or an x86-64 CPU/SoC.
 
Because you are demonstrating that you don't know what a bootloader is. Nor that you grasp what the difference is between a booter and a bootloader, let alone how that pertains to Apple hardware.

ok

That's a drastic oversimplification of what is likely a way more complicated issue.

And yet people were able to homebrew Windows booting off a Raspi with no help from Microsoft.

This block of text above what I am currently typing here shows that you don't understand how drivers in Windows really work. Microsoft has what's called "Generic Drivers" for when a more specific driver is not available. It's not a simple binary of "drivers either exist or they don't" like it is for macOS.

This is correct for some categories (such as graphics), sure.

(macOS also has generic drivers. Not sure why you would think it doesn't. For USB devices, for printers, etc.)

If Windows doesn't see a specific driver for something, it will employ the use of a generic driver so as to avoid serious kernel panics

It has nothing to do with kernel panics. Generic drivers exist with the idea that it's better to run hardware with the lowest-common-denominator feature set rather than not at all. E.g., it's better to have a printer driver that doesn't support duplex but is otherwise fine than to not be able to print. It's better to show a color 640x480 screen than to show no image at all.

(otherwise known as the blue screen of death; or in this case, the green screen of death).

Windows would BSoD if there's a bug in a driver, not if a driver doesn't exist altogether.

These issues are currently happening on VMs running the Parallels technical preview. Why?

Because of bugs in drivers, not because of missing drivers. Parallels's drivers are in preview, and Microsoft's have never been tested (and perhaps never will officially be tested) against Apple hardware.

Because, on top of that version of Parallels being in beta, there are no drivers for the Parallels VM in existence.

Then Windows flat-out wouldn't show any image.

In all hypervisors that aren't Hyper-V, drivers need to be installed in the form of software packages on the guest OS.

You can boot Windows just fine without a third-party package.

Windows drivers need to be written one way or the other. Windows doesn't care whether a driver is "paravirtualized",

It absolutely does, regardless of square quotes.

I understand how drivers for virtualized OSes work, thanks.

It does not appear so.

Windows is still Windows. Drivers are still drivers, whether running on virtualized hardware or bare metal.

There is a huge difference between a driver actually talking to physical hardware, or a driver merely being a shim that forwards calls to the driver on the host OS (or forwards them to nothing at all, as the physical hardware may not even exist). A modern "graphics driver" in a VM really just translates Direct3D calls to Metal calls, for example. It is completely unrelated to any graphics chip. Apple could be free to replace it with something completely different.

 
ok



And yet people were able to homebrew Windows booting off a Raspi with no help from Microsoft.

Actually the Raspberry Pi is supported hardware for Windows 10 IoT Editions. Microsoft, at one point, sold the Pi and the kit needed to load the correct Windows 10 IoT version for that particular Pi. So, no, you're wrong there.

This is correct for some categories (such as graphics), sure.

(macOS also has generic drivers. Not sure why you would think it doesn't. For USB devices, for printers, etc.)
macOS has generic drivers for external peripherals. Things like printers, scanners, cameras (be they still, video, or both), webcams, etc.) It does NOT have generic drivers for internal components. Sound, WiFi, Ethernet, Graphics, Intel motherboard/logic board Chipsets, storage controller drivers; none of those components have generic drivers for macOS. If they did, you wouldn't see the Hackintosh community literally trying to hack third party components to work with custom drivers.

The kinds of drivers macOS has generic drivers for are NOT for the same kinds of devices that are needed to be virtualized in a VM. Windows employs generic drivers for those because, unlike macOS, the drivers are not standardized (because there are only a finite number of Apple-made Mac models) nor are they built-in to the OS in that same fashion. Plus, you need SOME kind of driver in play lest you cause all sorts of nasty conflicts, kernel panics (BSODs) and so forth. AGAIN, this is NOT how macOS works.

It has nothing to do with kernel panics. Generic drivers exist with the idea that it's better to run hardware with the lowest-common-denominator feature set rather than not at all. E.g., it's better to have a printer driver that doesn't support duplex but is otherwise fine than to not be able to print. It's better to show a color 640x480 screen than to show no image at all.



Windows would BSoD if there's a bug in a driver, not if a driver doesn't exist altogether.

That is not universally true.


Because of bugs in drivers, not because of missing drivers. Parallels's drivers are in preview, and Microsoft's have never been tested (and perhaps never will officially be tested) against Apple hardware.

You're telling me that Parallels wrote drivers for an OS that technically isn't allowed on their hypervisor nor is sold in any legal capacity to run on their hypervisor? Please explain that one.

Then Windows flat-out wouldn't show any image.

For the love of whatever diety you believe in, that's not how Windows works! This is evident by the fact that, upon installing x86 Windows on an x86 Mac running x86 Parallels Desktop or VMware Fusion, BEFORE installing either VMware Tools or whatever the Parallels equivalent is called, YOU DO NOT HAVE THE CORRECT DRIVER INSTALLED!

Furthermore, WINDOWS IS STILL SHOWING AN IMAGE.

It works this way because Windows is using a generic display driver THAT DOESN'T TAKE ANY ADVANTAGE OF WHATEVER HARDWARE IT IS RUNNING ON.

If you install Windows on any hardware and don't install the graphics driver (assuming Windows doesn't try to fetch the correct driver for you via Windows Update), this is what will happen!

This is no different on a VM than it is on a bare metal install.

The fact that I have to spell this out for you showcases that you don't understand how this works.
You can boot Windows just fine without a third-party package.

Boot, yes. Boot and run stably, no.
It does not appear so.

Sure man, whatever you say. I'm not the one insisting that macOS Generic Drivers and Windows Generic drivers are at all analogous in the context of getting a virtual machine to function correctly.
There is a huge difference between a driver actually talking to physical hardware, or a driver merely being a shim that forwards calls to the driver on the host OS (or forwards them to nothing at all, as the physical hardware may not even exist). A modern "graphics driver" in a VM really just translates Direct3D calls to Metal calls, for example. It is completely unrelated to any graphics chip. Apple could be free to replace it with something completely different.
In the context of Windows and what Windows needs to do, there is no difference. From Windows' standpoint, drivers are drivers. Sure, the nature of the drivers are probably different, but the fact of the matter remains that without a video driver (regardless of how that video driver works in the context of the VM or the hypervisor itself), you get no 3D acceleration. Without a sound driver, you have no audio. Without an Ethernet driver (even if it's just virtualizing your M1 MacBook Pro's WiFi), you have no network connectivity.

Unless Parallels took it upon themselves to write drivers for an OS that their product legally can't support, there are no supported drivers for a Parallels VM and, as such, those need to be written. Doesn't matter whether they're virtualized or physical, the fact of the matter remains that they don't exist and they need to.
 
I remember when they transitioned to Intel it took some time, it wasn't just a recompile. Is this different?
I specifically remember QuarkExpress which I think too years, maybe 4?

A "modern" 64-bit app, written in C/C++/ObjC/Swift etc. that follows Apple's developer guidelines should just recompile (there are, of course, exceptions...). Bloated, complex applications full of code that dates back to the 1990s or that maybe use processor-specific "acceleration" features directly might need a lot of re-writing. Care to guess which category QuarkExpress was more likely to fall in to in 2006? The same principles apply this time round, although the Intel switch, followed by the end of 32-bit support, the demise of Carbon (which supported quick'n'dirty ports of Classic MacOS apps), the Mac App Store rules, lots of developers making iOS versions of their apps etc. have probably helped winnow out a lot of problematic code. In any case, as time passes, more powerful CPUs and smarter compilers reduce the need for developers to hand-optimise code for a specific CPU.

Are you trying to tell me that not customizing RAM and CPU cores on a Windows VM is a GOOD idea?
Yes, if you are a non-technical user who doesn't understand the issues and won't cry into your beer if your VM doesn't get the top score in Geekbench, just accepting the defaults will get you a system that "just works" even if it is not optimal. Just like a non-technical user with a "real" PC won't (and probably shouldn't) dive into the UEFI settings and start tweaking RAM configs etc., even though that can often improve performance.

Anyway, you raised ease of use by non-technical users as being a selling point of BootCamp. Reality is that such users probably wouldn't touch either with a bargepole and would get their local expert to do it... and if that were a regular task in a work environment then I'd have a pre-rolled "virtual appliance" ready to just download, click and go.

I'd LOVE to see you try to explain all of that to a computer novice that just needs to run AutoCAD but is otherwise computer illiterate.
Same as any other minor configuration tweak: "Click on the little cog wheel icon, click on hardware, click on CPU, change the "Number of cores" dropdown from 2 to 4.". How were you planning to tell them how to change the screen resolution in Windows, or install APFS for Windows so that they could get at their Mac files from Bootcamp?

With Boot Camp, they DON'T go within a million miles of their disc partition table. They just use a dirt simple slider.
...which alters their partition table. Which runs a higher risk of trashing their SSD if something goes wrong c.f. just creating a regular file bundle (hence the warning to do a full backup). No, it is not rocket science, but its a complexity that you don't get with a VM.

Your last experience booting bare metal Windows must've been on a 5400RPM 2.5" hard drive and with Windows 7. It boots FASTER than macOS does on average.

What's that got to do with anything? Know what's faster than booting Windows on bare metal? Not having to boot Windows because you didn't have to shut it down in the first place to do something on MacOS. Or, at worst, waking it from suspend-to-disc, which is what normally happens when you're not using your VM for a while. Not to mention the associated hassle of shutting down what you are doing, saving work etc.

Virtualization only suffices for the use cases that support it.

...which is every use case apart from demanding "pro" apps that don't "suffice" without bare-metal performance. And, as you say:

Plus, Apple doesn't care about Pro users. You know that.

....which was kinda my point in listing all those things that Apple has dumped/rejected.

As I said, neither of us has any numbers to support our opinions of what Mac users need Windows for ("evidence" is not the plural of "anecdote"). I just think you need a fairly unusual workflow (e.g. CAD by day, DJing on your work computer by night) to justify the hassle of continually jinking between primary operating systems. C.f. the pretty plausible scenarios where you work happily on your Mac but periodically have to deal with some joker sending you an Access, Project or Publisher file, use a PC app to get your work email/timesheets, do your taxes, whatever.

Maybe I'm wrong about the balance - but I don't think it is an unreasonable hypothesis.

Also, drivers need to be written for Windows 10 for ARM64 as they only exist for supported hardware at present (and an Apple Silicon Parallels Desktop VM is not supported hardware). Whether Apple is writing those drivers or whether Parallels is writing those drivers, it's almost moot.

Win10 for ARM64 Developer Preview has been shown running under Parallels for Apple Silicon. Stuff appears on the screen.

Ergo: video drivers for Win10 for ARM64 that work with Parallels already exist. That means one of two things: The Parallels Desktop app is emulating some hardware standard that WoA already supports or Parallels have written/ported their paravirtualised drivers to Win10 for ARM64.

Windows drivers need to be written one way or the other. Windows doesn't care whether a driver is "paravirtualized", whether it's bare metal or otherwise.

You're conflating two entirely different types of drivers. One requires technical information about the M1 hardware far beyond what has been published, while the other is largely a shim that passes calls to the hypervisor (with some wrinkles to support things like dynamic resizing).

The point is that BootCamp on Win/ARM64 would require Apple to write and maintain Windows drivers for M1 "bare metal" (or to share a lot of confidential data with a third party, making it much harder for them to continually tweak the M1 hardware).

Parallels/VMWare can support Win10 "just" by porting their existing x86 paravirtualised drivers to Win/ARM64 and having the hypervisor render the result using MacOS drivers - or, failing that, just emulate something that Windows has built-in drivers for. No insider knowledge of M1 graphics hardware etc. needed.

I understand how drivers for virtualized OSes work, thanks.

It doesn't show, unless you're wilfully missing the point that drivers for virrtualised OSs can be hardware independent.

Parallels doesn't have drivers for an OS they're not allowed to even run on their virtual machines to begin with!
Yes, the video at the top of this thread was faked, the shadows are all wrong, the flag shouldn't be flying like that in a vacuum and you can see the photographer's reflection in Armstrong's helmet.

Parallels are absolutely allowed to run the developer preview for development/evaluation purposes (there will be a 200 page T&C document somewhere). They're absolutely able to develop drivers for Win-on-A64 (there is documentation on Microsoft's public website and no M1-specific information is needed) - they're just not able to sell it commercially without an agreement from Microsoft,

Microsoft only allows this OS on OEMs! Only OEMs are producing drivers for this operating system!

Which is easily solved by the stroke of a pen, allowing Parallels to bundle a Windows-for-ARM image with their product. Quite likely being negotiated as we speak, or even the current technical preview wouldn't be happening.

That's assuming that the other "bugs" unrelated to drivers - including possible problems with bits of windows still using ARM32 code - are actually fixable. But, if that can't be fixed in a VM it certainly can't be fixed by direct booting.

If you're just saying that there's no guarantee yet that Windows-for-ARM will ever be available as a viable product for Apple Silicon - whether that's due to legal or technical issues - then that's absolutely true - but if it is true for virtualisation then it's true with knobs on for direct booting. So far, we have an unfinished but promising proof-of-concept of virtualisation vs. zip, zero, nada for direct booting backed up by a statement from Apple that they're not going to support it.

The only difference is that with direct booting, a special bootloader also needs to be engineered (as Apple is not using UEFI in the same fashion that all other ARM64 OSes seem to be).

...I'd agree that the bootloader is unlikely to be the deal-breaker, but it still requires Apple to either write the bootloader or share details of the Apple Silicon firmware which AFAIK was only ever designed to support Apple operating systems (so who knows how difficult a Windows bootloader would be) - and things are so much simpler for Apple when they can change hardware/firmware/etc. without having to worry about breaking anybody else's operating systems.

Hell, VMware almost decided to drop support for Apple with Apple Silicon altogether! A version of Fusion for Mac was not a guaranteed thing for a hot minute there!

There are plenty of reasons for VMWare to "wobble" over M1 that have nothing to do with the overall popularity of VMs... (competition from Parallels, uncertainty over the future of ARM Windows, skepticism over Apple Silicon prior to the M1 launch) and, yet they've apparently done the math and decided to go ahead. So I don't know what your point was.
 
For the love of whatever diety you believe in, that's not how Windows works! This is evident by the fact that, upon installing x86 Windows on an x86 Mac running x86 Parallels Desktop or VMware Fusion, BEFORE installing either VMware Tools or whatever the Parallels equivalent is called, YOU DO NOT HAVE THE CORRECT DRIVER INSTALLED!


Look at ~3:39.

...because if you can run 3D games at 60fps on a retina display, then the correct drivers are probably installed.

Or, maybe, the fallback "generic" drivers in Windows ARM64 are a completely different ballgame to the unaccelerated default drivers of old.

It's obviously still a long way from ready and lots of stuff doesn't work - but last I heard, gaming on "official" ARM Windows machines like the Surface X wasn't a "just works" fest, either.

NB: It is entirely possible that the Win10 preview in use includes Parallels drivers if Parallels have developed them and submitted them to Microsoft. Windows developers can write drivers. Parallels are windows developers. I don't know why you seem to think that somehow violates the laws of physics.

Edit: looked at another vid.
- it's clearly using Parallels Tools, running at full resolution and with all the re-sizing stuff working (for a given value of working - its buggy as heck at this stage of the development, but nobody is claiming otherwise). It has a Parallels video driver. End of.
 
Last edited:
  • Like
Reactions: chucker23n1
Yes, if you are a non-technical user who doesn't understand the issues and won't cry into your beer if your VM doesn't get the top score in Geekbench, just accepting the defaults will get you a system that "just works" even if it is not optimal. Just like a non-technical user with a "real" PC won't (and probably shouldn't) dive into the UEFI settings and start tweaking RAM configs etc., even though that can often improve performance.

You make more sweeping generalizations here. Just because one requires performance DOESN'T necessarily mean that one is knowledgeable about how to optimally set up a virtual machine. Not all heavy pro users are techies. I don't know why you seem to be so black-and-white about that fact.

Anyway, you raised ease of use by non-technical users as being a selling point of BootCamp. Reality is that such users probably wouldn't touch either with a bargepole and would get their local expert to do it... and if that were a regular task in a work environment then I'd have a pre-rolled "virtual appliance" ready to just download, click and go.

You do realize that you won't have that luxury at EVERY work environment, right? Boot Camp is a slider. Literally buy Windows, download Windows, run Boot Camp, pick how much of your system is devoted to it. You're not going to win an argument about anything else being easier than that, so just stop while your arguments still at least make SOME sense.

Same as any other minor configuration tweak: "Click on the little cog wheel icon, click on hardware, click on CPU, change the "Number of cores" dropdown from 2 to 4.". How were you planning to tell them how to change the screen resolution in Windows, or install APFS for Windows so that they could get at their Mac files from Bootcamp?

Save to a USB drive. Move it over. Inconvenient, sure. But it works and requires minimal explanation. You clearly don't deal with computer-illiterate folk for a living. I've been doing it for the last two decades.

...which alters their partition table. Which runs a higher risk of trashing their SSD if something goes wrong c.f. just creating a regular file bundle (hence the warning to do a full backup). No, it is not rocket science, but its a complexity that you don't get with a VM.

Users are not directly interacting with the partition table. Furthermore, I've been Boot Camping both my and other Macs for several years and have never encountered an issue. Are you telling me that these problems are commonplace?
What's that got to do with anything? Know what's faster than booting Windows on bare metal? Not having to boot Windows because you didn't have to shut it down in the first place to do something on MacOS. Or, at worst, waking it from suspend-to-disc, which is what normally happens when you're not using your VM for a while. Not to mention the associated hassle of shutting down what you are doing, saving work etc.

So, a couple things. You keep harping on the point that rebooting into Windows is slow. It's not. Takes a small number of seconds on a modern SSD based Mac and on any version of Windows 10 (about the same amount of time it takes to wake a suspended VM from sleep).

Secondly, suspending and waking VMs isn't currently supported on Apple Silicon Parallels. I would have to assume that they'll rectify this at some point, but for now that's not a feature, so that argument is moot.

...which is every use case apart from demanding "pro" apps that don't "suffice" without bare-metal performance. And, as you say:

Oh sure. Plus it's up to Apple and Microsoft to make a direct boot solution possible. They could just as easily say, as you have, that no one needs it. That seems to be Apple's most recently recorded stance, but it's not like they didn't have that stance before with Intel Macs.

....which was kinda my point in listing all those things that Apple has dumped/rejected.

As I said, neither of us has any numbers to support our opinions of what Mac users need Windows for ("evidence" is not the plural of "anecdote"). I just think you need a fairly unusual workflow (e.g. CAD by day, DJing on your work computer by night) to justify the hassle of continually jinking between primary operating systems. C.f. the pretty plausible scenarios where you work happily on your Mac but periodically have to deal with some joker sending you an Access, Project or Publisher file, use a PC app to get your work email/timesheets, do your taxes, whatever.

Maybe I'm wrong about the balance - but I don't think it is an unreasonable hypothesis.

You can't call that workflow "fairly unusual" without data to support it. Like, that sentence literally contradicted the one immediately preceding it. Again, I'm not suggesting that the user needing Project and Access and Publisher (or any number of non-intensive non-Microsoft-Office apps) wouldn't be served fine by a VM. That's certainly the route I'd prefer a user take! But you can't say it serves every or even most use cases, especially without the data to back that up.
Win10 for ARM64 Developer Preview has been shown running under Parallels for Apple Silicon. Stuff appears on the screen.

Are you not familiar with the concept of the Microsoft Generic Display Driver? As in the universal driver that gets applied when the actual driver is missing in action? Stuff appears on the screen with that in play too, you know. ;)

Ergo: video drivers for Win10 for ARM64 that work with Parallels already exist. That means one of two things: The Parallels Desktop app is emulating some hardware standard that WoA already supports or Parallels have written/ported their paravirtualised drivers to Win10 for ARM64.

Again, Microsoft Generic Display Driver. That's not the proper display driver. It's what exists when there isn't a better driver applied. Windows will attempt to fetch the right driver from Windows Update (hard to imagine that the Parallels VM display driver will exist there, if at all). And Parallels isn't making a driver for an OS it's not even supposed to be virtualizing to begin with.

You're conflating two entirely different types of drivers. One requires technical information about the M1 hardware far beyond what has been published, while the other is largely a shim that passes calls to the hypervisor (with some wrinkles to support things like dynamic resizing).

Considering I'm talking about drivers from the standpoint of Windows (which doesn't care about that distinction), that distinction is moot.

The point is that BootCamp on Win/ARM64 would require Apple to write and maintain Windows drivers for M1 "bare metal" (or to share a lot of confidential data with a third party, making it much harder for them to continually tweak the M1 hardware).

Parallels/VMWare can support Win10 "just" by porting their existing x86 paravirtualised drivers to Win/ARM64 and having the hypervisor render the result using MacOS drivers - or, failing that, just emulate something that Windows has built-in drivers for. No insider knowledge of M1 graphics hardware etc. needed.

Assuming Apple doesn't need to be involved in drivers for VMs running on their Hypervisor framework, then yeah, the difference is that Apple would need to write drivers (and a bootloader) whereas Parallels or VMware would need to do the work in making virtualized drivers. That said, it's not a simple matter of porting x86 drivers to ARM64 considering it's an entirely different virtual machine. If it was, you'd be sacrificing even more performance. Again, not going to matter for that person using the peripheral Office apps and other such minor Windows apps that aren't (and likely won't ever be) available for Mac. But that doesn't serve all use cases. Again, there are plenty of 16" MacBook Pro users who use Boot Camp heavily (and selected the 16" MacBook Pro specifically because it was more performant than any other Mac portable, thereby requiring heavy Windows usage).


It doesn't show, unless you're wilfully missing the point that drivers for virrtualised OSs can be hardware independent.

You're missing the point that VMs are technically computers as far as the guest OS is concerned. The guest OS still needs proper drivers to function stably. Proper drivers have not been made for Windows 10 for ARM64 for the Parallels Apple Silicon VMs, hence the instability that pretty much everyone has reported when doing tests with this stuff!

Yes, the video at the top of this thread was faked, the shadows are all wrong, the flag shouldn't be flying like that in a vacuum and you can see the photographer's reflection in Armstrong's helmet.

Don't be ridiculous. Seriously. You can't tell me that there are stable drivers for an OS that Parallels is legally prohibited from supporting on their Apple Silicon software as of this post. You can and are telling me that there are drivers that produce images. You are totally correct in that. Even if you tell me that there's another driver that isn't the generic display driver in play, you might even be right about that too. But you absolutely cannot tell me that those drivers are (a) the correct drivers for that VM (again, from Windows' standpoint), and (b) that they're stable.

Parallels are absolutely allowed to run the developer preview for development/evaluation purposes (there will be a 200 page T&C document somewhere). They're absolutely able to develop drivers for Win-on-A64 (there is documentation on Microsoft's public website and no M1-specific information is needed) - they're just not able to sell it commercially without an agreement from Microsoft,

Please link to said documentation. Parallels cannot provide support for Windows 10 for ARM64 running as a VM. Nor does Microsoft have to provide support when it goes against their current support model. You want to talk about a good user experience? For the time being, this ain't it!

Which is easily solved by the stroke of a pen, allowing Parallels to bundle a Windows-for-ARM image with their product. Quite likely being negotiated as we speak, or even the current technical preview wouldn't be happening.

That logic doesn't follow. The pen-stroke element, sure. That's just Microsoft changing policy. But the idea that the current technical preview wouldn't be happening if moves weren't being made to change said policy negates the fact that there is still a ton of Linux virtualization happening on Macs! Hell, that's what Apple was primarily advertising during its initial Apple Silicon presentation at WWDC! Hell, the T2 made native booting Linux nearly impossible on later-era Intel Macs, making virtualization the only option there.

Do I believe that everything standing in the way of a stable Windows 10 for ARM64 on Parallels/VMware Apple Silicon VM will eventually be rectified? Most definitely. But THEY'RE NOWHERE NEAR READY FOR PRIME TIME YET! DRIVERS ARE NOT 100% THERE, HENCE STABILITY ISSUES!

That's assuming that the other "bugs" unrelated to drivers - including possible problems with bits of windows still using ARM32 code - are actually fixable. But, if that can't be fixed in a VM it certainly can't be fixed by direct booting.

Those bugs need to be fixed regardless of whether direct booting or virtualization is involved. ARM32 code isn't executing in either case scenario and will cause issues in either case scenario. Frankly, that might be the biggest hurdle to Windows 10 for ARM64 making it onto Apple Silicon Macs in either scenario.

If you're just saying that there's no guarantee yet that Windows-for-ARM will ever be available as a viable product for Apple Silicon - whether that's due to legal or technical issues - then that's absolutely true - but if it is true for virtualisation then it's true with knobs on for direct booting.

I'm not outright saying that, but that statement is totally true and I'm in complete agreement there. If they can't get it going for VMs, then direct booting is moot for the aforementioned and agreed-upon reasons that doing so will require more work on Apple's and Microsoft's part than virtualziation would (which wasn't AS true for Intel Macs by comparison).

So far, we have an unfinished but promising proof-of-concept of virtualisation vs. zip, zero, nada for direct booting backed up by a statement from Apple that they're not going to support it.

You do have the precedent set in April 2006 of them reversing course on a similar decision. I'm not saying that they'll ever do direct booting, but I don't see why it's necessarily out of the question just because they're saying they're not going to do it. It's not like Apple doesn't reverse course on things all the time.

...I'd agree that the bootloader is unlikely to be the deal-breaker, but it still requires Apple to either write the bootloader or share details of the Apple Silicon firmware which AFAIK was only ever designed to support Apple operating systems (so who knows how difficult a Windows bootloader would be) - and things are so much simpler for Apple when they can change hardware/firmware/etc. without having to worry about breaking anybody else's operating systems.

It does require collaboration between the two, for sure. My guess is that if it were allowed, it wouldn't be in the form of the Boot Camp Assistant as we know it today (which makes the fact that the Boot Camp Assistant is a universal binary in Big Sur all the weirder). More likely, the two collaborate on a special app-based installer (a la the installers for every macOS release dating back to Mac OS X Lion) that is published in the Mac App Store. Apple's heavy influence would negate the concern for a third party OS landing in the Mac App Store (especially since the number of client-focused Linux distros for ARM64 is still much smaller than that for x86).

There are plenty of reasons for VMWare to "wobble" over M1 that have nothing to do with the overall popularity of VMs... (competition from Parallels, uncertainty over the future of ARM Windows, skepticism over Apple Silicon prior to the M1 launch) and, yet they've apparently done the math and decided to go ahead. So I don't know what your point was.

My point was that virtualizing ARM64 Windows 10, alone, is not enough of a reason to care about continuing to support virtualization products for Mac. Their concern (and frankly, as someone who is about to buy an Intel MacBook Pro for this very reason, mine as well) is that there isn't as much to virtualize. Most people don't want the hassle of not being able to run an x86 or x86-64 application natively, which is probably what fueled their concerns. I definitely see Microsoft improving in these areas to the point where it won't matter to the average user, especially on something like an M1.

I'm grateful that they decided to keep it going, but it really says something that this wasn't an immediate decision (let alone one that required a public twitter post to gauge customer interest). Parallels went all-in on their decision to support Apple Silicon (to the point where it was featured in the public announcement for the transition to Apple Silicon). Though, to be fair, Apple support is their bread and butter at this point (where the Mac is much more of a side-hustle for VMware's virtualization business at large).


Look at ~3:39.

...because if you can run 3D games at 60fps on a retina display, then the correct drivers are probably installed.

You must not have that much experience with drivers in Windows. I can assure you this is a very dangerous and often foolhardy assumption to be making. You can have the wrong drivers installed, still have 3D acceleration, and still incur instability. This is why anyone running an Intel PC (or Mac) with Sandy Bridge or earlier is taking a stability risk in running Windows 10 on that machine. Sure it meets the minimum requirements, but it's not supported and you're not guaranteed stability by any stretch.

Or, maybe, the fallback "generic" drivers in Windows ARM64 are a completely different ballgame to the unaccelerated default drivers of old.

It's possible, though I doubt that's the case. Generic accelerated drivers are not a thing. If they were a thing, the PC market would crap bricks with joy and excitement. It would also be a massive selling point to start moving Windows development from x64/x86-64 to ARM64.

It's obviously still a long way from ready and lots of stuff doesn't work - but last I heard, gaming on "official" ARM Windows machines like the Surface X wasn't a "just works" fest, either.

That's the fault of emulation technologies more than anything else and that's going to suck for a time regardless of whether it's a VM running on an Apple Silicon Mac or a Windows volume natively booting on an Apple Silicon Mac. Frankly, even if native boot AND virtualization of Windows 10 for ARM64 comes about and everything is made stable, that will still be one area where an Intel Mac (or just having a separate x86-64 PC) will be more convenient (and there's not much that can be done apart from getting developers to write fat binaries and/or native code). Native ARM64 code is the answer to the 'it isn't a "it just works" fest'.

NB: It is entirely possible that the Win10 preview in use includes Parallels drivers if Parallels have developed them and submitted them to Microsoft. Windows developers can write drivers. Parallels are windows developers. I don't know why you seem to think that somehow violates the laws of physics.
It doesn't violate the laws of physics. It does, however, violate the laws of practical logic. Why is Parallels writing drivers for an OS that isn't able to be licensed to even run inside their product? If it's in preparation because another shoe is set to drop, that'd be one thing.

Though that doesn't explain the near-universal instability that is resulting. Windows Insider Preview builds are never so bleeding edge that they cause that degree of instability. Beta versions of drivers also tend to not cause that degree of instability, especially when we're talking about "paravirtualized" drivers. Sure, you can chalk some of that up to the Parallels version being a technical preview, but not all of it. Furthermore, it's not like qemu emulation of Windows 10 for ARM64 doesn't also have similar pitfalls.
 
Last edited:
Can anybody help me understand the use of Windows on ARM with a Mac?? Is there enough app support to justify adding the OS to an M1?
I was wondering about the same and found out it actually has x86 emulation built-in so it should be able to run pretty much anything. Too bad the emulation doesn't seem to be anywhere even close to Rosetta 2 performance (which I will believe only when I see it myself, though).


Regardless, I'm not really interested in toying around with something like this. It'd be better if they could somehow hook up Parallels to Rosetta and get some real x86 emulation running so we could install x86/x64 versions of whatever linux/windows distrubutions we need. Or something. ARM Windows at this point, no thanks. Pretty much the same with ARM Linux distributions when pretty much all the information and software you find will be for x86 versions.
 

Not all heavy pro users are techies. I don't know why you seem to be so black-and-white about that fact.

Did I say all heavy pro users are techies? No. But professionals doing CAD, Video editing etc. are far more likely to be technically competent, and less computer-phobic than someone just using wordprocessing, email, spreadsheets etc. (and usually only scratching the surface of those apps, at that).

This isn't a question of black-and-white: you're the one making it a false dichotomy. You're the one refusing to even consider the possibility that all those "non-Pro" Mac users who need access to a few Windows apps to deal with the Windows-majority world might outnumber the special cases who choose to use a Mac to run "pro" PC apps.

Boot Camp is a slider.
Parallels users don't even need to see that slider.

Literally buy Windows, download Windows, run Boot Camp, pick how much of your system is devoted to it.

...boot Windows, set up the WiFi, configure the screen resolution and depth (probably seek out and install the latest video drivers if you care about performance that much) discover you need to buy and install Paragon APFS to read your Mac partition and/or work out how to access your NAS from windows... all of which are either unnecessary, done automatically or pre-installed when you use a VM (MS has pre-configured VM images for all the common hypervisors).

Come on, you know that a non-tech user can't properly configure even a pre-installed Windows PC for a pro app without a lot of guidance.

...and if MS do offer Windows-on-ARM64 then it's likely to be as an OEM-style bundle with a custom image sold via Parallels and/or VMWare (like SoftWindows was in the old days) it's likely to be even more click-and-drool.

Save to a USB drive. Move it over. Inconvenient, sure.

Inconvenient, sure - that's the whole freaking point of my argument!

You clearly don't deal with computer-illiterate folk for a living. I've been doing it for the last two decades.
I've been doing that for twice as long, and if you think that "computer-illiterate folk" could reliably install and configure Windows (regardless of whether it is bootcamp, a VM or a "real" PC) and get it working to spec without extensive support then you've been dealing with a better class of computer illiterate person.

Computer illiterate folk are still running their 27" PC screens at the default 800x600.
Computer illiterate folk don't know how to copy files other than by opening them and choosing "save as..."
Computer illiterate folk get confused about the difference between MS Office and MS Windows.
Computer illiterate folk don't know the difference between RAM and storage, let alone have any idea what a sensible partition size would be.
Computer illiterate folk use pocket calculators to work out the values to type into Excel spreadsheets (seriously, I've seen it more than once).
Computer illiterate folk aren't (always) stupid - they just aren't being paid to know stuff about computers.

You lost most of them at "download Windows".

The idea that bootcamp is easier to use and VMs were too hard was your point. I'm not suggesting that VMs are vastly easier, but at worst it is "swings and roundabouts" and at best you can set up a Parallels installation so that when the user double-clicks on a MS Project file under MacOS it wakes up windows and opens the file in a window on the Mac desktop.

I've been Boot Camping both my and other Macs for several years and have never encountered an issue.

I still hope you made a full backup first. There is a concept of "low risk of serious damage" vs. "larger risk of minor damage"? As in: totally hosing your SSD vs. having to delete a useless VM image file/folder and start again.

So, a couple things. You keep harping on the point that rebooting into Windows is slow.

No. I keep on harping on about the point where saving all your work, copying the files you need to USB stick (your suggestion) shutting down MacOS, booting up Windows (hopefully it doesn't want to install updates first), retrieving your files... then reversing the process when you want to switch back to MacOS... is slow c.f. just waking a windows VM from suspension and having it run alongside your MacOS apps. Windows' black-screen-to-login-prompt time is a tiny part of that.

It doesn't violate the laws of physics. It does, however, violate the laws of practical logic. Why is Parallels writing drivers for an OS that isn't able to be licensed to even run inside their product?

Practical logic is that established facts beat speculation. The video shows Parallels Tools working on Win10 for ARM. Whatever the technicalities of how the drivers are working, Parallels has self-evidently written/ported Parallel Tools to "an OS that isn't able to be licensed to even run inside their product". Except it is licensed: for development/evaluation use by people registered in the "Windows Insiders" program. Look at the videos again - people are getting a virtual machine disc image from an official Microsoft site after legitimately signing in. It's not some dubious Warez site.

And yes, that probably means that Parallels have some cause to expect that there will be a way of getting a full license. Since their entire business is built around virtualisation/containerisation products for Mac and servers, since the entire Mac range is going M1, since there's also huge interest in ARM processors on servers (even MS are rumoured to be working on an ARM server chip) then yeah, maybe, just maybe, they know more than we do about Microsoft's plans for Windows-on-ARM licensing.

Secondly, suspending and waking VMs isn't currently supported on Apple Silicon Parallels.
Seriously? You're going to go with that? You know that Apple Silicon Parallels is currently a technical preview with a laundry-list of missing features and bugs... running a developer preview of Win10 for ARM that isn't ready for production use even on a Surface X! ...and even if the suspend feature never appears (for some unlikely technical reason) you're still ignoring all the other advantages of not needing to reboot.

Thanks, though - that last absurd argument makes it clear that you're not even trying to engage with the discussion and just trolling, which saves everybody else a lot of time.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.