Wine Traffic #142 For 1�Nov�2002

By Brian Vincent

Table Of Contents


This is the 142nd release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 461 posts in 1447K.

There were 91 different contributors. 53 posted more than once. 40 posted last week too.

The top posters of the week were:

1. News: SuSE & CrossOver Office; Xandros LUG Discount

26�Oct�2002�-�1�Nov�2002 (1 post) Archive Link: "News"

Topics: News

People: ,�Xandros,�News

SuSE is releasing a product called "SuSE Linux Office Desktop" ( sometime early next year. They've released this product before (or at least something very similar) but this time they've added CrossOver Office 1.2.

Xandros announced special pricing for LUG members worldwide. If you're a member of a Linux User Group ask your officers about it and what the discount code is. Also in Xandros news, ExtremeTech did a review (,3973,648362,00.asp) . obScreenShot (,3969,s=1027&iid=17223,00.asp) .

Also, check out the Contribute ( page on WineHQ to find things that need to be worked on - Andi Mohr updated some of the jobs on there this week. And a lot of them don't even involve coding.

2. A Big To-Do List

30�Oct�2002�-�1�Nov�2002 (120 posts) Archive Link: "Versions & mass-appeal"

Topics: Project Management

People: Dimitrie Paun,�Alexandre Julliard,�,�Jeremy White,�Jeremy Newman

The talk on the wine-devel mailing list this week has been less about the technical details of Wine and more oriented towards project management. It seemed pretty much everyone was in agreement that everything surrounding Wine needed to be revamped, updated, or completely redone. Discussion centered around WineHQ ( , release management, documentation, and configuring Wine. Basically anything that's considered a barrier to people using Wine was discussed. I'm not going to go into the details of some of the discussion, though some of the topics are discussed below. I urge you to check out the archives ( for more details. Also, insofar as public forums go, mailing lists tend to only generate discussion when people disagree. Most of the disagreement in the discussion has been over relatively minor points. Does that mean most of the developers seem to agree?

I'm going to do a poor job summarizing this topic in general. And most certainly I'll do a disservice to anyone who contributed to this discussion. First, let me just run down a quick summary of the threads that generated this discussion:

Again, lots of discussion ensued. At press time, Dimi had once again revised his list and narrowed it down. Also, Alexandre had suggested most of the items fell into the .9 release plan hence the initial comment:

This will probably get renamed to Wine 0.9 TODO, after Alexandre's clarification, but I haven't changed the name just yet, to avoid confusion.

Once again, what I mean by 0.8:

What is NOT in 0.8:

That being said, this is my initial list. Comments, flames, suggestions, are appreciated.

3. Releasing WineSetupTk

1�Nov�2002 (2 posts) Archive Link: "WineSetupTk"

Topics: Codeweavers

People: Jeremy White,�CodeWeavers,�,�Codeweavers

Jeremy White put forth the following proposition concerning WineSetupTk (CodeWeavers' graphical configuration tool):

In responding to Dimi's call for better binary packaging, and the whole issue of getting a base line config ready, it felt clear to me that WineSetupTk is a tool that is underutilized.

I have been trying to persuade Alexandre to include WineSetupTk in the main Wine distribution for some time now, and have always failed. (Alexandre is rightly concerned about increasing the dependencies in Wine).

However, it struck me that we ought to be able to do a better job of making it available to binary packagers so that it could be included in more packages. We could also make it easier for people to get both Wine and WineSetupTk from source.

To that end, I have the following proposal, and I wanted to see what folks here thought.

We would create a parallel CVS tree to Wine; say the winesetuptk tree. We'd put that code out under a dual license (GPL/but we still own rights). I'd probably welcome multiple maintainers.

The only thorny issue is that we share code between WineSetupTk and some of our proprietary pieces. We could shift our main WineSetupTk development to this tree, and share the common bits, including our developments as we make them. However, in exchange, we would need anyone making changes to WineSetupTk to grant us a license to use their changes in our proprietary stuff. (And, of course, if we ever abuse this, someone can take the GPL tree and go host it somewhere else).

As of press time there hasn't been much response, however I suspect most people think this would be a great tool to have available.

4. FAQ Maintainer Needed

1�Nov�2002 (13 posts) Archive Link: "Wine FAQ - call for a volunteer"

Topics: Documentation

People: Jeremy White,�Dimitrie Paun,�,�Jeremy Newman

Wine documentation.. never mind, I won't even open that can of worms. Suffice to say, lots of it needs some care and attention. Jeremy White put out a call for someone to maintain Wine's FAQ ( :

Andi and I have talked about the FAQ a lot on and off through the years, going back to when he was in St. Paul and first set up the FAQ-o-matic.

When I go visit a project the very first thing I look at (before screenshots, about, or *anything* else) is the FAQ.

Therefore, I think it's extremely important to have a good FAQ.

Now, Andi has poured a lot of work and energy into the FAQ over the years. But, here's the truth - it's not really a job he wants. (He and I discussed it privately). There are a lot of other things he'd rather do.

So, I'm hoping that we could get a volunteer to step forward and take over responsibility for the FAQ from Andi. I'm particularly hoping that one of the new crop of wine-devel participants would be inspired to volunteer.

My vision for the FAQ is a hand edited main FAQ with the current FAQ-o-matic being pushed to a secondary role.

Dimi Paun threw out the first idea, " Please get rid of the FAQ-O-matic. The interface is atrocious. A hand written one would do just fine, is not like we add 100 questions per day! (And if we do, something's wrong, who's gonna read them?) " The FAQ-O-Matic he refers to is the link above. The interface is hard to use for just basic information. Andi Mohr pointed out that it also houses a troubleshooting guide, and for that it seems suited. Others argued that even for a troubleshooting guide the interface is so bad it detracts from the content.

In the end, everyone agreed a static page needed to be created for the FAQ that was easy to navigate. Jeremy Newman suggested any work on the FAQ be done with SGML in order to make converting it to other formats easy. Anyone want to volunteer? It's as easy as responding ( Wine FAQ - call for a volunteer) to Jeremy's original post ( .

5. Conversion to -DSTRICT

25�Oct�2002 (1 post) Archive Link: "Status Report: -DSTRICT"

Topics: Status Updates

People: Michael Stefaniuc,�

The conversion to using -DSTRICT covered a few weeks ago is progressing well. Michael Stefaniuc wrote in with a status update:

status reports seems to be pretty popular this day so here is mine regarding compiling wine with -DSTRICT. Below is the amount of warnings we get when removing -DWINE_NO_STRICT:

dll real total
commdlg 21 63
gdi 128 273
ntdll 148 178
ole32 16 38
shell32 120 155
user 450 839
winmm/wavemap 7 40
winmm 104 145
winsock 14 42
x11drv 60 79
total 1068 1852

"real" is the number of warning for which real work is need to be done, the rest up to "total" are warnings of the type "int format, HANDLE arg". And to fix this beasts just grab ( and do:

and you should be done.

P.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours.

6. Wine/Windows Security Concerns

26�Oct�2002�-�1�Nov�2002 (35 posts) Archive Link: "Wine securityflaw."

Topics: Integration

People: Peter Andersson,�Vincent Beron,�Greg Turner,�Alexandre Julliard,�Francois Gouget,�Eric Pouech,�,�David Hagood

Peter Andersson started a thread out innocently enough by asking about implementing more security in Wine:

I believe most wine users trust wine not to touch anything outside of its configured drive space. Malicious Linux/Unix syscalls could be embedded in windows apps and if executed do a great deal of damage. After all checking your app is run whithin Wine is not that hard (reading registry settings for instance). Lets call such an malicious app a wine-virus from now on. At present a wine-virus would even be allowed to fork itself, leaving the wine environment and continue to run even after you shutdown the wineserver, and in some cases even after the user logs out. The virus would now have full access to the system whithin the users permission, doing much greater damage than you expected.

The question is...Would you expect that damage from running a windows app in wine, when you know it could be safely run in Windows? In just a few embedded bytes in the code it could remove your home directory in a single syscall. Would you expect that? - I wouldnt.

Cant we atleast try implement some protection in wine against these attacks, before something really nasty happens. I do think company policy decissions againt using wine, will do just as much damage to the wine movement as too the free software movement at large.

A lot of random ideas were thrown about, and almost everyone was averse to the idea of changing Wine. A lot of people felt the best thing to do was use existing tools to provide a safer environment. Vincent Beron suggested, " Use the LSM patches for Linux if you want to monitor certain system calls. Use Wine in UML, chroot, or as a separate user (*not* as SUID) if you want to protect your current $HOME."

Greg Turner expounded on that idea:

I concur with Vincent, here. As wine exists here and now, we are basically implementing the level of "security" provided by Windows 9x. That is, wine "emulates" an OS with no security measures at the filesystem level, no security policy regarding what API's can be called (except as provided by the CPU itself), and so on.

Luckily, the native operating systems that host wine tend to be rich with security features, and those can be used to sandbox wine until some more sophisticated application-level security measures exist.

We've recently talked about some ways to move forward towards implementing the NT-style security model in wine. When those plans move forward, one of the issues to consider is the tendency of windows to propogate virii, and the possible need to selectively prohibit wine from accessing resources that the user invoking wine might have full control of.

Unless wine is going to be a true emulator (instead of an engine for executing windows apps natively under the security context of the invoking user), we simply cannot solve this "problem," by definition.

The closest thing to a solution involves a massive reconceptualization of how wine works (for example, the invoking user runs userwine, which uses some kind of IPC to talk to sandbox-wine, which does all the actual executing of windows code or, alternatively, wine works like a just-in-time compiler, verifying code is safe before it's loaded into memory (terrible idea IMHO)). Since "emulating" the NT security model for wine is a similarly major undertaking, and provides most of the same benefits as Peter would have, I think this is how we should solve this "problem".

Food for thought: by Peter's definition, neither Windows, nor most Unix operating systems, provide an acceptable level of security. Wine is no better, but also no worse, than any other powerful application, such as GNU make, bash, or the Konqueror file browser, from a security perspective. All of these can be used to destroy your $HOME directory and any other file you can delete.

I think the problem is one of wine being closely associated with Windows, and windows having a reputation of being insecure; in other words, it's a problem of perception, not of technical merit. Nothing wrong with that -- problems of perception can kill a project -- but bear in mind that, if wine, even as it exists today, is run in a carefully administered manner on a good secure OS, it ought to be safer than native Windows to run, if you accept the assumption that UNIX-like OS's are more secure than Windows ones. If you really don't trust windows, you could argue that running under wine in a sandbox is the /only/ safe way to run windows programs outside of an emulator.

Just my opinion, probably worth about what you paid for it, but there you go.

Alexandre's opinion was, " If you run untrusted code under your account it can do anything that you are allowed to. This is exactly equivalent to running an untrusted Linux app. From a security standpoint there is absolutely no difference between a Windows binary running under Wine and a Linux binary running natively. You can use the DOS drive configuration to limit the potential problems a bug in a Windows app can cause; but it is impossible to protect against malicious code except by not running it. Wine is not, and cannot be, a sandbox for running untrusted code."

Creating a sandbox by using other programs was discussed. Francois Gouget thought jail might be a possibility:

Why don't you study how chroot or jail could be used in combination with Wine to build a sandbox? As far as I know no-one has tried that and it is possible that some changes in Wine could make things simpler to set up. Of course, we won't know until someone actually tries this.

Also, I'm told that jail (available on FreeBSD) is much better than chroot. chroot only restricts access to files while I believe jail can also restrict access to other running processes and other system resources. Unfortunately I don't think a jail-like functionality is implemented on Linux. If you were to implement this I'm sure countless people would be grateful. (

Finally you could wrap it up by writing scripts that would make it easy to run Wine in a sandbox, and restore the sandbox to a clean state after a program has been run.

David Hagood thought checking the execute bit of a file before running it might provide a little better security, especially for things like the Klez virus running via KMail. But Eric Pouech pointed out a problem, " that could bring some issues while trying to run a native executable from a mounted FAT driver (without the proper umask option for mount) (this could be circumvented by a drive configuration option in wine, but that would be a bit tricky to set for the average user)" Andi Mohr mentioned that it would break installers too.

Other discussion involved making it much harder to run Wine as root, intercepting Wine server calls, and other architecture changes.

7. Detecting Wine vs. Windows

25�Oct�2002�Archive Link: "How can an app detect it's running under WINE?"

Topics: Winelib

People: Alberto Massari,�Paul Rupe,�,�Uwe Bonnes,�Patrik Stridvall

Alberto Massari wanted to know how to go about detecting a Wine environment:

I am working on making our software (Stylus Studio, run under WINE, if this is feasible. To achieve this, I have already implemented a bunch of APIs (the application is built against the UNICODE version of the Win32 APIs) and fixed some bugs I hit (I already mailed the first patch to

However, I would feel better if I could detect I am running under WINE and gracefully disable some functionalities that are not yet fully supported; is there any way to achieve this? Is there a WIN32 API (like, say, GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is WINE trying to be as stealth as possible?

Pretty much everyone was in agreement that specifically detecting Wine was not the solution. Instead, the missing functionality should just be added. However, as Uwe Bonnes pointed out, it's possible to look for Wine registry entries. Patrik Stridvall mentioned doing so wasn't necessarily guaranteed since those entries may not be there due to future changes. Paul Rupe's suggestion was a little more graceful:

My suggestion is whenever possible check for features, not version strings. Just call the API and if it fails, then gracefully disable whatever functionality. When some future version of Wine supports that API, it will just start working without any further effort on your part. An added benefit is that whichever Wine developer is implementing that feature will have your app to test with. Also have some sympathy for the poor Wine developer tearing his hair out trying to figure out why your app behaves differently in Wine vs. Windows no matter how perfect his shiny new DX12/DCOM/HAL/TANSTAAFL implementation is. :)

8. IDL Generated obj_* Headers

31�Oct�2002�-�1�Nov�2002 (8 posts) Archive Link: "IDL/header issues"

Topics: Patches

People: Ove Kaaven,�Alexandre Julliard,�,�Ove K�ven,�Greg Turner

Ove K�ven asked:

Now WIDL is good enough to generate a drop-in replacement for Wine's wtypes.h (attached) from a suitably crafted Wine-compatible wtypes.idl (also attached). I've included all the definitions that were already in Wine's wtypes.h (but I was too lazy to do everything that's in Microsoft's wtypes.idl yet).

What do you think, is this good enough to go into Wine? Are there some desirable changes to widl or wtypes.idl? And should IDL files go into the main include dir along with the other Win32 headers?

IDL-generated files would also eventually obsolete all the current wine/obj_*.h files, but those obj_* files seem to be somewhat more logically structured than MS's own IDL files, should we craft Wine's IDL files accordingly, and maybe have some top-level .idl files in include/ and some sub-.idl files under include/wine/, like it's done now in e.g. objidl.h?

Concerning the structure of the files, Alexandre replied, " No, I think we should follow the Microsoft way. Sure it's a mess, but so is the rest of the API anyway... And every time we tried to do things better than Microsoft we ended up having to revert it."

The work seems to stand a decent chance of making it into Wine. Greg Turner volunteered to merge the work from the ReWind tree Ove is working out of into the Alexandre's LGPL'ed one.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.