…it’s actually pretty easy: All you have to to is write an open-source emulator (OK, fine, “API Compatibility Layer”) for the worst piece of software in the history of mankind.

In case it’s not completely obvious at this point, I’m talking about WINE.

Wine is a piece of shit. The only reason I don’t rate it as “worse than windows” is that the wine devs don’t expect you to pay for their garbage, whereas Microsoft does.

No, wait, I don’t want you to misunderstand me, so I’ll clarify my statement: wine is a godawful piece of shit.

Legions of freetards will quickly jump to defend wine: They’ll tell me how I have no right to criticise the hard work of all these people who are giving me something for nothing, and they’ll talk about how well the wine team keep abreast of the latest developments and how they’re in an impossible situation because they’re aiming at a moving target and how Microsoft’s documentation leaves alot to be desired in terms of reimplementing the entire Win32 API.

And they do have a point – the wine devs are not trying to do something trivial.

But that doesn’t change the fact that wine is a piece of shit.

I won’t dispute that there are some talented people working on the wine project – I don’t even want to think about how complex such an undertaking is, but if you can’t even make things work consistently when somebody upgrades to a new version of your product, it’s a shit product, and you’re useless, not doing enough testing, and not managing your project properly. Keeping existing features working is more important than adding new features.

Keeping existing features working is more important than adding new features!

KEEPING EXISTING FEATURES WORKING IS MORE IMPORTANT THAN ADDING NEW FEATURES!

Wine suffers from a completely retarded number of regression bugs: something which works just wine in version X of wine may or may not work in version X+1. This is an absolutely ridiculous situation.

Apparently “STABLE” doesn’t mean what I thought it meant: I thought it meant “Working, Usable, and tends to not crash horribly in normal use”. But the wine team seems to think that “STABLE” means “This alpha feature is almost feature-complete and almost works. Mostly. Except when it doesn’t”. I can’t fathom the decision to mark Wine 1.4 as “Stable” with its redesigned audio subsystem which lacks a fucking pulseaudio driver! And the attitude they take is “pulse has ALSA emulation, so we don’t really need to support pulse” – a weak cop-out at best. I mean, it’s not like the majority of distros these days default to using pulse… Oh, wait…

Application-specific tweaking. Oh, the essay I could write on the bullshit required to make any particular application work. Here’s the usual procedure:

1. Go to appdb.winehq.org, see that it’s rated as “garbage”
2. Note that the ‘Garbage’ Rating was with the current version of wine, and that there’s a “Gold” rating for the previous version of wine. Click on the gold rating to see that review
3. Scroll down through the review to see if there are any helpful tips as to wierd and wonderful esoteric settings you should change to make your app work
4. Try all the tips and manipulating all the settings in the previous point, to no avail
5. Revert wine to the earliest version available in your distro’s repos. It’s important to note here that you probably just broke every other wine app you have installed
6. When this doesn’t work, download and attempt to compile the version which got the gold rating. If you manage to get it to compile and install correctly (it probably won’t – it’ll depend on an older version of at least one library, which will lead you straight into dependency hell), go back to fiddling with esoteric settings for a few days
7. When you’re sure you’ve replicated all the tweaks, DLL overrides. and settings for your app as per the gold rating on the appdb and it STILL doesn’t work, scream loudly
8. Install virtualbox and waste many resources just so that you can run your app
9. Hope that you used checkinstall when you compiled the old version of wine, so that it’s possible to remove it without wanting to commit ritual suicide
10. Install the version of wine you had installed from the repos. Hope that the other apps you spent days configuring and actually managed to get working still work.
11. Hope that the few apps you actually got working don’t break horribly next time you do an apt-get upgrade

I can’t be fucked with any of this anymore, so here’s the process I use:

1. Create a new wineprefix: ‘env WINEPREFIX=~/wineprefix_for_this_particular_app winecfg’. It’s important to create an entirely new wineprefix for each app, because that way it’s slightly less trivially easy to break all your other apps just by changing one setting.
2. Run the installer with something like ‘env WINEPREFIX=~/wineprefix_for_this_particular_app wine some_installer.exe’
3. When things fail horribly (and they will for about 99.999% of apps in my experience), type ‘rm -Rv ~/wineprefix_for_this_particular_app’ and install it in your VM.

The most hilarious and entertaining part about all of this is the way that even after all my experiences which indicate the contrary, sometimes I still tend to assume that things will work under wine – after all, the wine mantra is “if it’s old, it’s more likely to work”. Here are some examples:

• “The old PC version of ‘Road Rash’ – the one with soundgarden in the soundtrack – it’s more than 10 years old! It’ll be using DirectX 3 API calls if it’s lucky! SURELY it will ‘Just Work’ in wine, right?”
• “Oh, I know – I’ll Install Dungeon Keeper – it’s old – it should Just Work, right?”
• “AHA! Deus Ex has a ‘Gold’ rating with THE CURRENT WINE VERSION! Surely that means it will Just Work?”
• “Aah, JASC Animation Shop. Such a great little app. I used to use it all the time back in 1997. Is should Just Work, right?”

And now, some questions for the wine developers:

1. Why is it that Fl Studio uses about 3 times as much processor time in the current version than it did in the previous version? For some of my tracks, FL Studio sits at 90% CPU Utilization when it’s NOT EVEN PLAYING. Trying to play will give you a horrible mess of stuttering as the CPU valiantly attempts to keep up with wine’s bullshit demands. With the previous version of wine and the exact same track on the exact same install of FL Studio with the exact same settings, this track played just fine. I have been tweaking for about 4 days now and have achieved ABSOLUTELY NOTHING in terms of improving this situation.
2. Why has wine not absorbed PlayOnLinux (another awful piece of code – random hangs FTW!)? This functionality should be included in wine (i.e: a central, per-application/wine version ‘tweaks’ database. You have a nice interface for installing apps. You choose the app from a list, and wine downloads the tweaks appropriate for that app and applies them automatically. This would not be hard to implement, and would solve a HUGE number of issues for a huge number of users.
3. What genius decided that a version with a broken pulseaudio driver should be marked as “Stable”?
4. Speaking of re-engineering your audio stack, can you please explain how this new, non-functional audio subsystem is superior to the working one which it replaced?
5. Do you anticipate that one day wine will actually be able to do what it says on the tin? Or should I just give up on the whole concept? I feel like I am the butt of some huge, multi-year practical joke.

Now, to be fair, this is not all the fault of the wine devs – it’s also the fault of the people who manage repos for the various distros out there: these people should learn, and simply not upgrade the wine version in our repos until they’ve checked whether the fucking thing works or not – it’s a wierd kind of synchronicity that choosing a wine version is kind of like using Microsoft products: You never, ever, ever install the initial release, you wait for R2, when it might actually stand a chance of being something other than utter shit.

Wine sucks. It’s the worst piece of open-source code in the history of mankind. There are two factors why:

1. Because they’re emulating the worst piece of code in the history of mankind.
2. Because they’re amateur idiots who suck and can’t manage a project properly and don’t do enough testing. This is evident in that they regularly break backwards compatibility.

There is never a reason or excuse for breaking backwards compatibility other than laziness, and it’s therefore never acceptable to break backwards compatibility.

Wine is a piece of shit.

[EDIT: wine 1.5 is better than 1.4, but still not up to par with 1.2]
[EDIT 2: I'd really really love to hear an explanation of why opening a common dialog crashes metacity]