Wine Traffic #79 For 22�Jan�2001

By Eric Pouech

Table Of Contents


This is the 79th 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 109 posts in 370K.

There were 39 different contributors. 23 posted more than once. 22 posted last week too.

The top posters of the week were:

1. Porting to BeOS

11�Jan�2001�-�17�Jan�2001 (7 posts) Archive Link: "Interest in a BeOS port"

People: Doug Clement,�Michael Cohen,�,�Francois Gouget,�Patrik Stridvall

Michael Cohen made an old issue resurface. He asked if some effort was made to let Wine work on BeOS.

Francois Gouget pointed out to some information on the BeWine project:

This subject had already been covered in previous articles ( BROKEN KCREF and BROKEN KCREF).

However, this effort stopped almost two years ago. Patrik Stridvall explained the biggest difficulties that couldn't be solved:

Doug Clement (who was leading the effort at that time) also answered:
Last voice from the list was that we're waiting on BONE, for some features relating to sockets. To be honest, I've about given up on Be since it's taken so long to get BONE out, and I'm completely out of the loop now. I'll happily keep the web site up for whoever wants to use it, though. Make sure you start with the latest patch we have..

Michael Cohen tried to start up some discussion on helping with the relocation bits:
I had an idea contemplating the PPC port and I have some preliminary patches for 20001222 that might affect wine in general. I was considering one day that a sort of pre-interpretation system could be implemented, where the entire application is analyzed quickly and then modified as it is loaded into memory to suit the particular architecture's needs. I've not seen much in this way discussed on this mailing list, and I have also not received much input, be it positive or negative, as far as this idea is concerned.

