Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #7 For 5 Sep 1999

By Eric Pouech

Table Of Contents

Introduction

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

Warning

As of today CVS, the configuration files need some changes:

1. ElfDLLs (cont'd)

 Archive Link: "ElfDLLs (cont'd)"

People: Ulrich Weigand, Bertho Stultiens, Alexandre Julliard, , Patrik Stridvall

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:

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

2. DIB drawing speed-up

 Archive Link: "DIB drawing speed-up"

People: , Huw Davies, Eric Pouech, Marcus Meissner, Gavriel State

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.

3. Signal handling on FreeBSD

 Archive Link: "Signal handling on FreeBSD"

People: Jurgend Lock, Ulrich Weigand, Alexandre Julliard, 

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

4. Big fonts

 Archive Link: "Big fonts"

People: Jurgend Lock, , Gérard Patel, Richard Cohen

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.

5. Anonymous unions

 Archive Link: "Anonymous unions"

People: Alexandre Julliard, , Patrik Stridval, Marcus Meissner

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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.