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

Re: [PATCH] deferred trace

by Rob Farnum

> At 12:04 PM 14/03/2001 -0500, you wrote: > >I remember wishing fondly for something like this when we were working > >on WordPerfect, but never having the time to do it myself. > > FYI someone at Codeweavers has something much more sophistificated > than my simple patch but from my understanding it's not ready for general use :-/ That would probably be my modification that 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 programmatic interface. My current design is to have yet another dll that would register itself as the handler for this XClientMessage, so that on reciept 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.

March 14, 2001

Re: [PATCH] deferred trace

by Alexandre Julliard

Gavriel State <gav(a)transgaming.com> writes: > I disagree - many of the bugs I encounter can happen well into the run > of a program. For example, debugging a dialog box in an app that comes > up only after a specific set of occurances. Having the ability to turn > on -debugmsg +all at will would make this kind of debugging much easier. My reply was more targeted at the dumping of the window handles; I don't deny switching tracing on or off would be useful, but it needs to be done in a more generic way. Also this can be done externally to Wine, so that we don't need to burden the core dlls with extra command-line options or magic key sequences. There are many ways of doing that; an output filter is very easy to do and would work in many situations; if you need more complex stuff you could do it from the debugger, or write a small app that uses the debug API to manipulate the tracing state. -- Alexandre Julliard julliard(a)winehq.com

March 14, 2001

Re: [PATCH] deferred trace

by gerard patel

At 12:04 PM 14/03/2001 -0500, you wrote: >I remember wishing fondly for something like this when we were working >on WordPerfect, but never having the time to do it myself. FYI someone at Codeweavers has something much more sophistificated than my simple patch but from my understanding it's not ready for general use :-/ Gerard

March 14, 2001

Re: [PATCH] deferred trace

by Gavriel State

Alexandre Julliard wrote: > > gerard patel <gerard.patel(a)asi.fr> writes: > > > 2) I don't see how I will get the window list I generate with > > WIN_WalkWindows if there is no change at all in Wine - I should > > have said that to cut in the trace size in not a goal per se, but a > > mean to make debugging easier. > > If I have to make a first run with full trace that I have to browse to see > > what is the meaning of the window handles appearing in the trace, I lose > > a lot of time. Having immediately a view of all existing windows is *very* > > handy. > > I don't doubt it's very useful for the specific problem you are > tracking; but it's hardly generic enough to be included in the main > tree. I disagree - many of the bugs I encounter can happen well into the run of a program. For example, debugging a dialog box in an app that comes up only after a specific set of occurances. Having the ability to turn on -debugmsg +all at will would make this kind of debugging much easier. Trying to do this with an external program controlling the debug trace is an excersize in futility due to the speed hit you get from -debugmsg +all. I remember wishing fondly for something like this when we were working on WordPerfect, but never having the time to do it myself. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

March 14, 2001

Re: [PATCH] deferred trace

by Alexandre Julliard

gerard patel <gerard.patel(a)asi.fr> writes: > 2) I don't see how I will get the window list I generate with > WIN_WalkWindows if there is no change at all in Wine - I should > have said that to cut in the trace size in not a goal per se, but a > mean to make debugging easier. > If I have to make a first run with full trace that I have to browse to see > what is the meaning of the window handles appearing in the trace, I lose > a lot of time. Having immediately a view of all existing windows is *very* > handy. I don't doubt it's very useful for the specific problem you are tracking; but it's hardly generic enough to be included in the main tree. -- Alexandre Julliard julliard(a)winehq.com

March 13, 2001

Re: Heroes 3

by Tadeusz Szczyrba

W artykule <20010312203134.A21558(a)rhlx01.fht-esslingen.de>, "Andreas Mohr" <a.mohr(a)mailto.de> napisa³(a): > 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... ;-) Read my article from 21.02.2001 (I always thought that core wine developers read wine-devel carefully ;-))) TreV__

