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).
Damjan Lango posted some information on a PEACE project (quoting the
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:
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:
Q: How many Win32 API functions are implemented?
A: Currently, most APIs are NOT implemented.
- In-kernel *.EXE loader
- Dynamic linker for Windows *.DLLs
- Win32 API implementation (i.e. core DLLs)
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.
Gerard Patel wrote a patch to help debugging some parts of Wine.
- Peace uses C++ code (whereas Wine uses C). This may remind some
folks of the years old discussion about Odin (see older issues , , and )
- Peace uses the BSD license with the advertisement clause,
which is incompatible with Wine's
Alexandre Julliard didn't like the approach because he thought
This implements a way to not output the
debug trace to disk until the user hits Alt + F12. The goal is to
avoid too big trace files. This behavior would be triggered by
using the -dt command line switch.
- When switching the debug mode on or off, the list and
state of all known windows would be displayed
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:
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.
Alexandre suggested to extend the idea:
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