Ubuntu Wiki

Open Week -- Wine Q&A -- Scott Richie -- Tue, May 4

EDT -5

(11:01:51 AM) YokoZar: Good morning everybody, it's time to start the second day of Ubuntu Open Week
(11:02:42 AM) YokoZar: (08:02:41 AM) sebsebseb: YokoZar: afternoon here, plus in UTC, which is the time zone Open Week is going by :D
(11:02:59 AM) YokoZar: As sebsebseb has pointed out, there are in fact other time zones than mine.
(11:03:17 AM) YokoZar: I promise to use this information for good rather than evil
(11:04:25 AM) YokoZar: Now, this is meant to be mostly a Q+A session, as in the past I have received more than enough questions to cover an entire hour.  Today's topic is Wine, and I've been Ubuntu's "Wine guy" from pretty much the start.
(11:05:16 AM) YokoZar: Wine, to give a brief summary, is the program that lets you run Windows applications on Ubuntu.  Or, the way I like to think of it, once a program works in Wine it's no longer a Windows application, but rather just a plain old application that works in Ubuntu as well :)
(11:07:12 AM) YokoZar: (08:06:49 AM) johnsgruber: QUESTION: Is it possible, and safe to run something like quicken or Itunes under wine. Those are the two reasons I have to boot windows
(11:08:25 AM) YokoZar: There are two questions here, but they go together.  As a general rule, the worst thing Wine can do when it attempts to run an App is not work.  So if you want to know if you can run a program, it doesn't hurt anything other than your time to try it out
(11:09:10 AM) YokoZar: But there are likely many others who have tested the app before.  If one of them is really nice, they'll have made a recent test entry in Wine's application database (http://appdb.winehq.org/) that you can read.
(11:10:14 AM) YokoZar: The Wine project is always looking for people who can provide more recent test results.  We're also very keen on knowing if an application stops working as well as it did in the past (a "regression"), as it's much easier to fix them when they're caught quickly
(11:11:19 AM) YokoZar: As far as how well iTunes and Quicken work, I would suggest checking the AppDB as it depends on which version of Quicken and/or iTunes.  Both applications are major targets of Wine developers and get worked on a lot, however iTunes in particular uses a lot of "weird" parts of the Windows API and has been a huge effort to get working.
(11:11:50 AM) YokoZar: (08:07:12 AM) sirmacik: QUESTION: Are You adding many changes/patches to the wine package on ubuntu? What they are changing in it?
(11:13:27 AM) YokoZar: I like to keep the Wine package as close to upstream as possible, however there will be a growing difference in later releases.  The reason is that Wine's upstream consists of the "pure" Wine with hardly any interface - the Applications->Browse C: Drive link you see in the package, for instance, originates in Ubuntu
(11:14:56 AM) YokoZar: I will also be merging in (and providing my own code for) another upstream project called Vineyard, which I roughly designed a couple years back and was ultimately coded by Christian Dannie Stroggard.  Hopefully I'll have a demo of this ready by the Ubuntu Developer Summit.  I was originally planning to include it with Wine1.2, however that was not released in time for Lucid
(11:15:43 AM) YokoZar: Consequently, Lucid Wine looks very similar to Karmic Wine, except it's a newer Wine release and refuses to run executables that don't have the execute bit set (more on this later)
(11:16:07 AM) YokoZar: (08:07:45 AM) Nagz: QUESTION: Will the newly working iPhone/iPod access work with iTunes/wine ?
(11:17:02 AM) YokoZar: By this I assume you're talking about the ability to access iPods and iPhones in programs like rhythmbox for music.  This does not affect Wine, as Wine can't use that interface to talk to the iPhones because the programs it runs that do it (namely iTunes) use a different method
(11:17:41 AM) YokoZar: What Wine needs to do that is code for a USB driver - then any arbitrary USB device that a Windows app needed to talk to would work (like iTunes)
(11:18:00 AM) YokoZar: This is different from certain standard USB devices like keyboards and USB sticks, which already work in Wine
(11:18:43 AM) YokoZar: It's a good example of two seemingly unrelated things (like, say, iTunes+iPods and a program that uses a USB license-key dongle) both needing the same underlying Wine component to work.
(11:19:39 AM) YokoZar: There used to be a bit of a joke race between Wine and Songbird about who could access iPods first, but they've both lost ;)
(11:19:58 AM) YokoZar: (08:08:35 AM) gquigs: QUESTION: I want to package some applications (https://bugs.launchpad.net/ubuntu/+bug/387753) that use wine, is their a guide to help me do it?
(11:20:42 AM) YokoZar: No not yet, however you can ask me personally and we'll work on this together.  I've done it before as a prototype, and there are several ways to do it.  I'm quite keen to have more Wine-powered applications in the repository.
(11:22:33 AM) YokoZar: If it's a free software application then we can also attempt to get it building under winelib, which would make things much easier in the future.  Compiling from source is always nice anyway, however there is also work on porting Wine to ARM, and any winelib-based port would be able to start working on ARM without much additional effort -- even though Windows doesn't run on ARM at all!
(11:22:57 AM) YokoZar: *not technically true, since Windows Mobile has an ARM version and the Windows Mobile API is very similar to Win32
(11:23:17 AM) YokoZar: (08:08:37 AM) freckle: QUESTION: is there plans to make buisness apps like Sage Line 500 run well under wine. Currently there are issues with paging screens.
(11:24:42 AM) YokoZar: So it's a little vague if I say that "all apps are supposed to work in Wine", but in a way it's accurate.  Wine is developed with the principle of doing the "right" thing, ie exactly what Windows does.  If a program isn't working it's because Wine developers have either not implemented a Windows function it's using or they've done it incorrectly.
(11:25:17 AM) YokoZar: The former is usually a FIXME: warning if you run Wine in the terminal, and the latter is either an ERR: message or just weird behavior
(11:26:07 AM) YokoZar: Regardless, any program not doing what it's supposed to be doing is a legitimate bug report to file at winehq.org, and if the fix is easy enough to do it can happen very quickly
(11:26:28 AM) YokoZar: That said, Wine developers do target specific apps to try and get working first.
(11:27:11 AM) YokoZar: Generally these applications are Codeweavers' supported applications (~80% of Wine development is paid Codeweavers staff), however there's also a lot of community patches, especially for popular programs.
(11:27:34 AM) YokoZar: (08:10:27 AM) sebsebseb: YokoZar: Do you think it is ok for Windows programs developer to opt out of making native Linux apps, if their app will work properly in Wine, without a user first having to mess around with wineconfig which tends to not be much fun, if fun at all.  Plus most users don't really know how to use wineconfig properly.
(11:27:54 AM) YokoZar: I agree, I hate winecfg
(11:28:33 AM) YokoZar: Part of the work in the Vineyard project is to replace winecfg with something much nicer that asks only the essential questions
(11:28:53 AM) YokoZar: In an integrated desktop app.  Think System->Preferences->Windows Applications
(11:29:37 AM) YokoZar: Any configuration that a user currently has to do in the registry or by mucking about with Wine should be handled automatically by Wine.
(11:30:33 AM) YokoZar: There's been some effort at making this a reality upstream.  However there are a couple questions that we will always have to make configurable (such as which Windows version to emulate), and that's the kind of question that will live in the new configuration dialog.
(11:31:50 AM) YokoZar: As for whether it's ok for a developer to not make a "native" app, I think it's important to consider what the user experience is like.  If the app doesn't work very well in Wine, then a native app would naturally have many advantages.  However if the app works perfectly in Wine and requires no configuration, then it's a different matter
(11:33:09 AM) YokoZar: In principle a user doesn't even have to know that an app is using Wine internally, much like how Mac gamers don't know when programs are ported using Cider.  This is all a question of packaging - in principle any Windows program could be turned into a proper Ubuntu package (depending on Wine internally), given .desktop entries so it runs from Applications->Games rather than Applications->Wine, given sane default settings, and
(11:33:35 AM) YokoZar: If you do all those things in a program that works perfectly in Wine there wouldn't be any real user experience difference between that and a Native port.
(11:34:29 AM) YokoZar: Porting with Wine rather than a "proper native" port also has advantages to the developer of letting them unify their code bases.  Google's Picassa is ported with Wine in this way, for instance, and they use literally the same binary between Windows and Linux.
(11:35:30 AM) YokoZar: If I had more time I would like to help make this process easier for Windows developers to get their applications ported in a nice, usable way for Ubuntu.  In principle we could even have a "make Ubuntu package based on Wine" plugin for Visual Studio ;)
(11:35:53 AM) YokoZar: (08:13:44 AM) mhall119|lernid: QUESTION: What is the current API version targeted by Wine?
(11:35:59 AM) YokoZar: All of them ;)
(11:36:51 AM) YokoZar: Seriously though, Windows technically has a different version of the API for each Windows version, but Microsoft tries to keep it as similar as possible.  This is why programs written for 3.1 will still work in Windows 7 to a large extent
(11:37:22 AM) YokoZar: Microsoft does add new bits to the API of course (and thus new FIXMEs for Wine)
(11:37:46 AM) YokoZar: So Wine has some code in it that's "do this in Vista-mode, do this in XP mode", but most of Wine is just "do this", much like Windows is
(11:38:27 AM) YokoZar: Really, there's not much difference between switching Wine from Vista to XP mode and setting a Windows application to use "Compatibility mode" in Windows
(11:39:27 AM) YokoZar: Regardless, Wine developers target applications rather than a particular API version, as applications are what people care about.  This is different from the approach of the Mono project, who do target versions of the .net API, but things are much cleaner with .net compared to Win32
(11:39:45 AM) YokoZar: (08:14:45 AM) virtuald: QUESTION: Spotify recently added support to play mp3 files with windows codecs, but when it finds the string WINE-MP3 somewhere it fails, because it didn't work in their limited testing. What can be done about this?
(11:40:32 AM) YokoZar: Spotify can be harassed into working with Wine.  I've actually tried to contact Spotify myself and talk with them personally, because I know they're keen to have better Wine support.  They're actually really nice that way.
(11:41:04 AM) YokoZar: Regardless, it's more or less just another Wine bug, and there are quite a few open Spotify bug reports (in both Launchpad and winehq)
(11:41:34 AM) YokoZar: (08:26:56 AM) sirmacik: QUESTION: Wine is a piece of a really good software, but why it's logs are so unredable? Many times when it crashes it's log tells me nothin'. I know I should paste some sample but unfortunately I don't have any close at hand :/
(11:42:51 AM) YokoZar: A few reasons for this.  One may simply be not having the wine debug symbols installed (which are split into a separate -dbg) package, which gives more usable (to a developer) crash logs
(11:43:14 AM) YokoZar: The other reason is that Wine often doesn't know why it (or the application it's running) crashed
(11:44:34 AM) YokoZar: So if a program asks Wine how many bricks are in the great wall of China, and Wine tells it 2 million when it was supposed to say 3 million, you wouldn't see a "FIXME: wrong number of bricks" message in Wine.  And the program might carry on working for a little bit, until later it runs out of bricks and the mongol hordes invade.
(11:45:16 AM) YokoZar: (08:29:40 AM) sebsebseb: [16:13] <sebsebseb> QUESTION: Do you think it is ok for Windows software developers to opt out of making native Linux apps, if their app will work properly in Wine, without a user first having to mess around with wineconfig, which tends to not be much fun, if fun at all. Plus most users don't know how to use wineconfig properly.
(11:45:16 AM) YokoZar: (08:30:06 AM) sebsebseb: YokoZar: I mean like utorrent for example website even says it's made for Wine
(11:45:55 AM) YokoZar: To clarify: I think it's ok if the user experience is basically the same as a "real" native app
(11:46:17 AM) YokoZar: Some native apps you have to go through a big hassle to download and install (like Doom3)
(11:46:41 AM) YokoZar: With uTorrent the experience is very similar: you go to a website, download the app, and install it.  That's actually pretty much the same experience as you get on Windows
(11:46:53 AM) YokoZar: But in Ubuntu we can do much better, with proper packages and the Software Center.
(11:47:34 AM) YokoZar: So if, say, there were a uTorrent app with a minimal package that had some .desktop files and put it in Applications->Internet, and it were available through software center, I'd say it's ok that there's no native version.
(11:47:46 AM) YokoZar: (08:30:15 AM) virtuald: QUESTION: how do Vineyard relate to PlayOnLinux, wine-doors and winetricks?
(11:48:33 AM) YokoZar: Vineyard doesn't catalog specific apps like those projects do.  It would work alongside them to replace the stuff currently in the Applications menu.
(11:49:29 AM) YokoZar: One part of Vineyard, for instance, is a python-wine interface.  This allows me to write code for Software center to display installed Wine apps there, so you could then remove programs using Software Center rather than the awkward separate Wine uninstaller
(11:50:00 AM) YokoZar: (08:31:52 AM) amichair: QUESTION: How close is WINE to Windows nowadays? What's the probabiliy of a random windows app working correctly? And at what rate is that probability rising? (hopefully :-) )
(11:50:36 AM) YokoZar: Higher than it used to be, for sure.  It's gotten to the point where I expect most apps to work until I hear otherwise, even games.
(11:51:07 AM) YokoZar: I actually wondered that exact question - how fast is Wine improving - and went as far as making a mathematical model of Wine's growth
(11:51:44 AM) YokoZar: You can see it on my blog here: http://yokozar.org/blog/archives/48  -- there's even code to download and run your own simulation :)
(11:52:26 AM) YokoZar: But the executive summary is: given any reasonable model of Wine development, how we fix bugs, and what apps are affected by, we should expect applications to work at an increasingly fast pace.
(11:52:48 AM) YokoZar: This is what Wine developers call "collateral damage" - by making one app work by implementing something, you make part of another app work because it needed it too
(11:53:05 AM) YokoZar: Eventually these things add up, and you start having a whole lot of apps work without much (or any) specific effort
(11:53:48 AM) YokoZar: (08:41:25 AM) sebsebseb: YokoZar: as for Mono it apparnatly can run .NET version 1 apps, anything later than, that nope,  since it's quite different to the actsual .NET.  Plus then the whole Mono is bad for Linux distro's thing, because it uses a Microsoft programming technology #C and they could maybe patent sue distros over that or something.
(11:54:14 AM) YokoZar: So I should talk about Mono for a moment
(11:54:21 AM) YokoZar: It's a sister project in many ways
(11:54:31 AM) YokoZar: Although Wine doesn't communicate as much with Mono as it should
(11:55:05 AM) YokoZar: However there are a good chunk of .net apps that don't yet work in Wine.  Wine is trying to make it so that if you install either Microsoft's .net runtime or Mono's .net runtime these applications will work.
(11:56:11 AM) YokoZar: The Mono project has missing parts of the .net API in much the same way that Windows does.  We maintain a wiki page about what Wine needs from the Mono project, and what ultimately has to come from the community: http://wiki.winehq.org/Mono
(11:56:30 AM) YokoZar: There are some parts that Mono would accept into the code, but no one is getting paid to work on them officially.  Stuff that would be valuable to Wine
(11:57:11 AM) YokoZar: The ultimate goal would be to run "impure" .net apps - so called "mixed mode assembly" apps that use both .net and the Windows API.  These are things that can't run on "just" mono
(11:57:17 AM) YokoZar: They would need Wine too
(11:58:08 AM) YokoZar: As far as patents go, I am completely unworried by them.  It's not because I trust Microsoft at all, but rather it's because Microsoft (and others) have so many patents on so many vague things that Mono is just as much as a problem as any other piece of software.  There are even patents on CLICKING
(11:58:37 AM) YokoZar: (08:47:34 AM) sebsebseb: YokoZar: proper packages? as in native apps?
(11:59:18 AM) YokoZar: It's a good point - once a program is ported with Wine, installable via software center, and basically looks the same as any other program, it hardly makes sense to not call it "native"
(11:59:43 AM) YokoZar: But often people say "native" when they mean "the hard way of porting that doesn't involve Wine and requires manually rewriting DirectX to use OpenGL and so on"
(12:00:19 PM) YokoZar: Regardless, I believe I got every question.  If I missed yours feel free to ask me personally :)