Eric Pouech <[EMAIL PROTECTED]> writes:
> A] the command line for starting the debugger is read from the registry (something
> like "xterm -T WineDebugger -e winedbg <pid> <hEvent>)
> (read msdn.microsoft.com/library/periodic/period97/pietrek.htm for the details)
> then CreateProcess is called upon this command line. the only issue are that
> if xterm (/usr/X11R6/bin/xterm) location is not mapped on a Windows drive letter,
> this won't work (and not calling CreateProcess, but UNIX_CreateProcess is not
> correct either => one may want to set up a native windows debugger)
How about having the debugger do an AllocConsole() instead?
> the option 2) will not allow to grab symbols from the wine exec (since
> there is no known PE module for it - but that's not a big deal IMO -)
> (if it were, we could define a dummy PE module in wine exec, which is loaded
> at startup by KERNEL32, and this this should do the trick)
There will be a PE module for the main exe; we already have one for
Winelib apps, and there is no reason that Wine itself shouldn't use
the same mechanism.
> even if option 2 requires more work, it seems to me the cleanest of the two
Definitely; though it may be better to simply store a pointer to the
.so somewhere in the PE header and leave everything else to the
debugger; we don't really need to go to the trouble of building
complete section headers for every loaded .so file.
> For Alexandre, I also found some (primary) documentation on 16 bit module
> support for NT debugger
> (msdn.microsoft.com/library/periodic/period98/hood0898.htm), but I'm not
> 100% sure the VDM model matches Wine's implementation of 16 bit tasks
It doesn't really match it at the moment, but this is something that
I'd like to change. In fact the article description is quite close to
the implementation I envisioned (like using exceptions to report
16-bit debug events).
--
Alexandre Julliard
[EMAIL PROTECTED]
