Uwe Bonnes was the first to report a crash which seemed to be caused by the newest DLL handling mechanism (to be more precise, in the calls to dlopen).

As a remainder, Wine implements the Windows DLL in .so files. Recent changes (mostly by Alexandre Julliard) allow to embed a set of DLLs (being 16 or 32 bit) into a .so file. This .so file is then loaded/unloaded by Wine as the embedded DLLs are needed by the program.

Firstly, Marcus Meissner noted a nesting of calls to dlopen, and dlopen reentrancy was questionned.

James Abbatiello reported a similar crash on his machine. Both James and Uwe were running SMP machines with glibc 2.1. The former turned out to be fine (Uwe disabled the SMP feature and the crash didn't vanish), the latter was the issue.

James wrote: It seems to be a bug in glibc 2.1.x. If a dlopen() call fails, it sets an internal variable to point to a string describing the error (for later retrieval with dlerror()). If you then call dlopen() again, without calling dlerror() in between to clear the error status, dlopen() will free the string. Then it tries to load the library, and sets the internal variable again depending on whether the open succeeded or failed. However, during the time that its trying to load the library, it keeps this internal variable pointing to a now-freed block of memory. As we call dlopen() again before the loading of the library finishes, it tries to free the same memory twice.

James even quoted the glibc 2.1.x and 2.2 sources, showing that the issue has been fixed for the 2.2 release. As a matter of fact, the issue only occurred with glibc 2.1.x...

James and others (including Gérard Patel and Lawson Whitney) put together a patch for Wine's loader which shall work around this glibc issue. The patch has been applied to the CVS tree.

Vedran Rodic reported an error at link stage while compiling Wine 20001202 with -O6.

Even if compiling Wine with lots of optimization is a risky job, and should be avoided, developers tried to understand what happens.

Basically, some functions, defined with the __attribute__(__unused__) attribute are removed in the compilation process. This type of attribute is mainly used in Wine for the DLLs descriptors initialisations: each time Wine implements a 32 bit Windows module (DLL or EXE), a PE header descriptor is generated, and a pair of stubs. These stubs are hooked up into the Unix loading mechanism for dynamic module ; hence allowing, these stubs to instanciate, from a Wine point of view, those PE headers. (EdNote: I tried to keep this article as concise as possible, but a yet to come feature article shall cover the details of the DLL handling in Wine).

This type of code removal rang some bell to Ove Kaaven who reminded similar issues raised a while ago (read this for the details).

The compiler did optimize away the function code because it has been colored with the unused attribute (gcc keeps the code when only -O2 is used).

Even though Alexandre Julliard provided a fix for this issue, by putting all the stubs (are described above) in the .init and .fini sections of the compilers (which also work for gcc), Ove and Patrik Stridvall started a flame war.

They basically argued to know whether it was a compiler bug or not, if this behavior was driven by algorithms or heuristics and so on...

If you're currently writting a thesis on computer idiomatics semantics, you may be interested in reading the details. Since the editorial team doesn't target those people as their primary audience, details will not be covered.

Martin Pilka announced starting some Wine startup speed up effort: I'm working on speed up the registry parsing at wine startup. What I would like to do is to move the whole registry parsing to the server side (where *.reg format 2 files already are, for example). Right now I bounced to old *.reg format 1 parsing, which is still on client side. Should I invest some effort and move it where it belongs (as I believe, please correct me if i'm wrong) or some message like "format 1 no longer supported" is enough?

Alexandre Julliard slighty changed Martin's first proposal: I don't think you want to move the whole registry parsing to the server. What you should do is change the parsing code to dump the contents into a temporary text file (in .reg format 2) and then ask the server to load this file.

A few days later, Martin had finished writting the first pass of the code and was starting the test phase. No patch has been submitted yet, nor improvments figures have been provided.

Michael Cohen wondered if Wine had already been ported: If endianness is accounted for, can WINE be ported to different architectures / operating systems? WINE should be configured from the ground up with ifdefs in place, but I don't imagine that anyone was considering porting it when it was written. I can try and start a development team to port it, however. The first steps must come from the wine devel teams at large. WINE needs to be prepared to port. I would love to see a future with WINE as the sole windows interpreter for Win32, MacOS, LinuxPPC, Linux/Alpha, etc.

Jeremy White devoted himself for an answer: Wine (the binary loader) doesn't make sense to port to a non intel platform, unless you have a really high performance x86 emulator (and even then the rationale is a bit dicey).

Winelib (the Windows implementation and porting library) has been ported to PPC once by Gavriel State, and has been again by Josh DuBois of CodeWeavers [okay, Josh only has it sorta kinda working, but there you go].

There is still a fair amount of work to do to get the non intel Winelib working well, but it's only that - work - nothing really hard left <g>. (Okay, that's glib. There are some real issues. For example, you have a dilema about whether resources have a MS binary format or a format that allows fields to be accessed via fields in a structure).

With Winelib to PPC in hand, Winelib to most other platforms should be straight forward.

So, yes, Winelib can be the key instrument to bringing Windows software across many platforms. At least it darn well better be <g>.

For recent PPC efforts, you can also read this. When Eric Pouech wrote this he referred to a past issue. However the link was broken and I was unable to find what he was referring to.

Josh DuBois went on: I guess it's time to publicly 'fess up to being someone who is working on porting wine to PPC. I'm still a relative wine newbie, but I welcome interested parties to contact me about wine ports if they'd like as I will be working on it regularly for some time.

Josh then started the hard part by asking a good place to store the TEB on PPC ?

Alexandre Julliard advised to use register %r13 as Windows does. But, Alexandre said It may be available under linux too, that depends on how the system libraries have been compiled, since there are several gcc options controlling what %r13 is used for.

Gavriel State wondered Is there really any reason not to just use pthread directly? We're not constrained by binary compatability issues on LinuxPPC (or MacOS X), so there's no need to preserve any special registers.

Of course, as I'm writing this I'm trying to remember why I didn't try this out at MacHack this year when I tried to update the PPC port. I remember going through the same process of trying to find a register that I could be sure was preserved across library calls, and even consulted Stan Shebs (one of the gcc PPC developers). I couldn't find anything that seemed appropriate in time, so I just gave up. I have no recollection whether using pthreads' local storage even occured to me then.

Gavriel also offered his old PPC port to Josh, as a reference for some issues he already had fixed.

Even if using pthreads has been rejected for Linux and Solaris (read thisfor the details), this shouldn't be an issue for PPC (at least at first glance).

Alexandre Julliard agreed on the feasability, but proposed another way for the Linux PPC port: since we already support clone() on i386, using clone() on linuxppc may be easier to do, at least for the first version.