Wine Traffic #87 For 12 Mar 2001

By Eric Pouech

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:

1. Does Peace mean war?

11 Mar 2001 (9 posts) Subject: "The PEACE Project"

People: Damjan LangoPatrik Stridvall

Damjan Lango posted some information on a PEACE project (quoting the web site) ( ( ):
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:
  1. In-kernel *.EXE loader
  2. Dynamic linker for Windows *.DLLs
  3. Win32 API implementation (i.e. core DLLs)

Q: How many Win32 API functions are implemented?

A: Currently, most APIs are NOT implemented.

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:

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.

2. Helping debugging Wine

9 Mar 2001 - 14 Mar 2001 (13 posts)

People: Gerard PatelAlexandre JulliardRob FarnumGé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:
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 programatic interface.

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:
What you 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 process.

However, all of these large evolutions didn't solve Gérard's first needs:
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 use it.








Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.