Back in April 2006 I posted a copy of TickShifter, see here for details. It seems that there was a bug in my Win32 debugger code on which TickShifter is built. The bug was that we failed to “forget about” dlls that were unloaded… Because we failed to forget about them it was possible for the debugger code to try and do something with addresses in these dlls that were no longer loaded and this would cause a C++ exception on the debugger thread when our call to ReadProcessMemory() failed and this caused all sorts of problems…

Nice to see that the new beta, sorry, CTP, of the next .Net Framework will increase the performance of .Net sockets by 70%! Way to go .Net dudes…. Interesting to see that it’s a joint effort between the System.Net people (who, I assume own the sockets code) and the CLR people (who own the platform)… I wonder what the CLR guys brought to the tuning table… It would be nice to know how the new (and existing) .

Back in July Joe Duffy wrote an interesting piece on the CLR thread pool. I commented on it then, here. He’s now written another piece about why they increased the maximum number of threads in “the thread pool” from 25/cpu to 250/cpu. Joe, I refer you to my previous comment… You’re solving the wrong problem!

I’m in Jackson Hole right now, my skis are still in Denver… Although they’ve replaced the baggage handling system at Denver International Airport since the days of the classic software project failure, it seems that the current system could still need some work ;) Hopefull I’ll see my skis later today…

This is mainly a reminder for me so that I can read this when I get back from Jackson Hole… Dino Viehland has written some interesting looking blog posts on how to implement the thread/task and syncrhonisation host managers for a hosted CLR. Note that this is all “Whidbey beta 1” stuff so, well, your milage may vary…

I’m still playing with hosting the CLR in C++ (using “Customizing the Microsoft.NET Framework Common Language Runtime” by Steven Pratschner as my guide)… It’s an interesting journey but, once again, I wonder who makes the important technical decisions at Microsoft and how they sleep at night ;) . I’m currently playing with the ICLRRuntimeHost interface. This lets you load the CLR into your unmanaged process and gives you a remarkable amount of control over how the CLR that you’re hosting operates.

I’m playing around with hosting the CLR in C++ at present and have come across a bit of crapness in the mscoree.h file… #if (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) typedef VOID ( __stdcall *WAITORTIMERCALLBACK )( PVOID __MIDL_0011, BOOL __MIDL_0012); #endif // (_MSC_VER < 1300 || _WIN32_WINNT < 0x0500) This effectively says, if you’re using VC6 or you’re compiling for less than v5 of Windows NT then you don’t have this typedef so here it is… Unfortunately, if you’re compiling with VC6 but you’re using the platform SDK then you already have that typedef in winbase.

Here are a few interesting views on software development from Katie Lucas. Via Joel on Software. I especially enjoyed the design methodologies, becoming a manager and “remove developers net access” pieces.

The latest version of The Server Framework contains a memory leak in the CSocketServerEx class. It’s quite a good leak, it leaks an IO buffer on every connection attempt. The fix is as follows: Change this code: void CStreamSocketServerEx::PostAcceptRequest() { if (m_listeningSocket != INVALID_SOCKET) { if (m_connectionLimiter.CanCreateConnection()) { IncrementPendingReceives(); const IFullAddress &address = GetAddress(); IStreamSocketEx *pSocket = AllocateSocket(CreateSocket(address.Type())).Detach(); IBuffer *pBuffer = AllocateBuffer(); pBuffer->SetUserPtr(m_socketIndex, pSocket); PostIoOperation(pBuffer, IO_Accept_Request); } else to this:

I’ve just fixed a problem in The Server Framework that was reported to me by one of my clients. There’s a race condition during connection establishment which can be demonstrated by a client that connects and then terminates the connection very quickly. The bug could be said to be in the example servers rather than the framework itself but it can be fixed by a change to the framework… In the non AcceptEx() version of the TCP server code, during connection establishment OnConnectionEstablished() is called from the code that processes a successful Accept().