Wine Traffic #29 For 7 Feb 2000
Table Of Contents
Introduction
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:
- 11 posts in 31K by Andreas Mohr <amohr@student.ei.uni-stuttgart.de>
- 11 posts in 21K by Juergen Schmied <juergen.schmied@debitel.net>
- 4 posts in 7K by Turchanov Sergei <turchanov@otvprim.ru>
- 4 posts in 6K by Marcus Meissner <Marcus.Meissner@caldera.de>
- 3 posts in 9K by Ulrich Weigand <weigand@informatik.uni-erlangen.de>
- Full Stats
1.
CDs serial numbers
Archive Link: "CD serial numbers ?"
People:
Andreas Mohr, Eric Pouech, , Ove 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 Alberte, Alexandre Julliard, , Gé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:
-
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.
3.
WineLib stub reexplained
Archive Link: "Use .spec files for WineLib apps"
People:
Ulrich Weigand, , Bertho 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 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.
4.
Corel's WINE CVS
Archive Link: "Corel WINE branch publicly available"
People:
Gavriel State, , James 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: 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.
Sharon And Joy