![[LWN Logo]](/images/lcorner.png) |
|
![[Timeline]](/images/Included.png) |
Date: Wed, 20 Sep 2000 06:02:48 +0000
From: Eric Pouech <Eric.Pouech@wanadoo.fr>
Newsgroups: comp.emulators.ms-windows.wine
To: "Wine announce (WWN publish)" <wine-announce@winehq.com>
Subject: Wine Weekly News #61 (2000 Week 38)
This is a multi-part message in MIME format.
--------------4D0283C8BB688001626343AF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please find enclosed this week edition. Enjoy.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
--------------4D0283C8BB688001626343AF
Content-Type: text/plain; charset=iso-8859-1;
name="wwna.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
filename="wwna.txt"
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for September
18, 2000.
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
* WineHQ mailing lists cut over to Corel machine, changed to
Majordomo (2000-09-16).
* ...
_________________________________________________________________
Keeping Track of Wine
_________________________________________________________________
* ...
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 118 posts consumed 393 K. There were 49 different
contributors, 26 (53%) posted more than once, and 16 (32%) posted
last week too.
The top posters of the week were:
* 13 posts in 73 K by gerard patel <g.patel@wanadoo.fr>
* 6 posts in 15 K by Andreas Mohr <a.mohr@mailto.de>
* 5 posts in 12 K by "Ove Kaaven" <ovehk@ping.uio.no>
* 5 posts in 10 K by "Alexandre Julliard" <julliard@winehq.com>
* 4 posts in 9 K by Uwe Bonnes
<bon@elektron.ikp.physik.tu-darmstadt.de>
* 4 posts in 9 K by Eric Pouech <Eric.Pouech@wanadoo.fr>
* 4 posts in 7 K by "Dmitry Timoshkov" <dmitry@sloboda.ru>
* 4 posts in 19 K by mogul-wine-devel@gelatinous.com
* 4 posts in 12 K by David.Goodenough@dga.co.uk
* 3 posts in 8 K by "Jeremy White" <jwhite@codeweavers.com>
* 3 posts in 8 K by "Dimitrie O. Paun" <dimi@cs.toronto.edu>
* 3 posts in 7 K by "Stephane Lussier" <stephane@macadamian.com>
* 3 posts in 6 K by Ulrich Weigand
<weigand@immd1.informatik.uni-erlangen.de>
* 3 posts in 6 K by Christopher Morgan <cmorgan@WPI.EDU>
* 3 posts in 50 K by Jutta Wrage <jw@witch.westfalen.de>
* 3 posts in 5 K by Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* 3 posts in 5 K by Douglas Ridgway <ridgway@winehq.com>
* 3 posts in 32 K by Rein Klazes <rklazes@casema.net>
* 3 posts in 16 K by lawson_whitney@juno.com
* 3 posts in 14 K by "Serge Ivanov" <oponvybl@umail.corel.com>
* 3 posts in 10 K by "Douglas J. Hunley" <dhunley@columbus.rr.com>
Winelib portability Issue
Arie Tal asked what was the status about Wine portability across non
x86 platforms.
Jeremy White gave the outlook of the situation:
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 this.
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.
Gavriel State reported:
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
on Sparc:
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 ...
but who would need winmine on S/390 ???
Implementing CRTDLL or not (cont'd) Evolution
Jonathon Griffiths, continuing his CRTDLL effort (please refer to
[1]previous article), asked a few more questions:
+ 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).
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).
Mailing list Evolution
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 [2]wine-devel, [3]wine-announce,
[4]wine-patches and [5]wine-cvs is back online.
Solving the native DLL look-up Evolution
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 of
/usr/lib/wine.
However, Ove also wanted to be able to drive this directory with a
--dlldir option in configure. Steve Langasek proposed a quick way of
doing it.
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.
Credits: [6]Doug Ridgway, [7]Eric Pouech, and [8]Ove Kåven.
_________________________________________________________________
References
1. http://www.winehq.com/News/2000-14.html#3
2. news://winehq.com/wine.devel
3. news://winehq.com/wine.announce
4. news://winehq.com/wine.patches
5. news://winehq.com/wine.cvs
6. mailto:ridgway@winehq.com
7. mailto:pouech@winehq.com
8. mailto:ovek@winehq.com
--------------4D0283C8BB688001626343AF--