Interesting Insights Into Wine's Development

[dacha]

Wine usually has been working quit nice for many years, and for many things.

However, what really bugs me is when in order to get your fav game working you need that one-liner fix (literally!), and for that you need to recompile the whole shebang. In a 32bit chroot. With hundreds of -dev packages. And nightmares.
And when there's a new version, the patch isn't intergrated, but just needs to be applied to a different line number. And you have to do it all again. sigh

Actually you can blame Debian and Ubuntu for that particular pearl. Red Hat's distros have always used /lib and /lib64, Debian instead used "biarch" (/lib32 and /lib) for a while, then decided that wasn't good enough, and went for "multiarch", ie. /usr/lib/i386-linux-gnu and co. Of course than only solved the problem for *lib*, not for *include*, meaning you can't parallel-install development packages for 32 and 64 bit, and you need an independent chroot.

Oh and with per-application patching, Windows itself is not very different - it has a bunch of checks for which application is running and alters how things work, so it remains compatible with older apps...

[boltronics]

I run a ton of stuff (mostly games) under Debian Wheezy GNU/Linux using Wine. I run a chroot (managed nicely via schroot), and individual wineprefixes for the majority of my apps so it's easy to make any app-specific tweaks if necessary. More often than not, games just work using standard WINE with no patches, DLL overrides or tweaks. It's really impressive - it's came a long way in the last year or so. It's very rare that I hit regressions that are not easily worked around, and Wine's appdb (http://appdb.winehq.org) usually tells you what you need to know when things don't work quite right.

The list of games that I have finished via WINE can be seen here: https://systemsaviour.com/finished-games/#GNU"

[Thaodan]

PlayOnLinux is more like CrossOver in that it can set up specific wine directories per application with app-specific overrides. So if wine 1.5.22 breaks MS Office 2010, PlayOnLinux can set it up to that MS Office 2010, and only MS Office 2010, has a wine setup that is actually 1.5.21.

Its more than just "a frontend."

To manage prefixes you can use $WINEPREFIX, if you write some scripts you get it too*.
The part of manage wine versions is just not a part of wine's job.

*I wrote some stuff for it and wrote a CLI prefix manager that, makes working with prefixes and different wine versions easyer:
http://code.google.com/p/usenew/sour...c/usenew.sh.in. Debian package is on my project site too.

[GreatEmerald]

The list of games that I have finished via WINE can be seen here: https://systemsaviour.com/finished-games/#GNU"

You should probably replay Unreal, now that it has a native port and all

[V!NCENT]

Wine never works out of the box with most things, but neither does Windows. In fact; allmost all classic games need patches/cracks to work on anything that's older than Vista. There's a reason Windows software employs DLL versioning, and almost any Windows app ships with the DLL versions that they were developped against.

Ofcource, if you keep buying/installing anything that requires the latest Windows release, Wine will keep being behind on support, for obvious reasons. That is where virtual machines are for.

But for me, Wine is like Dosbox; it keeps legacy stuff running, and Windows simply doesn't.

[fuzz]

Wine usually has been working quit nice for many years, and for many things.

However, what really bugs me is when in order to get your fav game working you need that one-liner fix (literally!), and for that you need to recompile the whole shebang. In a 32bit chroot. With hundreds of -dev packages. And nightmares.
And when there's a new version, the patch isn't intergrated, but just needs to be applied to a different line number. And you have to do it all again. sigh

My Gentoo install makes compiling and installing so easy .

[Hamish Wilson]

But for me, Wine is like Dosbox; it keeps legacy stuff running, and Windows simply doesn't.

Definitely agree. Modern stuff should be done right (and by right I mean native) but for legacy purposes emulators and compatibility layers definitely do show their value.