If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Interesting Insights Into Wine's Development

01-21-2013, 04:00 PM

Phoronix: Interesting Insights Into Wine's Development

Wine, the widely-known open-source software for running Microsoft Windows programs on Linux and other Unix-like operating systems, now weighs in at more than three million lines of code. In this article is some insight into its pace of development, how the CodeWeavers company dominates Wine's development, and other intriguing statistics about this project that's been around for two decades...

Julian probably has the most knowledge about the most used operating system on the planet. (on consumer PCs) He then also managed to link all that to Linux and MacOS X, so he needs to have deep knowledge about Linux and MacOS X as well.

Comment

For me Wine works only for simple windows applications. Anything more and it gives weird errors or doesn't even load. So no. He would have been an uber geek if it worked.

To be fair just being to launch anything is a pretty impressive accomplishment. I have also had a lot of trouble with WINE, but I am not necessarily going to hold it against Julian. My main complaint with WINE though is the amount of breakages it has - the current version I am using the sound does not work and winecfg has severe GUI redraw problems.

Comment

Isn't it just a frontend for wine? I mean if it doesn't work with wine why should I expect it to work with PlayOnLinux?

It finds a Wine version known to be compatible(but you can easily change it afterward to experiment if you want) and makes all the tweaks for you.
I got MS Office to work perfectly with this, while I couldn't with plain Wine(but I changed to more recent Wine version to get rid of a bug in PowerPoint). And even a couple games I tried.
You might have more trouble getting a video to play the way you want through the command line with let's say MPlayer than you would with a fronte-end presenting the option you have in an easily accessible way. Here it's even worse ..
Wine doesn't exactly work out of the box(although it pretty much did with, let's say, Skyrim, but low performance, at least on AMD, still), but it usually does work.

Comment

Isn't it just a frontend for wine? I mean if it doesn't work with wine why should I expect it to work with PlayOnLinux?

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."

Comment

I think it would be more appropriate to say that Codeweaves "funds" moreso than "dominates". For this reason I get Crossover as well instead of Wine (plus their customer support is great, no more hunting around forums trying various hacks).

Comment

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

Comment

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...

Comment

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.