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.