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.

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:

• ClientRect is the client area (in screen coordinates)
• WindowRect is the complete window as returned by GetWindowRect()
• X11Rect is the dimensions of the X11 window we created (without window manager decorations)

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.

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

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: opensource.corel.com

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.