Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #147 For 6 Dec 2002

By Brian Vincent

Table Of Contents


This is the 147th 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 190 posts in 739K.

There were 57 different contributors. 25 posted more than once. 31 posted last week too.

The top posters of the week were:

1. News: German Wine Site, iPod + Linux + Wine

30 Nov 2002 - 6 Dec 2002 (2 posts) Archive Link: "News"

Topics: News

People: CodeWeaversNews

Since it was a slow news week I decided to dig up whatever I could find. So, I was kind of surprised to find some interesting stuff. First, there's a German site called Lx-Wine2 by Bernhard Suttner. Sprechen sie deutsche? Ich nicht. Coincidentally, this page was also added to the community part of WineHQ.

In the Geek News Dept, Ashish Gehani figured out another way to use his iPod with Linux. First, he started with a Windows iPod (if you have a Mac one you can always reformat it). Then he got the Windows program EphPod to work with Wine. As a side note, he happened to be using CodeWeavers' Wine. Check out the screenshot of it running.

2. Screenshots Preview

1 Dec 2002 - 2 Dec 2002 (3 posts) Archive Link: "Screenshots v0.1"

Topics: Documentation

People: Brian VincentDimitrie PaunTony LambregtsMike HearnEnderRick RomeroThomas WicklineCarlos Lozano

I announced the following:

I've gotten a lot of great screenshots over the past few weeks. I've put together a preview you can find here:

Be warned, the format isn't the best, the thumbnails aren't even close to optimized, I only looked at it in one browser, and it might even steal your lunch money.

Random notes:

Okay, if you've read this far maybe you're expecting something to prompt discussion. One of the things you'll notice is there's a lot of screenshots on there there almost certainly don't run out of the box. In some instances the folks above listed exactly what they had to do to make it run. Personally, I don't think it matters. We already have the apps DB and the proposed "Gold/Silver/.." apps list, I really don't think we need more than a link to one of those.

Dimi (in another thread) pretty much agreed and clarified:

we're going to have the Gold page, listing apps that you can get going without any tricks. It's going to contain screenshots as well, it's going to be self contained.

This page is a little different, there no point in putting the same constraints on it as the Gold page. That being said, I fully agree with you. So I think that we should:

3. Updated To Do List

2 Dec 2002 (4 posts) Archive Link: "Wine 0.9 TODO v0.6"

Topics: Project Management

People: Dimitrie Paun

Dimi Paun updated the to do list and announced:

Version 0.6 of the TODO for Wine 0.9 is available at:

As always, you can find the work-in-progress one here:

As a departure from previous release, this time I'm only going to include a small summary of changes since the last release:

4. Janitorial Projects

29 Nov 2002 - 4 Dec 2002 (17 posts) Archive Link: "Janitorial Projects"

Topics: Project Management

People: Dimitrie PaunRolf Kalbermatter

Dimi also wrote in with a list of cleanup projects that could be done:

I have updated the Janitorial section:

with the list of cross calls from 32->16, and W->A.

There are currently 13 cross calls from 32->16 bit code, and 194 cross calls from Unicode to ASCII.

Any takers? :)

Rolf Kalbermatter looked into it and had a question:

I was just looking at shell32.dll and wondered if it should implement A->U as it almost completely consistently implements U->A. So I guess this should all be changed then. Problem is that some of those functions call other functions where only the ANSI version is implemented yet, so it is a lot more work than just moving the implementation from the ANSI to the Unicode version.

But what the heck do the errors about AW functions calling Unicode mean? Isn't that the actual idea about the AW functions?

Dimi replied, " Good catch. I've updated the list, there were 52 AW functions, which leaves us 142 cross calls to deal with... :)"

A few days later he updated the URL (which I changed above) and noted the following:

Please feel free to suggest new projects for the list. There are many things to cleanup in the tree, and having them available on an easy to read page increase the changes of (1) someone picking them up, and (2) us not forgeting them.

So let me know if you come across anything that you feel should be on the list. Also, if you're working on something big, I can mark your name there so we can avoid duplicated work.

Last but not least, there are a lot of small, self contained, and easy to get into tasks listed there. If you feel like getting your feet a bit wet in Wine development, this is an ideal opportunity to start, and get to know the project a little better. Just ask for help if you are new, and would like some help to get you started.

5. IWebBrowser Status

3 Dec 2002 (6 posts) Archive Link: "HTML Help and IWebBrowser status"

Topics: Status Updates

People: James BrownMike HearnJoerg MayerRoderick Colenbrander

You can find more info on this thread if you go back into past issues, Issue #141, Section #7  (18 Oct 2002: Web Browser Integration Needed) . And there was also a recent thread on wine-devel about a month ago.

I'm just posting a quick update on my various WINE work for those intrested.

I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet).

Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :)

That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy.

Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes.

I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider:

Roderick Colenbrander asked why Mozilla wasn't being used. Mike Hearn gave a good list of reasons for KHTML:

