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.
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.
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.
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.
This morning a new Ready NAS NV+ unit arrived, so now I have three. I didn’t have a sudden change of heart about buying a development box, the power supply in my office NAS died on Thursday afternoon and buying a new, bare, enclosure was the quickest way to get my existing disks back online.
However, once I get the faulty until returned from repair I’ll have a unit that I could develop on…
As I mentioned a while back I’m using a pair of ReadyNAS NV+ RAID systems as my on-site data store and off-site backup. These are both working well and I’m pleased with the solution. After a few hickups and delays due to the Netgear takeover of Infrant it seems that the firmware is developing nicely again and the latest thing that I’ve discovered is that you can now develop and deploy your own code to the devices (if you’re brave enough!
Whilst I’ve been away I’ve had a bug report for the TDD timer queue code that’s available here. The report is completely correct and could result in a timer being scheduled out of sequence if it’s scheduled around the point when GetTickCount() wraps. I’ve coded up a fix but I need to write it up and post it. It may take me a while to do this as I have a lot going on in my life at present, if you need the fix sooner then drop me a mail.
An interesting piece here from Phil Haack about why they decided to use an abstract base class rather than an interface.
Versioning is always a complicated thing for library designers. I know that I’m lucky in that I don’t have a gazillion users of my libraries so I tend to make breaking changes rather than build up technical debt in the name of backwards compatibility but I’ve worked on software where we couldn’t do that and where binary compatibility was important.
For some time I’ve had a class which implements asynchronous file writing. It’s the basis for a logging class that some of my clients use. The class builds on several of the classes in The Server Framework and uses I/O Completion Ports and a thread pool to manage the overlapped I/O. Due to the way that I structure my servers you can often share the I/O pool that you use for your overlapped log writes with the pool that deals with the socket I/O.
