WWN Issue 7

This is the seventh release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

<h3>Warning</h3> As of today CVS, the configuration files need some changes:

mpr, winspool = builtin, native

mpr, winspool.drv = builtin, native

ElfDLLs (cont'd)	Archive
The discussion on ElfDLLs kept on going after a week of cease-fire (see previous two weeks old edition). First of all, the rationale of elf-dll was clarified. Ulrich Weigand's point of view: 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 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 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 a 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 completely 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 whether 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."

ElfDLLs (cont'd)

Archive

The discussion on ElfDLLs kept on going after a week of cease-fire (see previous two weeks old edition).

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

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 a 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 completely 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 whether 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."

DIB drawing speed-up	Archive
Gavriel State (finally :-) submitted the patch for enhancing speed for drawing DIB sections. Even if Huw Davies pointed out some issues (quickly fixed), some others (like Marcus Meissner) reported some failure (especially in GetDIBits function). Gav said this should be fixed later on next week and asked Alexandre to revert this patch. Eric Pouech disagreed, mainly because keeping the patch inside the CVS tree would speed up the correction phase.

Signal handling on FreeBSD	Archive
Jurgend Lock reported some issues with signal handlers on FreeBSD. Sometimes apparently wine's signal handlers receive %fs messed up (zeroed actually) and therefore crash/hang on FreeBSD (3.2-stable, wine current-cvs). 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).

Signal handling on FreeBSD

Big fonts	Archive
Jurgend Lock reported some strange behavior (very big fonts) on latest CVS. Gérard Patel explained this was caused by a recent patch from Richard Cohen which changed the default size of system fonts. Richard explained that this patch assumed the existence of a previous patch of his that Alexandre didn't yet apply, hence the problem. Richard's first patch has been applied, and this should be sorted out now.

Archive

Jurgend Lock reported some strange behavior (very big fonts) on latest CVS. Gérard Patel explained this was caused by a recent patch from Richard Cohen which changed the default size of system fonts. Richard explained that this patch assumed the existence of a previous patch of his that Alexandre didn't yet apply, hence the problem.

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

Anonymous unions Archive

Anonymous unions	Archive
Patrik Stridval proposed last week a patch to let any compiler use the anonmymous unions used by Microsoft. His idea is to chose one field amongst the ones provided in the anonymous union. Apparently, Microsoft did use a construct like: `#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.

Patrik Stridval proposed last week a patch to let any compiler use the anonmymous unions used by Microsoft. His idea is to chose one field amongst the ones provided in the anonymous union. Apparently, Microsoft did use a construct like:


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

World Wine News