The PEACE Project

David Elliott dfe at infinite-internet.net
Mon Mar 12 12:55:25 CST 2001


Patrik Stridvall wrote:

> > I don't know if you know about The PEACE Project:
> >
> > http://chiharu.haun.org/peace/
>
> Now I do. :-)
>
> > What is PEACE?
> >
> > PEACE is a set of programs to run Win32 apps on NetBSD/i386
> > (and other ports
> > in the future?) box.
>
> I see.
>
> > What is the difference from other Win32 emulators?
> >
> > Actually, PEACE is éWin32-compatible package' rather than
> > éemulator' because
> > different from Wine and WABI,
>
> And Wine isn't a "Win32-compatible package"?
>
> > PEACE does not have éemulator
> > executable'.
> > EXE files are directly executed from sh or csh.
>
> The above is IMHO a rather clintonesque use of the words
> emulator and executable. They hide the comparable code
> in NetBSD's dynamic linker instead.
>

Clintonesque?? HAHAHAHAHAHAHAHAHAHAHA  That's really good dude!  I guess it
follows in the tradition of words like "nasty".

>
> Not impressed, eventhough we could and probably
> should do that in the future.
>

I thought there was another kernel module running around that loaded wine
for exe files.  Used BINFMT_MISC or something?

>
> However if we hide the fact Wine is run, many user
> will not realize that it really is Wine's fault
> that their Win32 application crashes and say to
> their friends that Linux is unstable which gives
> Linux a bad reputation. We don't want that do we?
>
> So we probably shouldn't make it transparent at
> least not as long Wine still is alpha.
>

Should there ever be a kernel module exe loader?  IIRC, OS/2s WinOS/2 did
not support running Windows (Win16 in this case) apps directly (i.e. from a
shell or any program using the API call to run a program).  However it did
support running them directly from the WPS (GUI) and supported making
launchers for them and tweaking a number of properties.

To run windows apps from the command line you just ran "win programname".
Kind of like you would in DOS back in the Win3.1 days.  Kind of like "wine
programname" like we have now.

Codeweavers is on the right track here, allowing users to launch Windows
apps from gnome by creating a file association.

DOS programs were a bit different.  You could run them from an OS/2 command
prompt, but if you did that then you opened them up in a new terminal
window.  I believe the calling process waited on it too.  I am thinking
maybe that if you redirected the output of the DOS command to a file then it
would not run in its new window, but maybe not.

Win4Lin's "dos" command has some options that select whether you want to
create a new window (the default) or input/output from stdin/out.  This
allows commands to be redirected.  In this mode you cannot run any programs
that require any sort of access to hardware like directly writing into the
character buffer.  On the upside, you can run sort and expect it to work
correctly.  Since there are very few DOS programs designed for this you have
to explicitly give the option, most users would just want to have a nice
window opened where their DOS app can run.


>
> > PEACE consists of the following 3 components:
> >
> >  1.In-kernel *.EXE loader
>
> Can't find the source but can't imagine it is very complicated.
> Probably somthing similar to what David Howells did for Linux.
>

I thought David's module was implementing the Wine in kernel space (e.g.
part 3 of this).  This part can be done with or without having Wine in the
kernel.

>
> >  2.Dynamic linker for Windows *.DLLs
>
> Hmm, 233 lines of code including comments.
> Not very revolutionary.
>

Truly not.  We have had code to do this forever.

>
> >  3.Win32 API implementation (i.e. core DLLs)
>
> This is supposed to do exact what Wine (Winelib)
> does. However it currently only implements a very
> small part of what Wine currently does as they admit...
>
> > How many Win32 API functions are implemented?
> >
> > Currentry, most APIs are NOT implemented.
>
> ... here
>
> In short this is just some Japanese guys trying
> to reinvent the wheel.
>

I would say definitely that this is the case.

>
> I really can't understand why they don't cooperate
> with us in the Wine project instead.

I cannot either.  I know that there is this whole thing about wanting to
write your own code for stuff, but that is usually a waste of time.
Furthermore, the Wine project is developed in an extremely open way by a lot
of very talented developers.  It is a real shame to see someone who could
obviously help out the Wine project going out and doing their own program.

Anyone can join the wine development team.  Simply subscribe to wine-devel
and wine-patches and start hacking.  Because all patches go through
Alexandre before going into CVS every developer has basically equal chances
of getting their patch into the tree (assuming that it is following the
overall architecture goals of Wine).  Actually, I would say wine is an
extremely good example of the open source development process.

There is also no licensing issue with Wine, it's under such a liberal
license that anyone can use it!

-Dave





More information about the wine-devel mailing list