Wine Traffic #69 For 13 Nov 2000

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.

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.

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?

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

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

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.

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

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.

we won't have the problem with dlls, but we'll still need a way to locate libwine.so and libwine_unicode.so

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.

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.

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.

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.

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

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.

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

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?

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)

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

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

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

any sense in building static libraries left? Should configure just abort if it does not find a way to build symbolic ones?

I think so, yes. Static libraries don't make much sense any more; and anyway they have been broken for quite some time already.