There are obviously some pros for Mozilla as well, but the things that make Moz a good choice for a web browser don't apply so much to a good replacement for the WebBrowser control.

Joerg Mayer talked to the KDE folks and reported:

I just told Dirk (one of the people putting quite a lot of time into kde) about your work and he told be the following (translated from German):

6. Conformance Tests Need Help

29 Nov 2002 - 4 Dec 2002 (5 posts) Archive Link: "The conformance tests need you!"

Topics: Testing

People: Francois GougetMartin Wilck

Francois Gouget found something disturbing:

I have been running the Wine conformance tests on Windows 95 and NT4. The results are pretty bad. 24 tests out of 32 have failures in one or more of these two platforms.

That's 75% of 'Windows conformance tests' that don't work on Windows! Out of the 32 tests, only 4, that's 12.5%, execute successfully on all tested platforms (and one of them has 4 todos in Wine).

You can see things more graphically at the following URL:

Come on people, we can do better. Send fixes to wine-patches, and send me emails to so that I update this table.

He followed it up with a few patches for some of the offending tests. Martin Wilck jumped in with some updates for the Winsock tests but mentioned he had a hard time figuring out how to even compile the tests under Windows. Francois then updated some of the testing documentation and described how to use the perl script "msvcmaker" in the tools directory to create Microsoft Visual C++ project files for the tests.

7. Preserving DLL Separation

4 Dec 2002 - 5 Dec 2002 (4 posts) Archive Link: "Dll separation question"

Topics: Documentation

People: Martin WilckAlexandre Julliard

Martin Wilck asked:

can anybody point me to a resource saying what exactly I may or may not do when writing code for a wine DLL? In particular, when writing code for DLL X, which functions from other DLLs may I call?

Example: When writing netapi32 code, can I call advai32 Registry functions to obtain config options, or do I need to use the (IMO rather awkward) ntdll interface ?

Alexandre sent a short reply, " The rules are that you can only call exported functions, and that you can't add dll imports that would create a circular dependency. You can find the list of existing dependencies near the end of dlls/ " And with regard to Martin's question about using advai32 functions, " netapi32 already imports advapi32, so you can freely use the registry functions from there."

Martin put together a patch for the DEVELOPERS-HINTS file with the following addition:

The rules to preserve Dll separation are

Dll separation is a goal of current Wine development, it is not achieved yet. However, it is important that you adhere to these rules NOW, so that clean Dll separation can be reached more easily later.

8. Moving Wine Headers

28 Nov 2002 - 29 Nov 2002 (5 posts) Archive Link: "[RFC] Wine headers"

Topics: Build Process

People: Dimitrie PaunAlexandre Julliard

Dimi Paun wanted everyone's thoughts about moving the header files around:

Patrik brought up the header location sometime ago, in this thread:

At the time, I thought it is a bit premature, that we have other things to do. Now I realize that this is one of those highly visible external things, that would be a _lot_ better to fix before people start using Winelib. Otherwise will piss people off when we change, or we will not change because people are already using the headers.

Both versions are not good, and I think we can fix them now without too much pain.

Here is my proposal:

It is simple (to understand & implement), clean, and pretty. And I think it solved Patrik's problem (even if I can't quite understand what the problem is from the first message :)), plus a bunch of other things (like making it easy to use other headers for the Win32 API, etc). And best of all, it seems to be easily implementable, no?

As always with headers, it's important the include order won't cause any conflicts. Some discussion centered on making sure everything was ok. Alexandre suggested a slight change:

I think everything should be under wine/ otherwise we risk conflicts with other packages. So I'd suggest something like this:

It means the Windows headers are a bit buried instead of being directly under wine/, but it's not too bad. As long as you don't change anything in the source tree I could be convinced to go along with that...

A few days later Dimi submitted a patch.

9. Wine + Cygwin Update

4 Dec 2002 (1 post) Archive Link: "Cygwin/wine : partial success"

Topics: Status Updates

People: Sylvain Petreolle

Sylvain Petreolle emailed wine-devel with a status update on running cygwin under Wine. For more info on exactly what that means, check out Dimi's Fun Projects page.

Making only one tweak to /etc/profile, cygwin manages to launch partially.

If you comment the line USER="`id -un`", bash -l -i displays : (I placed "I'm here!" at the end of .bahrc)

The next step will be identify the reason why it just logs out.

I tried zsh but it says zsh: error on TTY read: permission denied and then I have no keyboard in wcmd.

mc begin to display itself,then makes disappear the wcmd window, the program doesn't terminate. (??)

10. Self-Registering DLL's

4 Dec 2002 (5 posts) Archive Link: "Registering DLL's"

Topics: Patches

People: Jeff SmithAlexandre JulliardJohn Hohm

Jeff Smith had a question about making DLL's enter their own registry entries:

I was looking at entry C.5 of the 0.9 Todo list: "Make Wine's DLLs register themselves to avoid manual merging of the winedefault.reg [TODO]"

