I've posted some more photos

of the Melbourne I know[^]. I took about 600 shots in total. Digital cameras are great. Zero shot cost. Just shoot and shoot and throw away what didn't quite work. What I now need is one of those anti-shake cameras with software that compensates for my tremor, for I fear that one or two of my shots don't quite show the crispness of which a digital camera is capable.

I'm also hoping that the internet plan to which our illustrious host, Michael, subscribes, can cope with the size of the photos (roughly a meg each). If it can't let me know and I'll cut em down to size.

Today was the return to the office. The powers that be haven't yet communicated a change in priorities though, given this company, I know changes have happened. I did make it pretty clear that in the absence of any clear directive I had no intention of changing my own priorities, which are to release a major new version in January, one which doesn't require admin credentials. My predecessor relied on the registry to an extreme but, what's worse, he opened every key with KEY_ALL_ACCESS permissions. No big deal if you're dealing with a key in HKEY_CURRENT_USER but of course our app saves all it's persistent data in HKEY_LOCAL_MACHINE. Hence the requirement for an admin login. Our customers network people don't like that; nor do I. More than once I've travelled to the Philippines to diagnose a problem caused by the operator deleting a registry key.

I'm about to pull a swifty on the team (and as software supervisor I intend to abuse my power). I'm going to add the access mode to the constructor of our registry class and not make it default. Each team member is going to face code that won't compile; and by not setting a default value they're going to have to examine each situation and make the appropriate decision. For the most part I suspect that the other team members will get away with KEY_READ access which will work regardless of admin rights. This is going to hit the code for which I'm responsible the most.

I've been doing a big refactor; pulling code out of the user interface that doesn't belong there and moving it into a config utility that checks to be sure it has write access to our root key. Unfortunately there are one or two places where I can't really remove the need for write access; for those cases I've had to write some impersonation code and thus code to store encrypted username/password combinations. And as a result, configuration utilities to set the username/password. The config utility grew into a framework with various plugins to configure this or that aspect. I'm up to 5 plugin DLL's and I've barely scratched the surface.

We're getting better at this though; my predecessor used to store SQL Server passwords as clear text in the registry. If that reads as I think I do a better job than he did you'd be right. It never crossed my mind that I could get away with storing passwords as clear text. I take it one step further though. I store the domain, username and password as a single encrypted entity. The scheme I use is a simplified version of this[^] No one, scanning our root key, could easily determine even the username we use. This is as it should be.