Create new mailing list wine-isv?

Dmitry Timoshkov dmitry at
Fri Dec 16 09:06:07 CST 2005

"Peter Beutner" <p.beutner at> wrote:

>> Why? Wine is effectively just a different toolkit, like QT or GTK 
>> (albeit much larger) that give applications a Windows, KDE and Gnome 
>> look respectively. Take Notepad for example - with some slight 
>> modifications you could even modify the File Open dialog to only show 
>> the Unix namespace. Is there any reason that this application can't be a 
>> fully fledged part of the desktop?
> Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do 
> to emulate the windows process environment. This is not exactly what I would prefer as an 
> ideal environment when I had to develop an application.

Since Wine is not a trivial thing written in 3 lines of code and it has huge
compatibility requirements it must to do all kinds of things to make you (a developer)
not to do that kind of things in your own code. Think about that.
Said that, nothing makes it a different from another toolkit, no matter
what Wine haters think about it.

>> Sure. While you're at it give them some docs about globalization 
>> practices and efficient CPU usage. These are all nice to have things, 
>> but you have to face it that if you're a developer at a software company 
>> with a deadline then these are the first things to be ignored. You also 
>> have to bear in mind that it is incredibly difficult to do platform 
>> idependent GUI programming, whilst still maintaining the Windows look.
> Nobody said it's easy or that it will happen over night. But it can/should be the long 
> term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits.

I don't understand why you can't include Wine in that list. Is that an ignorance or
a result of hate to all which goes from windows world?

>> It is the cheapest way for companies and it gives good results for the 
>> users. What's wrong with that?
> See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use 
> some complex window api the more is the chance that wine just can't implement it the way 
> it works in windows but has to use all sorts of workarounds to get it to work under linux.

Sounds like a popular Wine myth. Anyone who ever seen a working MS Office 97/2000/XP/2003
or any other not trivial application working under Wine wouldn't tell anything like that,
especially if he is a knowledgeable developer and not another member ./ crowd.

> Sure all that probably won't interest any manager in a company and probably won't stand 
> against the "money" argument. But as a developer I would always vote for doing a little 
> bit of extra thinking by going the platform independent way.
>> Wine is a very good way of testing the waters with a Linux market. If a 
>> significant part of the market share starts coming from Linux or other 
>> Unix operating systems then the company can start offering winelib 
>> extensions that integrate better with the environment in which they are 
>> running.
> I doubt that this will happen. If the windows version works with wine the company will 
> more likely continue to work on that. See your money argument.

Another myth about Wine.

>> However, you have to face facts that Linux is a hostile environment for 
>> commercial companies - constantly changing APIs, lack of regression 
>> testing by distributions, lots of variations meaning lots of testing 
>> needed and different standards on different distributions. Wine is a 
>> layer on top of that, which provides a degree of stability.
> As long as wine doesn't break. And we all have seen how easy wine gets messed up when 
> something in underlying linux software changes. May it be the kernel or X.
> Besides wine doesn't do all the testing for you. You still need to do a lot of testing on 
> different configurations.

Which is the case for every other toolkit, it's not Wine specific.


More information about the wine-devel mailing list