I’m finalising the testing of the x64 version of The Server Framework and, since it’s a fairly major release, I figured that it waranted an email to existing customers to see who wanted to have the update shipped to them straight away (although all existing customer are entitled to all upgrades to The Server Framework free of charge I usually rely on them monitoring this RSS feed and asking for new releases rather than just sending them out; generally only critical bug fixes are worthy of an email notification…).

What with holidays and having my head down doing x64 and CLR hosting stuff for a client it seems that the last month and a half has rushed by… The good news is that the x64 port is slowly slipping out to clients; the bulk of the work has been done for ages but I’m using this release to bring all of my example servers in line with best practices for using The Server Framework.

Interesting… It seems that rumours of C++’s demise in the brave new world of .Net were slightly over exagerated, perhaps, maybe… From a recent issue of MSDN magazine: “There are two main reasons why this column was born. First, despite the phenomenal success of the Microsoft® .NET Framework, there are still plenty of scenarios where it makes more sense to use native C++. Adoption of .NET will continue to grow, but C++ is here to stay.

It’s interesting, no, really, how the more things change the more they stay the same… I’ve been doing COM for a long time. I first discovered COM back at Interlink when I was writing a windows version of a product call CardMaster which did credit card production. The system supported lots of different machines and each of these machines needed different drivers, the drivers were written in C and usually spoke to the machine via a serial port.

I’ve just installed Visual Studio 2008 Beta 2 in a VMWare box so that I can start to test the x64 port of The Server Framework with the new compiler. I haven’t bothered to look into what’s new in the 2008 C++ compiler, I’m more interested in changes to the project file format (for the tools I’m building to fix this problem) and things that may prevent my code compiling or passing its tests rather than reasons to upgrade.

I used to work with Nick at CSFB and then at Barclays Capital. He’s always been a good, techie, low-level COM/.Net geek and his latest writings on the Microsoft Concurrency and Coordination Runtime are interesting! If you’re interested in async/multi-threaded/concurrent stuff then go take a look.

I’ve spent some time over the last few days playing around with my CLR hosting socket server example. I had stalled on a piece of client work, I’ve got a bit of a head cold at the moment and my brain just wasn’t in the right place for what I was supposed to be doing so I picked up one of more interesting the items on my todo list and took a look at that instead… The bulk of the work flowed nicely but then, just at the end things stopped working for no apparent reason… I’d done what was suggested in the book, the code compiled, the CLR called into my host in the right way and then I got a security policy exception… Hmmm.

I’ve just fixed a bug in the latest version of The Server Framework (v5.1 - if you dont have docs and a version number then you’re < 5). The probelm was that I was being fractionally over-zealous in making things easy for the user… CStreamSocket has a RequestWrite() method that takes a BYTE * and a length. Originally this used to fail if the length was more than the size of a buffer.

My Visual Studio 2005 C++ debugger seems to have stopped doing what VC6 used to do if you placed a breakpoint on a line that didn’t result in executable code… VC6 used to warn you and then move the breakpoint to the next executable code line, VS2005 just seems to ignore the problem and disable the breakpoint when you’re running and therefore just run straight past it… This is especially annoying in situations like this:

I’m still working on my performance counter library. I’ve got parent and child objects working and multiple instances and I have a sample server that publishes performance data using two objects, one for the executable (io threads, sockets and buffers in use, etc) and one for each of the server instances within the executable (connections active, bytes/sec, etc). The per server instance counters have the server executable as a parent and it has some totaled up counters for each instance… In turn there’s a _Total instance in the server executable object’s instances and that totals all executables… You can run multiple servers and they all just plug themselves in to the system and show their counters.