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 following results: 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 unsigned char*):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.

Donnchadh ó Donnabháin wrote: 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?

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:

 *** Warning: X development files not found. Wine will be built without
 *** X support, which currently does not work,

Later on, Donnchadh reported success.

Martin Fuchs announced: 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: http://private.addcom.de/M.Fuchs/tools.html

So, if some of you want(s) to take over this development, just go for it!!

Jeremy reopened the freshly closed discussion on Wine configuration (see previous issue for more details): 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 -rpath=/usr/lib/wine.

However, that app relies on specific library versions of Wine. Even if I start my app with LD_LIBRARY_PATH=/opt/x/wine/lib, the Y application will actually use the /usr/lib/wine shared objects.

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 use).

Jeremy also posted some Alexandre Julliard saying: 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 until then.

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.

In a middle of some discussion around Wine documentation, Joerg Mayer noted that one of Alexandre latest change broke the --debugmsg 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 channels.

Joerg asked for some possible solutions. Alexandre Julliard gave a rough answer: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.

John Wehle tried to have Wine working on his Solaris 7 box. He posted a traceback, and some explanations: 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.

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:It will 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: 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 Wine.

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 providing ourselves (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 mutual exclusion.

>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 ...

Based on this information, John worked into two directions:

• 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 help.
• 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).

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)

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: 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.

However, this is not Windows's behavior (a Window handle is unique across the system).

Gérard went further: >From what I have seen in existing apps, Interprocess FindWindow is used for 2 goals:

1. 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.
2. 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 :-).

Chet Murphy kept going: 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 communication?

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.

Alexandre Julliard committed a patch that implements a decent DLL scheme into Wine (see WWN 11, WWN 24, WWN 49 for previous articles on this matter).

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 GetProcAddress.

This was a painful process, because:

• 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

This should be over by now thanks Alexandre work. As he put it: 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:

.globl InitCommonControlsEx
InitCommonControlsEx: jmp *(imports+20)

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).

Marcus Meissner started to report some issues:

• -Bsymbolic appears not to work with binutils-2.9.1.0.21 (it does with 2.10.0.24).
• It also does not compile when using .a files as libraries. (avifil32 missing reference to msvfw32)

Regarding last point, Marcus even asked whether there is 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.