It took me quite long to make progess in the last days. Partially this is due me being in Munich again and working in my uni job part-time again - and I’m stunned each time how tired I am when I come home.
It also is due to me experimenting with my TelnetDebuggerClient implementation that connects my debug engine to Torque’s Telnet Debugger. I’ve tried quite a few different approaches for synchronous and asynchronous communication before I could settle for the simplest and the more advanced ones reside in the repository’s history. I’ll probably have to switch to them sooner or later because I only implement asynchronous communication at the moment which is fine for most things except when you need more advanced debugging info like for displaying objects properly in the debug window for example.
I’ve also had to read the “Definitive ANTLR Reference” in one night because I had to return it to uni’s library the next day, so I was busy for 7 hours reading 350 pages of a parser reference. It was interesting though and tonight I’ll try to write a QuakeC grammar - that’s the plan at least.
However yesterday, I had time to work on the debug engine some more and here’s a picture that tells it all:
As you see you can now break a program and it will retrieve the callstack from Torque and update the callstack window automatically and open the right file and jump to the correct file position, too - or rather as I’ve just noticed one-line off because VS line indicies have base 0 and TorqueScript uses base 1 >>…_
A few implementation notes as always:
It seems, if your Debug Engine doesn’t implement IDebugEngineLaunch2, your Program Provider has to implement IDebugProgramProvider2.WatchForProviderEvents
Moreover, if you don’t implement IDebugEngineLaunch2, which in turn forces you to implement IDebugProcess2 (and maybe IDebugProcess3, too), suddenly some “deprecated” methods in your Program class (your IDebugProgram2 implementation) will be called, which, if you follow MSDN and the debug engine sampe, will result in failed asserts and the nice fail message “This function is not called by the debugger.” :-) It’s kind of logical that IDebugProgram2.Execute() is going to be called because the debugger has no IDebugProcess2 interface to call _Execute _on..
What is enum_FRAMEINFO_FLAGS_VALUES? It’s undocumented and I suspect it’s used for the undocumented m_dwFlags field in FRAMEINFO…
I’m totally stunned by how stable Visual Studio is. Most of the interfaces I implement are only half implemented and return E_NOTIMPL on most calls and Visual Studio runs and runs well and only displays the information it can in a clean way.
I guess this is one of the advantages of the COM programming/design paradigma and I think it’s great. Being able to implement interfaces bit by bit and add functionality slowly makes debugging easier and also helps you understand things better - which is good because even though a lot is documented, you still need some practice and trial & error to get things right eventually.
Enough is enough though for now, and I’ll head to uni in a bit.
Only one last remark: I’ve started reading the book “The Pragmatic Programmer” and so far it’s really entertaining and, I guess, good. I’ll write more on it, when I’ve finished it and can actually assess its qualities..
Cheers, Andreas