wine is not an emulator

Let’s start with the basics (then probably skip the middle ground and jump straight to the advanced stuff). Programs written for Windows or Mac OS can’t be run natively in Linux. By ‘natively’, I mean you can’t just click on a Windows application, or type its name on your terminal, and expect it to work. You’ll get an error like this:

bash: ./windowsprogram.exe: cannot execute binary file

There are a number of reasons this doesn’t work. The first and most fundamental is that Windows and Linux use different binary file formats; that is, the actual program code is structured in an entirely different way.

So why not just create a tool that can take one binary format and convert it to another? Well, to begin with, that would be pretty complicated, and probably fraught with problems; these binary formats are actually pretty complex, and include things like how to dynamically access libraries. Libraries are big chunks of code that are written separately from the program, then used by the program so that software developers don’t have to repeatedly write the same code to accomplish common tasks.

And that leads us to the real problem – Linux and Windows have fundamentally different sets of libraries available. Each OS has a large collection of system libraries that developers can use to interact with the Operating System in different ways. And there is very, very little overlap between these libraries. A prominent example of a library that exists only in Windows is Direct3D, which is used by a lot of game developers; it contains code that makes it easier to do a lot of complicated things with the graphics card, thus making it easier to make pretty, visually involved games.

So, if you want to run a Windows program in Linux, you would have to create a tool that could take a Windows program, make it “think” it is running in a Windows environment, and then take its library calls and somehow convert them into a set of library calls that Linux can understand. Direct3D calls, for instance, might be converted into equivalent OpenGL calls in Linux. This is exactly what the wine project does.

Wine has been around for a long time, and it has aged well (these are the jokes, folks). The latest wine codebase does a great job handling a ton of Windows applications, including a great many games. This article is an overview of my experience using wine to play games on Fedora.

blizzards and steam valves

My journey begins with wine-1.3.18, the version packaged with fedora 13. Wanting to play Starcraft 2, I ran the installer, which executed without a problem. The game itself also ran great, without having to make any tweaks at all to wine’s configuration. So, Starcraft 2 was an easy win. Blizzard’s games, in general, work great under wine. I’m not sure if Blizzard just avoids strange API calls, or if wine has a lot of developers interested in making certain Blizzard’s games work. Either way, this one was phenomenally easy.

The next thing I tried was Valve’s Steam client. If you’re somehow reading this from the past, or Steam no longer exists in the future (or you have recently emerged from a coma), Steam is a game distribution platform. You can buy electronic copies of games, install them in steam, and play them. Many games also support achievements and server-side syncing of your game data. This makes gaming on multiple computers really nice (as long as you’re the only one using Steam, that is). It also has community features; you can see what your friends are playing, join them in multiplayer games, etc.

So, I have quite a few games on Steam, and before I can try to run the games under wine, I have to get Steam to run. This was a little bit trickier than running Starcraft 2. First, the Steam installer is a .msi file, which requires the msiexec tool to run. Luckily, recent versions of wine come equipped with an open-source clone of the msiexec tool. So, all I had to do was:

msiexec SteamInstall.msi

Once this was done, Steam launched, but I ran into a new problem: every time I move my mouse over the Steam windows, they would flicker, making it hard to see what I was doing. This was solved by using winecfg to set the ‘Windows Version’ to Windows 7. Problem solved.

The next problem I encountered with Steam was that, when I drag a Steam window, it continues to move around after I release the mouse button, as if I’m still holding it. I have to click on another Steam window to make it stop. This problem remains unsolved in the latest version of wine (1.3.21 as of this writing).

Having Steam running, though, I was able to try a few games. The first thing I discovered was that every game I tried had major problems until I unchecked ‘Enable Steam community in-game’. Once I had done this, Plants vs Zombies and Darkstar One both worked great ‘out of the box’, with no tweaking required.

Portal, on the other hand, was not as great. Every few seconds of game play (not exactly precise, and it happens more when portals are open) the game will stutter for a moment. I spent a lot of time tweaking wine to try to fix this, but the problem remains in the latest version of wine. In addition, in wine 1.3.20, an even worse problem appeared – instead of stuttering, the game would act as if the mouse had been moved a random distance in a random direction periodically.

