Wine Traffic #87 For 12 Mar 2001
Table Of Contents
This is the 87th 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 56 posts in 222K.
There were 17 different contributors.
7 posted more than once.
6 posted last week too.
The top posters of the week were:
- 17 posts in 81K by firstname.lastname@example.org
- 8 posts in 30K by Dmitry Timoshkov <email@example.com>
- 7 posts in 23K by gerard patel <firstname.lastname@example.org>
- 4 posts in 16K by Patrik Stridvall <email@example.com>
- 4 posts in 12K by Alexandre Julliard <firstname.lastname@example.org>
- Full Stats
Does Peace mean war?
11 Mar 2001
Subject: "The PEACE Project"
Damjan Lango, , Patrik Stridvall
Damjan Lango posted some information on a PEACE project (quoting the
The first cursory look didn't find lots of differences from Wine. The
PE loader has been included in the dynamic loader library and in the
BSD kernel. Something similar had been done on Wine. Chad Kitching
also noted that a command like:
PEACE is a set of programs to run Win32 apps on NetBSD/i386 (and other
ports in the future?) box.
Q: What is the difference from other Win32 emulators?
A: Actually, PEACE is `Win32-compatible package' rather than `emulator'
because different from Wine and WABI, PEACE does not have `emulator
executable'. EXE files are directly executed from sh or csh.
PEACE consists of the following 3 components:
- In-kernel *.EXE loader
- Dynamic linker for Windows *.DLLs
- Win32 API implementation (i.e. core DLLs)
Q: How many Win32 API functions are implemented?
A: Currently, most APIs are NOT implemented.
echo ":DOSWin:M::MZ::/usr/local/bin/wine:" > /proc/sys/fs/binfmt_misc/register
would produce the same effect on Wine (being able to directly run
Windows file from the command line).
So, it didn't seem the architectural differences were as high as the
Peace folks seem to claim. Moreover, lots of the DLL stuff is still in
its very early days, and Peace could really benefit (and even improve)
what has already been done in Wine.
However, Patrik Stridvall uncovered two possible hurdles:
However, no cooperation has been set up so far.
- Peace uses C++ code (whereas Wine uses C). This may remind some
folks of the years old discussion about Odin (see older issues Issue #21, Section #1
(Porting to OS/2 (Odin project) and C/C++ flame-war)
, Issue #25, Section #2
(Retrofitting Odin project's modifications)
, and Issue #26, Section #1
(WineLib apps, C++ and global constructors)
- Peace uses the BSD license with the advertisement clause,
which is incompatible with Wine's
Helping debugging Wine
9 Mar 2001 - 14 Mar 2001
Gerard Patel, Alexandre Julliard, Rob Farnum, Gérard Patel,
Gerard Patel wrote a patch to help debugging some parts of Wine.
Alexandre Julliard didn't like the approach because he thought
it would be much better to do that with a small
external program that you pipe the debug output into. This way you can
have much more flexibility, and you don't need to hardcode a specific
key that some apps may need.
Gérard didn't agree either. He tested, from a speed perspective, the
two options (turning off the output inside Wine versus using an
external program), and found the former being twice as fast as the
later on his machine.
Rob Farnum explained he also tried to achieve what Gérard did using a
more generic approach:
Alexandre suggested to extend the idea:
my modification allowed an external application to drive the debugging
by extending the XClientMessage by adding a new Atom, wineDebug. It
has the possibility to be more sophisticated than trapping on a
function key, but for my purposes I limited it to just a few
functions, ping, dumping the window list, and adding an entry into the
log file so that I could mark the start and stop of an area of
interest. It was something quick and dirty to solve a specific
problem, so I did not submit it for inclusion into wine. I originally
did use a keyboard interface, but needed something extensible allowing
for more than just dumping a window list, hence went to more of a
My current design is to have yet another dll that would register
itself as the handler for this XClientMessage, so that on receipt of
the XClientMessage, it is simply passed to this new dll. This dll
would implement whatever application specific debugging tools I need,
with only the bare minimum of support from wine needed. Since the wine
debugger already has quite a bit of the functionality that is needed,
it might be interesting if this method could be used to effectively
open a pipe and drive the wine debugger externally.
should rather do IMO is to put your dll inside the debugger, and have
the debugger drive Wine instead of the other way around. Then you can
add all kinds of elaborate mechanisms in the debugger, and do anything
you want without needing any cooperation from the running Wine
However, all of these large evolutions didn't solve Gérard's first
What I wanted is something short and simple, so
I could help people on the news group. The use of my patch could be
explained in one
line and it would have worked with Wine right 'out
of the box' :-)... something the internal debugger does not do anymore
since a long time.
I am afraid that this thing will be more complex to setup and to use
that the debugger - something already too complex for many people.
And well, I almost never use the debugger myself because it crashes at
the slightest provocation so I don't feel much about saying people to
Sharon And Joy