Alexandre Julliard julliard@winehq.com wrote...
What you should rather do IMO is to put your dll inside the debugger,
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?
and have the debugger drive Wine instead of the other way around. Then
My intention was not to have wine drive the debugger, but to allow the debugger to be driven by effectively hooking into yylex and feeding it externally by a separate application. I am not interested in driving wine, I am interested in getting state information from wine in as least an invasive way as possible.
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.
you can add all kinds of elaborate mechanisms in the debugger, and do anything you want without needing any cooperation from the running Wine process.
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.
If I have built debugging instrumentation into a dll, I would prefer not to be required to have the debugger and wine be linked to it at compile time, but be able to bind to it at run time. The idea is to be able to extend the language of the debugger to dynamically handle application specific instrumentation. Basically, I need the ability of gdb to 'call' an external function that the wine debugger does not have prior knowledge of.
With these two capabilities, externally feeding the debugger commands by a separate application to a currently running wine application and being able to call any function that the wine debugger can resolve, it is possible to meet the needs that have been expressed.