Damjan Lango posted some information on a PEACE project (quoting the web site) ( http://chiharu.haun.org/peace/): 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:

• 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

However, no cooperation has been set up so far.

Gerard Patel wrote a patch to help debugging some parts of Wine.

• 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

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.

EOT.