I’m continuing to work through my list of things to do for The Server Framework (and all the libraries that support it) and I’ve recently got to the ‘set up Doxygen and do a bit of documentation’ item…
I’m a firm believer that code should be documented once it has stabilised; I don’t tend to write many code comments as I prefer to try and make the code as self documenting as I can but for a tool like Doxygen to be worth using for more than just the pretty pictures it’s best to add some comments to explain what things are and how they hang together.
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 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.
Tim Anderson asks why there are so many developers still using VC6…
Well, as I said before, if you produce C++ software in source code form and any of your clients require that you support VC6 then it’s often easier to maintain the project files in VC6 (and thus use that as your day to day development tool) than it is to use any of the newer compilers. The reason for this is that all of the newer releases will read and convert VC6 project files but none of them will write out project files that work with earlier releases.
This is something that anyone living with a geek really needs to understand.
I find it interesting that Rands has his set patterns of behaviour for getting into The Zone in the mornings. I’m very much a creature of habit and I actively “grow” new and effective patterns of behaviour as and when I recognise them… I hadn’t really connected the successful completion of the patterns as being an enabling device for getting me into The Zone… Must look into that a little more when I get back.
It seems that Vista contains lots of interesting new Win32 API calls and some of these provide built in support for deadlock detection… I guess my deadlock detection tool can operate differently on Vista then…
