Wine Traffic Brian Vincent

This is the 266th issue of the Wine Weekly News publication. Its main goal is to think fondly of Montana. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
News Tom Wickline News

Tom Wickline gave a pointer to a Unified Modeling Language tool called Enterprise Architect. The makers of EA, Sparx Systems, suggest running it on Linux using CrossOver Office. It happens to fall into the unsupported category of software that works with CrossOver Office, but apparently the makers of the software don't feel that's a deterrent. This is interesting news because it's the first time I've seen an ISV recommend using Wine (or in this case, a derivative) to get their app to work on Linux.

Oliver Stieber updated his DirectX 9 page to point out he might not be able to continue working on it:

Cash is getting short, to the extent that I may have to stop my Internet connection, if you think my work is worth a beer or two then please make a donation, I would also appreciate any sponsor of my work, support or migration work porting games or software to Linux, anything from my Amazon list, computer bits or chocolate.

If you don't fancy donating there are many other ways you could help me and everyone else wanting to migrate to Linux

  • Consultancy, contract or other paid work, even if it isn't related to WINE (see my C.V.)
  • Translations, into other languages (or better English ;-))
  • Test/ cases for DirectX 9
  • Reports on working games and applications
  • Reports on non-working games and applications
  • Anything on the TODO list

If some of you guys have a few thousand dollars laying around I'm sure you could convince Oliver to get HalfLife2 working flawlessly..

Internationalization

Translating documentation can be tricky, especially when you're aiming at a moving target like Wine. Francois Gouget, who's worked extensively on the documentation in the past, announced a bulk of Wine's documentation has been translated into French:

The Wine documentation has been translated to French by students from the Insa of Rouen.

The credits for the translation go to:

And believe me, this is a lot of work so they really deserve our kudos. You probably noticed that the Wine Developer's Guide was not translated but that makes sense: if you want to work on Wine it's really best if you speak English anyway.

So what's needed now is to integrate the translation with Wine. This is what I have done by converting the translation to .po format to make it easier to maintain and tweaking the Makefiles accordingly.

