A couple of days ago I mentioned that I was having some problems with loading symbols for a common controls dll. I’m now pretty sure that it was my problem, as usual, rather than someone elses. I’ve reworked my process startup controlling code and now set and clear the breakpoints in a more reliable (i.e. less hacky) way and things are behaving themselves again. I think I was failing to stop one of the threads properly and that was later causing problems.
I was using one of my home made debugging tools recently and it kept crashing :( I assumed it was something I was doing but I’ve eventually tracked it down to where I load the symbols for the loaded modules in the target process. Attempting to load the symbols for x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.2180_x-ww_a84f1ff9\\comctl32.dll leads to dbghelp.dll generating a BEX event (which appears to be either buffer overrun or data execution prevention related).
Ned Batchelder reminds us of the value of the C++ FAQ (Lite). It’s been a long while since I’ve looked at it yet Ned’s example shows that I’ve still a lot to learn about the subtleties of C++. I can think of a few places where I could use that throw; as an exception dispatcher example to replace some rather ugly macros.
As I mentioned last week, I’m currently doing some Java work with an investment banking client. This week I added JMock to their toolset.
JMock is a dynamic mock object generation tool that works with JUnit to allow you to create mock objects without writing code. Since most of my TDD work has been in C++, most of the mock objects that I’ve used in the past have been hand coded.
I started back with an investment banking client this week. I’m working with the team that brought us “the refactoring project” and another small team, and integrating the trade entry system with some “xll” excel addins and some back end server software. Pretty standard fare for investment banking work…
I’ve worked with this client quite a few times over the years and it’s interesting to go back and find that they’re still using the systems that I helped them to put in place back in 2001.
Udi Dahan writes about managing dependencies in code at the ‘package’ level in “So many Dlls, so little time”.
“Sloppiness with dependencies. If two classes are independent of each other, and do not provide different implementations of the same interface, think twice about putting them in the same project/dll. Minimizing dependencies is the bread and butter of loose coupling. Break dependence on implementations by introducing interfaces in a separate project/dll.”
Mark Pearce writes about Debugging a .Net Windows Service from within the IDE. We do something similar with our C++ Windows services but, as you’ve probably come to expect from me, it’s slightly more complicated than Mark’s approach.
Similarly to Mark I allow the main thread of the application to call the service entry point rather than passing the work off to the Service Control Manager (SCM) when we want to run the service in ‘debug mode’.
It looks like all of the hosting problems are now resolved. There was a brief period when the database and CGI were fixed and an MT configuration path hadn’t been updated so pages were not being rebuilt after comments were added but that’s now been fixed and the pages have been rebuilt to include the missing comments.
If anyone notices anything strange please leave a comment on this posting.
As you may have noticed I’m having some hosting problems at present. The server that hosts www.lenholgate.com was hacked and it’s taking my hosting provider longer to fix than they expected…
Right now comments and trackbacks don’t work because of incorrect CGI settings on the webserver but even if that were fixed now there’s no database backing up the pages so things would just be broken in a different way.
Kevin Barnes over at Code Craft has just written an interesting piece on TDD. In it he claims that “Excessive unit testing infrastructure hampers your practical ability to refactor things efficiently. People scream at me when I say this. Unit tests are supposed to enable refactoring by spotting unexpected bugs resulting from the refactoring effort. I agree. Unit tests help with this, but only up to a point. When they cross the line into extreme-testing they can be pretty much guaranteed to break every single time you refactor the code”
