Wine Traffic #33 For 6 Mar 2000
Table Of Contents
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:
- 22 posts in 95K by Andreas Mohr <email@example.com>
- 17 posts in 34K by Alexandre Julliard <firstname.lastname@example.org>
- 13 posts in 58K by David Elliott <email@example.com>
- 7 posts in 18K by Uwe Bonnes <firstname.lastname@example.org>
- 6 posts in 58K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- Full Stats
Archive Link: "SCSI: Here comes the changes"
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:
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
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.
- maintain a WINASPI/WNASPI32 DLL pair containing all the
relevant SCSI code (even the current SCSI configuration lookup in
- this DLL pair would be used by any other part of Wine
needing it (like the DOS SCSI API, or NT SPTI) (meaning loading the
DLL when needed)
- at DLL load time, the configuration will be read
(including the /proc/scsi/scsi parsing)
Builtin DLLs and real files
Archive Link: "Fake builtin DLL file open"
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
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:
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.
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.
Debugging Wine with Microsoft tools
Archive Link: "Creating a data section at the beginning of a .so"
Jeremy White, Alexandre Julliard, , Bertho Stultiens
Jeremy White asked for some ELF twiddling he needed for some neat
Jeremy asked then what the best solution was to provide this .so
library layout. He went on:
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).
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.
Issue with glibc
Archive Link: "Debian parted/libc bug fixed "
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).
Subject: "Wine binary RPM ?"
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
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:
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"
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.
Alexandre Julliard had the final word:
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...
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