Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #110 For 11�Dec�2001

By Brian Vincent

Table Of Contents


This is the 110th 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 139 posts in 508K.

There were 57 different contributors. 23 posted more than once. 27 posted last week too.

The top posters of the week were:

1. Wine, Office, and the Antitrust Settlement

9�Dec�2001 (8 posts) Archive Link: "Wine, Office, and the antitrust settlement"

People: Dan Kegel,�Jeremy White,�Patrik Stridvall,�Andreas Mohr,�CodeWeavers,�,�Transgaming,�Patrik Stridval,�Codeweavers

I haven't read much on the antitrust settlement the states are trying to reach. Frankly, most of the coverage has been rather academic and inconclusive. But Dan Kegel took the time to dig through some of the challenges that face the open source community and ways to reach a common ground. He posted the following message to wine-devel:

I'm proposing that Wine be part of the settlement of the Microsoft antitrust trial. See Comments welcome.

I have a few questions for Wine developers, especially the good folks at Codeweavers and Transgaming:

  1. How much would it cost to achieve full support for Office 2000 in Wine?
  2. Is it true that Office uses undocumented Windows APIs? If so, how many? Are they a significant part of the challenge of supporting Office?

I highly recommend clicking on the link and perusing through some of the points Dan brings up. Jeremy White replied with some concerns:

I read your remedy proposal; nice work.

I obviously like your proposal (hire CodeWeavers to port Office, great idea! <grin>). I'm skeptical that this proposal will be accepted, and I also feel a bit uncomfortable advocating it as it clearly benefits organizations like mine, and doesn't so clearly benefit the Wine community.

However, to answer your question, if you value time (i.e. assume people get paid market wages, as opposed to donate their time), a reasonable off the cuff guess for MS Office support (to make it *really* work) is probably on the order of $1-2M or so.

Please note, that's largely a guess, and includes a large fudge factor because it's unclear how much work Office XP is going to require (AFAIK, no one has brought it up in Wine yet).

