Wine Traffic Brian Vincent

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).
News 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)

  • Many Direct Sound improvements.
  • File locking support.
  • Progress on kernel/ntdll dll separation.
  • Lots of bug fixes.

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.

Filesystems 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.

Integration 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:

  • You need the files from this post: http://lists.ximian.com/archives/public/mono-winforms-list/2003-March/000129.html
  • Get the mono source, I had to rebuild monostub. For some reason the binaries Alexandre (theirs, not ours ;) built didn't work for me.
  • You need to edit the makefile if you don't install wine to /usr/local. I've put together a small pkg-config file for wine which I might submit at some point, should make this stage more automatic.
  • monostub btw is a WineLib app that embeds the mono interpreter. Because winelib setup has to be done by wine itself at startup, you can't just dlopen the Wine libraries and begin using them. Therefore, you have to embed mono into wine.
  • The runwine script LD_PRELOADs a smalls shlib that is somehow related to the pthread stuff (monowinehooks.so) but I'm not really qualified to talk about that.
  • The SWF class heirarchy is rather stubby, the SWFTest app doesn't work for instance, due to stubs in the .NET code. I used the MenuTest app that was in Alexandres email.
  • You need to have an entry for each DLL used in /etc/mono/config to map them, or do as I did and symlink kernel32.dll.so to libkernel32.dll.so and so on for each library.
  • The pthread issue was, as discussed earlier on wine-devel, due to the fact that mono had to use Wines implementation of pthreads so Wine could keep track of them and do housekeeping. Mono now has some implementations of these functions, but I'm not sure if/when Alexandre will send them to wine-patches, the impression I got was that they were a bit hackish. Hopefully they'll be cleaned up and submitted soon though.
  • You need a special version of the garbage collector (libgc).

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.

Debugging

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:

    TRACE("you ");
    TRACE("can ");
    TRACE("do ");
    TRACE("this\n");

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>.

Utilities 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 wine.dll.so 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.

Testing

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: