I found JP’s blog whilst googling for some information on RVA forwarders in PE files. There’s lots of good stuff there about reasonably low level Windows development, debugging, testing and API hooking. Recommended if you like the kind of stuff that I write about. In addition to the blog postings JP has produced cfix a unit testing framework for C++. I haven’t had a chance to look at it too deeply yet, but the documentation looks good and the source is available from SourceForge under the GPL.

Back in October 2007 I sumarised my findings from getting my Win32 DebugAPI based debug engine working on x64. One of the strange things that I found at the time was this: When running a CLR app under the Win32 debug interface you only ever seem to hit the native entry point if you’re running under WOW64. In all other situations you don’t hit the native entry point ever. If you rely on it to pause your debug tools once the process is completely loaded and ready to roll then you need to stick a break point in _CorExeMain in mscoree.

I’ve been putting together a sample server for a client that shows how to cleanly terminate a socket connection. This should have been a simple thing to do, but in doing so I’ve discovered some gnarlyness within The Server Framework and the result has been some new TODO items for the 5.3 release… When you have an active TCP/IP connection that you wish to terminate cleanly you need to initiate a TCP/IP protocol level shutdown sequence by calling shutdown().

The endless torrent of bounce messages began again yesterday evening. Once again it was arount one email every 2 minutes or so. I turned on my laptop this morning expecting a few thousand emails to download and only a third of them to be correctly classified as spam by Outlook… There were a few, but, probably, under 10. There was no other spam either… Two legitimate email messages… It was, well, rather strange.

This morning a spammer somewhere seems to have used my main email address as the return address on a whole bunch of random spam that has been sent out from all over the place. As such I have around 3000 undeliverable mail responses flowing into my in box. No doubt this will now have knock on effects with ISPs who use DNSLB type systems as my domain is being used by spammers again.

I’ve turned the blacklist back on. I turned it off yesterday and have had a couple of spam comments get through. The blacklist itself doesn’t always catch the spam comments but it does give me a one click method of removing them. With it turned off I lose the easy removal. If your comment is refused you should get a message telling you why; the reason is logged, but, unfortunately the full comment txt isn’t.

There’s an entry over on the Dr. Dobbs blog about testing and how you make sure that your tests are testing the right thing; effectively, who tests the test. There’s a question at the end “What do you do?” and I think my rather pithy, I’ve had some wine, answer is, “I think harder”. The poster laments the fact that if you’re doing TDD then the test fails first and then you write the code and then it works and therefore you know the test is testing the correct thing but if you have existing code then, well, it doesn’t work that way.

There’s an interesting article over on the Dr. Dobbs Code Talk blog; PQR - A Simple Design Pattern for Multicore Enterprise Applications. It documents a design that I’m pretty familiar with and one which has worked pretty well for me in the past (this project was built in this way, for example). My variation on this idea is that it all tends to be in one process. Work items are passed from one ‘processor’ to another via queues and each processor can run multiple threads to process multiple work items in parallel.

The comments to my last practical testing entry got me thinking. The commenter who had located the bug in part 15, which was fixed in part 16, suggested a new approach to the problem and I’ve been investigating it. The suggestion is, essentially, to use a timer with a longer range before roll-over rather than GetTickCount() with its 49.7 day roll-over. In Vista and later we could just use GetTickCount64() but on earlier platforms that’s not available to us.

It seems I’m not the only one to make mistakes with GetTickCount() based timer code, see: System.Threading.Timer fires immediately when specifying a large value for due time.