So, back in June I discovered that my performance counter library code didn’t work on my new Vista x64 development box… The problem seems to be that the code has always been doing things in an undocumented/unsupported way and it’s only now that the old way doesn’t actually work at all any more…
I think I know what I need to do to fix the counter installation problem, use the wonderfully unixy named “lodctr” program (or the API alternative) to load the strings for the performance counters rather than simply shoving them into the registry myself… That means that the library code I have needs to be changed so that it writes out the appropriate files (an .
I’ve been doing some work for a client on their reliable UDP implementation. It’s been interesting stuff. They had picked out a ‘best of breed’ open source, reliable UDP protocol implementation (ENet) which was in ‘C’ and integrated it into their server that was written in C++ with my framework. Unfortunately the ‘C’ API assumed a synchronous ‘pull’ model for the communications and The Server Framework gave them an asynchronous ‘push’ model.
In the past I’ve mentioned my lack of enthusiasm for the normal ‘debug trace’ files that some systems seem to include… I pretty much consider them a design smell… But, some of my clients seem to like them and over the years I’ve been asked to provide high performance logging systems so that they can spew random messages to files and still run at a reasonable speed. I’ve written and adjusted an asynchronous file writing log file class a couple of times now and it finally ripened to the point where it was time to harvest it.
The x64 port of The Server Framework is going well. I’ve run the tests for the OpenSSL servers and things are looking good there; this is always an important stage to get to for me as these servers and their tests really thrash the framework and are good at shaking out any bugs that might be hiding…
So, now I’m faced with the monkey work of adjusting all of the other example servers to build cleanly on all platforms and (in addition to the x64 work) to support either IPv4 or IPv6… My problem is that I now support 5 compilers; VC6 through VS2005 + x64 and, since both I and my clients like being able to work in the IDEs, this means 4 project files to maintain per example.
Whilst The Server Framework has supported IPv6 for a while now I haven’t really used the functionality a great deal. My previous development box didn’t have IPv6 installed and so I never really got around to playing with it. Since my new box has IPv6 installed and since porting, building and testing can become a bit dull after a while I’ve spent a little time this afternoon playing with making sure the example servers are fully IPv6 aware, and, in fact, address type agnostic.
I’ve been aware that there was a ’need to run as Administrator’ issue with some of my server examples for a while; only the ones that installed/removed performance counter dlls or installed/removed themselves as Windows Services. The service installation problem was obvious, you got a message box saying that the user had insufficient rights and now, on Vista, this message box lets you try again and it relaunches the application with the “run_as” verb and you get a chance to run it as Admin… The performance counter issue seems more complex.
My new development box arrived last week. It’s a bit of a monster, dual processor (Intel Xeon E5320 quad core, 1.86 GHz), 8GB ram, and it runs 64bit Vista very nicely indeed. Since it’s an x64 box I have started work on porting The Server Framework to x64. So far things are going very smoothly. The main issue is that I have, in the past, tended to overuse size_t when I really mean “a reasonable sized unsigned value”.
I’m just about to try out the latest STLPort release and I went to apply my ‘STLPort 5.0 multiple side by side dlls changes’ from 2005 and noticed that the place where one of the changes needs to be made has changed.
The change to Makefile.inc should still be made to STLport-5.1.3\build\lib\Makefile.inc but the change that was previously made to stl_msvc.h now has to be made to STLport-5.1.3\stlport\stl\config\_auto_link.h
Given what Jeff wrote recently and what Ian and Dennis said about it… I’m definitely on the Ian and Dennis side of the fence…
I grabbed a couple of copies of “The NT Insider” from my ’not quite got around to reading’ rack today and read them on the train on the way in to London. These are the quite short, bi-monthly, driver developer and kernel programmer magazine from OSR. It’s free to subscribe and the content reminds me of the thrill that I used to get from reading computer mags back in the late 80s… I guess it’s possibly the fact that lots of it is slightly alien to me, there’s a certain excitement in knowing that there’s so much to learn and being able to follow half understood threads in one article to other articles and deeper understanding… Plus this stuff is hard, and complex, and a bit scary, and nobody is appologising for it… Anyway, sure takes me back…
