March 2001 - Wine-Devel - list.winehq.org

Re: The PEACE Project

by Martin Pilka

> 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

March 12, 2001

Re: Heroes 3

by Andreas Mohr

On Mon, Mar 12, 2001 at 07:06:03PM +0100, Rustan Rosen rustan(a)lysator.liu.se [AndiM/Usenet 01/2001] wrote: > I found this on wine-users, and have the same problem. I did as you said, > and have attatched the file. Good ! > I have tried to test different setups, and seem to have problems with > directx, it wants to install 6.1, which doesnt work, and then says my > system doesnt have directx ('failed' in a checklist). I use the latest > wine in debian unstable, from 5/3 2001. After checking for directx, it > seems to install fine, but then just hangs. After killing it, and running > wine HEROES3.EXE > from the installed directory, it gives the above message. Can you help? > Shall I ask someone else? > Shall I supply more data? Call kernel32.192: CreateFileA(418c1a11 "C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod",c0000000,00000003,405e6ce4,00000003,00000080,00000000) ret=00599971 fs=008f trace:string:lstrcpynA (0x405e6400, "/kul/musik/wine/fake_windows", 1024) Ret kernel32.192: CreateFileA() retval=ffffffff ret=00599971 fs=008f . . . Call user32.425: MessageBoxA(00000000,005dd4fc "Unable to initialize resources - possible disk problem.",005dd628 "Unexpected Program Termination",00000010) ret=004cef94 fs=008f Hmm. Does C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod exist ? Or maybe this should be DATA\\h3sprite.lod ?? Hmm. Let me check this. I smell some Wine problem... BTW, have you tried running http://home.germany.net/100-30936/download/winecheck ? Probably doesn't help here, though... ARGL: Call kernel32.414: GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,405e6cdc,405e6ccc) ret=00599630 fs=008f trace:string:lstrcpynA (0x405e63d0, "/kul/musik/wine/fake_windows", 1024) trace:string:lstrcpynA (0x405e63ed, "Program Files/3DO/Heroes3", 995) trace:string:lstrcpynA (0x405e67d3, "PROG~FBU\\3DO\\HEROES3", 1021) trace:string:lstrcpynA (0x405e67d2, "/Program Files/3DO/Heroes3", 1021) trace:string:lstrcpynA (0x405e67ed, ".\\DATA\\", 995) trace:string:lstrcpynA (0x405e6cdc, "C:\\Program Files\\3DO\\Heroes3\\DATA", 260) Ret kernel32.414: GetFullPathNameA() retval=00000021 ret=00599630 fs=008f THAT's it !! GetFullPathNameA() is broken (clips trailing '\\'). Latest Wine release, BTW ? Or which one ? Oh well, something needs to be fixed then, I guess... ;-) Andreas Mohr

March 12, 2001

Re: The PEACE Project

by David Elliott

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

March 12, 2001

Re: The PEACE Project

by Chad Kitching

"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.

March 12, 2001

RE: The PEACE Project

by Patrik Stridvall

> > 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 !). They use the BSD license, unfortunately the one with the advertisment clause. However I don't imagine it will be a problem since there is very little if anything that they have implemented that we haven't implemented I long time ago already. Additional problem is that they use C++. :-) In short they have wasted a lot of effort for little or no gain. > Other than that I'm tired of YAW (Yet Another Windows, which is > the name of yet another windows package, coincidentally ;-) Indeed. I can understand people that start working with a project has a lot of ideas and the project leader rejects them and they grow tired and decide to do it themselves. However for a project like Wine most things really can't be done that many ways since it must be compatible with Windows so this shouldn't really be a very large problem. In this case perhaps they, being Japanse, felt uncomfortable with cooperating with english speaking people. I noticed that they have a Japanese only mailing list. Anyway we could always create a wine-devel-jp or whatever if that was a problem.

March 12, 2001

Re: The PEACE Project

by Andreas Mohr

On Mon, Mar 12, 2001 at 03:41:51PM +0100, Patrik Stridvall wrote: > > I don't know if you know about The PEACE Project: > > > > http://chiharu.haun.org/peace/ > > 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

March 12, 2001

RE: The PEACE Project

by Patrik Stridvall

> 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. 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.

March 12, 2001

The PEACE Project

by Damjan Lango

Hi, I don't know if you know about The PEACE Project: http://chiharu.haun.org/peace/ What is PEACE? PEACE is a set of programs to run Win32 apps on NetBSD/i386 (and other ports in the future?) box. What is the difference from other Win32 emulators? 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. Requirements More information 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) How many Win32 API functions are implemented? Currentry, most APIs are NOT implemented. (I'm not involved in that project, just found it on the web) ciao Damjan Lango

March 12, 2001

Re: RFC: client side implementation of async I/O

by Michael McCormack

Hi Alexandre, i have rewritten my patch for the latest wine release. The main changes from the previous are that it only checks overlapped operations in WaitForMultipleObjectswEx, and it now uses SetEvent to end the operation. (courtesy of your new servercall architecture). I have done a simple benchmark. The results of the benchmark on my Pii350 and an internal modem are as follows: Wine 2001/03/05 vanilla + async-fix.diff: average write time for "AT" command: 675 usec average read time for response: 634 usec Wine 2001/03/05 + client-async3.diff: average write time for "AT" command: 362 usec average read time for response: 322 usec The times in themselves are pretty meaningless, but it is the same program, under the same conditions. The patches and program i used are included. Mike On Tue, 6 Mar 2001, Alexandre Julliard wrote: > Michael McCormack <mccormac(a)aals27.alcatel.com.au> writes: > > > The patch can be further optimised, for example by keeping active asyncs in a > > seperate list from inactive asyncs. i think it is more efficient because the > > number of server calls and context switches is reduced. > > Reducing the number of server calls but making them more expensive is > not necessarily a gain. Show me the numbers... -- __________________________________________________________________ mailto:Michael.McCormack(a)alcatel.com.au phone: (+8232) 667 0425 (h) (+8211) 430 0425 (m)

March 11, 2001

Re: [PATCH] deferred trace

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > This implements a way to not output the debug trace to disk until the > user hits Alf + F12. The goal is to avoid too big trace files. I think 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. -- Alexandre Julliard julliard(a)winehq.com

March 10, 2001