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!