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.
I’ve been running a pair of 2TB Infrant Ready NAS NV+ RAID systems for a while now as on-site file server and off-site backup and so far I’m very pleased with them. I have one under my desk and one in my dad’s office and they talk over a VPN and keep each other in sync using rsync. The one under my desk acts as a file server for my development boxes and as a music server for my Squeezebox music players.
Charles Miller over at ‘The Fishbowl’ provides a cheat sheet to decode what us programming types mean when we describe the difficulty of solving problems…
Around a week ago I started looking at rewriting my performance counter library so that it worked on Vista. That work is almost complete and I’m at the stage where the new library does everything the old one did but there’s a list of ’nice to have’ new items that I haven’t completed yet. The work was reasonably easy once I got into it. I wasted an afternoon or so trying to understand the original code that I’d hacked a little way back in 2000 and eventually gave up and went to the documentation (and the book from whence the original code came).
I’m fixing up my performance monitoring code and this uses shared memory to communicate between the perfmon extension DLL and the application. Since I’m tightening up security I decided to explicitly pass in the security attributes, which has a possitive knock-on effect to several of my Win32 tools classes which now also need to deal with security properly rather than just conveniently… Of course once you’re passing explicit security attributes around rather than simply passing 0 to the APIs you can get back some of the convenience of the not-needing-to-think-about-it style of security by passing in an “allow all” security descriptor.
