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.

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:

• 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

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.

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.

• OVERVIEW
  For beginning users; assumes Wine is already installed. Very simple language; task-based.
  1. Introduction
     • What is Wine?
     • How do I run Wine?
  2. 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.
  1. Introduction
     • What forms does Wine take?
  2. Installing on Redhat/Mandrake/SUSE
  3. Installing on Debian
  4. Installing from FTP
  5. Installing from CVS
  6. Configuring Wine
     • Setting up wine.conf
     • With Windows Partition
  7. Graphical Configuration
     • Using TkWineSetup
     • With GNOME Control Center (NYI)
     • With KDE Control Panel (NYI)
  8. 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.
  1. Introduction
  2. Running Wine
     • Simplest case
     • Command line parameters
  3. Configuring Wine
     • Customizing .winerc
     • Builtin vs. native DLLs
     • x11drv
     • Look & feel
     • Keyboard
  4. Networking
  5. Printing
  6. Fonts
  7. Multimedia
  8. Security
  9. OpenGL
  10. Troubleshooting
      • Making a bug report
      • Common debug flags
  11. FAQ
• WINE APPLICATIONS GUIDE
  For dealing with specific applications.
  1. MS Office
  2. Lotus Notes
  3. Quicken
  4. StarCraft
  5. ...
• WINE PORTING GUIDE
  For developers trying to migrate their apps to UNIX, using Wine.
  1. Introduction
  2. Binary emulation
  3. WineLib
  4. FAQ
• 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.
  1. Architecture
     • The Wine Server
     • DLLs in Wine
     • Drivers
     • The Kernel
     • The graphics subsystem
     • OLE Support
     • Unicode
  2. Debugging Wine
     • Debugging channels
     • The Wine debugger
  3. Tools
     • wrc
     • wmc
     • winapi_check
     • build.c
     • Misc. scripts
  4. Policies & Procedures
     • Preparing a patch
     • Documentation

Several peopled enhanced the proposal:

• 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.

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:

• maintain a separate (from Wine) package of documentation in DocBook format,
• publish on WineHQ the various generated files (like HTML, text...)
• include in Wine CVS tree (EdNote: perhaps for every Wine snapshot) the generated pure TEXT files

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

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.