The patch is pretty big (even compressed it's more than 200KB) so I did not attach it to this email. Instead I have set up a page on my web site and you can the patch using this URL:

Here is what the patch does: Add a Makedoc.rules.in file which handles the conversion of SGML files to the final documentation format. Modify documentation/Makefile.in to use Makedoc.rules.in. Add documentation/fr with the po files of the French translation. Use po4a to generate a translated Sgml file from the original sgml documentation and then let Makedoc.rules.in generate the documentation. Detect po4a in configure.ac.

The translation appears to have been made from a snapshot of the documentation taken in the summer of 2004. Now, a bit more than 6 months later, the translation is still more than 90% complete. IMHO this proves that maintaining the translation is quite feasible. If you see any bits of English in the documents above, this is precisely because the translation is not 100% complete anymore: in that case po4a-translate keeps the original version rather than use the outdated translation.

For more information about po4a:

I will upload anything new to the following page:

Now you pretty much know everything. Let me know if you have concerns, suggestions, etc. I'm hoping we can get this in place soon.

Configuration

Alexandre removed a big chunk of functionality out of the blue with the following changelog entry:

Get rid of the Windows registry loading on startup, this needs to be done differently.

Mike Hearn was the first to ask, What is the thinking behind this patch? If we don't load the Windows registry on startup where should it be loaded? Will this code re-appear at any point in the future? A significant number of users still expect to be able to point Wine at an actual Windows install despite what we recommend.

Alexandre explained what he would like to see happen, There should be an "import existing Windows drive" function in winecfg, or something along those lines, that would create symlinks to the Windows install and import the registry.

Mike wanted to know if it would remain a feature regression; Alexandre said it just needed someone to reimplement it, Nobody's working on it, so it won't be supported until someone cares enough to do it. I encouraged a few people to start working on it but nobody did, so taking out the existing support is a way to provide more encouragement. If that's not enough then the feature simply won't be supported anymore.

The good news is, all of the really hard work of loading a Windows registry is done. What's appears to be left is to load it and then merge the relevant parts with Wine's own registry. The implementation method would be similar to the new drive detection code in winecfg.

A debate about the utility of removing functionality ensued. Mike Hearn cited Wine's configuration as an example, We have no config file, yet this has apparently not accelerated the pace of winecfg development, we just have more confused users

Alexandre disagreed and mentioned that changing the registry loading code was directly tied to Wine's configuration, Actually there has been quite a bit of work done on winecfg. To get more done requires people to start depending on it, which means finishing the transition to the new config. And in order to do this we need to get rid of the current registry hacks, the first of which is the Windows registry loading code. Whether or not someone works on a replacement is really secondary, the primary goal is to get the new registry stuff in place, even if that means some less used features have to be dropped for the time being.

Later in the week, the ability to have a global registry was removed. Some people stepped up to mention that stuff was important to them, but there's no one working on it right now.

Controls

RichEdit development is rolling forward. More and more patches are coming in. This week Phil Krylov posted a large one to add RTF write support. Krzysztof Foltman commented on it:

Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks.

IMHO the patch can be applied without changes.

The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later.

Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code.

Phil thought of some work that needed to be done on the reader side, The RTF reader still has to be taught Unicode. Currently most of my existing .rtf documents are totally garbled.

Krzysztof wasn't too familiar with Unicode and asked Phil if it was something he'd be willing to tackle. Phil spent some time looking over the reader code and a few days later began submitting patches. All in all, this is a large item on the Wine wishlist and it's being tackled pretty aggressively.

Ports

Scott Ritchie announced Wine made the Tier 2 list of applications IBM's Linux on POWER contest:

IBM has started a new contest meant to spur open source development on their POWER architecture, http://www.linuxonpower.com/

Prizes are offered for coders that port some common open source applications to the architecture. A Tier 2 prize, a Mac G5, is offered to anyone who can port one of the list of Tier 2 applications.

Color me shocked to find Wine and Winelib listed there!

This marks a change in IBMs policy towards Wine, or perhaps signals a management oversight. While normally it seems that they have an active policy of censoring any references to Wine and completely denying its existence, here they are offering prizes for porting it to PPC.

So, now, I guess, the obvious questions: Does Winelib even need any porting? Does it build on PPC as it is? Can we run notepad and such on Linux/PPC?

Does any of the work done on porting to AMD64 help us here?

Discussion then ensued about the cold shoulder IBM seems to give to Wine. In fact, they seem to go out of their way to ignore Wine. In the past they've pulled articles from their website that mention Wine. In their new desktop migration Redbook they mentioned Wine once in passing. It'll be interesting to see if Wine gets pulled from that list.

Integration

Kuba Ober wanted to know about mailslots, Is the one-way mailslot IPC implemented in wine? I'm getting fixme:sync:CreateMailslotW(...): stub messages. Is this a simple thing to implement, or would it require additions to the server protocol?

Mike McCormack confirmed what needed to be done, but questioned the necessity of it:

Yes, it needs to be implemented in the server. I started writing it some time ago, but never got round to completing it. I submitted a test case...

Which application uses mailslots? I only ever found one real application that used them, and that was "Declan's Korean Dictionary" from [ 1 ].

If you're interested, I can send you what I wrote. It's probably very out of date by now though.

Jelmer Vernooij mentioned the Network Neighborhood in Windows uses it. The idea of using libsmbclient from the Samba project was tossed around since it contains a mailslot implementation. Mike McCormack followed up with some code and talked about the implementation:

Here's the mailslot implementatation that I wrote a while back. I've updated it to compile on the current CVS tip, but it's totally untested... I will try to test it, fix it and submit it, but in case I don't get round to doing that, here's a starting point for somebody.

Note that this patch does not allow mailslots to work over the network, only program to program inside Wine. Mailslots and named pipes over the network are hard to implement correctly in Wine. We can't use libsmbclient, and it probably needs to be done in the kernel to work correctly. Perhaps fuse (http://fuse.sourceforge.net/) will help when it is integrated into the Linux kernel.

The test program I wrote to test mailslots a while back is available at:

It's pretty much the same as the regression test in dlls/kernel/tests/mailslot.c.

Apply the patch by running the following commands on an up to date CVS copy of Wine:

    cd wine
    patch -p0 --dry-run < mailslot.diff
    (check there's no errors)
    patch -p0 < mailslot.diff
    tools/make_requests
    config.status server/Makefile
    make depend
    make

The patch and the test program are both LGPL licensed. The test program should run and terminate with no output or errors. (Running the test program now causes it to hang...)

There was more discussion of using libsmbclient, but Mike explained what the problem was:

I'm wondering whether fuse might be a good way for Samba and Wine to communicate? If Samba were a fuse server, and provided named pipes and mailslots through a single fd, that would be the perfect interface for Wine.

For those not familiar with why we can't use libsmbclient, it's because we need to make sure that many Wine processes can share reading and writing to a single file atomically. ReadFile needs to be done in a single read() operation, and WriteFile in a single write(), otherwise there'll be race conditions.

Because FUSE operates in userspace, it makes sense for integration with Wine. Andrew Bartlett followed up with more info about exposing this functionality in Samba:

This is one of the many things I hope we will discuss at the WineConf. There should be a good Samba contingent there, and I'm assured a few wine folks intend to turn up ;-)

In all seriousness, there are existing mechanisms to get at some of these packets to non-root users, but they are a bit of a Samba-specific hack. For Samba4 (which is where we should plan integration, because we can design it properly) I would love to see wine able to register for such mailslots with the Samba server. (Alternate non-samba solutions will probably be required in parallel, I suppose).

Security

Marcus Meissner provided a security patch to Wine that was announced on the Full-disclosure mailing list. He forwarded the original announcement:

Title: Insecure tmp file creation in Wine
Author: Giovanni Delvecchio
e-mail: badpenguin_at_zone-h.org

Version affected : Wine 20050211 and previous releases

Problem When a win32 application is launched by wine, wine makes a dump of the windows registry in /tmp with name regxxxxyyyy.tmp , where xxxxxx is the pid in hexadecimal value of the current wine process and yyyy is an integer value usually equal to zero.

regxxxxyyyy.tmp is created with 0644 ( -rw-r--r-- )permissions. This could represent a security problem in a multi-user environment. Indeed, any local user could access the windows registry's dump and get sensitive information, like passwords and other private data.

Details

The functions affected are _get_tmp_fn(FILE **) in $winerelease/misc/registry.c and save_branch( struct key *key, const char *path ) in $winerelease/server/registry.c

Alexandre pointed out that only one of those two functions actually were affected. One of the functions dealt with the Wine registry in the user's home directory, not /tmp. Peter Bortas thought that might still be an issue, Home directories are group readable on many sites, so to prevent information leakage 0600 would still be prudent.

Alexandre pointed out the registry is actually buried a level deeper and that's where permissions needed to be set, There is no leakage at all, the permissions are identical to the permissions on the final registry files. If users don't want their registry to be readable they can set umask or protect their .wine directory.

Architecture

Dmitry Timoshkov had some ideas for janitorial projects:

I'd like to suggest to add the following janitorial projects for Wine:

  1. Fix Wine to be compilable by a 64-bit compiler
    • before accomplishing this task read a good article about porting Win32 code to Win64.
    • inspect and fix all public Win32 headers to match PSDK definitions.
    • make sure that pointers do not get truncated.
    • add support for Win64.
  2. Fix wrong assumptions in Wine about endianess.
    • inspect all Wine code and public headers to eliminate endianess dependent constructs (low/high parts of a field, bit fields), add WORDS_BIGENDIAN when appropriate.
    • make sure that Wine code handles data in an endianess independent way.