andi at rhlx01.fht-esslingen.de
Wed Aug 18 03:39:58 CDT 2004
On Wed, Aug 18, 2004 at 09:27:53AM +0100, Mike Hearn wrote:
> My problem with this approach is that it relies on the exception
> actually getting through to the debugger instead of being trapped by the
> program code and swallowed. I guess we could install a vectored handler
> to boot the debugger and such but now the code is a lot more complex and
> confusing for newbies than just having some inline functions in the
> headers. As if the SEH code wasn't already confusing enough!
I'm sure every semi-involved Wine developer can imagine dozens of
"reasons of the day" why winedbg doesn't launch properly on error again...
Failure in wine exception handling code, failure to look up winedbg
(both registry and disk), failure to pass winedbg cmdline parameters properly,
failure to get winedbg started up properly, failure to get winedbg to
parse the current modules and stack frame properly, ...
That's why a "no frills" debugging mechanism is a good idea IMHO.
P.S.: no offense to Eric. He's done TONS of very useful things to winedbg,
and when considering how many fatal architecture changes winedbg had
to go through, it's amazing that it still works pretty well. :-)
More information about the wine-devel