Wine Traffic #49 For 26�Jun�2000
Table Of Contents
This is the 4r9h 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 120 posts in 354K.
There were 36 different contributors.
23 posted more than once.
19 posted last week too.
The top posters of the week were:
- 11 posts in 36K by Patrik Stridvall <firstname.lastname@example.org>
- 11 posts in 33K by John R . Sheets <email@example.com>
- 10 posts in 19K by Alexandre Julliard <firstname.lastname@example.org>
- 9 posts in 22K by Ove Kaaven <email@example.com>
- 5 posts in 14K by Dave Hawkes <firstname.lastname@example.org>
- Full Stats
Wine status page
Archive Link: "Wine Status percentage"
Ove Kaaven,�,�Dmitry Timoshkov,�Ove K�ven
After Ove K�ven put on line the Wine Status
Page, Dmitry Timoshkov asked which metric was used to get the
completion percentage for each Wine component (mainly DLLs).
Ove replied on the method he uses:
There's not much
more metric than my own guesstimate or judgement (which I thought
would at least be better than no metric), and any corrections the
developers would like to tell me about. I didn't try to devise
Dimitry also asked whether a todo list could be provided for all the
components (so that people could have a look at what remains to be
Ove liked the idea
If developers would like to provide
such a list, I could certainly put it online... In a few cases
(especially if it's "almost done"), I've tried put a line under the
percentage saying what is missing, but I didn't want to spend too much
time on it.
The discussion then evolved on the completion and remaining parts of
Wine .so files loading
Archive Link: "builtin .so load dependencies"
Bertho Stultiens,�Alexandre Julliard,�,�Ove K�ven
Ove K�ven re-posted a patch (already sent a couple of days ago, and
still not commited to CVS tree) and asked why it has been commited nor
rejected. This patch was an attempt to let binary packages for Wine
(like RPM) which normally are installed under /usr/local/wine work out
of the box.
This is a known cause of issues because some Linux distributions
(including Mandrake, Red Hat) no longer include by default /usr/local
in the /etc/ld.conf file (which defines the default directories where
to look for .so files). Since Wine has been highly componentized (and
components are stored in .so files), not founding the Wine .so files
is a brutal case of breakage.
As some of you already now, Wine handles several kinds of components:
Wine's final goal is to implement builtin DLL as ElfDll: this means
that a DLL (or many DLLs) will be stored in a specific file, but all
symbols resolution will be done in a very similar way as a native DLL
(this implies providing the same internal imported and exported functions
descriptions). Currently, Wine relies to implement the builtin DLLs on
an hybrid Windows/Unix mechanism. Once loaded the DLL will hook up in
Wine internal lists as a native DLL (using the same structure), but
the import/export functions resolution is done using the .so files
mechanism (the ElfDll shall use the Window's one).
You can have a look at
for more on the topic (wn19991004_11.html#1)
This shall require some extra work on Wine (like rewriting the .so
file generation, as well as cleaning up the dependencies between
Ove's proposal changed a little bit the way Elf symbol resolution was
done, but also forced the use of builtin DLLs of the
EXTRA_LD_LIBRARY_PATH environment variables.
Bertho Stultiens and Alexandre Julliard discussed then, with Ove,
the pros and cons of the proposal.
As a conclusion, Bertho wrote
- native DLL: they reside in their own .dll file, and are
provided in the Windows' world (hence the native name)
- builtin DLL: this one is provided by the Wine team.
- .so file: those are standard .so files from Unix, providing
similar behavior (or interface as their Windows' buddy). OpenGL is a
good example of this kind
Ove proposed then to drop (until ElfDll are in place) the
EXTRA_LD_LIBRARY_PATH use ; Alexandre suggested to
The EXTRA_LD_LIBRARY_PATH was never intended to work with builtin
The builtin dlls are pure
ELF-libraries. For these all the normal ELF
rules apply. Thus, when you use ELF-style linking (i.e. explicit
linking), then you must
use ELF-style loader features (i.e.
LD_LIBRARY_PATH and ld.so.conf). There is no other "Right Way" because
the underlying operating system does not support it otherwise.
print a warning if there are directories in
EXTRA_LD_LIBRARY_PATH that are not also in LD_LIBRARY_PATH.
Ove's first patch hasn't been committed, but no one submitted
something close to Alexandre latest proposal.
Archive Link: "Wine CVS Documentation"
John R Sheets,�Alexandre Julliard,�,�codeweavers,�Eric Pouech
John R Sheets wrote:
Later on, John also posted an outline of a possible table of content.
As part of an effort to improve the accessibility of the Wine
documentation, I've converted (most of) the contents of the
wine/documentation directory into DocBook (an SGML variant).
Naturally, quite a bit of the content is old and crusty, and perhaps
even flat out wrong, but hopefully that can be fixed in the near
future. The docs should be pretty current, including the new OpenGL
docs, and the latest revisions to the wine debugger docs.
The current state of things is sitting at
I'm interested in hearing what people think about the organization and
layout. I've done very little proof reading, and only added the bare
minimum of markup to get it up and running ASAP. Quite a lot can be
done to improve the looks; the overall appearance of the generated
HTML is pretty customizable, too.
Several peopled enhanced the proposal:
For beginning users; assumes Wine is already installed. Very simple
- What is Wine?
- How do I run Wine?
- Running Wine
- At the command line
- From the GNOME Panel
- From the KDE Panel (Taskbar?)
- WINE INSTALLATION GUIDE
For all users; includes FTP, CVS, Redhat, Debian, etc.
Covers getting it on the system, but not personalizing it.
- What forms does Wine take?
- Installing on Redhat/Mandrake/SUSE
- Installing on Debian
- Installing from FTP
- Installing from CVS
- Configuring Wine
- Setting up wine.conf
- With Windows Partition
- Graphical Configuration
- Using TkWineSetup
- With GNOME Control Center (NYI)
- With KDE Control Panel (NYI)
- Testing the installation
- Checklist to verify
- Running an app
- WINE USER'S GUIDE
For the day-to-day user; maintaining Wine on your system. How to
configure the basic services, like fonts, printing, multimedia.
- Running Wine
- Simplest case
- Command line parameters
- Configuring Wine
- Customizing .winerc
- Builtin vs. native DLLs
- Look & feel
- Making a bug report
- Common debug flags
- WINE APPLICATIONS GUIDE
For dealing with specific applications.
- MS Office
- Lotus Notes
- WINE PORTING GUIDE
For developers trying to migrate their apps to UNIX, using Wine.
- Binary emulation
- WINE DEVELOPER'S GUIDE
For developers wanting to contribute to Wine. How to submit patches,
what policies to follow, how to debug, and a nice, juicy section on
the Wine architecture.
- The Wine Server
- DLLs in Wine
- The Kernel
- The graphics subsystem
- OLE Support
- Debugging Wine
- Debugging channels
- The Wine debugger
- Misc. scripts
- Policies & Procedures
- Preparing a patch
Another part of the discussion covered the way this documentation
shall be written and delivered (so far, only text files are used for
both parts). Alexandre Julliard thought
- Eric Pouech proposed to have two separate porting docs, one for
porting Windows application to Unix using Wine, the second for porting
Wine to unsupported Unix flavors (this latest part could be part of the
developer's guide). Also, be a bit more specific in the developer's
guide about 16 bit support, thunking, DLLs, but also
providing a better split between USER and GDI functions
- Alexandre Julliard was a bit confused with the long list of
documents and wrote
a user's guide and a developer's
guide would be enough for a start. If some sections of a document
become too large they can always be split into a separate guide, but I
think it's better to keep it simple for now, and think more about the
structure when we have more material.
Lots of people do like DocBook (because it's already widely used, and
it decorrelates the content and hierarchy in the document from its
presentation - DocBook is just an XML DTD, and a couple of
John Sheets proposed for dealing between editing documents (in DocBook
DTD, and generated ones - text, HTML...):
factor is that the doc is as accessible as possible; if it requires
the user to install a lot of tools just to be able to read the doc
there is a problem. And this is what worries me a bit about DocBook; I
find the raw SGML text painful to read, and I'm not sure how easy it
is to get the right tools to format it to something readable. I think
texinfo is better in this respect; but this is only a personal
opinion, ultimately the choice is up to the people who actually write
What do other people think? Any strong opinions for/against DocBook?
problems have already been tackled by large projects who are already
using DocBook wholescale, like GNOME and KDE. We can offer separate
tarballs of the docs. Alternatively, GNOME uses makefile targets to
automatically generate and bundle the HTML docs into distributions
(meaning that only CVS developers need to generate them).
It seems the commonly agreed solution was to:
The thread evolved then with argueing on the good sides of DocBook,
including its use to generate API documentation (from comments
embedded in source code, as GTK+ and GNOME do).
- maintain a separate (from Wine) package of documentation in
- publish on WineHQ the various generated files (like HTML,
- include in Wine CVS tree (EdNote: perhaps for every Wine
snapshot) the generated pure TEXT files
Linux networking changes
Archive Link: "Linux 2.2.14 vs 2.3.x networking problem"
Berend Ozceri,�Alexandre Julliard,�,�Ove K�ven,�Marcus Meissner
Berend Ozceri reported:
I have a Windows application (Meeting Maker -
http://www.meetingmaker6.com) that works fine under the latest Wine
(built yesterday from CVS) using Linux kernel version 2.2.14. When I
switch to a 2.3.x kernel, the application has networking problems and
can't connect to a server.
After some analysis by Marcus Meissner and Ove K�ven, it turned out
that a specific change in 2.4 kernel series had a nasty side effect:
when using the poll function (as the Wine server heavily do for
sockets handling), there's a returned valid (POLLHUP) indicating that
the connection has hung up. Linux 2.4 changed its behavior and also
returned the POLLHUP value for not-yet-connected sockets. As a POLLHUP
is currently interpreted in Wine as (only) a closing connection, the
effective connection is never seen from Wine.
Alexandre Julliard proposed a direction for a fix, which Berend
implemented. But this lead to some other issues, meaning that this
issue is not over yet. No patch has been provided so far, so be
conscious of this pending networking issue on Linux 2.4 (and latest
2.3) kernels for Wine.
Sharon And Joy