Running Windows on Macs is still hit-or-miss
Article By : Brian Dipert
Native Windows on Macs will likely always be a hit-or-miss endeavor, as this case study indicates.
Given that I’m in the midst of a series of blog posts on the topic of running MacOS on PC hardware, the subject of this particular writeup is admittedly more than a bit ironic. But hang with me … particularly given recent hands-on experiences, I think you’ll find this angle interesting, too.
I’m a nearly 100% MacOS user nowadays, but I occasionally still have need to fire up Windows (or at least a Windows app). In the most common case, I’m doing my monthly reconciliation of my various bank accounts against statements I’ve received, for which I fire up an ancient copy of Quicken for Windows (I still haven’t converted over to Quicken for Mac). In that elementary situation, my solution is equally straightforward: open-source Wine.
What if I need to run a full-blown Windows environment? My longstanding solution here, as regular readers may recall, is VMWare’s Fusion, which nowadays I run in fully virtualized mode (i.e. virtualizing all hardware) versus more simply leveraging it only as a bridge between MacOS and a copy of Windows installed on a separate drive partition via Boot Camp. But after a recent MacOS upgrade, which rendered my existing Fusion version obsolete, I decided to get off the seemingly perpetual paid-upgrade treadmill (in fairness, VMware isn’t as egregious here as is Parallels, whose competitive virtualization product my wife has long used, but still …).
Enter open-source VirtualBox, originally developed by Innotek, then by Sun Microsystems via acquisition, and now managed by Oracle via another acquisition. The core package is free of charge for any purpose under the GNU GPLv2. The separate Extension Pack (which enables support for USB2/3 and other newer hardware and protocols), on the other hand, is covered under the proprietary Personal Use and Evaluation License, which only permits free-of-charge usage for personal use (“the installation of the software on a single host computer for non-commercial purposes”), educational use, or evaluation purposes.
In migrating from Fusion to VirtualBox, I didn’t even need to recreate from scratch my Windows 7 virtual machines on either of the two machines they were installed on. Instead, I ran them through VMware’s OVF conversion tool in order to convert them from VMware’s proprietary VMX format to OVF (the Open Virtualization Format). I was then able to open them up in VirtualBox and, after uninstalling VMWare Tools (the Fusion equivalent to VirtualBox’s Extension Pack) and installing Extension Pack in its place, I was up and running glitch-free. Both Windows and Office prompted me to reactivate them since the underlying virtualized “hardware” was now different, but even this was uneventful.
My wife, on the other hand, is actually a near-100% Windows user, although like me she still prefers Apple hardware. For that reason, I’ve always put Windows on a separate drive partition via Boot Camp, giving her the option of either running it native or virtualized under MacOS via Parallels. And most of the time, at least nowadays, she’s running Windows native. On the machine she’s using now, a mid-2015 15″ Retina MacBook Pro, I’d originally installed Windows 7, which I more recently updated in situ to Windows 10. Until a few days ago, everything was running fine.
While at the auto store getting my studded winter tires put on the Volvo the other morning, I got a frantic text message from my wife. She’d just walked into her office and found the computer sitting there displaying the login screen … she was used to Windows 7, for which you could permanently disable update “pushes” (as her IT department, I’d still manually install them periodically), and didn’t realize that Microsoft had gotten more assertive in this regard with Windows 10.
Once she logged back in, things got much worse very quickly. LAN performance over Wi-Fi still seemed to be fine, and she was still seemingly getting personal email via Windows 10’s Mail client program. But web access on any browser she tried was atrociously slow at best, and usually completely unusable. And her work email (Outlook 2016 via Exchange) was also at a standstill. Incoming and outgoing packets were, it seems, being dropped all over the place.
When I got home, I tried everything I could think of (and find online), including a deletion of the Wi-Fi hardware from Device Manager, followed by a reboot to force driver re-install (hold that thought). None of my other wired- or wireless-connected devices were exhibiting connectivity issues, but I rebooted my mesh network anyway, for good measure. Nothing did the trick.
I therefore reluctantly concluded that the prior night’s reboot must have been due not to a normal O/S update but as the result of an O/S crash which rendered the Registry corrupted or something else severe like that … so I blew away the Windows build, took advantage of the opportunity to upgrade the MacOS build from 10.12 “Sierra” to 10.13 “High Sierra” (blocking partition conversion from HFS+ to APFS in the process), and then attempted to recreate the partition and reinstall Windows from scratch.
Problem #1: I kept getting a weird error midway through the Boot Camp Assistant partition-creation process, which I’d never experienced before, indicating that “an error occurred while copying the Windows installation process.” After Googling around for a while, I stumbled across the root cause and fix (for those following in my footsteps, the author of that post makes liberal interchange of the terms “volume and partition” and also mistakenly uses the word “OSXRESROUCES” in one spot where he actually means “OSXRESERVED,” but these are nits), which I’ll attempt to summarize:
- Boot Camp Assistant creates two partitions: “BOOTCAMP,” where Windows will ultimately reside, and the temporary “OSXRESERVED” (containing the Windows installation files), which disappears after the next MacOS boot.
- “OSXRESERVED” is by default formatted as FAT32, which supports individual files up to 4 GBytes (minus 1 byte) in size.
- However, the ISOs for newer Windows 10 builds contain at least one file (install.wim) which is larger than 4 GBytes in size … 4.6 GBytes, to be exact, in version 1909 now available, therefore generating the error … and of course older-version ISOs are no longer available for download from official (i.e. Microsoft-served) sources (no BitTorrent for me, thank you kindly).
- The “solution” is to quit Boot Camp Assistant partway through, after the partitions are created but before file copy is attempted (and error is generated), then convert the “OSXRESERVED” partition from FAT32 to exFAT and manually do all the file copy-and-other steps from there that Boot Camp Assistant normally undertakes automatically.
I got Windows re-installed (and it even auto-reactivated; Microsoft’s servers must have conveniently recognized the hardware configuration from before). I then installed the various Boot Camp drivers that enabled, among other things, the computer’s Wi-Fi subsystem. I crossed my fingers, launched a browser … and all was back to normal. Then I went into Windows Update and a bunch of patches started streaming down. They installed, the computer rebooted … and Problem #2: it was offline again. Obviously, I had my big-picture culprit. But what to do about it?
The first thing I did, after wiping and reinstalling Windows 10 yet again, was to figure out how to delay updates as long as possible so my wife could get some work done on her computer (worst case, it actually still is possible in Windows 10 to block updates in perpetuity, but perhaps obviously that’s not wise long-term). Then I set about trying to figure out which of the installed updates had taken the computer offline. Turns out, it seems that Microsoft recently pushed an update to the Broadcom Wi-Fi driver, which others have reported caused the same issues my wife experienced; the solution is to roll back to the original Boot Camp driver. I’ll let you know in a bit more than a month, when upgrades are automatically re-enabled, whether or not the workaround solved the issue for us, too.
At first glance, running Windows on modern Macs would seem straightforward. They’re based on x86 CPUs and other PC building blocks, after all; what could go wrong? But realize first and foremost, as I mentioned a few months ago, that Apple’s EFI (Extensible Firmware Interface, the successor to BIOS) and the industry-standard UEFI are similar but not identical. Realize, too, the added complication of multi-partitioning a drive so that it can alternatively boot either NTFS-formatted Windows or HFS+-or-APFS-formatted MacOS. And finally, realize that Apple systems still contain plenty of hardware that’s rarely, if ever, found in other manufacturers’ computers, thereby explaining the driver suite that Apple supplies in Boot Camp.
Speaking of which … more generally, this situation reveals what a “red-headed stepchild” Boot Camp has always been. If running Windows natively on Mac hardware was something that Apple and Microsoft both enthusiastically blessed, you’d never have an Apple-supplied utility that created partitions format-incompatible with file sizes on Windows operating system installation images. And were it something that both companies consistently supported, you’d also not have a situation where Microsoft update utilities overwrote Apple-provided drivers, bringing systems to their knees in the process. 100% virtualization likely remains a long-term Windows-on-Mac option, because in doing so you’ve virtualized all of the Windows-sensed hardware and are fundamentally relying on Apple-developed drivers. Full virtualization also inserts an intermediary (Parallels, VMware, or the VirtualBox developer community) in-between the two companies, an intermediary with high motivation to keep things working. But native Windows on Macs will always be a hit-or-miss endeavor: caveat emptor. Sound off in the comments!
—Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.