Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #49 For 26 Jun 2000

By Eric Pouech

Table Of Contents

Introduction

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:

1. Wine status page

19 Jun 2000 (3 posts) Archive Link: "Wine Status percentage"

People: 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 anything complicated...

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 done).

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 Unicode implementation.

2. Wine .so files loading

16 Jun 2000 - 19 Jun 2000 (12 posts) Archive Link: "builtin .so load dependencies"

People: 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

This shall require some extra work on Wine (like rewriting the .so file generation, as well as cleaning up the dependencies between DLLs).

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
The EXTRA_LD_LIBRARY_PATH was never intended to work with builtin DLLs.

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.

Ove proposed then to drop (until ElfDll are in place) the EXTRA_LD_LIBRARY_PATH use ; Alexandre suggested to
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.

3. Wine documentation

21 Jun 2000 - 23 Jun 2000 (30 posts) Archive Link: "Wine CVS Documentation"

People: John R Sheets, Alexandre Julliard, , codeweavers, Eric Pouech

John R Sheets wrote:
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 http://wine.codeweavers.com/docs/

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.

Later on, John also posted an outline of a possible table of content.

Several peopled enhanced the proposal:

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
the important 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 the doc.

What do other people think? Any strong opinions for/against DocBook?

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 style sheets).

John Sheets proposed for dealing between editing documents (in DocBook DTD, and generated ones - text, HTML...):
These 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).

4. Linux networking changes

21 Jun 2000 - 22 Jun 2000 (8 posts) Archive Link: "Linux 2.2.14 vs 2.3.x networking problem"

People: 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
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.