Technical Comments

I've come up with some new helpful hints on several different topics.

First up, Windows 7. When installing an operating system, you might need to delete an old operating system. I recently was dual-booting with XP and 7 Beta. I gave up on 7 Beta, so it was just sitting on a hard drive. Before installing 7 RTM, I "deleted" the 7 Beta installation by going to the drive in XP, selecting all of the files, and deleting them. Job well done. Not quite. I wasn't showing system files in XP, so there were some 7 Beta files on the root drive that were still present, most notably, the 7 Beta boot manager. This caused major problems when I installed 7 RTM because the RTM tried to use the existing 7 boot manager and didn't install one on its own drive. The moral of this story is: format a drive to delete an operating system!

Windows 7 bug report:
The "My Pictures" screen saver allows you to navigate between pictures using the arrow keys. If you navigate "back" on the first picture, the screen saver crashes. I can't believe that somebody didn't test and handle that obvious corner case. One irritating thing about the "random" screen saver is that it always starts with the same picture. After that, it uses a random generator. The same is true of Windows Media Player. If I have my playlist and hit play with randomization, it always starts with the same song, then randomizes. That shouldn't be very difficult to handle, but there is either some arcane reason or somebody just didn't think it all the way through.


I'm programming in Clojure for a class project using the Eclipse IDE. My team is managing the code using SVN, and the Tortoise SVN client for Windows. We were getting some strange error messages from SVN after making changes with Eclipse. Even though we thought the "bin" folder (automatically created by Eclipse) was not under SVN, we kept getting the icon on the folder indicating that it was under SVN. Oddly enough, we couldn't update the folder ("it didn't exist on the repository"). If we deleted the bin folder and did an SVN update, it wouldn't download the bin directory (even though it was apparently under SVN). If we tried tried to commit the reposity, it would say that it was conflicted. A very strange combination indeed. We finally figured out the root of our problem: Eclipse was copying the .svn directory from the src folder (which was under SVN) into the bin folder (which was not under SVN) when it auto-generated the bin folder. We have no idea if that was intentional or not, but it certainly isn't helpful when using SVN. The result was that the bin folder had the src folder's SVN information. The Windows shell reported that the bin folder was under SVN because it had a .svn folder, but naturally the repository was very confused because of the conflicting information. Moral: I don't know. Eclipse is stupid? This bug was really hard to identify!

I've come up with a new problem to solve (even as I continue to investigate the practical side of security through password storage). This involves knowing when an executable has been modified. I thought it would be pretty cool for an executable to be able to compute it's own hash on the fly and compare it to a precomputed known-good hash (the original executable's hash). I suppose this wouldn't be hard to do with a separate program that simply computed hashes and compared results, but I wonder if it could be done within the executable in such a way that the hash would be easy to compute (this would be a recursive problem), but that changing one byte in the executable would force a new hash to be computed, which would be difficult. I don't know if it would work but it'd be cool if it did!

A problem, and a vow to find the answer

The roots of this problem are in Microsoft Outlook. For whatever reason, be it a bug in Outlook, incompetent IT professionals at my school, or some combination of the two, Outlook will not for the life of it save my Exchange password, even if I click the box that says "Save my password". I found this unbelievable irritating, so I searched the internet. Although there were numerous suggestions on how to fix the problem, none worked. Finally, I found a script that detects the Outlook password window and enters your password manually. It's perfect! Except for one thing....it stores your saved password in plaintext! This simply won't do!

So here is the problem I have set out to solve: either find a way for a program to save and retrieve a password SECURELY with no user intervention, prove that it is not possible, or determine that this question is open and has deserves much of my future focus.

To clarify exactly the functionality I want: I want a program to save a password, then be able to store that password so that no user can access it when it is stored. Although anyone with access to the program would be able to effectively use the stored password at will, they at least couldn't discover the password.

And so I begin.