Crossing Over: Wineskin Review & Discussion August 13, 2013 | Justin Ancheta

Pages: 1 2 3 4 Gallery

Click to enlarge Wineskin Winery: This is the default Wineskin Winery window.

Imagine if you had a magical app on your Android or iOS device that allowed you to speak, and understand a foreign language, in real time, with next-to-no training necessary. Imagine if it was so good, and so seamless that you could do incredibly complex tasks – like paint elaborate, gorgeous pictures, or construct large scale 3D models mathematically, or choreograph complex action sequences with hundreds of actors – all in real-time, all using instructions in that foreign language. Now imagine that it was completely invisible and almost unobtrustive to you, the user. It sounds like science-fiction, the stuff of Kurzweilian-visions of cybernetic transhumanism, or Adamsian pragmatism. Yet, what if I were to tell you that such a device exists? If you bought a Mac port of a AAA Windows game six years or so ago, or if you've bought a Mac port of an indie game from the Humble Indie Bundle, it may already be lurking in your Applications folder.

While the above analogy may not have been the best for this situation, it's the most direct one I can think of to describe WINE, the incredible open-source effort to bring Windows compatibility to Linux systems...without Windows. The WINE project sought to do no less than perform a complete, legal clean-room reverse engineering effort on the Windows APIs, and use that to provide a seamless translation layer that could turn a piece of software's calls to Windows APIs, into calls to Linux APIs. In short, it would allow you to run a Windows application, on your Linux (and later Mac OS X) computer. This would be achieved with no Windows installation, no Virtualization, and no Emulation required (Hence WINE's actual meaning: "Wine Is Not an Emulator"). Meanwhile the Windows app would be none the wiser.

Such a project would seem almost impossible to a casual end-user with an understanding of the vast differences between Windows and Linux (and Mac OS X). Yet, WINE has been stable and reliable enough that some commercial ports of AAA titles and indie games have relied upon WINE to power them (albeit, with some early mixed results). Over the course of my Crossing Over articles, I've focused on the most visible and best supported means of using WINE to run Windows games – specifically, the awesome catalog of GOG's games – running on Mac OS X: CodeWeavers' CrossOver, a dependable and reliable product with deep ties to the WINE developer community. But it wouldn't be fair to ignore another famed alternative, one that's been the product of the tireless efforts of what is practically a one-person operation. Like CrossOver, it allows users to tap into the power and promise of WINE to bring Windows games to Mac OS X. Unlike CrossOver however, it doesn't hide all of the fancy and bafflingly complex machinery underpinning its operation under an easy-to-approach GUI. Additionally, it's completely free. Welcome to Wineskin.

I originally was going to write a comprehensive breakdown of Wineskin's operations and how you go about using it, but that's best left to the well-written
documentation surrounding Wineskin, that nicely describes the process of how to utilize it to install and use Windows software. Instead I've opted to write a brief, general overview of how Wineskin works, and will follow that up with some of the issues in using Wineskin for Windows game compatibility vs. CrossOver. This is assuming you've already downloaded and installed the Wineskin Winery app; before you begin, make sure that Wineskin Winery (the latest version as of this writing being 1.5.8) is installed in /Applications.

1. Run Wineskin Winery - Think of the Winery as a spawning point where you create the Wineskin wrappers for your apps. With the Winery, you are in essence creating an application "wrapper" that surrounds your Windows game and allows it to talk to the Mac system software as a whole. Under "Installed Engines" the list will be blank, so click the "+" button.

2. Install a Wineskin Engine - Here you get to choose which version of WINE you will use for your wrapper, for your game. WINE engines are the heart of the compatibility wrapper you'll be making, and they range from some of the earliest 1.x releases of WINE all the way up to the latest development branches of WINE. You'll also see engines with a "CX" designation; these are WINE engines that are built from the WINE code contributed by Codeweavers, from their development of CrossOver. The "AMDSpeedHack" engines come with special custom adjustments to get around a bug leading to performance problems with AMD/ATi graphics cards in the 1.5.x series, and the "NoXinput2" engines come with special adjustments dealing with WINE's implementation of one of the later Windows input APIs in the earlier versions of 1.5.x series. The 1.6.x releases and the later 1.5.3x and 1.5.2x may come with an “X” designation; these have the native
Mac driver disabled by default to make Wineskin wrapper creation easier with the newer versions of WINE.

So which one should you choose? In my experience, that question is best answered through trial-and-error, with a healthy amount of research on Google. This is where the things get difficult. The Porting Team forums, the CrossOver forums, and the community surrounding the WINEhq are all good places to look for information on optimal versions of WINE engines to use; usually WINE AppDB listings are a general place to begin as they should give some idea as to what base versions of WINE work best with any given game. As a general rule, I've tended to start with the most recent version of WINE and work my way down, thus ensuring that the game works with the most recent WINE release possible. For the majority of the classic games I've installed and played, I've seemed to have the most personal success with 1.5.3-1.5.9, and 1.5.3x for WINE; with the "NoXinput2" versions used if I've had problems with joystick and mouselook controls.

3. Create a New Blank Wrapper - this button will take you into and through the wrapper creation process. To save on drive space, it's a good idea to avoid installing Mono or Gecko, unless you intend on installing an MMO or a newer AAA/indie release using .NET in your wrapper. Mono/.NET may be required for the installation of mods, however; the Circle of Eight mod package for The Temple of Elemental Evil comes to mind, here.

Pages:

1

2

3

4

Gallery