Wine Traffic #8 For 14�Sep�1999

By Eric Pouech

Table Of Contents


This is the eighth 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).

1. Porting to BeOS

�Archive Link: "Porting to BeOS"

People: Alexandre Julliard,�Patrik Stridvall,�,�Patrik Stridval

Patrik Stridvall sent out a patch to ease up porting Wine to BeOS. One of the major drawback he reported was the lack of mmap(), sendmsg(), recvmsg() and select() functions. Alexandre Julliard disliked Patrik's patch, but also the way to tackle the porting issue,
IMNSHO this is BeOS problem, not ours. Wine is a Unix program and needs a reasonable amount of Unix compatibility to work. It'd be much better (and probably easier) to implement a Unix compatibility layer for BeOS that adds the missing functions, rather than sprinkle hundreds of #ifdefs all over the Wine code, breaking half of the functionality at the same time.

Patrik expressed some difficulties on doing so, especially
functions like sendmsg/recvmsg that passes file descriptor between process can't be done without kernel support AFAIK, and BeOS doesn't seem to support it, it will have to be done some other way,
and to cope with lack of mmap() (which is also the case of SCO 4.2, and will arise on all systems without MMU).

Alexandre prefered not to put too much #ifdef in the code, and rather use stubs for missing functions (like mmap) in a compatibility layer and have them return failure values.

2. Accelerated OpenGL & Wine

�Archive Link: "Accelerated OpenGL & Wine"

People: Lionel Ulmer,�

Lionel Ulmer proposed a new plan for integrating accelerated OpenGL libraries with Wine:

You may recall my previous problems about the adding of OpenGL support to Wine (useful for people wanting to play Half Life on their nice GLx00 or TNTx cards).

The situtation has changed a bit since last time thanks to the on-going Linux OpenGL standardization effort: (

What I am think about doing now:
He asked for comments before starting implementing it. No one replied yet, so this should be ok :-).

3. Space to install Wine

�Archive Link: "Space to install Wine"

People: Marcus Meissner,�,�Jutta Wrage

Jutta Wrage, maintainer of the Wine HOWTO, asked for the common sizes of binaries for updating the Wine HOWTO, which was out of date to his respect.

It turned out that 30 to 80 MB was necessary (depending whether or not you asked for debug information, if you decide to build the static or shared lib, and which version of the compiler you're using).

Marcus Meissner noted that
gcc-2.8 and egcs use a slightly enhanced stab (debuginfo) format which allows the linker to strip out uselessly duplicated debuginfo (not all of the duplications, but most)
", yielding to smaller sizes.

4. Thread safeness

�Archive Link: "Thread safeness"

People: Uwe Bonnes,�Ulrich Weigand,�Bertho Stultiens,�,�Ove K�ven,�Manu

Uwe Bonnes reported a crash on his SMP system, while calling the libc function closedir, and asked whether or not he
put a critical section around DOSFS_CloseDir
or if this was
some deficency of my libc?

Ulrich Weigand gave an explanation of the issue,
Well, this is a known problem: glibc2 is reentrant, but this simply means that glibc uses thread synchronization mechanisms internally where necessary to protect its data structures against reentrancy. Unfortunately, it tries to use the pthread synchronization primitives, and as Wine isn't linked with libpthread (and doesn't use the pthread mechanisms to create and manage threads), those synch routines (pthread_mutex etc) are simply no-ops.

but also listed some orientations to solve those issues:

Bertho Stultiens proposed another solution, which would work on ELF systems (like Linux):
by overloading the allocation routines from another .so. The overloading .so must be loaded before for this to function (malloc and friends are weak symbols).

He also pointed at some drawbacks of the mechanisms, including
knowledge of some of the internals of libc; there were some libc routines that bypassed the top-level linking and went directly for the alloc primitives (might be an obscure old version of libc I have in mind); you also have to take the .so-library's initialization into account and make sure that your wrapper in initalized before libc start with its own initialization.
Bertho provided a few hours later a first patch implementing this behavior, and Uwe reported no crash after a few hours of test.

5. Winsock & 32 bit

�Archive Link: "Winsock & 32 bit"

People: Ove Keven,�Alexandre Julliard,�,�Ulrich Weigand,�Ove K�ven,�Patrik Stridvall,�Marcus Meissner

Ove K�ven announced that after the $600 founding he obtained on CoSource ( , he started the development on the 32 bit winsock.

Here's the main awaited improvment (quoted from CoSource):

The Winsock implementation in Wine is still from the Win16 days, and does not use proper Win32 file handles (so e.g. WaitForSingleObject doesn't work on it under Wine, although it should).

Migrating the socket structures from being just a winsock-internal list to make them be handled by the wineserver instead is thus a requirement for that kind of non-winsock operations to work. This is not believed to be very hard to do (at least with some advice from the gurus), just somewhat... longwinded? Probably takes a week or something to complete when knowing exactly what to do (which the Wine gurus should be able to explain, of course).

Let me just also mention that this is a requirement for things like Starcraft's to work under Wine (WHOA, now the sponsors suddenly come rolling in!...?)

He asked a few questions regarding sharing or not handles between 16 and 32 bit interface, Marcus Meissner and Alexandre Julliard adviced Ove to use an architecture to what has been done for the file interface. Marcus even proposed (for free) some work he had started on this subject.

Ulrich Weigand also requested to remove the winsock entries from the TASK descriptors (to clean-up the code) and Patrik Stridvall reminded that WinSock V1's handles couldn't be used as file descriptors (whereas V2 could), and asked for the V1 behavior to be also present, mainly to take into account OS:es (like BeOS) which don't treat socket descriptors as files descriptors.

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.