March 13, 2001

Re: The PEACE Project

by Uwe Bonnes

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

March 13, 2001

Re: [PATCH] deferred trace

by Rob Farnum

> >> 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 had this problem, and solved it using an external mechanism. I wrote an app that sends a clientmessage, and wrote a handler for that client message. The things I could do are change debugging flags, so effectively, i could turn trace on/off. I could call functions, like WIN_WalkWindows and others, if i knew ahead of time what they were. This lead me to another thought I think might be useful, adding a runtime interpreter, and using something my clientmessage, send snippets of code to be executed, much like running gdb, but not as invasive. the language could be anything that has a reasonable interpreter, something like C# :-) My goal is to have something that could look for events, when they happen, rather than trying to wade through dbg_printf statements. something that is potentially interactive...ie. when event A happens, the trigger action B to happen.... another thought is that i could dynamically load/unload a dll, that would load, do its diagnostics during init, and then unload when done. > > > >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 the problem is that you cant change things on the fly...what you want is to have the debugging options you want, selected when you want them, and then turned off. my clientmessage tool does this. i can start with no debugging, then have it start with what i want, and then, i can turn it off again... My goal is to use what is already there, but to make it much more dynamic. Then rather than doing post mortem examination, we can do it live. My thought is why can't we use the builtin debugger, asyncronously, driven by an external application that has some logic that can be used in real time.

March 12, 2001

Re: [PATCH] deferred trace

by gerard patel

At 11:24 AM 10/03/2001 -0800, you wrote: >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 I don't see why. 2 other points : 1) I wonder if I will not lose in speed with this approach; it seems to be more efficient to stop the output ASAP, than to filter data after it has passed through a pipe. I have timed Bcb4 loading with Wine on my computer (K6-350) - without any trace : 48 seconds With a simple -debugmsg +win,+relay : - with my patch : 70 seconds -> 22 seconds overhead - with a redirection to /dev/null : 95 seconds -> 47 seconds overhead I don't know if a pipe would be more efficient that a redirection, though. 2) I don't see how I will get the window list I generate with WIN_WalkWindows if there is no change at all in Wine - I should have said that to cut in the trace size in not a goal per se, but a mean to make debugging easier. If I have to make a first run with full trace that I have to browse to see what is the meaning of the window handles appearing in the trace, I lose a lot of time. Having immediately a view of all existing windows is *very* handy. >, and you don't need to hardcode a specific key >that some apps may need. But my patch does not use the Alt+F12 key if the -dt command line option is not used. It's true that some apps use this key, but in this case it's only debugging that is affected because the app does something when I use this key. It has never been a problem until now. Maybe a signal could be used instead. Gerard

March 12, 2001

RE: The PEACE Project

by Patrik Stridvall

> > > 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". It follows the same tradition as the word quisling which means "A traitor that serves as the puppet of the enemy occuping his or her country." after Vidkun Quisling the notorius Norwegian traitor. Being clintonesque means "Deliberately distorting the meaning of a word or words in order to make somebody believe something that is not true." Compare Bill Clinton saying "I did not have sex with that woman" using a rather non standard definition of the word sex. In the case PEACE this might not have been deliberate, but because of ignorance, so perhaps the use of the word clintonesque was too harsh. > > 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? See Chad's mail. > > 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? The advantage of a kernel module loader is that you can do relocation on demand as well as having the ability to just discard such pages when memory is low instead of swapping them out. > Codeweavers is on the right track here, allowing users to > launch Windows > apps from gnome by creating a file association. Agreed. > > > 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. Not quite he is trying to implement the Wine _server_ in kernel space. ie approximately thoses things that requires some sort of intra-process communication. > > 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). Indeed and if they prefer not to communicate in english, setting up a wine-devel-jp mailing list shouldn't be a problem. Most of the patches they send in will "speak" for itself without any or at least only a very short explaination. > 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! Agreed.

March 12, 2001