Wine Traffic #61 For 18�Sep�2000
Table Of Contents
This is the 38th 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 118 posts in 393K.
There were 49 different contributors.
26 posted more than once.
16 posted last week too.
The top posters of the week were:
- 13 posts in 73K by gerard patel <email@example.com>
- 6 posts in 15K by Andreas Mohr <firstname.lastname@example.org>
- 5 posts in 12K by Ove Kaaven <email@example.com>
- 5 posts in 10K by Alexandre Julliard <firstname.lastname@example.org>
- 4 posts in 9K by Uwe Bonnes <email@example.com>
- Full Stats
Archive Link: "Porting winelib to non x86 platforms"
Jeremy White,�Gavriel State,�Ulrich Weigand,�
Arie Tal asked what was the status about Wine portability across non
Jeremy White gave the outlook of the situation:
Gavriel State reported:
As far as porting Wine, I think the consensus is that it's probably
not worth it, due to performance issues. If anyone wishes to do this,
though (especially for Alpha), Compaq has told me that they would be
willing to release a free run time of their x86 emulator, so that this
could be done at high speeds. Ulrich also did a good deal of work on
As far as Winelib, I think the belief is that porting to a non x86,
Unix with X Windows should be fairly straightforward. There will be a
fair amount of work to find and remove all of the unknown bugs with
byte endianness and packing, but the fundamental design and plan for
Wine is to make this easy.
For non Unix and/or non X Windows systems (such as BeOS and MacOS), it
gets a little bit harder. BeOS seems to be much harder because it is
missing many systems calls that Wine relies upon (Patrik is the expert
on Be, and I believe there is a web page dedicated to Wine on
BeOS). MacOS <= 9 is similarly hard.
MacOS X, however, is another story. If you get an X server on MacOS X,
it should be pretty easy. If you want to do it the right way, you'd
need to develop a Carbon driver to parallel the Wine x11 driver. That,
while conceptually straightforward, will be a lot of work.
I got some simple winelib
apps up and running on LinuxPPC in early 1999, but it was fairly
hackish, and most of my changes didn't make it into the mainline WINE
tree. I did some work updating the port for newer releases of LinuxPPC
at MacHack this summer, but got stuck trying to figure out how to
properly deal with the thread local storage. My old code still works
ok though, if you happen to have a LinuxPPC machine around.
Ulrich Weigand spoke the last word, reporting he had Winelib working
but who would need winmine on S/390 ???
The main Wine tree doesn't compile out
of the box. There's still a few problems, mostly related to alignment
issues, that I haven't yet fixed in a clean way.
On machines without alignment constraints (even if big-endian), there
shouldn't be much changes necessary. For example, just for fun I tried
to get Wine to compile on S/390; it took me only a few hours until
WineMine was running ...
Implementing CRTDLL or not (cont'd)
Archive Link: "CRTDLL Qtns"
Jonathonm Griffiths,�Alexandre Julliard,�,�Gav State,�Jonathon Griffiths
Jonathon Griffiths, continuing his CRTDLL effort (please refer to
BROKEN KCREF), asked a few
On the #include part, everyone agreed that Wine's internal process.h
include file should be moved to Wine only include directories, and a
conformant process.h should be created in the include directory.
On the thread safeness issue, Alexandre Julliard was strongly against
making CRTDLL thread safe: it isn't under Windows, so it shouldn't be
under Wine. Gav State, however, did like the idea of using CRTDLL but
still having thread safeness. Alexandre wasn't still convinced, and
preferred to have Wine also to provide a native msvcrt.dll (which
would be thread safe).
Locking: at some point I will need to add locking
code for MT safety. Are there any issues (performance?) I need to be
aware of using the win32 locking functions in the dll?
Thread-safe: MS docs state that crtdll is not very
thread-safe, however I can't see any reason why wines shouldn't be. I
don't think any apps depend on non thread-safe behavior since by
definition it is unpredictable. So I think it may be worthwhile to
make it MT safe. This would mean a large part of the code could be
shared with msvcrt.dll (way in the future).
#includes: Wine's "process.h" will conflict with the
crt "process.h". Is it desirable to have crt headers in the wine
include dir, or should they be in include/crt? (note I wont be writing
headers for some time).
Archive Link: "Mailing list cutover"
Doug Ridgway,�,�Douglas Ridgway
Douglas Ridgway announced:
We're going to try to
cut over the mailing lists from the old server to the new server
today. Hopefully, we will be able to not lose subscription info
etc. The current plan is to change over to using majordomo at the same
time -- I'll provide some details once it's done.
Even if some people objected the use of majordomo and preferred
mailman, the move has taken cleanly (YMMV), and the good part of it is
that the NNTP access to
is back online.
Solving the native DLL look-up
Archive Link: "solution for /usr/lib/wine library search problem"
,�G�rard Patel,�Ove K�ven,�Steve Langasek
Ove K�ven, while browsing the Debian Wine bug database, ran into a
user's proposal which pleased him well. Lots of users had a hard time
configuring Wine; Wine installs (by default) its .so files in
/usr/lib/wine, which requires that either /etc/ld.conf or
LD_LIBRARY_PATH to list this directory in the to search for
list. However, some RPM installations (and lots of by hand
installations) forgot to do so, leading to numerous but irritating
questions on comp.emulators.ms-windows.wine newsgroup.
The main idea of the patch is to make use in the .so file link option
of the -rpath option, which tells where to look for the .so
file. Currently, the build options were pointing to /usr/lib instead
However, Ove also wanted to be able to drive this directory with a
--dlldir option in configure. Steve Langasek proposed a quick way of
G�rard Patel also expressed his will to still be able to keep several
Wine binary trees in parallel (for testing reasons). Ove didn't think
this should be too much of a problem, even if the details haven't
sorted out yet.
This small patch should definitively help in installing Wine.
Sharon And Joy