Article on wine development strategy

Jeff Latimer lats at
Sat Apr 18 07:06:17 CDT 2009

Scott Ritchie wrote:
> Reece Dunn wrote:
>> 2009/4/18 Kai Blin <kai.blin at>:
>>> On Saturday 18 April 2009 05:21:20 Dan Kegel wrote:
>>>> The one that worked out best was to pick some random
>>>> user who's almost happy, fix the last few bugs that
>>>> are keeping his apps from working, and then once
>>>> he's happy, move on to the next such user.
>>> The problem seems to be identifying these people. The model assumes 
>>> that you
>>> can tell which piece of software almost works, and that you know the 
>>> almost
>>> happy users. In reality, you only seem to hear from the pretty 
>>> unhappy users
>>> and the occasional really happy user. Susan Cragin is about the only 
>>> user I
>>> can think of off the top of my head who's almost happy and could be 
>>> made
>>> completely happy by fixing all of the remaining bugs in DNS.
>> You could also pick some games as well. A lot of the Oberon Media
>> casual games work (probably around 50-60%), but there are bugs in the
>> launch page that means you don't get a seamless experience. The Game
>> Socks versions of the games have a seamless experience with the splash
>> loader (not sure about purchasing games there, though).
>> Other popular games and games platforms like WoW and Steam will also
>> help your gamer users.
> The one trouble with gamer users is that they tend to have a lot of 
> games that they want working.  Probably the major exception is WoW -- 
> and it's a very wise choice for us to make sure it works really well, 
> since many users want that and only that.
>> CodeWeavers are doing this to some extent - now branching out to fix
>> other applications. There was a big push a while back to get Photoshop
>> usable.
>> AppDB or something similar is useful for determining the most popular
>> applications that people are using. This does not cover the users,
>> though -- a user may be happy with one app, but unhappy with another
>> because that one is obscure/unpopular (think in-house applications).
>>> Also, reality has us deal with the fact that new applications are 
>>> added while
>>> we're working on the old ones, and looking at the graphs, we're only 
>>> going to
>>> make a significant number of users happy when we're about 98% done 
>>> fixing the
>>> bugs. I realize that it's a bit hard to model "rate of new 
>>> applications with
>>> new bugs being added", but that's what happens in real life.
>> Not just new applications, but upgrades as well. iTunes is a
>> constantly shifting landmark, from what I understand. IE6, 7 and 8 use
>> more of the Windows API. Photoshop only works with earlier versions.
>> There have been updates to fix Office 2007 SP1 issues.
>> Some of the major pain points I can see in the future for getting Wine
>> to run applications are:
>>   1.  applications that use the newer Windows Vista and 7 APIs -- this
>> is ok if the application is also designed to run on XP or earlier, but
>> applications will start targetting XP and later or Vista and later.
>>   2.  applications that use .NET, WinForms and/or WPF -- these should
>> be ok on Wine if the Microsoft and/or Mono runtimes can support these.
>>   3.  applications that start using more (unimplemented or partially
>> implemented) of the XP and earlier APIs.
>> So a happy user today could be an unhappy user tomorrow if they try
>> and upgrade one of their applications. But such is the nature of
>> playing continual catchup.
> Perhaps this implies we shouldn't try so hard to get the apps that are 
> about to break on upgrade, even if they are big ones.  We've spent a 
> lot of effort chasing Photoshop, but if only the Photoshop of three 
> years ago works then we haven't really gained much directly.
There are big bugs and smaller ones.  If an app is in the high 90's for 
working and there is an active use of it in wine, smaller programs and 
utilities come to mind, then concentrating on those would seem to have a 
bigger satisfaction payback.  All the little glitches and problems are 
magnified as the users are expecting that if it is not a word or a 
photoshop then it should be small enough to work in wine.  Another way 
of looking at it is that these bugs and lack of functionality need to 
addressed sometime and if the effort is put in early then we do start to 
get happy users.


More information about the wine-devel mailing list