![[LWN Logo]](/images/lwn.banner.gif)
Date: Mon, 08 Nov 1999 20:25:29 +0000
From: Eric Pouech <Eric.Pouech@wanadoo.fr>
To: "Wine annouce (WWN publish)" <wine-announce@winehq.com>
Subject: Wine Weekly News #16 (1999-Week 45)
This is a multi-part message in MIME format.
--------------AFA6BF169B213BEE557B4664
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please find enclosed your (preferred ?) weekly publication.
Have a nice reading.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
--------------AFA6BF169B213BEE557B4664
Content-Type: text/plain; charset=iso-8859-1;
name="wwna.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="wwna.txt"
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for November
8th, 1999.
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
* Marcus Meissner reported that a talk will be given on Wine at
Comdex fall. But noone seems to know who's giving the talk (since
Marcus will be gambling in Vegas, we'll sure have some report).
* Microsoft has been ruled a monopoly in U.S. District Court.
* After one week of testing, newest version of cvsweb is now in
place (so URL http://www.winehq.com/cvsweb2/ is no longer valid;
please update your bookmarks if any).
_________________________________________________________________
Keeping Track of Wine
_________________________________________________________________
Ove Kåven (with new computer and about to obtain the $600 from
Cosource for the wsock32 project) has returned to writing this
section.
* You must change kernel to krnl386 in [DllOverrides] and [DllPairs]
in wine.conf if you run the latest Wine. If you don't, then Wine
will crash on startup if you run from an existing Windows
installation.
* A couple of new success reports have come in:
Quicken99 (for at least one person), EndNote 3, Opera, Word97, and
almost Baldur's Gate (while an attempt to get Outlook 98 up and
running came a long way but failed for now).
* David Grant (Corel) has submitted patches to add a KDE look (in
addition to Win31/Win95/98 look). These weren't considered clean
and modular enough to make it into official Wine. He also fixed
some other user interface bugs, though.
* Ian Schmidt made OpenDesktop return a proper error value to make
Quicktime 4 start up, and fixed usage of native USER.
* Eric Pouech made the registry reading code more fault-tolerant,
and fixed a message box resource string issue.
* Peter Schlaile fixed a GetDiskFreeSpace problem. (Maybe that'll
teach those pesky installers...)
* Peter Hunnisett did some work on DirectPlay.
* Lionel Ulmer enhanced DirectX mouse handling.
* Jaroslaw Piotr Sobieszek submitted a Polish keyboard map.
* Marcus Meissner improved linux joystick driver detection, added
ChangeDisplaySettingsExA stub, and improved the TLS relocation
hacks.
* Karl Lessard (Corel) fixed a focus problem in -managed mode and
some other popup problems.
* Alexandre Julliard fixed a couple of wineserver and handle
problems, made the wineserver an installed binary that's now
exec-ed, made wine wipe deallocated memory, and added some
prelimiary ptrace support.
* Jürgen Lock fixed some problems with the Wine clipboard server.
* Pierre Mageau (Macadamian) improved the listview common control.
* Huw D M Davies submitted a few more printing patches.
* David Grant (Corel) killed some treeview common control bugs.
* Ulrich Czekalla (Corel) kept working on common controls (now
listview) and common dialogs.
* Jeremy White fixed a winsock non-asynchronous accept() crash.
* Ove Kåven fixed a winsock socket creation error handling bug, and
dealt with XShm performance problems in DirectX.
* François Gouget added ICMP functionality to winsock.
* Rein Klazes added some stubs for RAS.
* James Abbatiello worked around some critical section issues.
* Andreas Mohr implemented RegisterNLSInfoChanged.
* Jürgen Schmied fixed window style specifications in wrc, and did
quite some work on shellview and shell folders and the open/save
dialogs.
* Patrik Stridvall did further cleanup work.
* Jim Aston (Corel) fixed a DC problem.
* Ulrich Weigand submitted a heap of patches (version autodetection,
VxDCall, exception handling, and others) that hasn't been
committed yet.
* Ian Schmidt submitted a VWin32 patch (that depends on Ulrich's
VxDCall patch) that should make "Bleem!" start up.
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 85 posts consumed 281 K. There were 34 different
contributors, 19 (55%) posted more than once, and 19 (55%) posted
last week too.
The top posters of the week were:
* 12 posts in 22 K by Eric Pouech <Eric.Pouech@wanadoo.fr>
* 9 posts in 29 K by Ove Kaaven <ovek@arcticnet.no>
* 5 posts in 30 K by Moshe Vainer <moshev@easybase.com>
* 5 posts in 17 K by "Juergen Schmied" <juergen.schmied@debitel.net>
* 4 posts in 9 K by Rein Klazes <rklazes@casema.net>
* 4 posts in 10 K by Uwe Bonnes
<bon@elektron.ikp.physik.tu-darmstadt.de>
* 3 posts in 8 K by Dave Pickles <davep@nugate.demon.co.uk>
* 3 posts in 7 K by Lionel Ulmer <lionel.ulmer@free.fr>
* 3 posts in 6 K by David Blackman <david@whizziwig.com>
* 3 posts in 16 K by "Jeremy White" <jwhite@codeweavers.com>
* 3 posts in 14 K by Ulrich Weigand
<weigand@informatik.uni-erlangen.de>
* 3 posts in 13 K by "Dmitry Timoshkov" <dmitry@sloboda.ru>
Threads and WineLib Issue
Mel Gorman reported some issues while using WineLib:
I'm writing a plugin for [1]XMMS for playing VQF's using WineLIB and
windows DLL's. I had a nice amount of success in getting a plugin
to work but I had to separate XMMS and the plugin into two
separate programs which is kruddy as hell. When I try to merge
them together, there is segfaults every direction when the windows
dll tries to thread. I'm fairly sure that it's due to the
difference in how pthreads (used by XMMS) does threading and how
Wine does it's own threading with clone.
Ove Kåven replied:
The issue is simple: for two threaded systems to be compatible with
each other, they should use the same thread primitives. This has
thus two solutions:
1. Make Wine use pthreads. Time and time again it has been
discussed and argued that pthreads is generally not
compatible with win32 threading, so cannot be used for the
binary emulator at least. It could conceivably be used for
pure Winelib if the binary compatibility part is disabled,
but I don't think anyone have bothered. (Besides, it seems
you are doing this for the binary compatibility, loading
win32 dlls)
2. Make XMMS use Wine threads, but it doesn't sound likely to be
an option, since this is a plugin.
I think you have to stick with separate processes for XMMS and
Winelib to accomplish what you want.
Note: [2]VQF is another format for compressed audio, and a possible
(better ?) replacement for MP3. For more on the VQF plugin for XMMS,
you can also check [3]Mel's project page.
Wine integration into Unix/X11 Evolution
David Grant from Corel submitted a patch that would better integrate
KDE look'n'feel inside Wine. It would allow to display every window
with a KDE look'n'feel (even the child ones, which Wine currently only
displays with the Windows look, whatever mode (-managed or not) Wine
is run with). In details, it implements the KDE (and also Windows 98)
gradient on windows' title bar, the menu tracking, use of KDE system
colors for Wine defaults.
Eric Pouech disagreed on the approach:
Have you thought 2 seconds of what it would mean to mimic every WM on
the field in Wine ? You've started with KDE, we could add Gnome,
mwm, fvwm, ice, CDE, ... The code would be an utter mess. And not
maintainable, needless to say. For example, are you sure that KDE
will always keep the same gradient, even in KDE 2 ? if not, you'll
have to integrate another tweak for KDE2... :-(
There are of course parts that can be applied as it is (like
gradient for caption), but, unless we provide a cleaner way to
better integrate a WM look (and perhaps feel) into Wine, I fear
that your patches would cause more harm than good.
Gavriel State (Corel) answered:
Yes, ideally we would be able to modularize more of the 'chrome' code
so that it would be easier to write additional modules to support
the various different looks that people might want (Gnome, mwm,
KDE, Win31, Win2K, etc). Right now though, we (Corel) don't have
time to spend on this. We're concentrating on the KDE look
primarily because KDE seems to be the most popular desktop WM, and
we anticipate that it will continue to be for quite a while. Even
if it doesn't look 100% right for KDE 2 (or KDE with themes), it's
still better than the Win95 look for MDI windows for what we're
working on.
Something else to consider is this: there is a potential copyright
issue with the Windows look and feel sets - specifically with the
maximize, minimize, and close buttons on the Window borders.
Better to have at least one look and feel setting that doesn't
look exactly like windows.
If Alexandre and the wider WINE community don't want to integrate
the patch into the main CVS tree, it's no big deal for us - we
mostly work from our own internal tree anyway. If someone else
wants to modularize the look and feel code so that it's easier to
support new looks (Gnome, mwm, etc), we'd probably be happy to
move the KDE look into that structure, but I don't think that
we're prepared to do that modularization ourselves at this time.
Jürgen Schmied proposed in order to help this modularization to build
upon the existing ownerdrawn mechanism:"Why not plug all drawing
functions (win31 and win95 look could be the first two) into the
ownerdrawn mechanism? Like if its a real ownerdrawn control send the
message and if its one of our internal drawing routines call the
appropriate function through a calltable. All structures of the
ownerdrawn mechanism could be reused and all the ugly if(style=win31)
the do this and if (style=win95) the do that constructs could be
thrown out."
The discussion evolved to a wider approach of the integration of
Windows applications (run with Wine) into the Unix/X11 environment
(having all widgets with a KDE look'n'feel, how to display paths...).
Gavriel State gave Corel's view:
* Even with the patch, there isn't "a real KDE look and feel for
each widget, only menubars and MDI windows. Luckily, for KDE, the
rest of the Windows widgets are very similar to KDE's widgets."
* "David Grant has been working on another patch that's basically a
hack to display DOS-style paths as UNIX paths by simply reversing
the direction of slashes and dropping the drive letter. The hack
is turned on via a switch in the ..winerc file. Our apps are being
built to use a .winerc file that maps C:\ to /, so that a path
like this:
C:\home\gavriels\myfile.xyz
gets displayed as
/home/gavriels/myfile.xyz
There are complications with the file dialogs, and some other code
that we haven't entirely resolved yet, so it'll likely be a while
before we would send the hack in to wine-patches.
We also have a patch coming that will allow the use of a --prefix
option so that a different .winerc and .wine directory can be
specified for different apps. This way, the use of the KDE look
and filename conversion flags by our apps will be in a .wporc
file, not your .winerc, and nothing other than our apps will be
affected unless you make the appropriate modifications to your
.winerc.
"
Wine identification Evolution
Gavriel State is looking for a "a clean way to determine if we're
running under WINE, and preferably the vintage as well."
He proposed a Wine only extension of return values from
GetVersionExA().
Ulrich Weigand proposed:
The TNT toolkit (which allows to run WinNT console apps under DOS)
exports a special symbol 'IsTNT' from its version of KERNEL32.DLL,
so apps can simply check with GetProcAddress() whether that's
there.
We might similarly add a KERNEL32 routine 'IsWine' or so; for
extended info that symbol could point to a string containing
version info, or even to a routine that could be called to query
lots of settings...
No patch has been submitted yet.
Of Windows' versions Issue
While fixing some incorrect behavior in edit control in disable state,
and finding out that the messages to be sent depend on the Windows's
the application is running on, Rein Klazes popped up this question:
"Now I wonder how windows can detect that an application is designed
for windows 3.1?."
There is currently, three different notions of Windows' version used
in wine (from Ulrich Weigand's explanation):
* "the Windows version that the current session of Wine emulates. In
the simple case, this is just a constant corresponding to the
-winver setting"(as returned by VERSION_GetVersion()).
* "GetProcessVersion() returns the Windows version that the process
in question expects. This is determined from the
'expected_version' field of the NE header or the
'SubsystemVersion' fields of the PE header."
* the tweak used for the presentation (Tweak options in ~/.winerc)
which triggers how the look'n'feel of various controls shall be
done.
So, to implement correctly the old and new behavior as explained by
Rein, Ulrich proposed the following:
First, check VERSION_GetVersion() to find out which Windows version we
do emulate; then, behave like that Windows version does.
+ If we emulate Win3.1, this means we always use the 'old'
method, even if the executable expects the new one (if the
executable indeed relies on the new method, it probably
wouldn't work on Win3.1, so if Wine were a perfect emulator,
we'd expect that the program doesn't work on Wine in Win3.1
mode, either :-/)
+ If we emulate Win9x, this means that we have now to implement
a further check, depending on the version expected by the
executable (because that's what Win9x does). If the
executable expects the old method, use the old, otherwise the
new one...
Actually, to be completely compatible we shouldn't even use
the application's expected version. Consider the case that a
'old' application links to 'new' DLLs or vice versa. If one
of those DLLs now call into the Windows core, e.g. to display
a private dialog, and that DLL specifically relies on either
the old or the new behavior, we choose wrong if we just
consider the app's expected version.
Instead, what Win9x does (in 16-bit code) is to examine the
return address to the caller which called the core routine.
Using the code segment selector which is part of the return
address, it finds out which module allocated that selector,
and hence which DLL performed the call. It then uses the
expected version of that DLL to decide.
+ If we emulate a particular WinNT version, we should do like
that does. I'm not completely sure myself what that is,
however ;-)
All this gets even more complicated if we expect Wine to
transparently select a Windows version to emulate, so that the
executable runs best ...
This thread triggered a set of patches, including returning correct
version information for builtin modules.
Credits: [4]Doug Ridgway, [5]Eric Pouech, and [6]Ove Kåven.
_________________________________________________________________
References
1. http://www.xmms.org/
2. http://www.vqf.com/
3. http://www.csn.ul.ie/~mel/projects/linux/vqfplugin/
4. mailto:ridgway@winehq.com
5. mailto:pouech@winehq.com
6. mailto:ovek@winehq.com
--------------AFA6BF169B213BEE557B4664--