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