Under Windows XP and 2000, Windows looks for a simple text file, called boot.ini, that controls boot options, displaying them for your selection in character mode during system boot. If you have more than one version of Windows installed on a computer, Windows consults the boot.ini file (located in the root directory) for this information at boot time. Boot.ini controls basic defaults, such as which installed OS will load automatically if you don't intercede on the multiboot screen, the wordings that describe your options there, and how long the multiboot screen will display at boot time before executing its defaults.
A simple tool for editing boot.ini to control default boot behavior is available in the Advanced > Startup and Recovery area of the Control Panel. The boot.ini file is protected by read-only attribution, but that doesn't make it secure. If someone hacked your network or a Trojan wanted to execute a script to edit this file, that wouldn't challenge it much. In fact, the vulnerability could cause major headaches, especially for inexperienced users.
Presumably, this is the reason Microsoft opted to do away with the boot.ini text file in Windows Vista. I'm OK with that. My problem is with the alternative it has instituted instead.
Introducing Bcdedit
For example, the act of switching the default OS from Windows Vista to Windows XP took me several trial-and-error attempts, and even then it didn't work properly. I'm sure I'll finish climbing the learning curve, but why the heck would Microsoft do this? Why not just encrypt the file and make it accessible only to users with Admin privileges who know the Administrator password? Why make the tool for editing the file as arcane as DOS or Linux?
When installing new versions of Windows Vista, I usually run Windows XP in drive C:, create a new partition, and then install the latest Vista beta in the new partition. Windows Vista, like Windows XP and Windows 2000 before it, automatically sets up the multiboot configuration during installation so that both operating systems are accessible. When I'm ready to install the next beta, I simply boot to Windows XP and change the multiboot configuration to default to XP. I use a utility to delete the Vista partition, recreate it, and reformat it as an NTFS drive. Then I install the new version.
Boot.ini Loses Control
How is that possible? Simple. Microsoft has placed a new "boot" folder on your root drive. The bcdedit utility stores data in this folder. As of the December CTP, in order to solve the problem of uninstalling a Vista build and returning to the Windows XP default boot configuration, I added a simple step. I started by editing the Windows XP boot.ini file, making XP the default entry (and deleting the Vista entry). Then I simply deleted the c:\boot directory added by Vista, and followed the steps above, deleting, recreating, and reformatting the Vista partition.
Overall, the new way of managing boot script data seems overly complex and not particularly secure. Hey, utility programmers! I see an opportunity for a GUI program that makes the Vista boot data as easy to edit as it was under previous versions of Windows. (Perhaps you could add some encryption too?)
I'm sure I'll finish climbing the learning curve, but why the heck would Microsoft do this? Why make the tool for editing the file as arcane as DOS or Linux?
The only way to make changes to the multiboot configuration now is with a complex command-line utility called bcdedit (bcdedit.exe). Admittedly, there isn't much documentation for this utility yet. There is extensive help information built into the tool, although it's poorly written and figuring out the syntax requires guesswork. I found the tool incredibly difficult to use, and I had trouble making it do what I needed it to do.
With Vista's new way of managing the multiboot script which has been in place since the October CTP Windows XP's boot.ini file can't control Vista at all. The Vista way of doing this trumps the XP way of doing it. Even if you entirely delete the Vista volume, as I described in the previous paragraph, you'll still see the Vista version of the multiboot screen when you boot your machine, and your Windows XP boot.ini file goes totally ignored.
BP seeking Regional Desktop Coordinator in Houston, TX
Agilent Technologies seeking Marketing Manager in Melbourne, AU
Advancement Project seeking Junior Web Developer in Los Angeles, CA
Johns Hopkins Univ Carey Business School seeking Asst Dean for IS in Baltimore, MD
City of Westland seeking MIS Director in Westland, MI
For more great jobs, career-related news, features and services, please visit our Career Center.
Insurance Providers: Improving Customer Retention through the Contact Center
Customer experience is a big deal for the insurance industry, and doing it right has never been more critical than now. In fact, Nationwide Insurance found that a 1% increase in customer retention increased annual premiums by $1 million. In order to master providing a consistent – and consistently positive – customer experience, insurance companies must rebuild their contact center operations around the customer. The problem? Desktop complexity in the insurance contact center, which is particularly prevalent in the insurance industry. Some insurance companies have more than 20 applications and tools on the desktop. That means that CSRs, who are supposed to provide quality and timely service to customers on each call, end up navigating through dozens of non-integrated applications. The good news is that implementing a unified desktop in the contact center will help insurers overcome all of the above-mentioned challenges, giving the CSR that fully integrated view of each customer. A unified desktop solution is the quickest and most efficient way to improve customer retention while reducing your cost of operations – it’s the insurance policy you need to keep your customers’ business for years to come.

NOTE: Offer valid for U.S., U.S. possessions, & Canada only