We could probably reduce the cost and effort if we had engineers at MS actively helping us (so we weren't always fighting up hill).

As far as undocumented APIs in Office, I know of only one used in Office 2000 (of course, the problem with undocumented APIs is that there may be many more we're ignorant of).

Finally, I think my largest concern with Wine is in securing protection from Microsoft patents.

I've lost some large sales because Mainsoft sales people use patent FUD successfully on my potential customers.

Further, it is unclear whether or not open source projects such as Samba, Mono, and Wine are going to be permitted to play in the post .NET world. My greatest fear is that MS will be able to take some legal action that will prevent Wine from supporting any .net enabled application.

IANAL, so I have not idea as to the full extent of the threat from MS or what a potential remedy would look like, but IMHO, that's a more significant issue than others we've faced.

Patrik Stridvall had some thoughts as well:

What is perhaps more realistic to require IMHO that Office and other Microsoft applications shouldn't crash or behave in a inconsistant way just because some odd feature in some API call is not available. Instead it should say, sorry can't do that not supported in the OS.

This would prevent Microsoft from sabotaging Wine as well preventing users of say Windows 95 from needlessly having to upgrade.

Yes, I'm aware of that Microsoft of course not can check every API call and have a fallback for each function, but groups of features that is potentially unneeded for basic features in Office like:

  1. DirectX
  2. MAPI
  3. .NET
  4. DAO
  5. "Sound"
  6. "Networking"
  7. <Insert whatever favorite technology from Microsoft that you like>
shouldn't be required to do normal stuff in Office.

In response to Dan's question about undocumented calls, Andreas Mohr suggested:

Well, I'd say SETUPAPI/SETUPX and SHLWAPI are certainly everything but documented... There do exist some header file defines for some stuff, but that's about it. My guess is that we could come up with a list of at least 10 DLLs that are rather badly documented (some even with some malicious intent, I'd say). OTOH I'm not sure whether we should try to play some role in that settlement. After all we're probably not too visible to Microsoft right now, and we're coming along rather nicely. Which would probably change rather fast once we make our public voice get heard...

We really should make up our mind NOW on whether we want to take part or not, though.

2. OSS Fixes

9�Dec�2001�-�10�Dec�2001 (8 posts) Archive Link: "OSS fixes"

People: Eric Pouech,�Duane Clark,�Michael Stefaniuc,�Gerard Patel,�

There have been some audio shake-ups for the past month. A few different patches have been thrown around. Eric Pouech submitted a new patch to audio.c and asked, " could the people who had issues with the latest OSS patch(es) test if this one fixes all their issues ?"

Duane Clark replied a few minutes later and reported, " This patch causes both Riven and Myst to immediately freeze for me, and no sound at all. Without the patch, the sound in Myst works pretty good (occasional brief dropouts). In Riven without the patch, only the opening sequence has sound, and that has many large dropouts. I'm using ALSA drivers in Redhat." Eric asked for a debugging trace which Duane provided.

The next day Eric submitted another version of the patch and it was greeted enthusiatically by everyone. Duane wrote back, " That one works great. Both Myst and Riven work, and for the first time in Riven all the sound works. There is slight bit of static in the sound, though part of that might be cheap sound hardware (onboard VIA 82C686A - which never gives particularly good sound)." Michael Stefaniuc mentioned, " Tested it with Quicktime and sound works now flawlessly. Good work." And Gerard Patel's test suite seemed happy too, " I have only one serious issue, and it's fixed by your patch."

Excellent work!

3. SHLWAPI Additions

3�Dec�2001�-�5�Dec�2001 (8 posts) Archive Link: "SHLWAPI pre-submit questions"

People: Jon Griffiths,�Alexandre Julliard,�Guy Albertelli,�,�Guy Alberte

Jon Griffiths wrote in to say he's been working on some improvements to the SHLWAPI dll. SHLWAPI is the Shell Lightweight API used for all kinds of tasks such as finding paths and

I've been hacking on SHLWAPI.dll for a couple of months now while holidaying around Thailand, using a beaten up laptop. Since I just obtained free use of a real machine with a good net connection, I want to start submitting my work but I thought I'd clear up a few style issues beforehand:

  1. Is it OK to give meaningful names to undocumented functions?
    e.g. SHLWAPI_1/2 => UrlGetInfoA/W
    SHLWAPI_5/6 => PathFindOnPathExA/W

    I want to do this where the names are no-brainers, as in the case above, and the functions are referenced by the dll internally.
  2. Is it OK to sync shlwapi.h with the windows version ?
    e.g. Remove undocumented entries, Remove its dependence on obj_base.h (windows has none), Add the function exclusion defines as per windows

    I assume this is fine, but doing this causes the next question -
  3. How to deal with shared undocumented functions?
    e.g. StrRetToBufA/W is used by shell32, but should not defined in shlwapi.h.

    Here there are 4 Choices:
    1. Define twice (Ugly)
    2. Put into a new wine/undocshlwapi.h (Seems that these are depreciated?)
    3. Define anyway (Im not a fan of having undoc functions in public headers)
    4. Have shell32 functions #include "../shlwapi/internal.h" (A little unclean)

    I'd like to go for 4, any objections?

I'll start feeding in the new function implementations over the next little while, once the structure is sorted.

There were a lot of different opinions for each of the points. For the first point, Alexandre suggested, " No, this will cause major confusion. What you can do is create a SHLWAPI_UrlGetInfo internal function that is called both by SHLWAPI_1 and by other functions that need it."

Guy Albertelli has been hacking on SHLWAPI for a while and had some suggestions. As far as syncing up the headers, Guy thought, " Be careful here, some of the entries took a long time to find since it is not that they are undocumented, but just not well documented (in fact I only found some of the #defines in Borlands lastest bcc)." Guy also felt it would be a good thing to remove the dependence on obj_base.h. There were other suggestions for how to deal with the shared undocumented functions, Guy's take on it was, " I created "shlwapi/ordinal.h" for that very purpose (since ordinal.c has the "undocumented" routines) and defined the structures for _1 and _2 in it. Note that _1 and _2 are used by other parts of shlwapi."

Jon wrote back with game plan:

Thanks for your prompt responses. Based on your feedback I'll:

  1. Create internal functions with meaningful names and call them when ordinal calls are used within the DLL (A plus to this is that the ordinal functions can stay in ordinal.c, and the implementation can go into the appropriate file, eg. path.c).
  2. Make shlwapi.h correspond to its windows cousin, except that:
    • Any functions exported by name get defined too, along with structures needed to call them (I think we should wrap these in "#if defined (__WINE__) || defined (SHLWAPI_UNDOC)", but that can wait).
    • All ordinal functions get defined in shlwapi/ordinal.h
    • Internal functions go into shlwapi/ordinal.h too.

There shouldn't be any conflicts with Guys work: my tree is so out of date I have to adapt everything anyway, so I'll make the changes as non-gratuitous as possible. The first patch only might be a little large due to the header re-org.

Header patches coming first, followed by code in managable chunks. I've been dying to get this code out in case someone nicks my laptop or it blows up (its 7 years old, the poor thing)...

4. InstallShield 6 Patches

8�Dec�2001�-�9�Dec�2001 (4 posts) Archive Link: "Installshield 6 (inter-proc) patches"

People: James Brown,�Alexandre Julliard,�Gavriel State,�,�Transgaming,�Ove K�ven

Transgaming has done a lot of work on getting InstallShield 6 installers to work under Wine and Ove K�ven's work can be found in the WineX code on SourceForge. So James Brown was wondering, " Any idea when Oves interprocess patches will be put into the main Wine CVS tree? The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support." .

Alexandre responded, " It could certainly be applied, even if it's not 100% clean it will always be better than not supporting InstallShield at all, as long as it doesn't break other things. However I cannot apply anything that hasn't been submitted to me under the Wine license, so for more information you'll have to ask Transgaming."

Gavriel State from Transgaming also replied to James to say, " There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." Which prompted Alexandre to write:

Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all.

If you can't/don't want to release your code, I'd strongly suggest that you reconsider your strategy of making it publicly available. If it was only available to paying customers, there would at least be a reason for other people to work on a free implementation. But if everybody who needs some feature in Wine can simply download WineX instead, no one will spend time re-implementing that feature. This is beginning to seriously hurt the project, and we need to find a way to address this issue.

5. UNC Patch

4�Dec�2001�-�10�Dec�2001 (22 posts) Archive Link: "Re:UNC patch"

People: Dan Kegel,�Gavriel State,�Alexandre Julliard,�Bill Medlands,�Robert Lunnon,�,�Bill Medland,�Eric Pouech,�Stefan Leichter

Stefan Leichter submitted a patch that would allow UNC paths to work under Wine. Namely, if a Windows program was searching for something like f:\x Wine would be intelligent enough to look through the mounted filesystems (in particular remote filesystems) and come up with answer. Dan Kegel's original suggestion for doing this suggested the following process:

Given a UNC path \\foo\bar,

Namely, this would allow the UNC path \\windows-server\x to show up as f:\x if it was mounted. In turn, that can be determined if smbfs is being used to mount a filesystem. Eric Pouech suggested making this configurable, such as whether or not to enable it on a per host basis. The thread quickly turned to what depth of configurability to offer. On the one hand, if a smbfs filesystem is mounted why not just use it? Alexandre also mentioned that it might not even be worth parsing /etc/mtab and just create the drive mappings in the wine config file. Gavriel State wrote in to say:

One of the problems we've come across recently is this: for games that use copy protection, we need to have direct access to the device that a CD-ROM drive uses. For the moment, this relys on the user to manually configure their drive letters. From what we've seen, doing so is beyond the ken of many of our users.

As such, we've put together a scheme for parsing /etc/fstab on startup (not mtab: the drive may not be mounted), and automatically adding drive letters for each iso9660 filesystem listed. The patch (to the WineX tree) is here:

We're happy to contribute this in our next outward merge if people think it's useful.

Alexandre wrote, " It's clear that the current mechanism is not very user-friendly nor very flexible. The first thing to do would be to make it possible to change drive mappings at run-time, and then have them integrated as much as possible with the Unix environment, detecting all local filesystems, partition types, media changes, possibly even calling mount/umount from Wine, etc."

Bill Medlands thoughts were:

Like Dan I initially considered the idea of equating the samba mount point with a drive and using the drive. However that is a hack; Windows doesn't require a UNC to equate to a drive. Therefore whatever is done needs to involve extending the "equate a DOS filename to a unix filename" functionality.

There is one further consideration; equating Samba and nfs (and that would possibly require something in the config file as suggested by Eric). The complication is byte locking (which I know we don't do yet but maybe one day soon we will). The complication is that although nfs does handle it to the best of my knowledge smbfs doesn't (and isn't smbfs unavailable on any unix other than Linux?). Therefore to do locking we would need to equate a UNC to a mount point that was actually supported through nfs or some other mechanism (I presume smb and nfs are not the only options).

And speaking of things other than smbfs, Bob Lunnon was against making the patch so linux-centric, " On Solaris fstab is vfstab, and mtab is mnttab, parsing these files is no good unless it is done in some portable way. (Not that smbfs even works on Solaris) I would think that persistent share selection should be saved in the registry and accessed through smbclient rather than smbfs, then smb shares would work for all OSs supporting Samba, not just those supporting smbfs."

6. Using a FAT32 Filesystem

1�Dec�2001�-�2�Dec�2001 (6 posts) Archive Link: "Win XP installation support?"

People: Hetz Ben-Hamo,�,�Gerard Patel,�Lawson Whitney

Hetz Ben-Hamo had a problem accessing his Windows partition, " I have installed wine cvs and I have here on this machine Windows XP pro - the partition is fat32 and I can access it with /mnt/win without any problem. However, the tools/wineinstall script simply doesn't recognize my windows partition" .

Lawson Whitney suggested going into /etc/fstab and taking a look at where it mounts the Windows partition. He suggested changing the filesystem type from "auto" to "vfat". Hetz replied that he had already done that. Gerard Patel submitted a tiny patch to wineconf and wondered if it fixed the problem. Hetz announced, " Yes, that helps, could you commit it to the CVS please?"

7. Async I/O Patch

3�Dec�2001 (2 posts) Archive Link: "[RFC] Async I/O patch: server code + ReadFileEx()"

People: Martin Wilck,�Mike McCormack,�

Martin Wilck announced some fixes for async I/O problems that have been discussed before:

here is a patch that fixes some of the issues with the async IO implementation in Wine that we discussed previously. My work on this was delayed by other duties, sorry. To make matters worse, I'll be out of office for the next 4 weeks (vacation :-)

I am submitting it as a RFC to show the basic concepts I am aiming at. Most important is the server-side code (server/async.h, server/async.c) that demonstrates the basic mechanism I am suggesting.

As an example, I recoded ReadFileEx() to use the new approach. Basic testing with disk file I/O works as expected. The code no longer messes up the order of requests.

Please have a look at this code and tell me if you consider it a reasonable basis for further development.

Mike McCormack replied:

i hadn't heard from you in a while, so i though you might have given up after nobody said anything about the last patch, but i see you've been busy :-)

i also had a go at fixing the problems you pointed out. i've attached the patch i've been working on... don't use it, it _will_ crash your wineserver! i need to create a requeue async request like yours, and activate my queues properly. The code is written to support async on serial port objects, not file objects.

8. FoxPro 5 Success

28�Nov�2001 (1 post) Archive Link: "FoxPro 5 Applications"

People: Rick Romero,�

Rick Romero reported:

I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens.

It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview.

Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed.

Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime)

BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked.

I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same.

I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k.

If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP.

I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction?

9. Merry Christmas!

4�Dec�2001 (1 post) Archive Link: "Happy Christmas wine"

People: Russell Howe,�

Russell Howe posted a link:

I got sent a Christmas card in Windows EXE format. Since it works perfectly with wine I thought I'd share it :)

The file is at

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.