Upon first glance I figured the approach is to (not necissarily in this order): add regsvr32.exe calls in the installation scripts, fill in the DllRegisterServer (and DllUnregisterServer) sections of the appropriate libraries, and remove those entries from winedefault.reg.

About a dozen dll files have their names in winedefault.reg. So I checked the native versions of these files, and only half of them have a DllRegisterServer function. I did some further research and found that perhaps DllInstall was what I needed. Well, that only adds one library, and two have *both* functions.

Does anyone have any better ideas on what the "Right Way" to tackle this item is? I am sure that adding external functions that do not exist in native versions is *not* the way.

Alexandre replied, " Part of it should be done with DllRegisterServer, the rest can be handled by the .inf script. And I think it's OK to add the necessary DllRegisterServer entry points even if the native dll doesn't have them."

John Hohm had already started working on this and said he would start submitting patches:

I'm glad you feel that way. I created bug 1117, "Make all Wine OLE DLLs self-registerable", and have been working on an implementation.

What to do about DLLs like ole32.dll that have a native DllRegisterServer but no corresponding DllUnregisterServer? I'm inclined to include it for completeness, though it's unlikely that anyone would ever want to unregister such a basic system DLL.

I posted my idea for representing the registration data, accidentally from "" rather than my usual "" (see, but I haven't gotten any responses, not even "looks fine" or "you are a moron". I guess I'll just start submitting patches, then.

Alexandre thought a little cleanup was in order and suggested, " I don't really like the ASCII description of the registry keys; I think it would be better to do it at a more symbolic level. For instance you shouldn't hardcode the ASCII form of the CLSID, you should have some kind of "register CLSID" function that takes a CLSID and uses StringFromCLSID or whatever to create the corresponding registry key."

11. Configuring Wine

4 Dec 2002 (2 posts) Archive Link: "Registering DLL's"

Topics: Project Management

People: Alexandre JulliardJeff Smith

One item on the to-do list is to merge configuration into the registry and Dimi was curious what problems could be expected. Alexandre explained, " it basically means making the Wine/Config branch into a normal registry branch. It's more a user interface issue, we need tools to edit it because you don't want to make users dig through system.reg manually."

Dimi also had a question about handling new Wine installations. The idea right now is to write a "wine.inf" script that handles the installation. He wanted to know if there was a facility for actually executing the script if one was written. Alexandre thought most of it was in place, " setupapi should support everything we need for that. The main missing feature is the user interface feedback on the install progress, but we can probably live without that at first."

Jeff Smith provided some links to information describing the process:

For those interested, here are a couple of links relating to the INF file format (1), and the SetupAPI (2). I don't know how complete our implementation is, but it can be found under wine/dlls/setupapi.

12. Direct3D Test Programs

4 Nov 2002 Archive Link:

Topics: Testing

People: Justin ChevrierChristian CostaLionel UlmerTransGaming

Lionel Ulmer and Christian Costa have been banging away at the LGPL'ed Wine's implementation of Direct3D (not to be confused with the work done by TransGaming). Justin Chevrier had a tip for testing:

I've been following the recent work on D3D and decided I would give a couple of benchmarks/demos I had around a go. Pleasantly I found that they actually start up now and display some stuff on screen! Before the recent patches they would fail completely when starting the actual D3D stuff. I'm not sure if you're aware of these programs or not but I figured I would pass on the URLs to you as they might be of help.

This first is a demo called Bleam:

This page has a binary of the demo and source code as well.

The second is an older benchmark/demo called Tirtanium:

The homepage doesnt seem to have the binary anymore so here's a direct link to a mirror:

Both display stuff on screen and will run through to the end with no crashes.

PS. Great work guys!

13. Case of Guiness Offered for Working App

26 Nov 2002 - 29 Nov 2002 (5 posts) Archive Link: "Partial success report: Toshiba 220CDS electronic manual"

People: Dan Kegel

Dan Kegel couldn't get an older program running right and wrote in asking for some help: is an "online manual" for the Toshiba 220CDS laptop. I unzipped it with Linux unzip, then ran its setup and the app itself with Wine20020605-2 from Red Hat 8. Both ran acceptably well, although I did get a few warnings

It was suggested he try a newer version of Wine. (Which, by the way, if you ever want help on wine-devel you might as well start by using the latest and greatest version.) Anyway, he updated to a newer vintage and reported:

OK, I tried the same app with a freshly compiled Wine20021125. The results are no better. The commandline to run the program is

With either version of Wine, clicking around for a while locks the app up. (e.g. clicking on the big red Right Arrow 10-15 times locks it up).

Plus the display artifacts (text being overwritten without being cleared) are still there.

Wow, I'm really striking out running either the 16 bit or 32 bit version of this old app (see my other post today). Both are freely downloadable... I'd gladly buy a case of Guiness for anyone who contributed patches to the Wine tree that got either of these apps running cleanly. I sadly don't have time to do much more than test.

Dan did a little more digging and wrote back with what appeared to be a problem with mmioOpen.







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.