Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #223 For 21 May 2004

By Brian Vincent

Table Of Contents


This is the 223rd issue of the Wine Weekly News publication. Its main goal is to forget the sunscreen and get a tan. 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 106 posts in 482K.

There were 50 different contributors. 25 posted more than once. 29 posted last week too.

The top posters of the week were:

1. News: Interview With Jeremy White

15 May 2004 - 21 May 2004 (1 post) Archive Link: "News"

Topics: News

People: Jeremy WhiteNews

Slashdot posted the interview of Jeremy White by the Slashdot community. Jeremy talks about everything from licensing to selecting products to support.

2. New Janitorial Projects

18 May 2004 - 19 May 2004 (2 posts) Archive Link: "some ideas for new janitorial projects"

Topics: Build Process

People: Eric PouechFrancois Gouget

Eric Pouech had some ideas for some new janitorial tasks. For someone just wanting to get started with Wine these would be great - they only require a bit of knowledge of C:

I've been toying with some gcc warnings lately, and this could generate some new ideas for janitorial tasks. For example:

Some others warnings could be used as well. Trying also the Intel compiler gave lots of interesting warnings (and a tons of not so usefull too).

Francois Gouget had some ideas too:

Here are a couple extra suggestions:

Add -Wwrite-strings
There has already been quite some work on this but I believe it's not finished yet. I'm not 100% sure of the status though.
Patch our min/max macros to catch signed/unsigned comparisons.
This generates a lot of warnings. Ideally they should be fixed without using casts but it may not always be possible.

(the modified min/max macros where borrowed from a Linux kernel patch)

3. Wine & Fedora Core 2 Workaround

19 May 2004 - 20 May 2004 (5 posts) Archive Link: "Upcoming breakage warning"

Topics: Fixes

People: Mike HearnMarcus Meissner

Mike Hearn warned everyone of a problem that was likely to appear more and more:

On Fedora Core 2, the kernel is compiled with the 4G/4G VM split option enabled, which can prevent us from performing a correct emulation.

Win32 apps are apparently built with the assumption that they will not be allocated addresses beyond the 3G boundary. The solution therefore is to perform a similar trick to the preloader and reserve the address space before the emulation starts so mmap will never use addresses in that area.

This probably won't be combined with the preloader itself though, as Alexandre says it can be done after Wine gets control (what about DSOs mapped >3gig?) and so it can be done more portably. Up until now this issue has only affected Solaris and therefore nobody fixed it.

There is currently no known workaround for this problem short of recompiling your kernel. The error looks like this:

Alexandre diagnosed this problem so I'm sure he'll correct me if this email contains any mistakes.

Digging deeper, Mike found a temporary solution the next day,

According to a Red Hat kernel engineer, you can use to switch it back to the 3/1 split while we fix it in the Wine code.

(man setarch if you want to know more details)

Over the past year there's been a series of breakages caused by new distributions. Marcus Meissner speculated it was part of a larger plot, " Could it be that Redhat is trying to deliberately break WINE every half year ;) "

4. Unreal 2 Working

19 May 2004 - 20 May 2004 (3 posts) Archive Link: "[DMUSIC] Happy Happy :)"

Topics: DirectX

People: Raphael Junqueira

DirectX guru, Raphaël Junqueira, has been submitting some large DirectMusic patches lately. With the latest one this week we finally understand what's been motivating him:

I'm glad to announce that now (with this little patch) Unreal2 is working and playable (it's only slow and i havent seen graphics problems for now).

Now play :)


5. Direct3D Retained Mode

18 May 2004 (6 posts) Archive Link: "Re: Empty (Stubs in spec only) d3drm"

Topics: DirectX, Creating Stubs

People: Ivan Leo Murray-SmithLionel UlmerRaphael Junqueira

Ivan Leo Murray-Smith submitted a patch to add a stubbed implementation of d3drm.dll; the Direct3D Retained Mode API:

