Wine Traffic #33 For 6�Mar�2000

By Eric Pouech

Table Of Contents

Introduction

This is the 33rd 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 138 posts in 450K.

There were 39 different contributors. 21 posted more than once. 17 posted last week too.

The top posters of the week were:

1. SCSI support

�Archive Link: "SCSI: Here comes the changes"

People: David Elliot,�Alexandre Julliard,�,�Dave Elliot,�Eric Pouech

Dave Elliot sent the first round of a set of patches to revisit the SCSI support in Wine, and proposed the following architecture:

Alexandre Julliard quite didn't like it:
Hmmm... any reason this stuff (EN: the low level module) cannot remain in WNASPI32? I don't like the idea of adding more things into the Wine core and defining yet another internal interface; we already have way too many of them that will have to be cleaned up for correct dll separation.

Another issue was the parsing of /proc/scsi/scsi at startup ; Alexandre went on:
we are already doing too many things at startup; and having to parse /proc/scsi every time when 99% of the apps won't care a bit about SCSI is a bit wasteful.

The desired implementation would mean:

Eric Pouech also pointed out that similar handling should be applied to the CD ROM interfaces (which currently exists in the CVS tree on a mode closer to David's first proposal).

The thread finished in a more detailed discussion of file handle creation and management, as well as segmented address manipulation for the DOS API.

2. Builtin DLLs and real files

�Archive Link: "Fake builtin DLL file open"

People: Alexandre Julliard,�Andreas Mohr,�,�Marcus Meissner

(A very active this week) Andreas Mohr proposed a patch to work around a well known problem: some applications, for using a given DLL, try to find/open the file holding that DLL to see if it exists. This is rather annoying when the DLL is a builtin one (internal to Wine), because no file exists for it.

Andreas' proposal was to simulate a successful open operation when the filename matches the one of a builtin DLL.

Alexandre Julliard rejected the patch and asked rather to
simply have the install script create empty dll files in the Windows directory? Besides, with DLL separation, there won't be a global list of builtin dlls anymore.

Marcus Meissner pointed out that this might be problematic if the same application would peek version information from that very file.

Alexandre followed his first idea and proposed to, in a
next logical step, to store the version information in these files. Certainly better than magic pseudo-handles to non-existent files.

Andreas was upset by the configuration and maintenance issues generated by the numerous files to be generated at installation if Alexandre's idea was to be implemented. He went on with ideas of automatic reconfiguration (from Wine code) of the setup if it has been broken. Alexandre had his mighty gun handy:
Oh please... should we also include the whole source in the Wine executable so that we can automatically recompile libwine.so in case the user deleted it?

This is a packaging issue; we need to have proper install scripts, and users who don't know what they are doing should use an rpm or debian package that will do everything for them. This stuff does not belong in the Wine executable.

That convinced Andreas of the correctness of Alexandre's point of view, but made some new questions from Andreas: there's a need for some enhanced configuration script (like for getting the local computer name). Andreas was still willing to create an ad hoc init application (which could for example stored the desired values inside the registry), while Alexandre favored an option like, get it from the registry, if it's not there fetch it from Unix.

No final conclusion has been drawn in the thread, but Alexandre's proposal seems solid rock to build upon.

3. Debugging Wine with Microsoft tools

�Archive Link: "Creating a data section at the beginning of a .so"

People: Jeremy White,�Alexandre Julliard,�,�Bertho Stultiens

Jeremy White asked for some ELF twiddling he needed for some neat features:
We are closing in on complete support for the Microsoft Visual C++ debugger nub. That is, you can use Visi C++ to control an app under Wine. The last piece of the puzzle is having full symbolic and stack frame information available not just for application code but also for all Wine code.

To do that, we are taking a Wine .so file (e.g. libwine.so) and reporting it to Visi C++ as a DLL load event. In order for Visi C++ to then resolve addresses within that DLL, we have to create a PE header that encompasses all of the code within that .so file.

Currently, we've just done hack tests to prove the concept. That is, we just use the currently allocated PE header, create a dummy text section (filled with int 3's), and branch to an address within the text section. Get the break point, backtrace looks perfect.

Now, we're trying to do this correctly. IMHO this requires using a PE header that is prior to the text section of the .so file, so that it can encompass the text section. (We did in fact use a PE header that was disjoint from the text section, and we could make it work to resolve a symbol into the correct address. However, Visi C++ would not resolve the address back to the symbol unless the address fell within the range starting with the PE. You need address to symbol resolution in order for backtracing and other goodies to work).

