My understanding of the recurrent drive- and drive-letter- related bugs in VBPro is as follows ---

The most important fact is that Windows 9x/Me, XP/2k/2k3/XP x64, and LH/Vista represent three different levels of technology, using three different MBR methods --- 9x/Me and XP/2k/2k3/XP x64 being generally intercompatible, provided older to newer setup order is followed ; LH/Vista not so.

LH/Vista unlike previous post-Win95 OSes implements a radically different pre-boot environment, Unix-like, not DOS-like. However, for retro-compatibility reasons, it continues to be DOS-like- MBR compatible.

Issues appear during Legacy & LH/Vista multi-boot scenarios, basically because unlike previous intergenerational Windows multi-booting, two separate partially incompatible MBR environments are created --- and the lower level is at the LH/Vista pre-boot level, not in the Legacy MBR data --- ie newer is lower than older, unlike all previous cases.

The issue is that the legacy MBR strictly mirrors the boot order mechanically defined in BIOS/CMOS and the physical hardware config, whereas the LH/Vista MBR boot order is defined logically IMO, by the sub-Monad environment needed for Vista pre-boot.

...

Taking the simplest case, XP/Vista dual-boot, there are then effectively several hard-to-reconcile boot levels:

CMOS / hardware config : OT1H defines the physical location of the primary MBR, OT2H simply assures that all drives can be seen by the low-level software and data transmitted to the higher levels

sub-Monad environment: in a XP/Vista dual-boot environment, it is at this command-line level that drive priority is defined --- this is why most (but not all) setups see both XP and Vista (internally and severally) as C: ... (bearing in mind that, except in some Server environments, this is not full Monad --- but the architecture of Longhorn in general requires that this sub-Windows level be managed by some kind of Monad) ... because it appears to be that drive priorities are generated here after OS selection, instead of OS boot choices being generated from the lower-level boot environment, as in the Legacy pre-boot systems.

Vista pre-boot / BCD : here is the source of greatest confusion IMO ... BCD is capable of managing both the Legacy MBR and the Longhorn MBR ; BUT it uses the Longhorn MBR to identify the various boot entities. Boot letters are non-existent at this level BTW , and furthermore -- unlike in Legacy pre-boot, boot order is defined not mechaniically but logically, by the sub-Monad software environment. However, when booting into Legacy Windows environments, the sub-Monad logically recreates the Legacy boot order, so that the Legacy boot order is recreated, seemingly transparently, but in fact with a potentially incompatible non-Legacy logical structure.

Final level are the dual XP/Vista Windows environments, which is where the drive letters are assigned --- however, unless certain specific pre-installation conditions are created, drive letters assignment will usually be core-variant, and for the purposes of VBPro, occasionally incompatible.

Vista pre-boot order cannot be easily predicted from the hardware config, nor from BIOS/CMOS, nor from the order of drive letters in the Legacy OS, but it is instead an artifact of the sub-Monad pre-boot and sub-BCD environment of the Unix-like Longhorn Core.

Accordingly, I believe that VistaBootPro 3.0 should be developed using Monad ...

...

... it's a long time though since I did any significant coding, and I may have the levels wrong or perhaps even mixed-up here, and especially it may not be Monad specifically but some related protocols that are needed ; however I feel fairly sure that this is a good enough general view of the inherent problems, and that here is the level where the ANNOYING driveswap issues occur and mess up people's dual=boot systems ... ...


Split and moved to own topic by Grav!ty

JabbaPapa this post of yours does not belong in the bug reporting thread of VistaBootPRO as it does not deal with a bug in the current build.

The issue you are talking about with reference to VistaBootPRO was a simple coding error in a release two versions ago and was completely addressed and fixed in the refresh version 2.0

I think as more people get used to the dual-boot (Especially the BT crowd), they will see how Vista assigns drive letters differently based on how it was installed to the system.......... booting from DVD or running setup.exe from within XP or even Vista.

Once folks get comfortable that their drive partitions aren't actually "changing" locations, they should get a better "feel" for the dual boot environment

Just popping in for a minute and saw this. Graham is correct. It was partly a coding issue and later we discovered that it went deeper than that. Vista and XP assign drives letter in two different ways. The drive letter has to exist in order for you to add a legacy/vista entry. This is where we discovered what that error code actually means (the one that was a problem in 2.0 with renaming entries). If you go and add an entry and then reboot and try to select that "installation" you will receive the notorious error that was related with VBPro 2.0. This is because it can't find the ntldr and it fails. Now, if you remove any type of entry, go and "Add" a new entry where that os is installed, reboot, you have no problem booting.

I know that may seem confusing, but that is basically the break down. And that was a previous error which has been corrected to an extent. If someone creates a drive, adds an entry matched to that drive and restarts and selects that entry, they will still receive that error code. And that is only cause we can't install the OS for them. That type of feature is only for someone who wants to install an OS on that new entry/drive on reboot. However, like I stated before, if they just add an entry where an OS already is installed and reboot, they will have no problem booting to that OS.

HTH,
Jason

Grav!ty wrote:

JabbaPapa this post of yours does not belong in the bug reporting thread of VistaBootPRO as it does not deal with a bug in the current build. The issue you are talking about with reference to VistaBootPRO was a simple coding error in a release two versions ago and was completely addressed and fixed in the refresh version 2.0

I asked someone by PM about the appropriate place to give my feedback/analysis (some weeks ago admittedly) and was told to put it there, but I agree with you Grav!ty that it is not a specific bug with the current build, rather an analysis of various issues that have cropped up from build to build, and do still occur, often because of people's understandable confusion in face of the variant drive letters allocation between XP and Vista.

kd1966 I think there will be very few issues once people start just ditching XP totally, and having Vista as their sole OS

jbullard, your explanations are closer to the gist of what I was saying --- that "Vista and XP assign drives letter in two different ways" to quote, except I personally believe it goes even deeper than that, and that there are variant MBR protocols, and that ideally, VBPro should manage volumes at the MBR level whilst at the superficial UI level continuing to use the existing drive letters.

VBPro is software for people wishing to multi-boot, and of course eventually the target audience for the RTM app will be a tech-savvy lot with less need for safety nets than in the present timeframe

Actually, I was very impressed that the 2.1 checks for the presence of a proper boot environment before implementing some of the possible system-breaking changes, awesome work guys I'd (just personally) love to see more features and safety nets like that in future builds

Please take these as they're meant, suggestions not criticism --- I honestly just love this app and the awesome work that is going into it