Wine Traffic #69 For 13 Nov 2000
Table Of Contents
This is the 69th 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 121 posts in 422K.
There were 34 different contributors.
25 posted more than once.
21 posted last week too.
The top posters of the week were:
- 16 posts in 41K by Alexandre Julliard <email@example.com>
- 7 posts in 15K by Uwe Bonnes <firstname.lastname@example.org>
- 6 posts in 21K by Francois Gouget <email@example.com>
- 6 posts in 20K by Ulrich Weigand <firstname.lastname@example.org>
- 6 posts in 18K by Jeremy White <email@example.com>
- Full Stats
6 Nov 2000
Archive Link: "Warning fixes - please review"
Joerg Mayer, Alexandre Julliard,
Joerg Mayer started the task to reduce the number of warnings
generated by compiling Wine with -Wall -W flags (currently Wine is
built with -Wall only).
He started working in the tools subdirectory. Fix tries gave the
Earlier this evening there were 3260 warnings (2357 unused params, 864
signed/unsigned comparison, 39 others). I'm trying to take up the task
to reduce that number and reveal some bug in doing so :-) So if you
don't agree with what I'm doing and how I'm doing it: Now is the best
time to let me know.
Alexandre Julliard didn't like some of the type casts added (for
example between a
char* and a
There may be a few cases where a type
cast may actually make a difference; but when the only difference is
the warning I consider the type cast unnecessary. And if the choice is
between having warnings with -W or having type casts all over the
place, I prefer the warnings.
Joerg furnished a patch according to Alexandre wishes.
Wine without X
6 Nov 2000
Archive Link: "wine without X"
Donnchadh ó Donnabháin, , Patrik Stridvall
Donnchadh ó Donnabháin wrote:
Patrik Stridvall answered that console applications should work
without X under Wine. However, GUI applications don't work under Wine
without X (Patrik did some hacks some months ago and add some simple
applications working in text mode (windows were drawn in text mode)).
Donnchadh didn't investigate too hard after the Wine configure message:
We use Microsoft Visual SourceSafe as our Version Control system here
and I use Wine (20001026) to run the command line tool (win32 console
app) under Linux (The GUI also runs but hangs on some operations). I
would like to get the latest version of on project using VSS from
within an automated build script, but would prefer not to have to
install/run X on the build server. ./configuring wine without the X
libraries indicates that wine can be built without X but that it
doesn't work yet.
What needs to be done to get wine working without X?
which turned out to be a completely wrong message.
Later on, Donnchadh reported success.
*** Warning: X development files not found. Wine will be built without
*** X support, which currently does not work,
6 Nov 2000
Archive Link: "winefile"
Martin Fuchs announced:
So, if some of you want(s) to take over this development, just go for it!!
Some time ago I started to program a file manager replacement for
Wine. If I look at the time stamps, it seems, I didn't change anything
in the last 6 months. ;-)
So if some one wants to continue the work... I've put the current
source code archive at my HP:
More configuration discussions
8 Nov 2000
Archive Link: "-rpath option"
Jeremy White, Alexandre Julliard, Ove Kaaven, , Eric Pouech
Jeremy reopened the freshly closed discussion on Wine configuration
(see BROKEN KCREF for more
Jeremy would have liked to remove the -rpath option. Eric Pouech would
have seen it done the other way around (add an option to remove -rpath
Jeremy also posted some Alexandre Julliard saying
Why do we have the -rpath option on by default?
It creates a serious problem for us. Say we build a Winelib
application for customer Y. By default, that app is built with
However, that app relies on specific library versions of Wine. Even if
I start my app with
, the Y application will
actually use the /usr/lib/wine shared objects.
So if I get this right, what you do is that you don't set -rpath at
all? I'm beginning to think this should actually be the standard
behavior; setting rpath is broken because it takes precedence over
LD_LIBRARY_PATH. How about submitting a patch that removes rpath
completely, and start a nice flame^H^H^H^H^Hdiscussion on wine-devel?
However, Ove Kaaven noted:
There's no sense in aiming for ultraclean rpath solutions... as I
understand, neither rpath, LD_LIBRARY_PATH, nor ld.so.conf
modifications will be required in Wine 1.0 anyway, because by then we
should have Alexandre's perfect DLL separation with import system that
makes ELF dependencies a thing of the past. The problem that rpath,
ld.so.conf modifications, etc, aims to solve won't exist anymore once
Alexandre finishes his work. I'd just go for rpath without relocation
Ove also added that putting away from the standard .so load path the
Wine's DLL would help solving file name collisions (like the one Wine
had with Gnumeric' libole32.so).
Alexandre agreed, but added
we won't have the problem
with dlls, but we'll still need a way to locate libwine.so and
libwine_unicode.so and suggested that in order to start Wine,
the best approach IMO is to use LD_LIBRARY_PATH in a
wrapper script like winelauncher. But of course this only works if we
never set rpath.
Some Wine help removed
7 Nov 2000
Archive Link: "Re: docu/wine update *sigh*"
Alexandre Julliard, Joerg Mayer,
In a middle of some discussion around Wine documentation, Joerg Mayer
noted that one of Alexandre latest change broke the
help feature (this allowed to list all the known debug channels
which give some feedback of what Wine's doing).
For the insiders, this patch moved the definition of the debug
channels from the Wine core to every DLL (in fact, each DLL is able to
define its own set of debug channels), which of course is a better
open approach, but kills the centralized listing of the defined
Joerg asked for some possible solutions. Alexandre Julliard gave a
not do anything ;-) The whole point of
the patch is to avoid having a centralized list of debug channels;
this way any dll/app can add its own channels when loaded. So of
course this also means you have no way of printing the complete
list. I'm not convinced that such a list is really useful anyway; you
still need to read the code to see what debug channels are useful for
debugging a given problem.
Some people, like Petr Tomasek, found the end result too harsh and
requested at least some better documentation on the matter.
Wine and Solaris 7
8 Nov 2000 - 9 Nov 2000
Archive Link: "Patch to fix Solaris 7 x86 thread support"
John Wehle, Patrik Stridvall, Ulrich Weigand, , Patrik Stridval
John Wehle tried to have Wine working on his Solaris 7 box. He posted
a traceback, and some explanations:
So, John tried to get rid of the _lwp* functions and use the
thr_create ones for Solaris x86 (Solaris Sparc would keep its
interface). He even proposed a patch to do so.
Patrik Stridvall asked not to apply the patch:
Wine uses _lwp_create on Solaris which has the following note:
Applications should use bound threads rather than the _lwp_*()
functions (see thr_create(3T)). Using LWPs directly is not advised
because libraries are only safe to use with threads, not LWPs.
with high probability crash and reboot _every_ Solaris 2.6 out
there. And yes I mean CRASH and REBOOT. There is a kernel bug
concerning LDT:s that haven't been fixed even in the latest patches.
Ulrich Weigand gave a good explanation of the reasons why Wine was
using the low level interface:
Based on this information, John worked into two directions:
Well, it was done that way for a purpose ;-)
The problem is that the higher-level thread libraries (typically
pthreads) tend to make certain assumptions about things application
programs typically do or don't do, and these are sometimes violated by
For example, the Linux pthreads implementation assumes that all thread
stacks must have the same size, and must reside at positions
determined by the library. Wine doesn't like this, as it has to satisfy
Windows applications' requests for variably sized thread stacks. (OK,
recent versions of glibc also allow variably sized stacks, but only at
a huge performance penalty.)
The Solaris x86 pthreads implementation, last time I looked into it,
assumes that it is free to create selectors in the LDT without being
disturbed by the application. This obviously breaks with Wine, as Wine
also thinks it can freely use the LDT without interference. (Note that
due to a kernel bug in Solaris, this problem can quite reliably
trigger kernel panics in certain circumstances :-/)
Due to this sort of problems, we decided to do it the other way around
and fall back to the most low-level interface to create threads on the
platforms we support, which are direct system calls without library
involvement. This way, we are at least sure that the threading library
does not interfere with what Wine does.
Of course, this approach leads to a different problem: the system
libraries (libc etc.) typically rely on the system threading library
to provide for mutual exclusion primitives or other mechanisms to make
the library thread-safe. On Linux, we've solved this problem by
(a subset of) the pthreads interface,
implemented *on top* of the Wine threading primitives, which gets used
by the system libraries instead of the system libpthread to provide
>From the backtrace you posted it appears, unfortunately, that the
Solaris libc does not fall back to libpthread, but libthread. As we
don't fake the libthread interface, the real libthread gets used and
breaks, of course.
I'm not quite sure how to solve this problem. Just using pthreads (or
libthread, as you propose) opens up the problem of conflicting LDT
allocations again. (Note that I'm not definite that libthread also
uses the LDT. But as threads created by pthread_create and thr_create
can be used interchangeably, I'd be astonished if not.)
We might try the same hack as on Intel and implement a subset of the
libthread interface to satisfy the Solaris libc. I'm not sure whether
this would be feasible either...
B.t.w. this topic comes up regularly, but has never been satisfactorily
solved :-/ If you have any new ideas, they would most certainly
be welcome ...
Things should now go a bit better on Solaris x86... John reported some
success with Solitaire, but also failures (EdNote: but this is
still being discussed as this issue is written, so we'll cover it up
in next issue)
- first, he discovered that configure made OpenGl be used in
Wine, which was known under Linux to use libpthread.so. Under Solaris,
it links with libthread.so, hence bringing the type of errors Ulrich
and Patrik described. Configuring without OpenGL supported seemed to
- then, John started hacking some synchronization functions for
libc on Solaris, which also seemed to help (it's the same kind of job
which has been done under Linux to synchronize the pthreads).
Windows and Processes
9 Nov 2000 - 10 Nov 2000
Archive Link: "FindWindow warning"
Gérard Patel, Chet Murphy, Joerg Mayer,
Joerg Mayer while trying to fix some programs, found out that current
Wine's code for FindWindow didn't check other processes Windows after
search in current process' windows failed. Joerg was also astonished
that no fixme was emitted.
Gérard Patel gave some explanation on the situation:
However, this is not Windows's behavior (a Window handle is unique
across the system).
Gérard went further:
That's a following of the address space separation. Although the Wine
processes are separated, the windows handles are still generated by
each Wine process through a local mechanism based on memory
allocation. The Wine server does not generate them, and as such these
handles have no meaning for another process.
For example, it can happen that 2 windows of different processes have
the same handle. So it does not make sense to do a FindWindow for a
window in another process in current Wine.
Chet Murphy kept going:
>From what I have seen in existing apps, Interprocess FindWindow is
used for 2 goals:
- find if another instance of the app is running (this is a very
bad way of doing it, but there are pretty bad apps indeed). Typically
when the app has found an existing instance, it activates it
(something like SetActiveWindow) and exits. This is widely used but
it's not really important to support it.
- when launching auxiliary apps, it's the first step before
calling an interprocess SendMessage. I have seen this used by
installers, but I don't know if these features (interprocess
FindWindow and SendMessage) have to work for the installer to work
completely (the installer was not terminating correctly and was
leaving apps running). If yes, having this fixed seems mandatory for
the legendary 1.0 bottled Wine since InstallShield working perfectly
is included in the official spec; however, I am not sure if IS is
working perfectly now - I think not but there are other points of view
Then it sounds like the problem is not just with FindWindow. One
important use window handles is when using WM_COPYDATA to send data
from one process to another. I use WM_COPYDATA to send data between
instances of my applications. I also use WM_COPYDATA when using a
custom hook dll that will be loaded by another process so that the
custom hook dll and my application can establish interprocess
communication (in this case I pass my application's window handle to
the dll as part of the command line). If window handles are local to
the process then how can WM_COPYDATA work for interprocess
This only means that more work is required on Windows handling to
reach the 1.0 target. To go even further, the current Wine Windows
management is broken for multiprocess handling. Most of the calls
dealing with multiple processes (like FindWindow, SendMessage...) do
not work correctly yet.
DLLs get separated
12 Nov 2000
Archive Link: "Re: wine/dlls Makefile..."
Alexandre Julliard, Marcus Meissner,
Alexandre Julliard committed a patch that implements a decent DLL
scheme into Wine (see
BROKEN KCREF for previous articles on
Basically, Wine was missing the following feature: as the DLL which
contains the implementation of a function can be either a native (from
Windows) or builtin (from Wine) DLL, it would be neat to have, in
another part a the code, a single way to call such a function. Before
the patch, the only doable way was to get the handle of the
destination DLL, and get, by hand, the function address thru
This was a painful process, because:
This should be over by now thanks Alexandre work. As he put it:
- cause was hard to read (thru function pointers)
- more error prone: no check could be performed on the "regular"
function prototypes in the Windows header files
- switch from ANSI to Unicode was kind of hackish
Marcus Meissner started to report some issues:
Yes, we can remove the LoadLibrary hacks and call the functions
directly instead, and everything will magically work.
The way it works is that all the dll objects except for the main spec
file are linked together as a temporary .o; winebuild then runs nm -u
on this file to find which symbols are unresolved, and resolves them
against the functions exported from the imported dlls. For each
resolved entry point it generates a jump instruction that will use the
address stored in the import table at load time.
So for instance if you call InitCommonControlsEx from shell32,
winebuild will notice it is not defined in shell32 itself, find this
symbol in the exported table of comctl32, and will generate an
assembly stub like this:
InitCommonControlsEx: jmp *(imports+20)
in the shell32.spec.c file. The loader will store the actual address
of InitCommonControlsEx into (imports+20) at load-time, no matter
whether the builtin or native comctl32 was loaded. This means you can
use InitCommonControlsEx() in your code just like if you were using
ELF libraries exclusively; the redirection to the native dll will be
The things to consider is that any dll using this mechanism must be
linked with -Bsymbolic to make sure the assembly stubs do not override
the real function definitions, and that it should only call functions
that are exported by the dll (which is the main reason why not all
dlls can use this yet).
Also, this mechanism takes precedence over normal ELF linking, so for
instance if you import crtdll you can no longer call libc functions
since they will be redirected to crtdll (of course crtdll itself will
call libc, so it will still work).
Regarding last point, Marcus even asked whether there is
- -Bsymbolic appears not to work with binutils-184.108.40.206.21 (it
does with 220.127.116.11).
- It also does not compile when using .a files as libraries.
(avifil32 missing reference to msvfw32)
any sense in building static libraries left? Should configure just
abort if it does not find a way to build symbolic ones?
Alexandre quite agreed:
I think so, yes. Static
libraries don't make much sense any more; and anyway they have been
broken for quite some time already.
Sharon And Joy