Wine Traffic #47 For 12 Jun 2000
Table Of Contents
Introduction
This is the 47th 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).
About.com runs a Wine
introduction.
Mailing List Stats For This Week
We looked at 130 posts in 294K.
There were 57 different contributors.
26 posted more than once.
33 posted last week too.
The top posters of the week were:
- 10 posts in 17K by Alexandre Julliard <julliard@winehq.com>
- 8 posts in 13K by Ove Kaaven <ovehk@ping.uio.no>
- 7 posts in 18K by Andreas Mohr <a.mohr@mailto.de>
- 7 posts in 15K by Bradley Baetz <bbaetz@student.usyd.edu.au>
- 7 posts in 14K by Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
- Full Stats
1.
Strange API conventions
2 Jun 2000 - 8 Jun 2000
(10 posts)
Archive Link: "Missing prototypes (courtesy of winapi_check)"
People:
Francois Gouget, Andreas Mohr,
Francois Gouget, still toying with winapi_check and ports of Windows
apps with WineLib) sent a patch to mimic better the way Windows splits
the definitions across the header files.
One point of peculiar interest was the MCIWndCreate function (Francois
fix was: MCIWndCreate conflicts with the corresponding
A/W macro
.
As a side note, since the introduction of UNICODE strings in Windows,
most APIs exist in two flavors when strings come into play:
- an ANSI version
- an UNICODE one.
Usually, the ANSI version is postfixed by A (fooA) and the UNICODE
with W (fooW) (for Wide characters). In the header file, depending
whether the manifest constant UNICODE is defined, foo is either
#defined as fooW or fooA.
Francois Gouget went further on some tentative explanations:
When I say that the DLL had three APIs I checked
with windows and saw that they do use the usual macro for
MCIWndCreate. So, I assume that they created MCIWndCreate first and
then realized that it should really have an A and a W version, added
those but did not remove the original one to not cause compatibility
problems. So I assume one is not supposed to use the old one anymore.
Of course if one really wants to use the old one all one has to do is
to use GetProcAddress.
After lots of people complained about this reminiscence of the bad
coding habits, the discussion evolved into the prototypes for such
function. Andreas Mohr also pointed out that
WINSPOOL.DeviceCapabilities{A|W} might suffer from the same symptoms
and may require the same treatment, but no one replied.2.
Problem with gcc-2.95.2 and -O6
6 Jun 2000
(2 posts)
Archive Link: "Problem with gcc-2.95.2 and -O6"
People:
Lionel Ulmer, Ulrich Weigand,
Lionel Ulmer reported some IRC discussion he had:
By discussing with a Wine user on #nvidia, we found out that when
compiling 'scheduler/sysdeps.c' with gcc 2.95.2 and -O6, the function
'SYSDEPS_DoCallOnStack' is undefined
nm sysdeps.o | grep DoCallOnStack
gives 'U SYSDEPS_DoCallOnStack').
After some discussions with Ove, he thought that it was because gcc
was inlining this function.
Well, I had hoped the __attribute__(__unused__) that I attached to
the declaration would suffice ... I'm not aware of any other pragma
or attribute that could be used.
The proper solution for gcc would IMO be to replace the ASM_GLOBAL_FUNC
hack by proper GNU inline assembly, specifying the procedure address
as input argument. This way, gcc would be aware that it is used.
Unfortunately, Patrik won't like this as it breaks non-gcc compilation :-/
3.
Making Star Money 2.0 to work
8 Jun 2000 - 9 Jun 2000
(13 posts)
Archive Link: "Star Money 2.0 crash"
People:
Alexandre Julliard, Gérard Patel, Andreas Mohr,
Andreas Mohr reported a crash while running Star Money 2.0. He also
started digging into the traces, and reported some bad behavior
between windows handles and menu id. Speaking after himself, Andreas
smelled some mismatch between windows IDs and menu IDs. Alexandre
Julliard pointed back to the recent changes to
SetParent which do not clear wIDmenu when making the window a
top-level one.
As a side note, Windows (at least in CreateWindow) uses the same
parameter for two different uses:
- if the window is a child/popup window, then this parameter is a
child ID (which helps uniquely identify a child among his siblings)
- if the window is not a child window (overlapped...), this
parameter is an ID to a menu control
Alexandre also suggested that we should probably have
separate fields for id and menu to avoid this problem.
A naive Andreas asked whether he should do the work, and Alexandre
slapped the impetuous: I want the patch in my mailbox
in 10 minutes. That will teach you what happens to people who dare to
find bugs. ;-)
Andreas missed the deadline but Gérard Patel sent the proper fix in
SetParent that all of them suspected to be the culprit.
Gérard gave also some more details on his fix:
The combo listbox is now created like a child window in controls/combo.c
But this 'strange little beast' is not keeping its style when it's reparented
in the wnd.c file (because of the code removed by my patch).
So, the style is turned from child to neither child nor popup - hence,
overlapped (main window).
An overlapped window can have a menu and has, of course, no
child Id. A child has an Id, but can't have a menu.
With my patch, the id can't be handled as a menu handle in the (rather
special) case of the combobox.
It's an incredibly bad design, of course, but being compatible with Windows
and having a good design is a challenge.
4.
Feature: The X11 driver by Ove Kĺven
People:
, Patrik Stridvall
Most Wine users run Wine under the windowing system known as X11. During most of
Wine's history, this was the only display driver available, but in recent years,
parts of Wine has been reorganized to allow for other display drivers (although
the only alternative currently available is Patrik Stridvall's ncurses-based
ttydrv, which he claims works for displaying calc.exe). The display driver is
chosen with the "GraphicsDriver" option in the [wine] section of wine.conf/.winerc,
but I will only cover the x11drv in this article.
x11drv modes of operation
The x11drv consists of two conceptually distinct pieces, the graphics driver
(GDI part), and the windowing driver (USER part). Both of these are linked
into the libx11drv.so module, though (which you load with the "GraphicsDriver"
option). In Wine, running on X11, the graphics driver must draw on drawables
(window interiors) provided by the windowing driver. This differs a bit from the Windows
model, where the windowing system creates and configures device contexts controlled
by the graphics driver, and applications are allowed to hook into this relationship
anywhere they like. Thus, to provide any reasonable tradeoff between compatibility
and usability, the x11drv has three different modes of operation.
Unmanaged/Normal
The default. Window-manager-independent (any running window manager is
ignored completely). Window decorations (title bars, borders, etc) are drawn
by Wine to look and feel like the real Windows. This is compatible with
applications that depend on being able to compute the exact sizes of any
such decorations, or that want to draw their own.
Managed
Specified by using the --managed command-line option or the Managed
wine.conf option (see below). Ordinary top-level frame windows with thick borders,
title bars, and system menus will be managed by your window manager. This
lets these applications integrate better with the rest of your desktop, but
may not always work perfectly. (A rewrite of this mode of operation, to make
it more robust and less patchy, is highly desirable, though, and is
planned to be done before the Wine 1.0 release.)
Desktop-in-a-Box
Specified by using the --desktop command-line option (with a geometry,
e.g. --desktop 800x600 for a such-sized desktop, or even --desktop 800x600+0+0
to automatically position the desktop at the upper-left corner of the display).
This is the mode most compatible with the Windows model. All application windows
will just be Wine-drawn windows inside the Wine-provided desktop window
(which will itself be managed by your window manager), and Windows applications
can roam freely within this virtual workspace and think they own it all,
without disturbing your other X apps.
The [x11drv] section
AllocSystemColors
Applies only if you have a palette-based display, i.e. if your X server is set
to a depth of 8bpp, and if you haven't requested a private color map.
It specifies the maximum number of shared colormap cells (palette entries) Wine
should occupy. The higher this value, the less colors will be available to other
applications.
PrivateColorMap
Applies only if you have a palette-based display, i.e. if your X server is set
to a depth of 8bpp. It specifies that you don't want to use the shared color map,
but a private color map, where all 256 colors are available. The disadvantage is
that Wine's private color map is only seen while the mouse pointer is inside a
Wine window, so psychedelic flashing and funky colors will become routine
if you use the mouse a lot.
PerfectGraphics
This option only determines whether fast X11 routines or exact Wine routines
will be used for certain ROP codes in blit operations. Most users won't notice
any difference.
ScreenDepth
Applies only to multi-depth displays. It specifies which of the available depths
Wine should use (and tell Windows apps about).
Display
This specifies which X11 display to use, and if specified, will override both
the DISPLAY environment variable and the --display command-line option.
Managed
Wine can let frame windows be managed by your window manager. This option
specifies whether you want that by default.
UseDGA
This specifies whether you want DirectDraw to use XFree86's
Direct Graphics Architecture (DGA), which is able to take over the entire
display and run the game full-screen at maximum speed. (With DGA1 (XFree86 3.x),
you still have to configure the X server to the game's requested bpp first,
but with DGA2 (XFree86 4.x), runtime depth-switching may be possible, depending on
your driver's capabilities.) But be aware that if Wine crashes while in DGA mode,
it may not be possible to regain control over your computer without rebooting.
DGA normally requires either root privileges or read/write access to /dev/mem.
UseXShm
If you don't want DirectX to use DGA, you can at least use X Shared Memory
extensions (XShm). It is much slower than DGA, since the app doesn't have direct
access to the physical frame buffer, but using shared memory to draw the frame
is at least faster than sending the data through the standard X11 socket, even
though Wine's XShm support is still known to crash sometimes.
DXGrab
If you don't use DGA, you may want an alternative means to convince the mouse
cursor to stay within the game window. This option does that. Of course, as with DGA,
if Wine crashes, you're in trouble (although not as badly as in the DGA case,
since you can still use the keyboard to get out of X).
DesktopDoubleBuffered
Applies only if you use the --desktop command-line option to run in a
desktop window. Specifies whether to create the desktop window with a double-buffered
visual, something most OpenGL games need to run correctly.
Sharon And Joy
Mirror provided by HKMirror. Sponsored by Porno Verzameling and webcamsex