Why doesn't MDbg use generics?

If you've looked at the MDbg sources, you'll notice it looks a lot like a V1.1 app. There are few to no V2 (Whidbey) concepts in there: few anonymous delegates, very little (if any?) generics, no 'yield' keyword. Since MDbg shipped in V2, why didn't we use the greatest stuff from V2?

1. Bootstrapping: We started writing Mdbg early in V2; when V2 still looked a lot like V1. Generics weren't even available yet. This bootstrapping reason is also why V1.0 Cordbg was unmanaged instead of being managed with COM-interop. When we started writing Cordbg in V1.0, COM-interop wasn't ready yet.

2. In case we ever wanted to run Mdbg on V1.1: New V2 features like generics don't run on the V1 CLR; and so if we wanted to leave the door open for backporting Mdbg to V1.1, then we needed to only use the V1.1 feature set in V2. There are other problems for making a managed debugger in V1.1, so it's unlikely we'll ever actually do this. And the longer that V2 is out, the less attractive porting MDbg to V1 becomes.

Comments

• Anonymous
  March 17, 2006
  One suggestion in managed debugger is that unlike the CDB or WINDBG the symbol file path isn’t so easy. In windbg it is pretty easy to set it in the _NT_SYMBOL_PATH and which can point to symstore. Does MDbg support looking for symbol files with in a symstore?
  
  
  
• Anonymous
  March 21, 2006
  This might be unrelated to the topic here and I apologize, but I looked around and couldn't find a right place to ask questions about MDbg. I am writing a debugger and Mdbg helps a lot. My question is, in Mdbg sample, it seems to me debugging commands (such as setting a breakpoint) can only be input and executed when the debuggee is stopped(for instance, when a breakpoint is hit). Is this a requirment imposed by the CorDebug API? In visual studio, however, you can set breakpoints anytime, even when the debuggee is running.
• Anonymous
  March 21, 2006
  Max - great question. It deserves its own post. Stay tuned...