gerard patel wrote:
At 03:00 PM 14/03/2001 -0800, you wrote:
<snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed.
Expressed ?
What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time.
I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people.
And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it.
So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-)
just a few (late) comments: using the Wine debugger (or any program using the debugging API) may have some drawbacks. As the API is designed, it's not possible to get control of the debugged program between its creation and its entry point entering this makes very difficult to let the Wine debugger trigger the expected features by poking the memory in the debuggee. The only solution is to use a file base approach (.ini or .rc files, registry...) or a server based approach (but I fear Alexandre wouldn't like a parent process to store information to drive the child process... it would end up with the same issues - in AJ's view - as the command line one)
but, we could also build a small Winelib program, using the debugging API, to provide the requested features
A+