The last game I tried out was Team Fortress 2. It refused to start until I added an override for hl2.exe (in winecfg) disabling gameoverlayrenderer.dll and changing the Windows version to NT 4.0 (who knew Windows NT was a good gaming platform?). After this, the game worked with a stuttering problem similar to Portal’s, but more dependent on how much action was happening on screen. This was probably my most disappointing experience with wine, and 1 problematic game out of 5 isn’t bad.

So far, I have a (let’s say) 80% success rate with running Windows games under Linux using wine, with comparatively little effort required on my part. This is a fantastic result compared to even 2 years ago, and I look forward to watching the wine project enable ever more games under Linux.

tips, tricks, caveats

If you’re using Fedora, you may run into problems with pulseaudio. I recommend disabling it completely, via the following:

yum remove alsa-plugins-pulseaudio
echo > ~/.pulse/client.conf << EOF
autospawn = no
daemon-binary = /bin/true
EOF

Then, reboot your machine (or make sure you kill all running pulseaudio processes). Wine works a lot better this way. You’ll probably also want to run:

setsebool wine_mmap_zero_ignore 1

To make SELinux play well with games in wine.

Something I wanted to do but was unable to achieve was run native Linux games directly from Steam, and have Steam keep track of them. After asking on the wine-users mailing list, I learned that the way wine emulates Windows process handling makes this impossible. So, instead, I created steamstub, a Windows program written specifically for Steam under wine. To use it, add it as a non-steam game to Steam, then edit the game’s properties and change the name to a native Linux game of your choice. Now, before you go play your Linux game, click ‘Play’ on this game in Steam. Steamstub will deliver a small popup, and to your Steam friends, it will look like you are playing a non-steam game until you click ‘OK’. This lets you advertise what game you are playing, even when Steam can’t launch it.

One more thing you may find interesting is a tool I developed called wino. It lets you keep track of multiple wine prefixes (virtual Windows environments), so you can keep your programs separated. This makes it easier to recover if something in your drive_c directory gets broken; you only have to worry about reinstalling at most one program. If you make heavy use of steam’s ‘non-Steam game’ functionality, like I do, then this is not as useful for you. However, wino also does a lot of other useful things, like allow you to have a default command assigned to a wineprefix (so you could just run ‘wino steam’ to launch Steam.exe). It can also run winecfg (and a lot of other tools) on a prefix via ‘wino prefixname –config’.

Anyway, there are people in Second Life that I like being able to communicate with. However, when I’m at work, it’s a lot of trouble to create an SSH tunnel home, then forward a text-only client like ommviewer-light just so I can log in and see who is online.

So, as I always do, I went way overboard and created a system that can relay chat between an IRC channel (or channels) and any location (or locations) inside Second Life (or any other grid that supports LSL). It can also check the online status of users and send them one-way IMs. I call the entire system slrelay, and you can get it here.

It requires a few things to work: a running webserver is absolutely necessary. If you want the IRC features, then you also need an IRC network of your choice and a machine that can execute perl scripts. I have my IRC bot connected to irc.slashnet.org.

slrelay has a number of possible uses. You could use it to relay chat between key locations on a large landmass (say, an area that spans 3 or 4 sims). It could relay chat between Second Life and another metaverse grid like OSGrid. It can be used as a simple IRC tool to check who is online very quickly. Or it can do all of these things at once.

