[Previous] [Next]
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 additional 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.
- 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.
- Finally, you could always write a better disassembler and a C7 symbol engine to make WDBG really useful!