New subject: [PATCH] deferred trace

14 Mar 2001


      "Rob Farnum" rfarnum@mindspring.com writes:
...
I am not exactly sure what you mean by this.  Do you mean to put the
code that would be in the dll, into the debugger, or to extend the
debugger in such a way that it can load dll's to enhance its
functionality, or something else?
I mean that the code that would have been in the dll and loaded into
Wine should be in the debugger instead. So for instance, instead of
having a magic key (or X message) to switch tracing on, you'd have a
debugger command 'set tracing on' that would poke into the Wine
address space to do it. Since you can read/write memory, call
functions (I think it's broken now but should be easy to fix),
etc. from the debugger you can do everything from here and avoid the
need to have any debugging code running inside the Wine process.
...
This would bypass the objection of intercepting a key, like F12, and
using it to generate a window list dump, and replace it with a
mechanism that uses the debugger own builtin functions to do that.
Yes, exactly.
...
I think it is desirable to use as much of the existing debugger
functionality as possible, and to add an "elaborate mechanism in the
debugger" that allows it to be dynamically extended in
functionality.
It would certainly be possible to load dlls inside the debugger itself
to extend it; though maybe simply loading a batch file containing
debugger commands may allow to do a lot of things already without
requiring compiling new code.
-- 
Alexandre Julliard
julliard@winehq.com

Re: [PATCH] deferred trace