I don't know if you know about The PEACE Project:
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. Not impressed, eventhough we could and probably should do that in the future. 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.
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.
2.Dynamic linker for Windows *.DLLs
Hmm, 233 lines of code including comments. Not very revolutionary.
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 really can't understand why they don't cooperate with us in the Wine project instead.
On Mon, Mar 12, 2001 at 03:41:51PM +0100, Patrik Stridvall wrote:
I don't know if you know about The PEACE Project:
Now I do. :-) Now I know it somewhat better ;-)
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 really can't understand why they don't cooperate with us in the Wine project instead. That's exactly what I thought several weeks ago when I first heard of it.
Licensing issues might be the reason (I did not look at their license !). Other than that I'm tired of YAW (Yet Another Windows, which is the name of yet another windows package, coincidentally ;-) Andreas Mohr
"Patrik Stridvall" <ps(a)leissner.se> wrote:
Not impressed, eventhough we could and probably should do that in the future.
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.
On Linux, it would not be all that difficult to do with the misc executable support already integrated into most standard kernels. A simple shell command such as the following would implement exactly what he's talking about: echo ":DOSWin:M::MZ::/usr/local/bin/wine:" > /proc/sys/fs/binfmt_misc/register I'm not sure how difficult/easy it would be to do on the other platforms Wine runs on, but their method seems like overkill.
Patrik Stridvall wrote:
I don't know if you know about The PEACE Project:
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
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.
well, the problem is that sometimes some patches fall to nowhere - they're rejected without any note. this could be very annoying especially for newbies (who have the fair chance they'll not fit into wine architecture). i mean - we should have some mechanism which deadly indicates the state of the patch. however, it's not the case now. they should really join. martin
"David" == David Elliott <dfe(a)infinite-internet.net> writes:
... David> Win4Lin's "dos" command has some options that select whether you David> want to create a new window (the default) or input/output from David> stdin/out. This allows commands to be redirected. In this mode David> you cannot run any programs that require any sort of access to David> hardware like directly writing into the character buffer. On the David> upside, you can run sort and expect it to work correctly. Since David> there are very few DOS programs designed for this you have to David> explicitly give the option, most users would just want to have a David> nice window opened where their DOS app can run. David>... There are a lot of dos compilere out there that I want to run on the genuine commandline and not in a separate dos. In my eyes that's one plus of winedos against all other competitors.... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
participants (6)
-
Andreas Mohr -
Chad Kitching -
David Elliott -
Martin Pilka -
Patrik Stridvall -
Uwe Bonnes