First of all I want to say congratulations to the New York Giants. I've never been a big Eli Manning fan, I was always more supportive of Peyton, but just as well he deserves credit for ruining Tom Brady's perfect season. Secondly, I want to say that I'm now using a new Blogging software for my blog. It's called ScribeFire. I particularly like how well it integrates with Blogger and Firefox, my web browser. Finally, sorry I haven't posted in a while, I've been busier than usual the last couple of weeks. Plus, on the 25th of January I underwent a quest to trim all of the bloatware of my new notebook. My 500GB external hard-drive got here and I decided that now was as good a time as any to pimp my laptop, reformat style. So because I don't really have anything else prepared, this post is going to be about reformatting tips. And just so you know, I couldn't be more satisfied; My Vista configuration boots in 7 seconds, and idle ram consumption is down to about 35%.
Vista has some strange quirks that may throw off the unwary. First of all, immediately following reinstalling Windows I hit my first patch of trouble. After going through all of the Dell reinstallation driver disks, I attempted to install the newest version of SPTD Layer, a component in the popular applications Daemon Tools and Alcohol 120%. It wouldn't install all the way and I couldn't figure out why. I thought surely there can't possibly be a software conflict, as the only things that had been installed were necessary device drivers and system software. I also immediately discounted it being a problem with Vista, as I had used both Alcohol 120% and Daemon Tools successfully before reformatting. Obviously, something was different now than it had been, the trick was figuring out what. My first thought was that I might have lacked some kind of runtime redistributable that the developers forgot to include. That happens more than the software industry likes to admit. At any rate, I immediately did as much research on what components went into making SPTD as possible. Unfortunately that was a dead end. My next idea was that perhaps my default security policies denied the installer some critical privilege. I went into regedit and opened up the group policies dialog. Unfortunately, that route also was a dead end. After having ruled out software conflicts, lack of run-time components, and my administrative settings as causes, I went back to the drawing board. The only remaining possibility was that some option had either been enabled or disabled between the reformatting process and my first attempt at the install process. Then, it hit me. I had used a batch script to set certain options via command-line switches to personalize my configuration; I hadn't counted on one of them disabling a vital service to SPTD. I looked through it and examined each command looking for what it modified and what that setting controls. After about half way down the list, I found it:
Vista has some strange quirks that may throw off the unwary. First of all, immediately following reinstalling Windows I hit my first patch of trouble. After going through all of the Dell reinstallation driver disks, I attempted to install the newest version of SPTD Layer, a component in the popular applications Daemon Tools and Alcohol 120%. It wouldn't install all the way and I couldn't figure out why. I thought surely there can't possibly be a software conflict, as the only things that had been installed were necessary device drivers and system software. I also immediately discounted it being a problem with Vista, as I had used both Alcohol 120% and Daemon Tools successfully before reformatting. Obviously, something was different now than it had been, the trick was figuring out what. My first thought was that I might have lacked some kind of runtime redistributable that the developers forgot to include. That happens more than the software industry likes to admit. At any rate, I immediately did as much research on what components went into making SPTD as possible. Unfortunately that was a dead end. My next idea was that perhaps my default security policies denied the installer some critical privilege. I went into regedit and opened up the group policies dialog. Unfortunately, that route also was a dead end. After having ruled out software conflicts, lack of run-time components, and my administrative settings as causes, I went back to the drawing board. The only remaining possibility was that some option had either been enabled or disabled between the reformatting process and my first attempt at the install process. Then, it hit me. I had used a batch script to set certain options via command-line switches to personalize my configuration; I hadn't counted on one of them disabling a vital service to SPTD. I looked through it and examined each command looking for what it modified and what that setting controls. After about half way down the list, I found it:
bcdedit.exe /debug -on
At first I didn't realize why it was important. This setting is Vista's way of controlling whether or not kernel-mode debugging can be performed locally on a machine. It doesn't necessarily mean that kernel-mode debugging is taking place, I just enabled it because I like the feeling of being able to take a gander at what the Kernel is up to. Then I remembered that SPTD has a dislike for local kernel-level debuggers. But, surely a setting like this isn't a reliable indication of whether a kd is active - the developers wouldn't use this as the only means of determining whether a kd is present? I was wrong; Upon disabling this privilege (use the same command, only with the "-off" parameter to the "/debug" switch.), everything fell into place after a reboot. This brings us to the first tip. Don't give developers too much credit. Get your software installed before you go fiddling with things, even if you know what they are and what they do.
My next challenge arose when I was customizing Windows. This however was one that had bested be before, and I was forced to give up on the answer. This time I was determined to find the solution. The problem was simple: Whenever Windows rebooted or experienced a logoff event, any custom cursor immediately took the form of the default white pointer. I quickly discovered that the effect was purely cosmetic; meaning that each time the anomaly occurred, the setting itself did not change - simply the form the cursor became that of the default file within the '%SYSTEMROOT%\Cursors' directory. Ahhh, the workings of a drag and drop named based file system! Don't ya just love it! The solution is both elegant and primitive, making it wonderful for those who lack certain technicial computer skills. Indeed, who needs to know how to operate the machine when they can simply circumvent whatever happens to work against them? Simply rename the custom cursor file to the default cursor's name and replace the original with your customized one (Actually, now that I think about it, append '.bak' to the default file then rename the custom file and move it to the desired directory. This allows you to revert back to the default should the system's functionality ever change.). For example, in my situation I use the Aero theme - so my default file name would be 'aero_arrow.cur'. I have tested the workaround to the effect that functionality between the '.ani' and 'cur' formats are the same, and can be interchanged; This does not mean however mean that it is advisable to leave the 'ani' extension in place; If your customized file has a '.ani' extension, simply change it to '.cur'. This brings us to the next tip: Sometimes the most elegant and effective workarounds are also the most crude and primitve. If an OS has a quirky behaviour that can be harnassed, you are encouraged to do so. Beware though, you must always make a backup of anything you change.
I think that's it for this post. Make sure to add an Atom/RSS feed for the blog, you never know when I might go and post about something somewhat interesting.
My next challenge arose when I was customizing Windows. This however was one that had bested be before, and I was forced to give up on the answer. This time I was determined to find the solution. The problem was simple: Whenever Windows rebooted or experienced a logoff event, any custom cursor immediately took the form of the default white pointer. I quickly discovered that the effect was purely cosmetic; meaning that each time the anomaly occurred, the setting itself did not change - simply the form the cursor became that of the default file within the '%SYSTEMROOT%\Cursors' directory. Ahhh, the workings of a drag and drop named based file system! Don't ya just love it! The solution is both elegant and primitive, making it wonderful for those who lack certain technicial computer skills. Indeed, who needs to know how to operate the machine when they can simply circumvent whatever happens to work against them? Simply rename the custom cursor file to the default cursor's name and replace the original with your customized one (Actually, now that I think about it, append '.bak' to the default file then rename the custom file and move it to the desired directory. This allows you to revert back to the default should the system's functionality ever change.). For example, in my situation I use the Aero theme - so my default file name would be 'aero_arrow.cur'. I have tested the workaround to the effect that functionality between the '.ani' and 'cur' formats are the same, and can be interchanged; This does not mean however mean that it is advisable to leave the 'ani' extension in place; If your customized file has a '.ani' extension, simply change it to '.cur'. This brings us to the next tip: Sometimes the most elegant and effective workarounds are also the most crude and primitve. If an OS has a quirky behaviour that can be harnassed, you are encouraged to do so. Beware though, you must always make a backup of anything you change.
I think that's it for this post. Make sure to add an Atom/RSS feed for the blog, you never know when I might go and post about something somewhat interesting.
No comments:
Post a Comment