Background: I like to have more than one OS on my machines for a number of reasons. I've been using System Commander 2000 since, well, 2000. I usually have a small DOS partition and I use the SC CD to bring it in and from there on it's Fat City. I've had as many as 7 different entries, representing different states of different OS'es and it's always worked like a charm.

V-Comm sold out System Commander a few years ago, and the reading I've done seems to indicate it's gone way downhill (the original author made his pile and is now a Tesla enthusiast. But I digress.

Just picked up another laptop with a nice dual core, lots of memory, a good sized hard drive, and with the impending demise of XP support I thought I'd set up at least two partitions, one for XP and one for Win7. Unfortunately, there's no easy way to install DOS (no floppy) and some of the other tricks I tried didn't work (System Commander fiddles directly with the hard drive, and XP/7 won't allow that - you need a less picky OS to initially install things. After that you're OK since the fiddling goes on before the OS loads). So, I had the choice of using either the XP/Win7 dual-boot option, or a third-party boot loader.

Lots of folks seem to think that EasyBCD is a pretty cool and stable. Since it seemed so popular, I was surprised that search turned up nothing on this forum. This surprised me a little, since it's about the first thing I've ever found that somebody here hasn't fooled with.

So - anybody using it? Anybody else here use a multi-boot configuration? If so, how do you do it?

Just put FreeDOS on a USB stick (you can probably also put old-school MSDOS on a USB stick, but why would you want to.)

If just using XP and Win7, I would recommend the former. As long as you install XP first, Windows 7 should just see the old installation there and set it up automatically.

I've got my laptop on triple-boot, Windows 7 / Windows 8.1 / Linux, but it's UEFI not BIOS and has two drives (Win 8.1 on mSATA, the other two on 2.5") so my solution isn't generalized. To get into Linux, I have to hold down F12 to see the BIOS list, but I added the Windows 7 install to the the Windows boot manager originally from 8.1.

For XP and 7 on a single drive, personally I'd just run 7 and run XP virtualized, but I don't have any non-USB hardware or performance-sensitive software that won't work with 7.

I have not needed more than one version of Windows in parallel between Windows XP and Windows 8.1 (I skipped 8 entirely), and when I did it regularly with one of NT4/2000 and one of 95/95OSR2.1/98/98SE (I skipped ME), they were happy to coexist as NT/2000 was on NTFS and 95/etc was on FAT.

If I had to physically boot XP for something non-USB, here's what I'd do:
1) Install XP to a small partition.
2) Back up the XP partition to an external drive using clonezilla.
3) Try to install 7 to free space on the drive, minus 1GB. I think there's a good chance this will just work, AND set up the dual-boot. Have you tried it?

Assuming that didn't, or it killed XP in the process...
3a) delete the XP partition, create a pair of dummy non-Windows partitions, 1 of 1GB, and one the size of the XP partition.
4) (re)install Windows 7 on the free space.

Your partition layout would then be:
dummy #1
dummy #2
Windows 7 100mb system reserved
Windows 7
(yes, that uses up all your primary partitions. If you want a separate data partition, you are probably SOL, but you can probably make dummy#1 the first extended partition and put after...)

5) restore the XP partition to the dummy #2 space using CloneZilla.
6) Confirm you can boot both XP (with the partition #2 set active) and 7 (with partition #3 or #4 set active; unless you run bitlocker, either should work but the installer is picky and sometimes only one or the other is set up OK)
7) Install a SystemRescueCD image ( http://www.sysresccd.org/SystemRescueCd_Homepage ) and copy of GRUB to the dummy #1 partition.
8) Create a grub.conf file to allow chainload on (hd0,1) and (hd0,2) [assuming the active partition for 7 was #3... hd0,3 if #4... adjust down by one if using first extended for the dummy#1] and to boot systemrescueCD . Set the default and delay as you prefer.
9) install grub on (hd0,0) [or hd0,4 if using the first extended]

Should be good to go.

