This is release 20010326 of Wine, a free implementation of Windows on
Unix. This is still a developers only release. There are many bugs
and unimplemented features. Most applications still do not work
correctly.
Patches should be submitted to "wine-patches(a)winehq.com". Please don't
forget to include a ChangeLog entry.
WHAT'S NEW with Wine-20010326: (see ChangeLog for details)
- Serial async I/O improvements.
- Support for app-specific dll overrides in config file.
- Lots of bug fixes.
See the README file in the distribution for installation instructions.
Because of lags created by using mirror, this message may reach you before
the release is available at the ftp sites. The sources will be available
from the following locations:
http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010326.tar.gzftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wi…ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/develo…
ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/Wine-20010326.tar.gz
It should also be available from any other site that mirrors ibiblio.org.
For more download locations, see http://ftpsearch.lycos.com. These
locations also hold pre-built documentation packages in various
formats: wine-doc-html.tar.gz, wine-doc-txt.tar.gz, wine-doc.pdf.gz
and wine-doc.ps.gz.
You can also get the current source directly from the CVS tree. Check
http://www.winehq.com/dev.html for details.
If you submitted a patch, please check to make sure it has been
included in the new release.
If you want to receive by mail a patch against the previous release
when a new one is released, you can subscribe to the mailing list at
http://tiger.informatik.hu-berlin.de/cgi-bin/mailman/listinfo/wine-patches.
Wine is available thanks to the work of many people. See the file
AUTHORS in the distribution for the complete list.
--
Alexandre Julliard
julliard(a)winehq.com
enjoy this week edition.
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for March 12,
2001 .
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
Daniel Schwarz' web site ([1] http://www.winecentric.com/) has been
completely revamped and now has expanded coverage: in addition to the
existing coverage of Lotus Notes, info for Microsoft Excel '97 have
been added (How to install, how to use, tips and tricks, etc).
_________________________________________________________________
Keeping track of Wine
_________________________________________________________________
* Andreas Mohr contributed a winecheck script that lets users check
that Wine is configured somewhat correctly.
* Alexandre Julliard made the wineserver protocol reentrant.
* Ian Pilcher moved the PostScript AFM loader's previously hardcoded
font paths into .wine/config instead.
* Other Workers/Bugfixers: Marcus Meissner (KDE2 support), Gerard
Patel (misc dialogs and menus), Mike McCormack (overlapped I/O),
Rein Klazes (message conversion), James Juran (win98/2000 stubs),
Nerijus Baliunas (Latvian), Hann-huei Chiou (Chinese)
+ CodeWeavers: François Gouget (winemaker), Dmitry Timoshkov
(edit/combobox control), Huw D M Davies
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 30 posts consumed 128 K. There were 16 different
contributors, 4 (25%) posted more than once, and 6 (37%) posted
last week too.
The top posters of the week were:
* 9 posts in 31 K by "Alexandre Julliard" <julliard(a)winehq.com>
* 5 posts in 28 K by David Howells <dhowells(a)cambridge.redhat.com>
* 2 posts in 7 K by Gavriel State <gav(a)transgaming.com>
* 2 posts in 24 K by Michael McCormack
<mccormac(a)aals27.alcatel.com.au>
Enhanced asynchronous I/O Evolution
Michael McCormack provided a first version of a patch to enhance the
I/O operations in Wine:
This patch moves responsibility for asynchronous I/O to the client
process.
I think this implementation is more efficient, as it makes fewer
server calls and duplicates fewer file descriptors, while
maintaining correctness.
However, Mike requested some feedback on his patch.
Alexandre Julliard objected several points:
* first of all, the patch conflicted with underway work from
Alexandre: "your approach is not going to work with the latest
changes I made to the server. The good news is that the changes
I'm making are in part to allow making server calls in signal
handlers, so when this works you should be able to use SIGIO to do
async IO."
* secondly, Alexandre really doubted the patch improved the
performance.
Mike tried to defend a bit his changes (especially, in the area of
performance, where Mike thought he drastically reduced the number of
context switches and the number of server calls), but Alexandre
remained dubious: "Reducing the number of server calls but making them
more expensive is not necessarily a gain. Show me the numbers..."
Later on, Mike provided a second patch (a derivation of the first one,
making use of Alexandre's latest improvements on the server
communication protocol). Here are the final results of a simple test
program Mike wrote (against Wine 2001/03/05):
Wine's patch average write time for "AT" command average read time for
response
vanilla 675 µsec 634 µsec
Mike's patch 362 µsec 322 µsec
Sounds like a big gain!!!
However, this doesn't fix one of Alexandre favorite topics: getting
rid of the service thread (it's only use as of today is the handling
of asynchronous requests). Using (SIGIO) signals should help getting
rid of it.
So, this discussion is likely not finished yet. We'll keep you posted
with its follow-up.
Wine's speed up (cont'd) Evolution
Following [2]last weeks' discussions , David Howells, Alexandre
Julliard and Gavriel State resumed their exchanges.
David re-iterated his "main gripe against the slow speed of access to
files... Every Read/WriteFile goes to the wineserver to convert the
handle into a file descriptor and to check for locking. The FD is then
passed back over a UNIX domain socket, used once and then closed."
Alexandre Julliard explained this had just been enhanced: the file
descriptor is only transferred once. All subsequent accesses only
check if the file descriptor on client's side is still valid, hence
reducing the complexity and the length of the server call (but, not
the number of calls).
The latency of the Wine server call is rather high as David explained:
Context switching is the main element of it. Going to the wineserver
and back again just for a ReadFile() call or a Wait*() function
incurs a fairly serious penalty (particularly on an X86, I think).
Plus there's no requirement for the kernel to pass the remains of
your timeslice to the wineserver and back again.
Since the context switch also implies that "you have to flush all the
CPU caches, muck around with the MMU and execute scheduling
algorithms", this can explain some of the latency.
However, Alexandre thinks "that it should be possible to improve that
by a small kernel hack. It will never be as fast as doing everything
in the kernel of course, but it may just be fast enough to avoid the
need to reimplement the whole server." and that "we are doing more
than two switches (though I haven't proved it), which is why I think
there is a margin for improvement. You'll obviously always have the
context switch cost unless everything is in the kernel."
By a small kernel hack, Alexandre means " having a specialized fifo, a
network protocol, an ioctl, etc. Basically any mechanism that ensures
that we do the strict minimum number of context switches and
schedule() calls for a server call. And probably also a way to
transfer chunks of memory from the client address space so that we
don't need the shared memory area. ". David already suggested a new
protocol (AF_WINE) which could nicely fit into this category (and also
let the ability to use the internal API on non Linux platforms,
although the kernel module had to be rewritten).
David also asked Alexandre how does he "plan on doing the locking
stuff for Read/WriteFile? Cache it locally? It is unfortunate, but you
can't really make use of UNIX file locking, since this is mostly
advisory and as such doesn't actively stop read/write calls.".
Alexandre quickly replied "Yes, we'll need to store the locks in the
server and check them before each read/write (and probably also
release them afterwards if necessary). There may be some optimizations
possible, but we should probably do it the easy way first.". This
would, of course, require some more server calls.
Later on, Gavriel explained that Alexandre would unlikely accept a
huge patch at once, and that he'd rather have an incremental approach.
Alexandre answered, but also spoke out some directions for adding such
a kernel module David is working on into Wine:
The kernel module itself may be hard to do incrementally, but you
should really consider reusing the existing server API so that
your module can be plugged in easily. For instance your module
entry points should be the same as the server requests, and use
the same request structures.
As a reminder, David used the int 0x2E trap (as any NT system does) to
hook the kernel module up to the Wine code, putting more into the
Linux kernel than Wine currently does with its wineserver. However,
this introduces another API into Wine, and makes it quite difficult to
maintain the two APIs (the INT 0x2E and the wineserver's).
Alexandre explained what he had in mind a bit more clearly: "I'm not
suggesting keeping the current socket stuff, just reusing the
structures. So basically instead of passing the address of the stack
arguments (which is really ugly IMO) to your ioctl, you pass one of
the server request structures. This allows your changes to be
localized to wine_server_call and doesn't require changing any of the
routines that make server calls. Obviously you'd need some more
changes for a few calls like ReadFile/WriteFile, but most operations
could switch to your mechanism without needing any change. You simply
cannot require people to recompile all of Wine to use your module."
David also pointed out some strange issues with Wine loader. After
some discussion, it turned out that alignments required by mmap did
change between Linux 2.2 and 2.4. Wine did made the assumption that
"Page alignment is needed for the address in memory, not for the
offset inside the file on disk; since section virtual addresses in PE
files are always page-aligned the memory address is never a problem.
The only problem comes from the alignment of the data inside the PE
file, and this is where we only need block-size alignment to make mmap
possible." David also proposed some enhancements for the Linux 2.4
kernel.
As a (temporary) conclusion, the area of optimizing the Wine
architecture is still under heavy discussion. Many tracks are
available, and the potential results/benefits are still not 100%
clear. On the bright side, there's still lots of space for
improvement.
Credits: [3]Doug Ridgway, [4]Eric Pouech, and [5]Ove Kåven.
_________________________________________________________________
References
1. http://www.winecentric.com/
2. http://www.winehq.com/News/2001-10.html#0
3. mailto:[email protected]
4. mailto:[email protected]
5. mailto:[email protected]
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for March 05,
2001 .
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
Wine-20010305 has been released. Main changes include:
* Some improvements to the wineserver protocol.
* The usual common controls fixes/improvements.
* Version information in builtin dlls.
* Lots of bug fixes.
_________________________________________________________________
Keeping track of Wine
_________________________________________________________________
The following changes from the last two weeks made it into the
20010305 release.
* Alexandre Julliard optimized wineserver communication some more
(including better file descriptor caching), and strived for more
DLL separation cleanliness.
* Dmitry Timoshkov (CodeWeavers) added version resources to the core
built-in dlls.
* Eric Pouech implemented some shell32 rundll features (making the
control panel starting to work).
* David Grant added some copy and delete functions to the shell
filedialog.
* Workers/Bugfixers: Andreas Mohr (misc), Gerard Patel (16-bit print
dialog, misc), Michael Stefaniuc (Winsock routing table query),
Ian Pilcher (PostScript driver), Johannes Schindelin (German
keyboard layout), Ove Kåven (winelauncher), Lionel Ulmer (OpenGL
support), Vedan Rodic (DIB depth conversion), Przemyslaw Bruski
(Mac codepage in locales), Valery Kartel (Ukrainan locale),
Dominik Strasser, Chris Jacobson
+ CodeWeavers: François Gouget (winelib, winemaker, listview
control), Dmitry Timoshkov (controls, windows, ANSI
fileapis), Susan Farley (pager control), Aric Stewart
(clipboard), Chris Morgan (mousewheel sysparam)
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 45 posts consumed 190 K. There were 20 different
contributors, 11 (55%) posted more than once, and 9 (45%) posted
last week too.
The top posters of the week were:
* 7 posts in 17 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr>
* 6 posts in 38 K by "Alexandre Julliard" <julliard(a)winehq.com>
* 5 posts in 17 K by Ian Pilcher <pilcher(a)concentric.net>
* 3 posts in 9 K by lawson_whitney(a)juno.com
* 3 posts in 23 K by Michael McCormack
<mccormac(a)aals27.alcatel.com.au>
* 2 posts in 9 K by David Elliott <dfe(a)infinite-internet.net>
* 2 posts in 8 K by Andreas Mohr <a.mohr(a)mailto.de>
* 2 posts in 6 K by Vedran Rodic <vedran(a)renata.irb.hr>
* 2 posts in 5 K by Francois Gouget <fgouget(a)free.fr>
* 2 posts in 4 K by "Ove Kaaven" <ovehk(a)ping.uio.no>
* 2 posts in 0 K by Robert O'Callahan <roc+(a)cs.cmu.edu>
Wine's speed-up Evolution
(EdNote: resurrecting [1]old article) Gavriel State put out a speed
issue in current Wine code:
We've recently been working on getting American McGee's Alice (a
visually stunning game, if you haven't seen it before) running
well under Wine, and we've run into a serious speed issue with
synchronization objects like Mutexes.
Currently, Alice runs at about 50% the framerate it gets in
Windows with the same graphics driver (NVidia). When we started
investigating, it turned out that the reason for this is that it's
spending half of it's time in the WineServer. At first we assumed
that this was due to the fact that the GL thunks need to grab the
X11 lock. We realized that this wasn't necessary for most GL calls
if we're using a direct rendering GL implementation, and turned
off the locks. There was no effect - because there really wasn't
much contention for the x11 lock.
After going through a number of similar Wine internal
possibilities and getting nowhere, we finally realized that the
problem was the app itself. It's grabbing and releasing a mutex of
it's own bazillions of times each frame. Since there's nothing
much we can do about that we started thinking about the proposed
linux kernel module approach. After re-reading the thread (EdNote:
you call also look at [2]WWN coverage part #1 and [3]WWN coverage
part #2) and looking over the prototype, I have to concur with
Alexandre's judgement - the prototype that exists is trying to do
too much work.
Gavriel and Ove Kaaven proposed to use a shared memory section between
every process and the Wine server to help speeding up the lock/unlock
operations.
Alexandre Julliard didn't like the approach at all:
I don't see how you are going to make this work reliably. A basic
design principle of the server is that no matter what a client
process does, it cannot break either the server or other clients;
given the number of bugs Windows apps contain, I feel this is very
important.
As soon as you introduce a shared memory area, you need the
collaboration of all clients to ensure the stability of the whole
system, since any client can corrupt system data structures. This
is very bad. Also since the server is single-threaded its data
structures don't need to be protected; but as soon as you
manipulate them from multiple threads you need locking mechanisms,
which will probably cost a lot in performance too.
Gavriel tried to minimize the impact on system stability of his
proposal, but he couldn't convince Alexandre of it.
Robert O'Callahan put on the table some other algorithms to tackle the
issue. Unfortunately, they either required some "ugly" (read not
accepted by Alexandre Julliard features) like letting the wine server
call back some function on the client side, or using the already
rejected shared memory approach.
As a conclusion (since none went out of the discussion), it may be
possible that Gav (with TransGaming) writes an almost right but quick
implementation of the mutexes, but which wouldn't be commited into the
main Wine tree because it wouldn't be completely right.
Wine press coverage Report
Eric Pouech posted a link to a [4]C|Net article, making a comparison
of three Linux products, letting Windows applications run on Linux.
Those products are Wine (of course), VMware and Win4Lin.
The article is pretty much product (and end user) oriented, hence the
final bad ranking for Wine (so far, the Wine had put more effort into
adding feature, rather than putting a 1.0 version). However, the
potential for Wine is here. It just needs some more (oouch) work to
terminate the developments.
Here are the overall comparison from the CNET Linux Center's review by
Bill O'Brien:"
Product Overall rank (1..10) The good The bad The bottom line
VMware Workstation 2.03 9 Provides a self-contained Windows
environment that makes its Linux host platform nearly immune to
collateral damage. It's expensive. VMware is an essential IS tool for
multiplatform application management.
NeTraverse Win4Lin 2.0 7 Simple installation; good documentation;
works as promised. No DirectX or Windows networking support. Win4Lin
is a bargain Windows emulation platform if you need just the basics.
Wine 5 Runs Windows apps without Windows; strong user community
Difficult to use; spotty application support; still under heavy
development. With its innovative approach to Windows compatibility,
Wine is destined to play a major role in the world of Linux. But for
now, it's not quite ready for prime time.
"
C Code style Evolution
After an unwanted semi-colon had been found where it shouldn't: loops
of the form:
for (i = nFirst; i <= nLast; i++);
{
/* do something */
}
, Andreas Mohr proposed several things.
First of all, he wanted to add a space between the closing parenthesis
and the semi-colon to indicate clearly the intent of putting an empty
C expression. François Gouget replied he preferred the writing of such
cases as
<init_expression>;
while (<test_condition>) {
<update_expression>;
}
Alexandre Julliard more than agreed: he converted such cases into the
while form of the loop.
Andreas also looked for other places plagued with the same default and
found another one (which he of course fixed).
Unsurprinsignly, this almost started a flame war on coding style (how
many spaces for a tab, which indentation style...). But it didn't
happen. Wine developers seemed to like sticking to the rule of letting
the developer do what best fits him (her), even if this doesn't
provide a consistent coding style across the source files.
Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove Kåven.
_________________________________________________________________
References
1. http://www.winehq.com/News/2001-08.html#4
2. http://www.winehq.com/News/2000-36.html#3
3. http://www.winehq.com/News/2000-37.html#0
4. http://linux.cnet.com/linux/0-2136864-7-4961586.html
5. mailto:[email protected]
6. mailto:[email protected]
7. mailto:[email protected]
This is release 20010305 of Wine, a free implementation of Windows on
Unix. This is still a developers only release. There are many bugs
and unimplemented features. Most applications still do not work
correctly.
Patches should be submitted to "wine-patches(a)winehq.com". Please don't
forget to include a ChangeLog entry.
WHAT'S NEW with Wine-20010305: (see ChangeLog for details)
- Some improvements to the wineserver protocol.
- The usual common controls fixes/improvements.
- Version information in builtin dlls.
- Lots of bug fixes.
See the README file in the distribution for installation instructions.
Because of lags created by using mirror, this message may reach you before
the release is available at the ftp sites. The sources will be available
from the following locations:
http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20010305.tar.gzftp://ftp.infomagic.com/pub/mirrors/linux/sunsite/ALPHA/wine/development/Wi…ftp://ftp.fu-berlin.de/unix/linux/mirrors/sunsite.unc.edu/ALPHA/wine/develo…
ftp://orcus.progsoc.uts.edu.au/pub/Wine/development/Wine-20010305.tar.gz
It should also be available from any other site that mirrors ibiblio.org.
For more download locations, see http://ftpsearch.lycos.com. These
locations also hold pre-built documentation packages in various
formats: wine-doc-html.tar.gz, wine-doc-txt.tar.gz, wine-doc.pdf.gz
and wine-doc.ps.gz
You can also get the current source directly from the CVS tree. Check
http://www.winehq.com/dev.html for details.
If you submitted a patch, please check to make sure it has been
included in the new release.
If you want to get the new releases faster, you can subscribe to the
wine-patches mailing list by sending a mail containing 'subscribe
wine-patches your_address' to majordomo(a)tiger.informatik.hu-berlin.de.
You will get a patch against the previous release when a new one is
released.
Wine is available thanks to the work of many people. See the file
AUTHORS in the distribution for the complete list.
--
Alexandre Julliard
julliard(a)winehq.com
please find enclosed the latest WWN issue
A+
--
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
Wine Weekly News
All the News that Fits, we print.
Events, progress, and happenings in the Wine community for February
26, 2001 .
_________________________________________________________________
_________________________________________________________________
Discussions on wine-devel
_________________________________________________________________
This week, 67 posts consumed 246 K. There were 32 different
contributors, 12 (37%) posted more than once, and 14 (43%) posted
last week too.
The top posters of the week were:
* 9 posts in 20 K by "Ove Kaaven" <ovehk(a)ping.uio.no>
* 6 posts in 26 K by Eric Pouech <Eric.Pouech(a)wanadoo.fr>
* 6 posts in 23 K by "Alexandre Julliard" <julliard(a)winehq.com>
* 5 posts in 28 K by Ian Pilcher <pilcher(a)concentric.net>
* 4 posts in 12 K by FT Rathore <mawali(a)news.icns.com>
* 3 posts in 7 K by Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at>
* 3 posts in 10 K by Andreas Mohr <a.mohr(a)mailto.de>
* 3 posts in 0 K by Robert O'Callahan <roc+(a)cs.cmu.edu>
* 2 posts in 7 K by "Patrik Stridvall" <ps(a)leissner.se>
* 2 posts in 6 K by gerard patel <gerard.patel(a)asi.fr>
* 2 posts in 5 K by David.Goodenough(a)dga.co.uk
* 2 posts in 23 K by Martin Pilka <mpilka(a)codeweavers.com>
local IP and registry Issue
Alan Chandler wrote: "I spent most of the weekend trying to get Grand
Prix Legends GPL to work. I achieved my first goal of getting it to
run in server mode.
One of the things I needed to get the game to do, was to recognize
that there where some interfaces it could talk TCP/IP out of. It took
me some time to realize that under windows it was doing this by
looking for the key
[System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then
enumerating the keys under it to establish an IP address ie the
following:
[System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000]
"IPAddress"="10.0.10.100"
The thought occurred to me that maybe the tool the builds the registry
during wine install could actually create these keys - since it is
essentially a key part of the system (and other similar keys are also
built in the same way).
"
Ove Kaaven agreed on the utility of the key itself, but noted that
"the IP address can change between Wine invocations (PPP, DHCP, and
things like that), so it would have to be a dynamic key, generated at
Wine startup or something like that."
There is already some keys which are dynamically generated (like the
processor information - Pentium, stepping... - or copying the contents
of the init files into Wine specific registry keys to ease the reading
of those configuration afterwards), so the approach could be extended.
However, Ove wondered how the network interfaces could be gotten from
the OS in a portable way ? There hasn't been any answer so far.
Setting up a Wine's test harness Evolution
John Sturtz (re)-opened the long awaited issue of bringing up a test
harness for Wine (and its implementation of the Windows API).
I work for CodeWeavers here in St Paul. Awhile back, I was set to the
task of working on winetest, a Wine application which provided a
flex/bison-based parser for a little scripting language from which
Wine API functions could be called. The idea was that one could
write test scripts which would call Wine API functions and examine
the results, and the scripts could be used for regression testing
of Wine.
The scripting language began life with a rather Perl-ish syntax,
and as functionality got added, it got more so. Eventually (about
the time I had implemented a pack function, and wanted an unpack),
I decided to see if I could write a Perl extension that provided a
gateway for calling Wine API functions. That way, scripts for
regression testing could be written directly in Perl instead.
John then provided a first implementation of this (you can find it at
[1]ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz).
Basically, what you can do with this is invoke some tests like:
$atom = kernel32->GlobalAddAtomA("bark");
Joshua Thielen pointed out that some existing Perl modules for Win32
(from the [2]ActiveState site) allowed to provide the same interface
as John's work (which was Linux based only). Alan Gonzalez also noted
that this "will work out of the box on cygwin for windows using the
perl 5.6.1 that is bundled with it." Jeremy White then started to
figure out what the test harness should contain: "I think it would be
great if we could start to define (and build) a test harness. I think
that there are a lot of people who would help write test scripts, who
might otherwise be unable to help with Wine development. The more the
merrier, I always say... "
Jeremy started to split out the test cases into two categories:
* non-interactive: no user interaction is needed
* interactive: user interaction is needed
As already covered (see [3]this article ), a free test tool for X11
regression test has not been found yet, making the second category a
bit difficult to run.
Eric Pouech proposed to have a two pass approach to run the test.
First the test case is run and outputs some results which are stored
into a file. Then, the contents of this file is compared against a
reference file.
This would allow, beyond the simple regression idea - running twice
the same program should provide the same results -, to compare the
output between running the program under Windows and running it under
Wine.
Eric also liked to idea of writing test cases in C which would allow
to test three cases:
* test case compiled and run under Windows,
* test case compiled under Windows, and run with wine
* test case compiled under Unix as a Winelib application
Alexandre Julliard really backed up the idea of the Perl test scripts:
"The idea of using an interpreter like Perl is precisely that you
don't need to compile anything to run tests. I think this is important
because not everybody has a Windows compiler. It also allows using the
exact same test script under Windows and Wine, so that you don't have
to worry whether your Windows binary exactly matches your Winelib
binary. "
Eric and Alexandre further argued whether it was more common not to
find a compiler or not to find a Perl interpreter on a PC/Windows box.
François Gouget also liked the C/C++ tests because " The downside of
interpreter-based tests are:
* they won't test the Winelib headers or Winelib specific issues
* I imagine that some of our potential test writers would be windows
programmers (after all these tests would be nothing more than
simple Windows applications). They would probably be more
comfortable writing tests in C/C++.
"
The thread ended with Eric and Alexandre still arguing on some other
points. All the details of the test harness are not settled down yet,
but the effort of providing such an environment has started. We'll
keep you posted with the advances.
Wine .so files' names Issue
Andreas Mohr asked whether all the Wine libraries shouldn't be renamed
to libwineXXX to avoid any conflict with existing libraries. Wine
already had a clash with libole.so and gnumeric.
After some discussion on how the current distributions were doing
their packages (Debian, RedHat...), Ove Kaaven explained what should
be the final scheme.
The Wine DLL files (to be semantically correct, read the .so files
containing Wine's DLLs ; see [4]for the details) should be stored in
/usr/lib/wine (as FSH suggests). All the other .so files (like
libwine_unicode, libwine_tsx11...) should be stored into /usr/lib (or
any directory pointed by /etc/ld.conf). /usr/lib/wine shouldn't be
referenced by the /etc/ld.conf configuration file.
Any program (winelib or wine itself) which wants to import a file will
do it through the import directive of its .spec file (and will not
require the support of the linker (like using -lfoo) for that).
In other words, all is already in place for a proper storage, avoiding
any naming conflicts.
Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove Kåven.
_________________________________________________________________
References
1. ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz
2. http://www.activestate.com/
3. http://www.winehq.com/News/2000-43.html#0
4. http://www.winehq.com/News/2000-51.html#FTR
5. mailto:[email protected]
6. mailto:[email protected]
7. mailto:[email protected]
