Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Wine Traffic #29 For 7 Feb 2000

By Eric Pouech

Table Of Contents


This is the twenty nineth 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).

Mailing List Stats For This Week

We looked at 88 posts in 213K.

There were 39 different contributors. 19 posted more than once. 22 posted last week too.

The top posters of the week were:

1. CDs serial numbers

 Archive Link: "CD serial numbers ?"

People: Andreas MohrEric PouechOve Kåven

After successfully providing a patch for reading CD Rom labels from the CD Rom itself (and no longer from a static configuration option), Andreas Mohr kept on going with CD Roms support in Wine.

He asked
does anybody have any real info about how Win 9x creates the serial number when doing a "dir" on a CD ? (even audio CDs feature that !) Raw DOS doesn't print a serial number in this case, so it's a Win 9x addition. I already searched my whole docu and the whole web like crazy, but couldn't come up with anything really usable.

Ove Kåven suggested that CDDB (an open source CD ROM Database system) might use the same algorithm, but Andreas already had checked it, but CDDB wasn't producing the same values.

Eric Pouech reminded that
there's a computation of an ID done at the MCI level (check dlls/winmm/mcicda/mcicda.c in the MCICDA_Info function), which is based on track length & pos. The algo used is the same as Windows' one, except for one track CDs.

Andreas gave a look at the code, which contained what he was looking for, except for 1 or 2 tracks CD audio, which he found was quite valuable, but no one came back with the proper algorithm.

2. Managed mode metrics

 Archive Link: "Managed mode metrics"

People: Guy AlberteAlexandre JulliardGérard Patel

Guy Alberte submitted a patch to somehow fix another "flying window" problem. This is an old issue, as Guy explained
This method was the result of much work on the Winword "Bullets & Numbering" dialog. Winword does in fact use GetSystemMetrics to get the frame width and caption height. It then uses ClientToScreen to take its known client rectangle to the screen coords. It then uses the saved system metrics values to compute the actual window rectangle in screen coords. Then it calls SetWindowPos. Without the patch the window moves up and to the left every time one of the tabs is clicked.

Gérard Patel reported this type of issue months ago, and dubbed this phenomenon "flying window". Part of the problem comes from the fact that it's quite impossible to know from different window managers the height used for the caption of a window. Not knowing this value, can make erroneous positionning.

Alexandre Julliard gave a more in depth analysis, which broke some of the accepted cause of the "flying window" problem:
If we define the 3 following rectangles:

then we have:

WindowRect == ClientRect + menus + borders + caption + scrollbars

in all cases (some values can be 0 depending on the window style of course).

For non-managed windows we have X11Rect == WindowRect, and for managed windows we have:

X11Rect == ClientRect + menus + scrollbars == WindowRect - caption - borders

Currently the code assumes X11Rect == WindowRect in all cases and this is what is broken.

Thuy Nguyen fully agreed with Alexandre's analysis and pointed to CreateWindow as an example of this bad coding.

3. WineLib stub reexplained

 Archive Link: "Use .spec files for WineLib apps"

People: Ulrich WeigandBertho Stultiens

After Ulrich Weigand submitted a patch to unify the start-up sequence for both WineLib based programs and the Wine emulator, Matthew Francis asked for some more explanations. In particular, Matthew wanted to elaborate on how Ulrich's patch would integrate with his attempts to enhance the C++ support in WineLib programs (see issue #26 for more on this).

As usual, Ulrich wrote a very precise description:
Well, the main reason why the WineLib linking process needs to be changed is that the init sequence should really switch to the Wine thread stack instead of using the main Linux stack. This initial switch is currently done only in the emulator, and this is one of the few remaining differences between the emulator and the lib.

As it is somewhat hard to return from a routine that switches stacks, it seemed simpler to just never return from the WineLib init routine, but instead just go through the whole startup sequence and then call the program entry point, which could be specified in the .spec file.

So, the current process goes about like this: the app calls MAIN_WineLibInit, and after that returns, the environment is set up. This call can reside either in winestub (which calls WinMain after it is finished), or else directly in main (in the case of a console app).

What I want to do is to start execution directly in libwine instead, perform initialization (including stack switch), and then call the app entry point. This entry point will probably reside inside the .spec.c file generated by build and contain code to set up the correct arguments and call the app's WinMain() or main() routine.

To achieve this, there are two options: either, the .spec.c file contains the real main() routine, which directly calls some WineLib routine that never returns, or else itself contains a main() routine. In both cases, there's no need for a winestub, as all necessary code resides either in the lib or in the .spec.c file.

Ulrich and Matthew discussed some more details and Bertho Stultiens provided an in-depth description of ELF initialization (and finalization) support, which could provide a better (and more portable solution).

4. Corel's WINE CVS

 Archive Link: "Corel WINE branch publicly available"

People: Gavriel StateJames Sutherland

Gavriel State announced that
We're opening up read-only CVS access to our internal branch of WINE. Our last full merge with the WineHQ branch was in late December, and since then we've been concentrating on our internal branch only due to release time constraints. We plan to start merging our changes back into WineHQ (ie: making patches out of our CVS commits) after we release. In the meantime, if anyone wants to do any of that work for us, please feel free to submit any patches you want from our branch so long we get credit in the changelog. 8-)

The site where you can get all this is:

It's also got at least one other thing that may be of interest to WINE people, our Application Printing Services library. This is a printer configuration and job settings library that our branch of WINE uses if available.

Quite a few developers jumped in and started feeding Wine's tree with Corel's efforts.

Upon request, James Sutherland announced that he put a snapshot of the CVS tree (bz2 compressed) for people wishing to get the tarball (like for those behind a firewall)

Later on, Gav' also mentionned that the first Corel Office for Linux will be built using the emulator (but it will be a special build for Linux). Next release will use WineLib.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.