Wine Traffic #8 For 14 Sep 1999
Table Of Contents
Introduction
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:
http://reality.sgi.com/opengl/linux/linuxbase.html
What I am think about doing now:
- hard-code the opengl32.spec and glu32.spec using OpenGL 1.2 / GLU
1.3 and all the extensions defined in the future glext.h file.
- have a file that does the translation for all the OpenGL calls
(stdcall / cdecl translation + X11 critical section handling) :
void WINAPI win_glPopMatrix(void) {
ENTER_GL();
glPopMatrix();
LEAVE_GL();
}
- use of the new glGetProcAddressEXT function to conditionnaly use
extensions:
void* WINAPI wglGetProcAddress(LPCSTR lpszProc) {
HMODULE hm;
TRACE(opengl, "(%s)\n", lpszProc);
if (glGetProcAddressEXT(lpszProc) != NULL) {
hm = GetModuleHandleA("opengl32");
return GetProcAddress(hm,lpszProc));
} else {
return NULL;
}
}
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:
- Use pthread_create() etc. to create and manage threads, instead
of using low-level primitives.
This would seem the cleanest solution, but is rather difficult to
implement as far as I can see. This is because the implementation
of pthreads on the various platforms make some low-level assumptions
that collide with assumptions made by Wine (e.g. on Solaris/x86,
the pthreads implementation assumes it can freely use the %gs segment
register; on Linux/x86, the implementation makes rather stringent
assumptions as to just where exactly the thread stack has to reside
etc.)
- Do not use any libc routine that uses synchronization primitives.
This would also be a clean solution, but will probably be hard to
do, as it would mean reimplementing quite a lot of libc features ...
- Manually protect against libc reentrancy (use a LIBC_CritSection
analogous to the X11DRV_CritSection).
This would work, but it seems ugly and not especially efficient ...
In addition, it would mean that WineLib programs using libc routines
would need to be aware of this.
- Provide an implementation of the pthreads synch primitives (on top
of Win32 synch routines) for use by libc.
This has already been implemented by Ove Kåven; IMO this is probably
the best way to go, as it allows full use of all libc routines, while
using low-level routines for thread management, but still ensures thread
safety.
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
libc.so 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 Battle.net to work under Wine (WHOA, now the sponsors suddenly
come rolling in!...?)
Sharon And Joy