What s Next for WDBG?

What's Next for WDBG?

As it stands, WDBG does what it's supposed to do. However, you could improve it in plenty of ways. The following list should give you some ideas about what you can do to enhance WDBG if you're interested. If you do extend WDBG, I'd like to hear about it. In addition, as I mentioned in Chapter 1, examples of your own code are wonderful props to bring to a job interview. If you do add a significant feature to WDBG, you should show it off!

• The WDBG UI is just enough to get by. The first improvement you could undertake is to implement a better one. All the information is there; you just need to design better ways of displaying it.

• WDBG supports only simple location breakpoints. BREAKPOINT.H and BREAKPOINT.CPP are ready for you to add interesting kinds of breakpoints, such as skip count breakpoints (execute the breakpoint a specific number of times before stopping) or expression breakpoints (break only if an expression is true). Make sure you derive your new breakpoints from CLocationBP so that you get the serialization code and you don't have to change anything in WDBG.

• Add the ability to detach from processes when running under Windows XP, Windows Server 2003, and later versions of operating systems.

• With a little work, you should be able to extend WDBG to support multiple process debugging. Most of the interfaces are set up to work on a process identification scheme, so you would just need to track which process you're working on during a debug notification.

• The WDBG interface is set up to allow you to drop in remote debugging and different CPUs and still have the main UI work the same. Write the remote debugging DLLs and extend WDBG to allow the user to choose whether to debug on the local machine or on a remote machine.

• You could always write a better disassembler.

• The SymbolEngine code simply dumps the decoded symbols to a callback, and you have to set the amount of expansion when you first call EnumLocalVariables. If you want to mimic something like the Visual Studio .NET Watch window, you'll need to extend the local enumeration to return memory blobs that you can expand on the fly. You won't need to change anything in the SymbolEngine internals, just the higher-level code in SYMBOLENGINE.CPP that controls the enumeration. If you get this written, you might want to look at extending SUPERASSERT so that you can expand symbols on the fly.

• Right now SymbolEngine concentrates on expanding locals based on a context scope. Take a look at expanding SymbolEngine to allow you to enumerate global variables as well. The work is nearly all done; all you'll need to do is write a method that does everything EnumLocalVariables does except call SymSetContext with a NULL stack.