As I have seen it, the developers of wine have put an immense amount of effort into understanding MFC and the various quirks of such a horrible but extensively (almost universally :-( ) used operating system set as windows is, but I am surprised that the modularization to bring wine to other systems is not as big of a focus as I thought it would be upon first taking interest in wine. Wine has come a long way, but it still needs a bit of polishing before it can become a truly excellent app.

There was no response.

2. Porting to S/390

17�Jan�2001 (3 posts) Archive Link: "Wine for LINUX on S390"

People: Jim ___doe,�Ulrich Weigand,�,�Francois Gouget

Jim (without a last name but with an email address' domain at asked:
has anyone tried to port Wine to run on LINUX on an IBM mainframe? We are running several LINUX virtual servers of different distributions and would like to try running WINE. So far when I run the /tools/wineinstall I get the error that I must add my CPU CONTEXT to WINNT.H.

Francois Gouget said that, for the time being, it was not possible to run Wine on S/390, but it could be possible to run Winelib applications, as long as the basic support was put in (like the CPU context handling...).

Ulrich Weigand started putting his hands into it:
While I just did a quick hack, I got at least WineMine running. Now that Winelib is a bit cleaned up (Sparc runs out of the box), it would probably be not too difficult to properly implement S/390 support, or in fact support for any 32-bit architecture (64-bit is an entirely different story).

I didn't pursue it further because I wasn't sure there's really anybody interested in running Wine on S/390. But if you'd like to try it, I could certainly contribute the arch-specific patches.

[ B.t.w. I'm now working for IBM on the Linux for S/390 port. That's why I am quite familiar with the architecture ... ;-) ]

3. Unicode and Winelib

16�Jan�2001�-�18�Jan�2001 (11 posts) Archive Link: "Winelib + Unicode"

People: Jonathonm Griffiths,�Francois Gouget,�,�Jon Griffiths

Jon Griffiths, still working on MSVCRT DLL, was trying to make VWCL ( working on Wine (as a strong user of the MSVCRT DLL). He needed to have a way to define Unicode string even when the Winelib program (using VWCL) was compiled as a ASCII one.

However, the standard way of using the L prefix on string fails: L"foo" is compiled by gcc as a 32 bit Unicode string, whereas a Windows compiler would generate a 16 bit Unicode string (see BROKEN KCREF on UTF-16 and UTF-32). Jon looked for ways of defining UTF-16 properly from Winelib code.

Francois Gouget suggested two solutions:

Jon went further and was upset with the use of -fshort-wchar flag in combination with standard gcc libc:
Actually, having said that, have you tested -fshort-wchar? does it require libc to be rebuilt? or just to build with a different set of headers (i.e. lib funcs still cannot be used)? My assumption is that it just changes the behavior of L"foo", and doesn't address the crt issues at all.

Francois replied:
That's right, it does not address the crt issues at all. Actually it helps a little in that you can use the standard C library headers (e.g. to get wcslen) and then link with crtdll or msvcrt.

But the libc C still expects 4byte Unicode chars and I don't expect this to change anytime soon. It would require two implementations of each Unicode function which means two versions of the library.

Jon continued with:
I think this sounds the end of the idea of the 3 crt scenarios (ms/libc/mixed) that were discussed before, for all but the most trivial apps. What is left is ms and mixed, where mixed still uses modified headers but uses the ignore directive in the apps .spec file to link to the libc implementation where desired (and where not already specified in msvcrt.spec).

For more details on the matter, you can look at old articles: (BROKEN KCREF, BROKEN KCREF, BROKEN KCREF)

Francois was less pessimistic, at least on the impact of this Unicode matter:
I think that there are many Windows applications that don't really care about Unicode. These should not have too much trouble with the native C headers.

Anyway, the final scenarios for MSVCRT are still open, but, with time going by, it seems the number of options is decreasing and the full native header might be the final solution (just a feeling that might start growing).

4. DirectDraw reorganization (cont'd)

16�Jan�2001�-�17�Jan�2001 (6 posts) Archive Link: "Reenable DXGrab"

People: Ove Kaaven,�Alexandre Julliard,�

Continuing after last week article (BROKEN KCREF), Ove Kaaven got a look at the DDK for the DirectDraw/3D interfaces:
It seems that whoever designed DirectDraw/3D weren't the same guys that designed DirectSound. There isn't exactly a COM interface, rather the HAL interface is a range of C structures and callbacks (although GUIDs and vtables seem to be referenced here and there).

(As a reminder, the DirectSound driver interface is in fact another COM object. Here, the interface is merely a couple of C structures with function pointers).

Alexandre Julliard reiterated his approach on adding/deriving Microsoft interfaces in Wine:
If the interface is reasonably sane (at least by Microsoft standards, so it's not a strong constraint ;-) and it allows doing everything we need, then yes, it's better to use an existing interface than defining our own. OTOH if we need to add our own private interface on top of this one then it's probably not worth the trouble.

Ove felt like 99% of the job can be done with the standard interface, but 1% would require Wine specific flags.

Alexandre went on:
A few extra flags are not really a problem, there are some precedents already (like the Wine-specific WS_EX_* window style bits). This should of course be avoided as much as possible, but as long as the basic meaning of the interface is preserved, adding a few small extensions is acceptable.

This should now be the end of the thread.

5. WebBrowser DLLs (cont'd)

17�Jan�2001 (1 post) Archive Link: "Initial stubbing of shdocvw.dll (IWebBrowser)"

People: Yoram Grahame,�

Yoram (Yoz) Grahame, while reading last week issue, posted a follow up on BROKEN KCREF regarding the COM object for web browsing:
Just saw the bit in WWN about Mozilla and IWebBrowser, and thought I'd better tell you guys that a lot of this work's been done already: (

6. Documentation access

18�Jan�2001�-�21�Jan�2001 (13 posts) Archive Link: "documentation patch"

People: Uwe Bonnes,�Alexandre Julliard,�,�John R Sheets,�Jeremy White

After a patch was submitted to update the .sgml contents in the documentation directory, Uwe Bonnes started complaining:
our development package now doesn't contain any more readable formatted files in documentation. So it gets harder to point posters in c.e.m.w to those files...

What about adding a directory with formatted documentation? This would require Alexandre to run a make in the documentation directory after patches to the documentation as a run with autoconf is needed if was patched.

If that isn't acceptable, there should be another place where up-to-date readable versions of our documentation files can be found

Jeremy White explained how to build the documentation (at least in HTML), but setting up the XSL/XSLT tools for the DocBook conversion always has been a hard thing to do and remains a hurdle, even for regular developers.

John R Sheets started providing a conditional make to test for the presence of doc-book tools, but Alexandre Julliard has a more radical opinion:
The doc is not built by default, so there is no point in making it conditional. People who don't have the docbook tools simply shouldn't run 'make' in the doc directory.

Alexandre also explained that all the documentation versions generated from DocBook (including text and HTML) were available:
Only it's in separate tar files because I don't want to force everybody to download the doc in 4 different formats if they don't need it. If someone can download the source package, they can also probably figure out how to download the doc package that sits in the same directory (we probably should mention this in the README though, patches welcome).

Anyway, the documentation can also be browsed on-line at

7. Wine logo

18�Jan�2001 (4 posts) Archive Link: "Proposed New Wine Logo"

People: Jeremy Newman,�,�Marcus Meissner

Jeremy Newman announced:
I have placed a revised logo Design at ( , and asked for some feedback.

Marcus Meissner found the foot of the glass too thick, but Jeremy was also concerned by the look when the image is reduced to a 48x48 xpm, and sticked to his idea.

Jeremy proposed, after all comments are made (and taken into account) to update the website accordingly. He also proposed to have a consistent spelling of Wine across the Web site to be 'Wine' (and not 'WINE' or 'wine').

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.