cxk297:What do you do if you have Vista & XP on seperate drives and they are both Primary Active? I have just been switching the sata cable back and forth.
Have you set the jumper on the drives?
SATA Drive 1 (WinXP) Jumper set to - MASTER
SATA Drive 2 (Vista) Jumper set to - SLAVE
QUOTE:
Windows Vista Gets Harder to Multiboot?
One of the many small things about Windows Vista that haven't been well explained by Microsoft or us technical reviewers is the change in the way the new OS handles boot instructions.
Under Windows XP and 2K, 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. Prior to Windows Vista, if you had more than one version of Windows installed on a computer, Windows consulted the boot.ini file (located in the root directory) about how to handle basic options and default actions at boot time. A simple tool for editing boot.ini to control default boot behavior is available in the Advanced > Startup and Recovery area of the System Control Panel. 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. 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 be challenging. 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. I'm OK with that. My problem is with the alternative it has instituted instead. 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, though it's poorly written and figuring out the syntax requires guesswork. Bottom line: I found the tool incredibly difficult to use, and I had trouble making it do what I needed it to do. 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?
On most of my test machines, I run Windows XP in drive C:, create a new partition, and then install the latest Windows 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. Then I use a utility to delete the Vista partition, recreate it, and reformat it as an NTFS drive. Then I install the new version.
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.
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 it stands in the December CTP, I found that to solve the problem of uninstalling a Vista build and returning to the Windows XP default boot configuration, 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. Then I followed the steps above, deleting, recreating, and reformatting the Vista partition. It adds a simple step.
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?
END QUOTE
There is a nifty program out called "VistaBootPro" that I think might be of some interest to you. Check it out here: http://www.pcworld.com/downloads/file/fid,64564/description.html
QUOTE:
Control how Windows Vista boots with this easy-to-use tool.
Want to change how Windows Vista boots? Ordinarily you'd have to learn the ins and outs of the incomprehensible BCDEdit command-line tool. But this simple, graphical program lets you master Windows Vista boot-up and startup without ever touching dreaded BCDEdit.
END QUOTE:
-MRG