Wine Traffic #151 For 3�Jan�2003

By Brian Vincent

Table Of Contents


This is the 151th 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 196 posts in 796K.

There were 48 different contributors. 26 posted more than once. 15 posted last week too.

The top posters of the week were:

1. Visual-MinGW Under Winelib

31�Dec�2002�-�2�Jan�2002 (7 posts) Archive Link: "Visual-MinGW: Winelib patch"

Topics: Status Updates

People: Visual-MinGW,�Dimitrie Paun,�Manu,�

Dimi collected some various changes necessary to compile Visual-MinGW under Wine and submitted them to the maintainer, Manu. If you're not familiar with Visual-MinGW, here's the description from their web page:

The aim of this project is to provide an Integrated Development Environment for MinGW compiler. (Minimalist GNU for Windows)

Development started during July 2001 with following goals :

  1. Provide a "Minimalist" Open Source IDE, developed with nothing more than itself and built with MinGW compiler.
  2. Make it as small and fast as possible, using only Windows APIs.
  3. Make it easy to use for beginners and as powerful as possible for advanced users.
  4. Specialize one module of its code for simple and reusable C++ objects that will provide ready to use application skeletons. A quickly way to create a dialog box, SDI or MDI based project.
  5. Provide simple, but original features like creating archives, copying these to a floppy disk or uploading to a server in a few mouse clicks. Make use and promote Open Source command line tools.

Dimi described his modifications necessary to work under Winelib:

I got around getting Visual-MinGW to compile under Winelib. This patch touches only your makefile, and I hope the changes are not controversial:

Please apply this patch with 'patch -p1 < winelib.diff'.

Note that I still need to get some changes integrated into the official Wine tree before you can actually compile Visual-MinGW under Winelib. The changes are not controversial, and I hope to get them in real soon. I will let you know when that happens.

Regardless, I think the changes I'm proposing are logical in and of themselves, so I figured they can be integrated regardless.

The two discussed the specifics of the changes, most of which weren't too controversial. However Manu wanted the changes to reside in a different file:

makefiles are generated by Visual-MinGW, so I suggest to add dedicated makefiles for Winelib. eg: "".

That way, makefiles for Winelib won't be overwritten by Visual-MinGW, and it will be more convenient to do some changes in these.

Dimi really didn't like that idea though, " As for "cvs add", it's clearly not the way to go. Since the makefiles are generated, we need to support things in the code that generates them, so that _all_ projects benefit from it. I will not track all the rapid changes manually to a file, that's for sure."

As of press time that hasn't been resolved, but it's more of a semantics issue than a technical one.

2. Separating NTDLL and Kernel32

2�Jan�2002 (1 post) Archive Link: "ntdll / kernel32"

Topics: Patches

People: Eric Pouech,�

I really hate covering messages sent to wine-patches. It sets a dangerous precedent for not commenting on someone's interesting patch. Fortunately a lot of the time a patch will generate discussion on wine-devel and it makes for something interesting to read. This week Eric Pouech sent a large patch with the note below. This gets at the core architecture of Wine and is the start of something that's been needed for quite some time:

this patch starts splitting code between ntdll and kernel32:

however, it doesn't move the code to kernel32 (there are still quite a few pending dependancies)

since I'm not sure Alexandre will apply it right away (it seems his mailbox is ready to explode ;-)), please give it a try (I've been using it for a few days without noticable glitches, but since it tackles wine at heart, heavy testing would be better)

for the ones of you who would like to go further with it, I put #define (_NTSYSTEM_ and _KERNEL32_ to mark where the functions belong to) The final scheme should be (even if it's not achievable today):

what's still missing:

3. Best Win32 API Spy Tool?

1�Jan�2002�-�2�Jan�2002 (8 posts) Archive Link: "FAQ: best win32 api spy tool?"

Topics: Debugging

People: Dan Kegel,�Duane Clark,�Jeremy White,�Dmitry Timoshkov,�Thomas Wickline,�

Dan Kegel wanted some help finding a tool to help with debugging:

I'm trying to figure out why an app works on Windows but not Wine, and it'd sure be nice to be able to log all the api calls the app makes under each of the two environments; then perhaps I could compare the logs to see where Wine differed from Windows.

Does anyone else do stuff like that? If so, what tools do you use? ( says that the best tool out there is ( (Supposedly the author will send source to you on request, too.) That program requires a text file containing the prototype for each API you want to spy on, though, and it only comes with 3 APIs as an example. Does anyone have a full version of that file, or a perl script to create it from the wine tree?

I suppose I could write my own, too, if that's the only way to get a tool that works well in both environments. ( seems to have lots of info on that.

Duane Clark replied first and suggested, " You had previously mentioned having a copy of msvc. Did you check in it for SPY++? I would have to say that it seems to work quite well under Wine. " Dan didn't think that would work since it only seemed to log window messages rather than actual API calls.

Jeremy White felt it was an interesting subject and gave his views on it:

We've looked into this extensively; looking at both flavors of apispy (yes, there are two of them, with very similar names), and a lot of other variations.

However, I've got a half baked W2K based solution similar to the Detours library from Microsoft. The advantage to my approach is that it generates a relay log identical to that of Wine, which then allows for diffing the log files.

*I* think it would be wicked cool. Sadly, most of the Wine gurus I work with just shake their head and smile whenever I suggest it deserves priority.

Dmitry Timoshkov had a similar idea:

Debugging Tools for Windows ( has logger.exe/logviewer.exe which help a lot in investigating what actually windows applications do. Logger creates binary log files which logviewer is able to parse/view. Even there is a mechanism to extend the logging facility by simply editing a .h like files.

Logviewer is able to show all the API arguments, various data structures, API results and more. It can export log into the plain text file, which could be diffed against another one. I would say that log file is *very* similar to the Wine relay log. Just give it a try.

Tom Wickline had some suggestions too:

You could look at :

For hooks : (

4. File Locking in Wine

28�Dec�2002�-�31�Dec�2002 (4 posts) Archive Link: "File locking ... need info"

Topics: Filesystems

People: Mike Robinson,�Bill Medland,�Dan Kegel,�Alexandre Julliard,�

Mike Robinson asked for help with file locking:

I am interested in support for file-locking and locking of specified regions of a file, in order to support databases such as MS-Access and Paradox.

But as I ponder the various likely-looking segments of the source-code, I really do not know where to begin ... nor what has been done in this area before.

It is clear that an implementation of locking must work on SMB-shares and that it should "actually lock things" in that other Windows users should see the locks as they are placed and removed. It's also clear that implementing timeouts on these locks could be "problematic," since the Unix impl. of file locking is not quite the same as Windows expects.

Pointers? Comments? War-stories? Advice? "Someone already did that"s?

Bill Medland shed a little light on the subject:

Basically much of it has been done before but hasn't made it to the CVS. Way back, Alexandre Julliard implemented it in the Corel source tree. Back in November 2001 I tried reworking the code to fit into the current tree and submitted it (with a few bugs I am sure) but it was not accepted. Alexandre had it on his list of things to do but I don't know where it stands currently.

If you do intend working on it then you are going to have to address some of the following issues:

  1. Windows region locking has different behaviour with regard to merging regions etc. than Unix.
  2. Remember that fcntl locks are on the actual file, not on the handle; and closing one handle drops all the locks on all other handles to the same file. (I am being almost criminally lax with my wording here but it will do for now).
  3. The timeouts are going to be an interesting task. However the structure of the wine server should help immensely
  4. To the best of my knowledge SMB file systems don't handle it. No one has yet told me differenly on the several occasions I have tried to ask. (I know that Samba serves out locks to Windows machines successfully but if you put an fcntl lock on a file on a SMB share to the best of my knowledge it doesn't translate to an SMB lock request).
  5. The whole issue of advisory and mandatory locking.

Our software depends quite significantly on region locking but we don't need the full semantics and we can make guarantees such as only one handle open on a file by a process so what we have done is to use winelib and create builtin dlls for our own ones but that use the native fcntl locking.

Dan Kegel had some experience on with the subject too and replied:

Ah, yes, file locking. I was one of the folks who advised Sun as they were bringing file locking to Java (in "JSR-51"), and we had some fun discussions about how to define file locking in Java so it would map properly onto either Windows or Unix.

One thing I recall is that W. Richard Stevens has a nice discussion of Unix locking in chapter 12 of "Advanced Programming in the Unix environment", published 1993. It aged fairly well, I think, and provides a bit of insight into how locking evolved -- and some problems with mandatory locking (e.g. mandatory locking didn't prevent ed from editing a file!) Note that mandatory locking is not part of Posix ( ( ).

JSR-51 decided to map Java file locks to mandatory locks on Windows, and advisory locks on Unix. I'm afraid that's about the only real option.

Mike thought it was interesting, but still wanted a solution to the problem:

It sounds to me like the file-locking code I am looking for has "already been done" and/or "was rejected" at some time in the past.

I'm probably not the best qualified to do this if it has already been done.

But in order to run databases on Wine, I need it.

5. Winemaker Problems (and Solutions)

1�Jan�2003�-�2�Jan�2003 (9 posts) Archive Link: "winemaker problem"

Topics: Winelib

People: Hans Christian Studt,�Jeff Smith,�,�Sylvain Petreolle

Hans Christian Studt ran into some problems using winemaker. The first problem was with the Wine resource compiler:

I am trying to follow this discription on how to compile win32 source code with the winelib ( ( )

The process generates a Makefile that is supposed to complie a ressource file e.g. winemine.rc with the wrc compiler, but winemaker adds a '-L' option to the wrc compilwr that is does not recognize.

I am using wine-20021219 on RedHat 8.0.

It seems like a bug in winemaker.

I have changed this line in the Makefile

and it compiles.

Sylvain Petreolle recommended trying with the latest CVS version that fixes this. The second problem Hans ran into involved the naming of the Winelib executable:

(/user/usr/local/wine/programs/winemine-hcs) #./winemine-hcs
/usr/local/bin/wine: cannot find 'winemine-hcs.exe'

It still cannot find 'winemine-hcs.exe'. What seems to comes nearest is

I sure hope someone can help out - because I plan to try to see if I can make some of those 7.000 win32 applications over at compile under winelib.

Jeff Smith confirmed this was a known bug that he was working on:

Currently is being created rather than The patch I submitted a few hours ago (don't know if it has made it through yet) includes a fix for this.

Copying the file is actually what I did for several weeks, rather than dig in to winemaker to fix the problem. But I get fed up and started putting together a patch for this several days ago. So now it is ready to roll. Good timing, yes?

Jeff's patch appeared on wine-patches a few hours later.

6. Special Characters in Resource Names

2�Jan�2003 (5 posts) Archive Link: "RFH: ICON statement"

Topics: Patches

People: Dimitrie Paun,�Mehmet Yasar,�,�Visual-MinGW

Dimi wanted to know how Windows handled resource names:

Visual-MinGW uses the following:

which apparently windres accepts, but fails with wrc because of the '-' in 'visual-mingw'. Can someone please check if it works with the MS tools, to determine if we need to fix wrc? Tnx.

Mehmet Yasar said it should work,
I'm developing a small app with MS tools and I know that MS accepts '-' and '!' for ressources (icon, bitmap, accels, menus ...).
Dimi wanted to know if that meant the special characters could appear anywhere in the name, including the beginning. Mehmet checked and found:

I knew that strings like "x-x!xx" were accepted.

I just tested icon ressource beginning with weird characters like "!icon" or "-icon" and that works (tested under VC++/sp5).

Dimi sent in a patch then to change wrc.

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.