(require 'dbus)
(defun send-desktop-notification (summary body timeout)
  "call notification-daemon method METHOD with ARGS over dbus"
  (dbus-call-method
    :session                        ; use the session (not system) bus
    "org.freedesktop.Notifications" ; service name
    "/org/freedesktop/Notifications"   ; path name
    "org.freedesktop.Notifications" "Notify" ; Method
    "emacs"
    0
    ""
    summary
    body
    '(:array)
    '(:array :signature "{sv}")
    ':int32 timeout))

(defun pw/compile-notify (buffer message)
  (send-desktop-notification "emacs compile" message 0))

(setq compilation-finish-function 'pw/compile-notify)

Add this to your .emacs file and you will receive a libnotify popup when M-x compile completes. It will even give you the exit message, so you know whether the compile was successful.

So now you can let that long compile run, and work on something else. emacs will let you know when the compile finishes.

As written above, the notifications will stay on your screen until you dismiss them (by clicking on them). If you would like them to vanish after a preset time limit, change the 0 in the call to send-desktop-notification. Set it to the number of milliseconds the popup should remain on the screen.

Screenshot of libnotify popup showing a compiler error

This is just the tip of the iceberg, of course. Any application that presents a dbus interface can be interacted with from emacs, which means that emacs can also integrate itself with the Linux desktop in other interesting ways.

Get it here.

I’m lifting my moratorium on D&D 4e, as well. This means that d20tools will eventually support 4e creatures. However, this is a huge undertaking, and I have to decide how best to handle it. I’m leaning towards a system that will allow anyone to write system templates; then, any gaming system could be plugged in, theoretically. In practice, this is a lot of work for a single developer, so I wouldn’t anticipate this happening any time soon.

Here is the result:

#!/bin/sh
echo -n "twitter> "
read text

while [ ${#text} -gt 140 ]; do

echo
echo "Message too long; used ${#text}/140 characters."
echo
echo -n "twitter> "
read text

done

echo
echo "Message is ${#text}/140 characters.  Press enter to post, or Ctrl+C to cancel."
read

curl --basic --user "username:password" --data-ascii "status=`echo $text|tr ' ' '+'`" "http://twitter.com/statuses/update.json" &> /dev/null


To use the script, copy all of that into a file somewhere in your path, then make the file executable (e.g., chmod 755 /usr/local/bin/twitter).  Now you can type ‘twitter’, type in your tweet, and you’re done!

I even set up fluxbox so that mod4+t launches a terminal with the script running.  To do that, I added this to ~/.fluxbox/keys:


Mod4 t :Exec xterm -e "twitter"


If you’re not familiar with ‘mod4′, it is the Windows key on most PC keyboards.

I’ll eventually get around to writing a slightly more full-featured twitter updater in c or c++.  Until then, enjoy this script!

The netjatafl server (taflserv) operates on a simple, completely open protocol; it will eventually support authenticated logins and statistics tracking. Anyone could write a netjatafl client for any platform, if they wished. My clients will all be in C++, because this let’s me reuse the ‘libboardgame’ library, which contains the game logic used by the server. I will also build in a “capabilities” system at some point, so the client and server can both advertise which games they support.

The whole thing is theoretically usable in its current state; the client is an ncurses-based text UI that is pretty cumbersome, but can be used. As far as I know, it only works in Linux. Anyone who wants to cross-compile it for Windows and send me a patch with everything you had to add, feel free! I will eventually add a proper GUI, probably gtk+-based.

Like the sound of this project? Feel free to check out the code, compile it, and let me know what you think!

Etymology notes: netjatafl is Old Norse for “net-table”; i.e. a networked table you can gather around to play games. ‘taflbordh’ is ON for ‘tafl board’ (tafl can also refer to tafl games in general), which sounds a little redundant, but it made a nice name for a client. And ‘taflserv’ is just ‘tafl server’… ‘serv’ was meant to be short for ‘server’, but I later noticed that it’s also a French word meaning ‘it serves”. I find this somewhat appropriate.

A programming language is a tool. A skilled craftsman isn’t good at her trade because she knows how to use a given set of tools; anyone can learn that. Rather, true skill comes from knowing how to *apply* the tools. The fundamental concepts behind programming are the skills on which we should be focusing.

This applies to academia as well. The language you use to teach students, especially the first language they encounter, *is* important. I’m not about to advocate “teaching languages” like Pascal, though. I think it’s important to choose a real-world language, with all the pitfalls and caveats of a real-world language, as a student’s first language. At the same time, it should be a language with the features available to demonstrate all the fundamental concepts in programming. A language that doesn’t support recursion would be a Bad Choice, for example.

So, when someone (a peer or a hopeful programmer-to-be) asks me “what languages do you know?”, I won’t respond “Well, I know C, C++, Java, perl, php, xhtml/xml/css (if you count those), lisp, prolog, LotusScript, Javascript, LSL…” etc. Instead, I’ll say “I’ve used a number of languages, but the key thing is that I know how to learn any language.” When an employer asks, I suppose I’ll have to say “Well, I know @languages…”. Then, though, I might add “…but I consider the fundamental concepts behind programming languages to be more important, because mastering those means I can learn to get around in any language given a week or two of study.”

In summary: Learning a programming language is trivial, once you know the fundamental concepts of programming.