Tried that, for some reason it wouldn't work. "bad boot.ini" message, etc., that DOS doesn't use. I think it comes from the bios, but that would seem to mean that the bios expects you to be loading Windows always.

Anyhow, I have some stuff on DOS that I still use, and if I want to screw around directly with the hard drive, I have to do it outside of XP/Win7.
This is what I was hoping would happen. On an existing setup, when I boot into XP, it also know that my FAT16 version of DOS is on the drive and offers to boot it. Not sure why it doesn't see my FAT32 DOS, but in any event all are available from SC.

Not sure what happens if I try to install linux on the same drive, but there's stories out there purporting to tell how to do it. A third-party manager should be able to handle all this stuff.

For the record, I don't know what UEF1 is, and at the moment I have no interest in virtualizing anything. Ordinarily, I don't have to do it and it's one of those things that may be just wonderful but since I can get along without it just fine I'm probably not going to bother.

Of course, this opens me up to the criticism that "You don't know enough for me to tell you what to do" like I used to get from the Linux weenies when I'd things like, "Where are the usual places the docs say the files go?", or "Why don't the man pages tell me what the switches do?".

What tool did you use to put DOS onto the USB stick? Are you telling the machine to boot specifically off the USB -- usually via the F11/F12 boot-up menu?

And that requires direct access to hardware, so it won't run in DOSBOX or a Virtual Machine?

The good tools for that are all free, and Linux-based these days; having a small Linux partition is the best way to go there.

Well, with just XP and 7, it should work.

Adding DOS, if you absolutely had to, would need to be done later... and is probably best done by using a DOS disk image on the small Linux partition, and using GRUB to load that, rather than installing it to a separate partition (you wouldn't have enough unless FreeDOS can boot from an extended partition.)

I haven't heard of/thought about SystemCommander in around a decade.

Then again, I haven't used FAT on anything except removable media in nearly that long, since decent NTFS drivers became available for Linux. Modern journaling file systems are significantly better.

Commercial 3rd party utilities are so 1990s. Learn GRUB (I recommend GRUB 1.x, which is a lot easier, as long as you don't need UEFI support; GRUB 2 is even more powerful, but GRUB is already essentially a very light operating system, and with GRUB2 you trade a lot of unfriendliness for features you don't need.)

UEFI, "Unified Extensible Firmware Interface" is a new standard that replaces the old interrupt-based BIOS. The main practical benefit is knows how to boot from GPT-partitioned disks, which for the scenarios you are talking about gets rid of two annoying DOS-era limitations: no booting from disks larger than 2TB, and no more than 4 bootable partitions (3 if you have an extended partition.)

It has some other benefits (like not needing a bootloader at all to do multiboot, faster system initialization, secure boot for those using it) Unfortunately, it's only supported with Windows 7 and later, and on comparably recent versions of other operating systems (e.g. for Linux or *BSD, versions since 2009 or 2010 on most distributions.)

It's also a bit harder to figure out when you start digging into custom installs of more than one OS, although it's really powerful once you learn it.

I can't see why someone would WANT to multiboot, but not WANT to take the time to learn about virtualization.

With modern software -- most of which is free, BTW -- you can very easily run multiple OSes at the same time, rather than having to multiboot, and for old DOS stuff, it adds the benefit that it reliable runs old pretty much ALL old DOS stuff that doesn't require dedicated hardware in a Window vs. Windows' DOS console (gone in newer 64-bit versions, anyway) which failed with a lot of software (the now-unsupported open source NTVDM package helped with a lot of things, but not everything.)

I have a few old games that run well on XP but not which have problems on 7 or later. 7 (well, 7 Pro or better) came with a free virtualization solution "XP Mode" which at the cost of a moderate size download runs about 95% of the software I've seen that has problems on newer versions. The remaining 5% are all games that require a stronger graphics card than it's possible to emulate, or require direct access to a piece of non-USB hardware. It has no trouble with USB-based hardware; my old scanner, which is not supported under Vista or 7, ran great on XP mode, and connecting USB hardware through to the VM is dead easy. (It's based on Microsoft Virtual PC which used to be a separately sold commercial product, and the copy that XP Mode installs can technically be used for other OSes, but it's very NON-easy for any use case other than XP Mode.)

VirtualBox isn't quite as easy, but can run pretty much any OS out there (including the ones you've talked about plus even older versions of Windows, the Mac OS, Android, Solaris x86.) It's still pretty easy, and it's free/open source for most of its features; emulating higher-speed USB 2.0 requires a free-for-non-commercial-use but closed source extension pack downloadable from Oracle, and USB passthrough is trickier to do than on XP Mode. It's a much smaller download, too (although to run XP on it you need a license or to look up instructions on how to use the VM image from the XP mode download.)

