By James Hanback
If you were ever into mid-1980s computer gaming, you might know about a little graphical computer adventure game called King’s Quest. At the time, the game was developed and distributed by a company known as Sierra On-Line. King’s Quest was a role-playing adventure game, which meant that your goal as player was to guide the main character, Sir Graham, through the three-dimensional computer-generated Kingdom of Daventry. You walked Sir Graham around Daventry (and beyond) by using the keyboard. You made him perform other actions by typing verb and noun combinations or phrases like “take mirror” to gather items you would later use to solve puzzles that eventually (hopefully) enabled you to solve the game’s ultimate objective. Sometimes the game’s interpreter couldn’t figure out what you were telling Sir Graham to do, and those were the times that you’d need to get creative.
As an information technology (IT) professional, I have occasionally likened the process of developing a viable solution for an unusual computing need to the process of adventuring off on any one of those various Sierra game quests. Inevitably, there are obstacles — financial, logistical, or technological — to your goals. Sometimes you require a bit of creativity to get over those obstacles. Such is the case if you want to run an application developed with Microsoft’s .NET Framework, such as the Boson Exam Environment or the Boson NetSim Network Simulator, in an environment that is not natively configured with Microsoft Windows.
From time to time, customers ask our support personnel whether Boson Software can provide a Mac OS X version of either the Boson Exam Environment or the Boson NetSim Network Simulator. The short answer, as of this writing, is that we are not currently working on a native Mac OS X version of these Boson products. However, there are a number of other methods that users can try in order to take advantage of Boson’s .NET Framework-based software on Mac OS X, or even on a Linux distribution. In this post, our quest will be to identify and weigh the pros and cons of the various methods for running Boson software in a non-Windows environment. Future quests in this series will focus on how to implement each of the specific solutions presented here.
But before we go all pixelated and start adventuring off to the next scene, I should put the following disclaimer out there:
Ahem. Please be aware that none of the technologies or processes you read about in this post or future posts related to this post are officially supported by Boson Software, LLC. Neither Boson nor this author will be liable if your box starts smoking, spews bits in your face, or engages in other delinquent behavior as a result of your voluntary implementation of or variation from the steps in this post or future posts related to this post. Hardware and software configurations vary. What works on one installation might not work exactly the same way (or at all) on another. Some of the techniques you will encounter on this quest require moderate familiarity with clean operating system (OS) installation processes, boot loaders, and software configuration. They might also require a hefty amount of both time and patience. As a result of all of the above iffiness, you’ll pretty much be on your own if you attempt any of these techniques and hose your system, or have problems obtaining a completed, working installation of either the Boson Exam Environment or Boson NetSim Network Simulator.
Your best bet for successfully using Boson’s .NET Framework-based software (and for obtaining assistance from our friendly support staff) is always going to be installing said software in a properly supported Microsoft Windows environment. The Boson Exam Environment’s minimum system requirements indicate that it is supported for Windows 7, Windows Vista, and Windows XP. The Boson NetSim Network Simulator’s minimum and recommended system requirements indicate that it is supported for Windows 8, Windows 7, Windows Vista, and Windows XP.
If you’ve reviewed all the system requirements and choose instead to go adventuring, you should at least test a demo version of the Boson product of your choice in the environment you want to use before purchasing a license for that product. That way, if your experiment fails, you won’t have plunked down your hard-earned money for a software license you can’t use.
Lecture over. Now it’s time to start exploring.
Perhaps the safest and most obvious alternative to using a physical Windows host to run Boson software is by using desktop virtualization software. Desktop virtualization is the process of installing an actual licensed copy of Microsoft Windows inside a virtual machine (VM) that runs on your Mac OS X or Linux host device. Both VMWare and Parallels offer commercial desktop virtualization solutions that enable you to run Microsoft Windows inside a VM on a Mac. VMWare Fusion, which is VMWare’s Mac OS X desktop virtualization solution, has a Windows and Linux counterpart in VMWare Workstation. VMWare additionally offers the free-for-personal-use VMWare Player, although there is no Mac OS X version of that product. A free alternative to VMWare or Parallels is Oracle’s VirtualBox, which is available for Mac OS X, Linux, and Windows.
One nicety that’s become common among virtual desktop applications is the ability to integrate virtualized environments more-or-less seamlessly with the host environment. In other words, you can choose to visually hide the virtualized OS so that the application you are running inside it appears to be running transparently against your Mac OS X or Linux desktop. This integration enables you to switch between the Windows application in the VM and the host applications without the VM’s OS getting in the way.
However, choosing the VM path does have a few drawbacks. Financial burden is one of them. The cost of the virtualization solution (if you choose one of the commercial ones) plus the cost of the Windows license and the cost of the software you want to run in the Windows VM might give you pause. As a general rule, you should always conduct a cost-benefit analysis before licensing an OS or any other software to run in a VM. In other words, weigh your needs and how the virtualized software addresses them against the cost of the licenses and installation.
Additionally, you need to ensure that your Mac OS X or Linux host has enough CPU capacity, RAM, and disk space to simultaneously support the host environment and the virtual Windows environment of your choice, along with all the applications you want to run in it. Otherwise, the performance of your host device could take a big hit. Additionally, virtualized environments can suffer some performance hit anyway because the environment is not directly communicating with the host device’s hardware the way the host OS is. Instead, the virtualized environment is communicating with the virtualization software, which is in turn communicating with the host’s OS and hardware. Therefore, be sure you compare your host device’s specifications against the requirements of a virtualized solution in order to ensure the best user experience.
If the cost or potential performance problems of a VM solution are a deterrent for you, then let’s walk Sir Graham out of that scene and into the village of Dual Boot. Everybody hit the right-arrow key.
In contrast to a VM, a dual-boot solution means that you have two OSs physically installed on your computer’s hard drive. The boot loader, which is software that is tasked with launching an OS on your device, can then enable you to choose which of the installed OSs you want to load at system startup or reboot. For example, the Windows boot loader and the Linux GNU GRand Unified Bootloader (GRUB), among others, can all be configured to prompt a user to choose an OS. It is also possible to use Apple’s Boot Camp to install a copy of Windows directly onto an Intel Mac’s hard drive. You can then press and hold the Option key at startup, which will cause the Mac to prompt you to choose which OS you want to start. That means you can boot your Mac directly into Windows instead of running Windows in a VM on top of Mac OS X.
The performance benefit of the dual-boot solution when compared to virtualization is obvious because directly booting Windows on the computer will enable the OS to have direct access to your host device’s hardware. This method might also reduce cost if a virtualization scenario would have resulted in your purchase of a desktop virtualization solution and you do not plan on buying Windows versions of commercial software that you already use on your Mac OS X partition, such as the Microsoft Office suite. Otherwise, the financial burden of using a dual-boot method could be equivalent to or greater than using a virtualization solution, depending on the software you want to use on the Windows partition.
If you don’t like the idea of dual booting or you’re afraid you might hose your boot loader, let’s again walk off the right side of this scene and see if we can find a different place to adventure. As in most of the greatest Sierra On-Line adventure games, there’s a secret or a trap door somewhere around here. We just have to find the cleverly concealed lever that opens it. Pick up that glass bottle on the table over there. What do you know? A hidden cellar door opened! What do you think is in there?
If you put the bottle and cellar hints together and said “Wine,” you probably already know where I’m going with this.
Wine, which, once upon a time, was a recursive acronym that meant Wine Is Not an Emulator, is free software. Its purpose is to translate Windows application programming interface (API) calls into calls that can be executed by a Portable Operating System Interface (POSIX)-compliant system, such as Mac OS X or Linux. In other words, by configuring Wine on your Mac OS X or Linux device, you might be able to run some of your Windows applications directly from your POSIX-compliant OS of choice without dual booting or virtualizing or even licensing a copy of Microsoft Windows. The pros of this option are obvious: you can run Windows applications without a Windows license and without virtual hardware.
As with the other solutions, there are some drawbacks. Wine can be complex to install and configure, depending on your level of experience and comfort with configuring and compiling free software and its required dependencies. Developer CodeWeavers offers a supported commercial version of Wine for both Mac OS X (CrossOver Mac) and Linux (CrossOver Linux) that is easier to install and configure than the source code version. However, neither the CodeWeavers solution nor free Wine can do everything native Windows can do in terms of running programs developed for Windows. For example, you can install the various versions of Microsoft’s .NET Framework by using Wine, but Wine does not yet fully support every aspect of that framework. That means your .NET application might function normally. Or it might function except for a few glitches or odd errors. Or it might function if you install supporting applications and libraries from a specific repository or in a specific way. Or it might not function at all.
Both WineHQ and CodeWeavers maintain databases of Windows applications that have been tested on Wine, along with information on what works and what does not work about each application. However, as of this writing, your humble co-adventurer has only experimented a tiny bit with Wine solutions and Boson software.
This looks like a great place to save our game.
And so you have completed the first task in your .NET quest: the exploration of your options for running Boson software in a non-Windows environment. Your journey from here could be either smooth or treacherous, depending on the choices you make and your skill and determination in implementing them. But you’re not going to go it alone. In fact, if you’ll wait just a few more CPU cycles for me to rest up from the trip so far, I’ll be happy to guide you more of the way in .NET Quest, Part II: The Wares of VM.