Wine Traffic #162 For 21�Mar�2003

By Brian Vincent

Table Of Contents


This is the 162nd release of the Wine's kernel cousin publication. It's main goal is to keep me from passing out after skiing 4 feet of fresh powder. It serves to inform you of what's going on around Wine (the Un*x windows emulator).

1. News: Wine-20030318

15�Mar�2003�-�21�Mar�2003 (1 post) Archive Link: "News"

Topics: News

People: Alexandre Julliard,�,�News

We've seen CVS commits daily for the past week. Then on Tuesday Alexandre released Wine-20030318:

WHAT'S NEW with Wine-20030318: (see ChangeLog ( for details)

Download, compile, be happy: http ( , ftp #1 ( , ftp #2 ( , ftp #3 (

There's been more CVS commits since it was released including the introduction of a new portability library, mostly a code reorganization so far. The file locking support is a major addition that's been needed for a long time. More on that in the thread below.

2. File Locking

19�Mar�2003�-�20�Mar�2003 (8 posts) Archive Link: "LockFile() and UnlockFile() are working"

Topics: Filesystems

People: Paul McNett,�Tony Lambregts,�,�Mike Robinson

As noted above, Alexandre tossed in file locking at the last minute to Wine-20030318. We recently discussed this back in issue #151 ( . At the time Mike Robinson needed it for MS Access and Paradox database access. After the recent CVS commits, Paul McNett reported early success:

As of yesterday, 3/18/2003, LockFile() and UnlockFile() are now implemented, and seem to be working perfectly on my end, testing with the Visual FoxPro native functions of flock(), rlock(), and unlock().

This resolution will make a ton of business apps based on desktop database software that much closer to working.

Thanks Alexandre for slipping that one in to the 20030318 release! :)

Tony Lambregts was also excited, " Yeah when I saw that I let out a loud WOOHOO, My wife asked me what it was about,.so I had to explain. This is BIG. It seemed to me that there should have been a parade and fireworks involved with this announcement. Oh well... It's still cool... Thanks Alexandre."

3. .NET Success

20�Mar�2003 (2 posts) Archive Link: "Success with Mono"

Topics: Integration

People: Mike Hearn,�,�Dan Kegel

Mike Hearn dropped a note to inform everyone of the status of Mono - Linux's .NET implementation:

I just thought I'd let you know that the mono team have succeeded in resolving their problems with wine and pthread, and here's a screenshot to prove it to you:

I had to jump through quite a few hoops, so I wouldn't bother experimenting until things are better integrated with the main mono tree. It shows a lot of potential for the future however!

Dan Kegel wanted a better explanation of what was needed to make it work, so Mike explained:

Hopefully once it's all integrated work on filling out the SWF class heirarchy will pick up - it would be extremely cool to be able to run Windows .NET apps. There aren't many (any?) in wide circulation at the moment, but that's going to change fast in the next few years.

4. DPRINTF to TRACE Conversion

13�Mar�2003�-�16�Mar�2003 (31 posts) Archive Link: "Re: Oleaut32 Debug Messages"

Topics: Debugging

People: Dimitrie Paun,�Alexandre Julliard,�Tony Lambregts,�

Alexandre and Dimi got into a thread on converting DPRINTF calls to TRACE calls instead. Dimi mentioned:

But since we're at the subject, maybe we could modify the debugging stuff to allow:

If we detect that we're appending, we just have to skip over the class:channel:function preamble (that's trivial, the preamble ends at the first space (' ')).

This way we can eliminate the DPRINTF macro which is rarely used, and thus confusing. Alexandre?

Alexandre replied, " No objection. Something like this should do the trick" and with that he included a small patch.

What exactly does all that mean? Wine prints out several different types of messages. Some of these are familiar to Wine users - FIXME's fall into this category. For more details on the mechanics of DPRINTF, check out the debug.h ( header. Also note, FIXME and ERR messages are enabled by default, whereas TRACE and WARN are not. So by converting DPRINTF calls into TRACE calls it's possible to get them compiled out.

Dimi was pleased with the patch, " There are 767 DPRINTFs, and 736 MESSAGEs. I think DPRINTFs should just die, they are confusing, it's not clear what they output, etc. Your patch is just perfect, as it does the obvious thing the user expects. I think we can just turn most of the DPRINTFs into TRACEs, but we need to do that manually. If we do so, we could probably also simplify the code in certain places, so a manual process is better (in fact, a search & replace is the worse combination, as we'd simply lose track of the places we need to audit)."

Alexandre also cautioned against a simple search and replace, " I agree most of them can be replaced by TRACE, but not all of them. There are cases where we want to dump debug output without the standard header; relay output is the obvious example. So I think a DPRINTF that can be compiled out would still be useful."

Tony Lambregts got involved and posted a small patch. >From there he went on to submit 19 more patches converting various files. Then he announced, " This completes the first stage of DPRINTF->TRACE. There are still a lot of files that use DPRINTF. The following is a list ( of the files I where I did not replace DPRINTF with TRACE along with a breif explanation. I would appreciate any comments on this or any of the patches that I submitted over the last day. " Later he added, " I think that there is still work to be done on this. All I did was a quick sweep with the broom. Some of the stuff that is left will require something more like saws and hammers.<g>."

5. Finding DLL Imports

13�Mar�2003�-�17�Mar�2003 (10 posts) Archive Link: "Determining dll imports in dlls"

Topics: Utilities

People: Brad Campbell,�Francois Gouget,�,�Dmitry Timoshkov

Brad Campbell needed some help determining what DLL's were imported by his app:

I'm using wine in a small control system to run a gui win32 program. I had an idea that I could determine what dll's this program used and only including the files that were required to run this program.

I started by doing a strings on the .exe file and using that to determine which .dlls it referenced. I thought I could use the same process to determine which dll's were then referenced by the dll's the .exe pulled in. Plus including the core dll's by default.

Am I missing something, or will this work ?

I'm in the process of developing a batch file to do it for me, is there a more accurate way of determining which dll's a dll references than doing a text search for dll names in the binary?

Brad further explained that since this is an embedded program he's trying to make it small enough to fit on a flash drive. He knew he would need multimedia type stuff, but wasn't sure of other libraries Wine loads. Francois Gouget suggested using some of Wine's tools to figure it out:

A better way is to run your application with '--debumsg +loaddll'. This will generate a log enumerating all the libraries that your application loads (and also tell you whether it's using the native or builtin version).

Alternately, you can use 'tools/winedump/winedump dump -j imports' on your executable and recursively on each library. But it's more work (however you can use this method on applications that don't work on Wine yet, not your case I guess).

Winedump worked fine on Brad's executable, but he wasn't able to run it on Wine's own DLL's. Since most DLL's import other ones he couldn't determine the minimum ones he needed. Rather than using +loaddll he thought it might be better to just manually check the imports in each DLL makefile. Dmitry Timoshkov offered another alternative: Dependency Walker ( .

6. Completely Broken Test App

19�Mar�2003�-�20�Mar�2003 (2 posts) Archive Link: "shell + listview + imagelist great test program"

Topics: Testing

People: Vitaliy Margolen,�

Sometimes things that don't work are even better than things that do. Vitaliy Margolen reported a damaged program:

I think I struck gold! I found pretty simple yet _RELY_ broken program. Here are screen shots:

It's one of the demo programs from Delphi 5. Source included. To download executable use this link:

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.