DOS is even easier, since it's sufficiently old and basic you can emulate it outright rather than using virtualization. If you don't need physical hardware access, DosBox just runs and is a superlative program as long as you don't need any hardware access -- your files live in a regular subdirectory under Windows or Linux (can map as many subdirectories to different drive letters as you like) -- and can run pretty much every piece of DOS software I've ever seen that doesn't need raw access to disk drive blocks. (Free, and open source.) The biggest problem it's got is no printer-port emulation support, so if your software doesn't support COM port printers it is not possible to print (and if it does, it's not much better, although it IS possible.)

(I'm pretty sure you've said you don't game, but for old DOS games it has the added benefit of doing speed throttling way more effectively than any other option I've ever seen -- you can smoothly scale the speed to it your liking, plus for loading screens and stuff you can hit Alt-F12 for "run as fast as the hardware is capable of")

--

Your call on what to spend your time on, but I would expect that the couple hours it would take to explorer VirtualBox fairly thoroughly would prove fruitful as a matter of general knowledge even if you decided it was not appropriate for your use cases.

My brain and some old Peter Norton books. Certain files have to be there in order and that should be enough. And, yes, I can see the one-time boot menu. Interestingly enough, with no usb stick, boot from USB is an option. When I put the stick in, that option disappears. I dunno why. It was late, so I quit.
Because I don't care enough about it at this point to delve into it. I just want to be able to boot whatever OS I want like I've always been able to do.

When I make my living with computers. they're just boxes that perform various functions, Yeah, I have to know a lot about what goes on under the hood, but I treat them pretty much as appliances. Tweaking them for maximum whatever is not high on the priority list.

Maybe when I have nothing better to do I'll look into it. It's already on my to-do list, but fairly far down.

