I’ve been using the
SetThreadName() function from the MSDN docs for ages to provide a way of distinguishing between threads in the VC debugger. I always thought it was a bit of a weird ‘API’ but had never really thought to wonder why. Steve over at “Bug Babble” explains how the ‘API’ works from the debugger’s point of view and, well, then it all becomes obvious. For some reason I’d always thought that the ‘API’ was communicating with the OS in some weird and wacky manner; I hadn’t twigged that in fact it was just communicating with the debugger using the only method it could, via raising an exception which gets routed through the Win32 debug API.
This piece of information comes at quite an interesting point for me. I’ve been working with the Win32 Debug API for a few weeks now as it’s how I manipulate the target processes of the debugging tools that I’m writing. Over the last few days the design has really come together and I’ve refactored the code so that I can start pushing the new code up through the layers of code above and start taking advantage of the new features I’ve added in the tools… Now is a very good time to add support for displaying the names of threads that have been named using