If you care about running Windows on a Mac, you’ve undoubtedly heard that the end user license agreement (EULA) for Windows Vista Home Basic and Home Premium forbids you to use these versions of Microsoft’s latest operating system release with virtualization software—software that allows you to run operating systems other than the Mac OS in a windowed environment within the Mac OS. Such virtualization software includes the popular Parallels Desktop for Mac. What the reports on this matter don’t reveal is whether this is simply a legal restriction or also a technical one.
I hoped to have the answer. And then, last night, it came to me in a dream.
Officially, the operating system that was available on that Mac at the time that you bought it is the oldest version of macOS that can run on that Mac. It's likely that an older OS won't include.
In that dream, the boss OK’d the purchase of Windows Vista Home Premium for the purposes of testing its effectiveness when run both in Apple’s Boot Camp and in the latest beta (3150) of Parallels Desktop for Mac. It wasn’t an entirely happy dream.
For example, early in the proceedings (in the dream, may I remind you) I floated over to the local Costco to purchase said OS. Regrettably, Costco offered only the $159 upgrade version—one that required a valid key from a version of Windows XP Home Edition. In both my dream and real life I have a copy of XP Professional, and you can’t upgrade from XP Pro to Vista Home. The upgrade path from XP Pro is to Vista Business or Vista Ultra, both of which have been granted virtualization privileges by Microsoft.
So off I drifted to the local Staples, which sells the full version of Vista Home Premium for exactly one arm and one leg. (More precisely, the list price for the full version is $239.) To get a better sense of what Vista under Parallels could do, I also purchased an upgrade version of Office Standard 2007, as I had the previous Office XP Standard. (Good thing this is a dream, eh boss? I might have forgotten to mention that in the original expense request.)
To get a sense of what Vista could do on a Mac without virtualization software, I installed the latest beta of Apple’s Boot Camp on my 2.66GHz Mac Pro with 2GB of RAM and an ATI Radeon X1900 graphics card with 512MB of RAM. I then created a Mac Drivers CD, and proceeded to install Windows Vista Home Premium and Office 2007 under Boot Camp. Everything went swimmingly until I attempted to install the Mac Drivers CD. Part way through the installation I saw this:
Although my dream-self understood there were ways to manually install these Mac drivers, I had bigger fish to fry and so let it wait for another time.
Under Boot Camp on my Mac Pro, Vista and Office 2007 performed nicely. Vista’s three-vowels-and-a-consonant-just-like-Aqua-transparency-effect—otherwise known as Aero—was in evidence. Right-click on my Microsoft mouse worked as it should, Vista recognized my AirPort network, and my HP LaserJet 1300n printer appeared when I attempted to print a Word document. The Windows version of QuickTime 7 installed properly and played back a movie preview I accessed from Apple’s QuickTime site. Windows Media Player was able to rip an audio CD and play back the resulting files reasonably well (though there was occasional stuttering when the Mac’s processor was taxed). All in all, I felt like I was running a living and breathing (and fast) PC.
One reason my dream-self initially installed Vista under Boot Camp was so I could employ the Parallels beta’s ability to use a Boot Camp installation rather than requiring its own installation of Windows. Regrettably, this was a non-starter. Even though I added the Boot Camp volume as a hard drive within Parallels, attempting to create a new virtual machine based on Boot Camp failed. If I told Boot Camp that I was attempting to use the Vista OS, the Boot Camp option was grayed out. If I told it I was trying to install XP from my Boot Camp volume, the Boot Camp option became active, but the installation couldn’t proceed.
That left installing Vista Home Premium directly into Parallels—the thing that the Vista Home EULA forbids. While my dream didn’t exactly turn to nightmare at this point, it certainly had its scary moments.
Cutting briefly to the chase, Vista Home Premium installed perfectly well. Once it was up and running I noticed that the Aero effect was nowhere to be seen—Parallels simply couldn’t emulate the kind of graphic card/power necessary to make it work. I then asked Vista to install the latest Vista updates—something I understood to be a problem for others who tried it.
Vista Home Premium running on a Mac via the latest Parallels Desktop beta |
No problem. Vista downloaded the updates, installed them, I restarted, and everything continued to work. The Office install also proceeded according to plan—I first installed Office XP Standard so the upgrade would see that I had a legit copy of Office and then installed the Office Standard 2007 upgrade. I launched the various Office applications and they worked. Performance wasn’t nearly up to that of running Vista and Office under Boot Camp, but it was no worse than working with a Mac-native version of Office on, say, a late-model iBook.
Where things began to break down was with media files. I ripped that same audio CD in Windows Media Player as a 192kbps MP3 file and playback was dreadful—the tracks played slowly and stuttered constantly. I tested some of the audio tracks bundled with Vista and they exhibited the same problem. Shutting down Vista and bumping up the amount of memory allotted to Vista within Parallels (1.5GB) didn’t help.
I rose this morning with a mixed feeling of elation and disappointment. I like having Windows on my Mac. It’s useful for running the latest version of Office, and I do a moderate measure of cross-platform audio and media work where quickly moving between the Mac OS and Windows is handy. I’m elated because—at least according to my dream—Windows Home Premium does run acceptably under Parallels as does the latest version of Office, despite what the EULA may hint. But I’m disappointed that it doesn’t run as well as XP.
Happily, nothing in the EULA forbids me from running Vista under Boot Camp. As far as Vista and Microsoft are concerned, a Mac running Boot Camp is just another PC. But Boot Camp isn’t convenient for quickly moving files between operating systems. My hope is that Microsoft will back off from its EULA when it understands that one sale of an almost-affordable version of Vista is better than no sales of the “Wait, you want how much for this!?” spread. At the same time, I pray that Parallels will continue to explore ways to make Vista perform as well as possible in virtualization.
Then again, maybe I’m dreaming.
[ Senior Editor Christopher Breen dispenses troubleshooting tips in the Mac 911 Weblog and offers iPod-related commentary in the iPod Blog. ]
Editor’s Note: This article was updated at 4:20 p.m. PT to include specifications of the hardware used in this Hands On.
System and Network Extensions are fairly easy programmatically. However, there is some nuance around building them. Much of this is in getting the correct entitlements – but also a little in troubleshooting.
To see (or set) those entitlements, look at the .entitlements file located in the root of an Xcode Project. That will be a plist with a few entries. In this one, we’ll see com.apple.developer.networking.networkextension so we’re working on a network extension.
com.apple.security.app-sandbox com.apple.security.application-groups $(TeamIdentifierPrefix)com.krypted.firewall com.apple.developer.networking.networkextension content-filter-provider
To add one, go to the General screen for the project, and locate the section for Frameworks, Libraries, and Embedded Content.
Then use the plus sign to add and provide the name of the framework to add.
That allows us to use network extensions (so we'll add or see import NetworkExtension
in the beginning of a swift file that uses it, as well as an import SystemExtension
when using those. That import will allow us to use classes Apple provides for tasks that expose functionality such as NEFilterManager (https://developer.apple.com/documentation/networkextension/nefiltermanager). I won't get into everything one might do with these, but once we get to doing the things, we invariably need to troubleshoot. And given that they have specific needs, the things I'm about to cover shouldn't be done in production and are really just there for troubleshooting new extensions.
First, we can't do much with SIP on so this is one of the very few cases where we're going to disable it on a development machine. To do that, we'll boot into Recovery Mode (using Command-R to boot) and run the following command.
csrutil disable
Now, let's boot the machine and set
systemextensionsctl developer on
If it's an arm and it's a driver extension, we might then need to run the following:
sudo nvram boot-args=-arm64e_preview_abi
Now that we're booted and able to interface with system extensions directly, we can use lldb. To enter the lldb interactive mode, simply run lldb
:
sudo lldb
Now from the interactive mode, we can attach to a process to see what's happening when it's run:
process attach --pid 8766
In the above we're attaching to a specific pid and could have used --waitfor
following it if we wanted to attach to the next instance. But if we wanted to attach to an app we'd just be running lldb followed by the .app bundle URI. For example, if we're putting test apps into /Compiled and want to attach to an app called myextension.app:
lldb /Compiled/myextension.app
We can then see any breakpoints as well (from that lldb interactive mode):
breakpoint list
So let's say we invoke an extension in line 87 of file blocker.c we could create a breakpoint there:
breakpoint set --file blocker.c --line 87
This sets the breakpoint for each methods that implement that line, or its class, as well. Once the breakpoint is hit, use the thread
verb followed by continue
to proceed:
thread continue
This brings up threads. From within lldb use the thread verb followed by list to see the state the process is in:
thread list
Or use thread with backtrace to see those:
thread backtrace
Also checkout waypoint
and frame
in lldb.