and I'm so 1960's
Yeah, I googled it (and found out it's UEFI - on my screen the I looked like a 1).

"UEFI eliminates the old-fashioned BIOS", followed by "UEFI runs on top of the BIOS". Hello?

The purpose of the BIOS is to provide a standard interface for the user software to access the hardware - the board-specific BIOS handles the details so you can write software that will run on any machine without having to customize it. I believe this function is still required. The end user ('the great unwashed') couldn't care less about how it's done. Many of my students were not even aware that such functionality even existed on their machines, much less that it was required. I suspect that 95 out of 100 people I would ask would never have heard of UEFI (unless I was asking at a Developer's Conference or something).

Bt the way, I think it also makes a nice, juicy target for hackers and virus writers, too. No need to write OS-specific malware - just get into the UEFI code and you can do your dirty work without any OS even running. This, I understand, is a 'feature' of UEFI. Just sayin'.

Meanwhile ... there is apparently still a healthy market for third-party boot managers out there, and my specific questions were -- what do you do (you answered) and have you used EasyBCD (still no answers).

Uh, no. That neither should be nor is enough today -- it only ever was for media formatted by DOS because those always had a DOS boot sector. You also need a compatible boot sector (and potentially a correct partition table, and a master boot record, depending on if the USB stick is formatted with partitions or not.)

Windows can't format a USB device to be bootable out of the box, and and given that most versions of DOS don't speak USB, putting it on via the traditional DOS way (format /s) is unlikely to work.

There are a TON of tools you can use; being a Linux guy, I like to use GRUB to make bootable USB sticks[*], but if you want more of a pure DOS one you might look at http://sourceforge.net/projects/tuxboot/ or http://unetbootin.sourceforge.net/ or http://www.pendrivelinux.com/yumi-mu...t-usb-creator/

[* my keychain has permanently a USB stick with the Windows 7 installer, System Rescue CD, CloneZilla, and an old SuSE livedvd image -- which I really should upgrade to Fedora. I assembled it manually, but it would be possible to use YUMI of the ones up there to do something similar. ]

You're putting method ahead of results. "Booting whatever OS you want" is presumably something you're doing to achieve certain results, rather than being an end in itself... no?

Dealing with the hassle of running archaic OSes directly on modern hardware, and dealing with dual-booting (or triple-, or more) is a great deal MORE "tweaking them for something" than dealing with a 2nd (or 3rd) OS under virtualization.

Which is fine, if you like the former, and it suits your actual needs.

If you were 1960s you'd be IPLing with switches on the front of the machine and loading the OS off giant tapes.

Poorly written, although both can be true depending on how the individual machine is implemented.

The original IBM PC BIOS was a relatively poor job of that even on the original generation of PC hardware; it provided a minimal level of abstraction which was adequate for PC-DOS/MS-DOS, but which had to be subverted for TONS of software pretty much from day one -- which is a big part of why there was more to IBM compatibility than just the BIOS.

Indeed, that's the difference between a half-arsed OS like DOS (which does not offer an common abstraction supporting a great deal of the hardware on the machine) and a comprehensive OS like Linux or Windows NT (where there are standard APIs for pretty much all the common sorts of hardware.)

Even under DOS, the prevalence of DOS extenders and Windows 3.x that went around the BIOS to get to disk (the one function the BIOS

These days, the BIOS exists purely to initialize enough hardware to boot into another OS, and to support a recovery environment. It's adequate for that, but it's still a very early 1980s design with a whole ton of weird kluges on top.

Sure.

The subset of that function that's actually required in firmware (a lot of what you described is better served by the OS, and is not in either BIOS or UEFI) is still served quite well by both.

UEFI is just adapted for modern hardware, and offers a (modestly) higher level of abstraction and service level to the software, rather than requiring compatibility with a 30+-year old 16-bit design

(As an aside, there have been several earlier attempts like EISA, MCA, and ABIOS ... none of which caught on.)

All standard PC compatible UEFI implementations include "legacy support" which is basically a BIOS; for some others, where the basic software is PC compatible, you can always load a BIOS as a software application -- which is as I understand it (not clear if this is correct) how Boot Camp works on the Intel Macintoshes.

Indeed. Of course, most end users can't care less about the infrastructure of their OS either, and just care that the UI is to their liking, will run their software, and won't crash.

Probably not, but most enthusiasts/hobbyists -- let alone IT professionals -- who would make the effort to do their own installation their own OS these days on hardware new enough

Uh, dude, ever hear of a "boot sector" virus? Been around since at least the late 1980s? That's in essence a BIOS virus. VERY old news. Meanwhile, UEFI is less insecure than the BIOS, although that's neither saying very much nor that it's in any practical sense "secure" -- unless secure boot is enabled, in which case it's MUCH more secure (although it's a great deal less convenient to install a non-"blessed" OS, as you need to understand a bit of public-key cryptography from the "generate a key and sign files" level... not that hard for someone who can handle PGP or SSH, but not for the novice.)

Sorry, thought I'd said; no, I've never used EasyBCD, and when I've run into references to it in passing it's been as a tool to repair broken Windows boot manager entries not for intentionally setting up multiple OSes.

--

BTW, you might look into SysLinux rather than GRUB. Slightly lighter-weight, slightly more DOS-like. Both SysLinux and GRUB can use a DOS partition as the bootloader partition, rather than an ext-whatever Linux one. Would not be my preference (running Linux being very comfortable, and the file system reliability is much better), but if you're more comfortable with DOS-based tools, might be a little more maintainable for you.