This dll is needed by a game, bug report number 1202. With this empty dll, the game crashes at the same point where it crashes when used with the native copy, mainly because it crashes before any function in the dll is called. But at least it doesn't crash with a dll not found error. You'll have to run the autofoo stuff after applying this patch.

Lionel Ulmer thought the DLL should be disabled by forcing it to native though, " As far as I know, you did not submit also a patch to the default configuration file to add this DLL with 'native' as default (which is a good thing as all the people having a Windows box have this DLL - it could even be installed if someone manages to install DirectX under Wine). "

Ivan pointed out the native DLL didn't work, so that might not be a good idea. Raphaël suggested "just" completing the stubbed DLL, " This dll should be easy to implement (almost geometries utilities functions as d3dx8/d3dx9 for d3d8/d3d9). It can be a beginning for people who want to begin patches for wine (as for d3dx8/d3dx9) :) "

Lionel explained his reasoning:

Well, my point was the same made about stubs in normal DLLs: why add a completely useless DLL which may break more things than actually help.

Or, when adding it, have it at least disabled by default.

As for its simplicity, from what I remember there are tricky stuff like Mesh builders, interpolations, ... Which are 'easy' in the sense it's pure geometrical stuff and not at all linked to Win32, but still something that needs at least a good knowledge in 3D geometry processing.

Raphaël felt it might be a nice starting point just because little knowledge of Win32 is required. The geometry could all be tested with DirectX development kit demos. Lionel cautioned against spending much development time on it:

Well, D3DRM is so rarely used (in all my game demos I ever tested, only one actually used it) that it's something very difficult to do for no real gain to Wine.

But well, I do not object to someone working on it, I just object to the 'let's add an empty DLL to Wine' approach... If adding an empty DLL, it should at least have FIXME printed on each call (to know which calls are used) and, even better, to have the COM hierarchy implemented with stubs to see which calls are used in which interfaces.

Otherwise, it's no help to anyone.

6. Hiding Symbols (con't)

16 May 2004 (3 posts) Archive Link: "symbol hiding - with gcc -fvisibility"

Topics: Build Process

People: Guido DraheimMike Hearn

Guido Draheim followed up this week on a thread we covered ( issue #222) about hiding symbols:

sorry, just saw the note on WWN. I did hope that there would be someone to point to the gcc visibility stuff already - but it seems that people are more concerned to exchange their beliefs and politics rather showing off some engineering stuff.


it's not in the file format - it's in the tools.

The name ELF stands for Extensible Linker Format, it allows to invent all kind of new sections, and expand the symbol table with many interesting attributes that can be checked up by a toolchain. Well, "IF" the tools check for them.

gcc -fvisibility
The gcc -fvisibility exists since 3.1 and is supported by binutils. If you read up some web reports, it seems to have been invented for hiding stuff not quite unlike what the original poster wanted. The icc supports all -fvisibility options as well afair.
the real problem
traditionally, one can kill local systems which are usable within one file only, i.e. "static". Pretty 20year old unix stuff. The other symbols are referencable outside (in .o) and the standard shard linker will put all of them into the shared library symbol export table. - But now we want two different symbol flavours, one exported to the same library, the others for the rest of the world. Perhaps use a linker script to decide later about symbol visibility.
example solution
gcc supports the universal attribute syntax, and it does now know about more symbol flavours as to their visibility. Probably you want to have "hidden". Attached are two simple test*.c files and a makefile. The final sharedlib symbol table contains only test3 after stripping. - using a linker script instead of in-source __attribute__ is left as an excercise to the reader.
more hints
search freshmeat - there are ELF tools to staticlink, to obfuscate, and more. It's all in the tools. There is only one problem with opensource: many programmers do not need to hide symbols to the extreme, so they did not write such tools so far. Not yet. There are some real ELF-educated people out there - hire one, and let him write the tool you need. The ELF format is well-defined and simple enough to allow everything and quite easily.

Mike Hearn tried it out and reported success after stripping the resulting binaries.







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.