Jeremy asked then what the best solution was to provide this .so library layout. He went on:
So, it is my belief that the best way to do this is to declare (only after a nasty configure option is selected, of course) a data block to hold the PE header, and arrange with ld for that data block to be placed immediately prior to the text section.

Some people, including Bertho Stultiens, approved Jeremy approach but feared that Alexandre would reject the use of a dedicated linker script. Alexandre replied:
I object on general portability principles, but if the advantages are big enough (or the alternatives too ugly) I can certainly consider it. I think building dlls will require some advanced tools anyway (like objdump -L etc.) so a linker script is not too bad, as long as linking statically remains possible without special magic.

4. Issue with glibc

�Archive Link: "Debian parted/libc bug fixed "

People:

Several people reported Wine crashing with the latest Debian. In fact, it's a bug in libc6 2.1.3, which has been fixed in 2.1.3-5 in potato. So, either upgrade your lib C, or set up in the shell context LC_ALL=en to work around the bug (in locale handling).

5. Wine RPMs

�Subject: "Wine binary RPM ?"

People: Robert Cunningham,�Linus Torvalds,�Alexandre Julliard,�,�Ove K�ven

This thread took place on comp.emulators.ms-windows.wine, but is rather interesting regarding the Wine's packaging.

Robert Cunningham expressed some bad feelings regarding Wine installation:
The past two Wine releases have seen my Wine performance actually decay to near zero, and I think part of the problem is that "make install" does not seem to follow FSH conventions for what files go where, while the binary RPMs I had used before managed this quite well.

On my system, the latest Wine release was completely unable to find its shared library files. After kludgeing a fix using soft links, Wine was then unable to find wine.conf. So I moved wine.conf. Then Wine generated errors about being unable to bind to many functions within mscrt32.dll (using "deadbeef" instead), then crashing when a "deadbeef" was accessed.

Rather than suggest that Wine itself is getting worse with time, it seems to me that the installation might not not keeping up with the needs of the program itself. The use of an RPM spec file may serve to make the installation easier to monitor and maintain.

So I humbly request that Source and Binary Wine releases should be generated in the RPM format, to make life (system and application management) easier for Wine users and testers who are not Wine developers. Sure, keep the tar.gz format (since it is easy to extract from the current CVS tree), but I would also recommend that the RPM spec files be added to the CVS tree, and that both the RPM spec files and the "make install" are check for conformance to the FSH.

Furthermore, if the needs of wine.conf change over time, a script should be included as part of the installation to at least detect out-of-date wine.conf files and allow the user to make needed updates before running an updated instance of Wine. Similar checks should be made for the PATH content. There should be little or no need to debug the Wine runtime environment every time Wine is updated.

I know this may be a lot to ask, but as Wine gets closer and closer to leaving alpha status, installation and environment issues will become ever more important. It may be best to start getting a better handle on them sooner rather than later, since this should also encourage more people to use Wine.

Ove K�ven tried to split the cause of Robert's issues between what falls inside wine developers's realm, and what is under the umbrella of the packagers themselves. Anyway, that's always a bad idea to mix RPM and self-compiled for the same software.

Then followed some flame-wars regarding packaging (Red-Hat's RPM versus Suse or Debian packaging).

A global agreement seemed to pop up regarding the role of distributors (make packages from the source tar ball) and development team (provide the source tar ball), but there's seem to be a demilitarized zone regarding who's in charge of providing installation script, or whether the source tar ball should contain some sample of a RPM packaging for example.

Even Linus Torvalds jumped in:
Guys, don't be assholes. There are tons of people out there that should be _encouraged_ to test out wine, without blaming them for a hard install. Do not get stuck in the old-time UNIX (and BSD and Debian) mentality of "it's supposed to be hard, because that's what makes you a man".

There was a reasonable cry for help and easier installation, don't miss the POINT of this all. Wine developers in particular should be aware of the fact that it's a good thing when programs are easy to use, install and play with, WITHOUT the kind of "go fix all your problems yourself" mentality...

Alexandre Julliard had the final word:
Please folks, let's keep our priorities straight. The real issue is that we need easy-to-install binary packages for people who want them; I think nobody will dispute that. Since I'm not releasing such packages myself (and this is not going to change) you need to take up whatever problems you encountered with the package maintainer, and help him improve the situation, or take over the job if necessary.

If the package maintainer feels that his job would be made easier by having a spec file in the CVS tree, I'm certainly open to discussing it. But it is not a miraculous solution that will suddenly make the packages work, for the obvious reason that the people who try the binary packages are precisely those who do not use the CVS tree.

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.