Wine Traffic #214 For 12�Mar�2004

By Brian Vincent

Table Of Contents


This is the 214th issue of the Wine Weekly News publication. Its main goal is to eat leftovers. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at (

Mailing List Stats For This Week

We looked at 152 posts in 476K.

There were 52 different contributors. 29 posted more than once. 24 posted last week too.

The top posters of the week were:

1. News: Wine-20040309

6�Mar�2004�-�12�Mar�2004 (1 post) Archive Link: "News"

Topics: News

People: Alexandre Julliard,�,�Eric Pouech,�News

The latest Wine snapshot is available; Alexandre released it on Tuesday:

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

A lot of the stuff that appeared in this release is a direct result of things discussed at this year's WineConf, although some of them have been planned for longer. Alexandre and Eric Pouech have been working extensively on filesystem reorganization and this release has the beginnings of that. Alexandre's work thus far has mostly been focused on cleaning up things and simplifying others. Some of the larger changes proposed by Eric haven't been implemented yet.

Vincent B�ron pointed out that RedHat RPM's wouldn't be available for a few days. Otherwise, go download it ( .

2. Wine As A Shared Library & Mono (con't)

4�Mar�2004�-�9�Mar�2004 (23 posts) Archive Link: "Re: Wine as shared library patch"

Topics: Integration

People: Alexandre Julliard,�Dennis Peter Bartok,�Miguel de Icaza,�Mike Hearn,�,�Peter Bartok,�Boaz Harrosh,�Mono

Earlier this week more discussion went on about supporting Mono with a generic Wine installation. As it is right now, the Mono community has two approaches for implementing Windows.Forms functionality. The first is a community approach using Gtk as the backend. The second approach by the Ximian/Novell guys uses a separate, hacked version of Wine. Obviously it would be much better if they could just tell someone to go download Wine itself; especially because it seems like not too many people need that functionality. Discussion occurred this week in irc (an increasingly more important venue for development). Alexandre suggested they could still use a generic Wine installation by shipping a separate Winelib program as an entry point:

It seems to me that you could simply do a longjmp() out of your WinMain, and then you wouldn't need to modify Wine at all. It would require patching up the TEB a bit (for instance to remove the exception handler chain), but nothing really complicated.

Miguel de Icaza mentioned that WinMain never gets called, which led Alexandre to wonder why. Peter Bartok explained:

Our WinMain doesn't get called because our patch prevents it. If it were to get called, we'd be on a different (Wine-created) stack, with all kinds of things that are hard to undo, like the exception handling, etc.

The goal of my patch was to have minimal impact on Wine, and allow the *same* wine code/binaries to be used for regular use as well as shared library, so any future Wine version you create will automatically also support shared library use.

I modeled the global __wine_shared_lib variable after the __wine_main_argX globals you introduced last year, assuming that following that style would create the least resistance of getting my patch accepted.

Having Wine set up the TEB and stack environment and actually call our WinMain and us then trying to 'undo' that in WinMain creates potential for future breakage of our library, in case you change something related to the TEB & stack. Having a variable in kernel that prevents creation of these, on the other hand, is easy to maintain, and really has no impact on performance or coding.

I will be happy to implement any suggestions you may have on how to solve it another way in a single codebase that doesn't intruce the potential of breaking it in the future. I may very well have overlooked something.

Alexandre still disagreed with that approach, " The TEB & stack layout are dictated by binary compatibility, and are much less likely to change than the Wine init code. It's not clear to me at all that this global variable hack is the right interface for a proper shared library implementation, and I'm not going to commit to supporting that interface in the future. OTOH WinMain and the TEB layout are not going to change, so you should build on top of that. "

Miguel was unsure of the approach and didn't think resources were available to solve the problem:

It still makes the code too hard for us to maintain.

Our patch is simple, and we lack the experience to work on Wine, TEB and what not. We just do not have the time to learn everything there is to Wine.

For now, we will ship a different Wine RPM, and use a different prefix to avoid conflicting or something like that.

About two hours later Alexandre showed them how to do it:

Something along these lines should do the trick:

#include <wine/library.h>
#include <stdio.h>
#include <windows.h>
#include <winternl.h>
#include <setjmp.h>
static jmp_buf jmpbuf;
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)

int SharedWineInit(void)

So, with all of this being self contained, it's not necessary for Wine to do incorporate anything. Boaz Harrosh wondered how general of a solution it is - tons of projects have wanted to utilize proprietary Windows libraries. The general solution right now is to make a Winelib program that does it. Writing a Winelib program is a bit of overhead though. Most people would just like to dynamically load the library and rsuh off to use the API. Boaz Harrosh wondered how general of a solution this was and Mike Hearn replied with some of the deficiencies of the approach:

For the record there are still a ton of unresolved questions that Mono is just choosing to ignore here (because they can). For instance, multithreading won't always work correctly, but as S.W.F is not thread safe this doesn't seem to matter too much. I think stuff like exception handling and so on won't work either. So it really is not a general solution.

Being able to initialize winelib mid-flight is possible but a whole ton of work that very few people understand enough to do (in fact maybe only AJ).

Miguel also wrote back to describe how they plan on using it:

The intention is to have a module that you can dlopen and call a method in there to have Wine initialize itself. After this you can call the API as a library.

Now, this might not be as helpful to others as you might thinkg, unless they dlopen/dlsym every symbol they want to import (this is what we do with Mono: every symbol we need has to be explicitly invoked).

MPlayer sounds like the perfect consumer for this though, and drivers as well.

Mono on CVS (mono and mcs modules) now have the capability of running Windows.Forms applications.

Windows.Forms is basically an API to create GUI applications with .NET and its essentially a wrapper around Win32, hence our strong desire to use Wine as a runtime library.

3. Changes to Wine to Compile MFC

11�Mar�2004 (5 posts) Archive Link: "1/4 patches for compilation of ATL & MFC"

Topics: Winelib

People: Boaz Harrosh,�,�Microsoft,�Unknown

Boaz Harrosh was able to get the Microsoft Foundation Classes to compile with gcc and Wine. Quite a bit of work was involved and he posted patches required by Wine for the process.

Patch 1: (

uuidof.diff - enable use of some ms extensions

include/wine/uuidof.h (new)
Lets GCC compiler use the uuidof MSVC++ extension used in ATL. See comments inside the file
include wine/pretty_com.h (new)
Lets any C++ compiler use the __decelspec( property () ) MSVC++ extension. See comments inside the file
A Perl script that changes __decelspec( property () ) declarations to the proper macros from pretty_com.h. see comments inside the file
include/unknwn.idl (updated)
Adds a C++ only extension to the IUnknown Interface. This is to let ATL compile (use of uuidof.h)

Patch 2: (

ForAtlMfc.diff - some fixes and additional files needed by ATL/MFC

Added some new .idl files, see below
Add the DWebBrowserEvents + the IWebBrowser2 and events
include/expdispid.h (new)
needed by expdisp.idl and ATL code
The font constant will not compile. I think it should also be fixed for c but I can't be sure. It was written like in MS headers, MSVC will compile it, but GCC will not. The way I did it works for both.
include/mshtmhst.idl (new)
other Interfaces related to IE that are not present in expdisp.idl
include/msstkppg.h (new)
some GUIDs used by MFC
include/objsafe.idl (new)
common Interface also used by ATL

Patch 3: (

msvcrt.diff - minor fixes to msvcrt

very much synced with MSVC, needed by MFC
I'm not sure who submitted a broken empty math.h header. Just to show that no one is doing serious winlib work lately, or they are not reporting about it. This header is the one I have for use with STLPort, it will Just #include the standard lib one. If it is not acceptable than at least completely remove the one in now.
Some missing constants for the _setmbcp, used by MFC
Some code was copy pasted from <sys/stat.h> and was protected by an #ifndef. The <sys/stat.h> added some newer definitions that where not added to wchar. This patch removes the old definitions and instead #includes <sys/stat.h>. It is the same way in ms-headers. In fact I had some code that presupposed stat.h included by wchar that would hence not compile under the old version.

Patch 4: (

warning_off.diff - some of these might be controversial but would eliminate 17 tons off warnings when compiling MFC/ATL and user code. I have found (the hard way) that GCC in some cases would produce none working code but will Just warn about it. Having thousands of warnings or turning warning off will eliminate the ability to catch these cases. I have found that most of the trivial warnings can be avoided with a few small tricks. here they are below. (for complete discussion of GCC's bad code please post me)

This one will eliminate 1000 warnings in MFC and any using code The actual issue is definitely a mal-practice in the code of CString. But since MSVC does not care it was never fixed by MS . In effect it does nothing. ( I think code looks better, but that is subjective). It lets me a way to avoid these warnings when compiling MFC with -D_MBCS. (I did not currently managed to compile it with out it. And I did not even get to Unicode). This single patch would be very hard to maintain outside of wine. If any one has other suggestions I would be happy to hear them. for now it is the best I could do.
Lots of offsetof in MFC headers and code. GCC will automatically warn on use of this macro on c++ objects. Regardless if it is right or wrong to do so. (for a complete discussion of this topic just browse to and search for "offsetof"). this patch will eliminate the warning. ( Maybe it is best to keep this patch separate)

Patch 5: (

winegcc.diff - I know I promised 4 but here is a 5th.

include/wine/winegccdef.h (new)
This is an exact replica of what winegcc is doing (extracted from winegcc.c) it is for use by people like me that cannot use winegcc directly. I hope that some day winegcc will just do: "-include wine/winegccdef.h" and save space and time. One addition I have added is an NO_NO_WARNING_MODE option that will eliminate lots off warnings. The default is warning off.
needed missing stuff

4. Vino: A Small Script for Setting Options

12�Mar�2004 (3 posts) Archive Link: "In Vino Veritas!"

Topics: Utilities

People: Mike Hearn,�

A lot of Wine options are being moved into environment variables - DLL overrides have been gone for a while and debug messages are next. Mike Hearn posted a small script to allow changing the options on the commandline easier. If you call the script "vino" as Mike suggested, you can invoke it with "vino +relay ole32=n [program.exe]" for example. The script:

# A wine wrapper script. In Vino Veritas!
# v1.0 (C) Mike Hearn
# Licensed under the GPL
for a in $@; do



if [[ "$WINEDEBUG" != "" ]]; then echo -e "${red}debug channels:${normal} $WINEDEBUG"; fi
if [[ "$WINEDLLOVERRIDES" != "" ]]; then echo -e "${red}dll overrides:${normal} $WINEDLLOVERRIDES"; fi
wine $@

5. Patch Roundup

6�Mar�2004�-�12�Mar�2004 (11 posts) Archive Link: "Patch Roundup"

Topics: News

People: Robert Shearman,�Christian Costa,�Dimitrie Paun,�,�Dimi Paun,�News

A lot of development communication has moved from the wine-devel mailing list to irc on #winehackers. It seems to be working well, however summarizing development is a bit tougher now. This week I thought I'd cover some of the patches that appeared.

Robert Shearman has been doing a lot of work on controls lately. He posted these patches (among others) this week.

Implement Drag List Control: (

This patch adds full support for drag list common controls. There are no known bugs, so as far as I am concerned this is 100% complete compared to ComCtl32 v5.81 and probably v6.0 too.

This patch also adds a new cursor, the copy cursor which is a normal cursor (copied from user32) with a + sign next to it. This is needed as the user can request the control to display this during dragging. I have also fixed the tabs in LBItemFromPt. Don't mix tabs and spaces!

Toolbar: Drawing Code Rewrite: (

This patch makes DrawButton a lot simpler. It splits out the drawing functions into DrawImage which draws the button image, DrawFrame which draws the frame around the button and DrawSepDDArrow which draws the entire separate drop-down arrow. Not only does this make the drawing functions easier to manage, it should also make it easier to add theming code in the future (they are now split up into the same parts as in the themes). We also now properly support the state CDIS_MARKED/BTNS_MARKED. Next on the agenda is to rewrite the button size calculation code, including integrating Dmitry's code.

Toolbar: Improve Button Calculation (

This patch improves the code calculating how big a button should be and where to draw the various parts. It adds support for a toolbar global iListGap parameter (future patches will allow you to set this) and makes the toolbar use padding supplied by applications. It also fixes Internet Explorer's "Go" button and the Media Player sidebar buttons. It is still not identical with the native version, but that doesn't seem to be a problem.

Christian Costa has been working on Direct Show lately and some of the underlying infrastructure.

Add MultiMedia Streams: (

Add amstream dll (MultiMedia Streams), part of Direct Show.

IFilterGraphImpl_EnumFilters and IEnumFilters interface: (

IMediaEventSink and IMediaEventEx interfaces: (

Implemented IMediaEventSink and IMediaEventEx interfaces.

And finally, Dimi Paun has been doing a lot of work on winegcc.

add support for -B prefix: (

Never used -B before, so I don't know if this is how it's supposed to behave. Basically, if a prefix is given, I first look there for the name of the executable. If I find a file that's executable, I run that. If not, I default to the original.

add wine-specific mode: (

Add a wine specific mode. If is activated if the -B prefix ends with /tools/winebuild. If you happen to have such a prefix, but you don't want this behaviour, simply add a trailing '/index.html'. In this special mode, no default Win32 DLLs are linked in, we don't force the short wchar_t, and the standard dirs are not searched.

add support for CC="ccache gcc": (

preserve the relative order of files and libraries: (

Preserve the relative order of files and libraries. We do so by maintaining a unique list of files and lib, each marked with the appropriate metadata.

support winebuild options: (

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.