First of all, the rationale of elf-dll was clarified. Ulrich Weigand's point of view:

1. it is currently rather hard to mix native and built-in DLLs in an arbitrary way, due to the missing import redirection. There's already a lot of work-arounds, using explicit GetProcAddress, to get around this to a certain extent, but this is rather ugly and at other places even the workarounds are missing
2. the build processs currently forces the build of the one large libwine.so, which is somewhat annoying, as the linking of libwine.so takes nearly a minute on my system, even when actually only a minor change to one of the built-in DLL's implementation has been made
3. Of course, I see another use of elfdlls, namely to allow development of DLLs outside of the main Wine distribution, for use with WineLib programs. This is not my primary concern at this point, though.

Then, the process to introduce, write, debug this elfdlls feature has been vehemently argued.

Ulrich Weigand propose to extend the current code (mainly the build tool and enhance the builtin DLL loader with elfdll capability). This would allow to still use all the existing DLLs (but, this requires the ability to allow multiple export tables in a single elfdll.

As a matter of process, Ulrich didn't like to have two different solutions, performing (at least partially) the same task, both active in the source tree. This means I don't think it is a good idea to have both the 'build' and the 'dllglue' tool parse .spec files, and neither is it a good idea to have both an built-in DLL and an elfdll loader. The disadvantages of this approach should be rather obvious: not only do you have to keep the two solutions in sync with every modification, but this also means that we cannot take full advantage of the new features. E.g. one of the main reasons why the .spec parsing of dllglue is preferable to the one in build is IMO that it is much easier to modify a lex/yacc parser to add new syntax to the .spec format. But, we can't take advantage of that as long as 'build' also needs to parse the same files ...

Bertho Stultiens disagreed about having multiple export tables in one .so file (which is need to implement Ulrich's proposal, because current implementation of DLLs use internals of some other DLLs, e.g. commdlg/comdlg32) and said implementing multiple PE/NE headers in dllglue is simply the wrong way to go IMHO. My motto: Fix the code, not the tools.

Ulrich (and later on Alexandre Julliard) disliked the process proposed by Bertho, mainly because most of it happens outside of the CVS tree, or not being widely used. They both preferred having a set of small changes applied to the CVS tree, rather than a separate development being switched to later in time when everyhing has been fixed.

Some more detailed discussions outlooked the modifications to be applied to the build tool: Bertho did propose his dllglue code to generate export tables, import tables and resource embedding (as well as NE & PE headers). This would actually completly replace build (which only provides export tables for now). His idea was to create a brand new tool (using lex & yacc for better readability / maintenance) for elfdlls and only use build for the soon obsolete built-in DLLs). Ulrich Weigand disagreed and was in favor of making build evolve to dllglue (even it is means starting to rewrite it, with the same set of features, with lex & yacc). One issue of the process is to know wether is existing .spec files (the export tables) can be used by both tools (or said in other words, whether the syntax will be the same). Patrik Stridvall noticed that as long we don't know what needs to be changed: We _must_ properly see the problem before we can decide on how to change the .spec files. BTW, are we 100% sure that we really want to have .spec files, like they are today, why not have special format comments in the .c files instead."

Ulrich Weigand gave some explanation of the behavior:

Well, this problem would seem to be caused by Wine. The problem is that while any Wine signal handler is running, %fs needs to be loaded with the value %fs had in the code that was interrupted by the signal *if that code is 32-bit*. If *16-bit* code was interrupted, however, %fs needs to be loaded with the value had at the time the switch from 32-bit to 16-bit took place (this value was saved at the time)...

The reason for this is that Wine, like 32-bit Windows, uses the %fs register to identify the current thread. On 16-bit Windows, however, %fs has no special meaning and is freely used by apps...

Unlike Wine, FreeBSD 3.x doesn't provide the %fs value in sigcontext structure and current Wine code was broken. Ulrich proposed a fix. Luoqi Chen also added that FreeBSD 4.0 will provide this feature. Luoqi proposed a compilation-time check for it that Alexandre Julliard rejected (he'd better like a run-time check, so that the same binary can run on both OSes).

Richard's first patch has been applied, and this should be sorted out now.

#if defined(__cplusplus) || !defined(NONAMELESSUNION)
#define DUMMYUNIONNAME
#else
#define DUMMYUNIONNAME u
#endif
 
typedef struct {
   field1_t field1;
   union {
      field2_t field2;
      field3_t field3;
   } DUMMYUNIONNAME; 
} struct_t;
 
void test(struct_t *ps)
{
   struct_t s;
   s.DUMMYUNIONNAME.field2 = ps->DUMMYNIONNAME.field1;
}


but, if the compiler does support anonymous structs, this is expanded into s..field2 and ps->.field1 which gcc doesn't like (however it seems Microsoft didn't suffer from it).

Marcus Meissner proposed to append the dot to DUMMYUNIONNAME and to use it as:

s.DUMMYUNIONNAME field2 = ps->DUMMYUNIONNAME field1;

Alexandre Julliard proposed:

#if defined(__cplusplus) || !defined(NONAMELESSUNION)
#define _U(x) u.x
#else
#define _U(x) x
#endif
 
s._U(field2) = ps->_U(field1);

Then, Patrik and Alexandre discussed the best (or "least worse") solution when porting existing Windows code using Winelib with a compiler not supporting anonymous structs. Alexandre found that doing a search and replace (to add the anonymous struct macro) was better than Patrik solution, which, when the used field was not the one choosen from the struct, would lead to design change, which are worse than pure text manipulation.