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’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…
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.
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 .
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.
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…
I’ve been having some problems with Explorer hanging when opening “My Network Places” on some of my machines. Some work fine, some hang. Most annoying. I’ve been trying a few things over the past few weeks (as and when I get a hang and as and when I feel like it), but nothing has seemed to have fixed anything, until this morning…
I’ve recently adjusted my networking kit and now have a couple of UPnP devices floating around and it’s useful (but not essential) to be able to connect to them directly in Explorer.
