5 replies to this topic

[Kaos-Industries]

Hi there,

 

I successfully created a multibootable USB using WinSetupFromUSB, allowing me to boot into an ISO for MS-DOS 6.22 and installer ISOs for Windows 7 32- and 64-Bit from a single bootable USB. However, while the Windows 7 ISOs are both accessible from the Windows Boot Manager (bootmgr), MS-DOS requires grub4dos to be loaded.

 

This means that my bootable USB is split into two separate boot menus; the grub4dos menu, which is initially booted into and contains the menu entry for booting into DOS 6.22, as well as another two (first and second half of Windows 7 installers) for booting into bootmgr, from where both the Windows 7 entries can be found.

 

I don't like this way of doing things, and I'd really like to unify all four entries into one single menu under Windows Boot Manager. Is this at all possible?

 

Thanks in advance, I really appreciate any help I can get. I also have a related thread on getting DOS 6.22 to work with a bootable USB over here, and would appreciate expertise on that too:

 

http://reboot.pro/to...ccess-to-files/

 

[Wonko the Sane]

Yes you can, but you shouldn't (see the reason on the reply I gave you on the other thread).

However BOOTMGR parses automatically BOOT.INI discarding each and every ARCPATH but adding on-the-fly to the BCD options one to boot any line in BOOT.INI pointing to a boorsector.

You can have a BOOT.INI with an entry pointing to grldr (that can behave as a bootsector) and thus load grub4dos from BOOTMGR.

Then you can remove the menu.lst and change the embedded menu in grldr to only do the *whatever* you want it to do to load DOS.

Still, if you run DOS for your software a .ISO (which is read only) is not suitable.

 

Wonko

[Kaos-Industries]

Yes you can, but you shouldn't (see the reason on the reply I gave you on the other thread).

However BOOTMGR parses automatically BOOT.INI discarding each and every ARCPATH but adding on-the-fly to the BCD options one to boot any line in BOOT.INI pointing to a boorsector.

You can have a BOOT.INI with an entry pointing to grldr (that can behave as a bootsector) and thus load grub4dos from BOOTMGR.

Then you can remove the menu.lst and change the embedded menu in grldr to only do the *whatever* you want it to do to load DOS.

Still, if you run DOS for your software a .ISO (which is read only) is not suitable.

 

Wonko

 

The multibooting isn't really a problem, and unlike with the specification of a certain version of DOS, there's nothing to suggest the software won't work with multibooting, so I consider it relatively safe.

 

Regardless, I'm now considering using FreeDOS. Would FreeDOS be easier or harder than DOS 6.22 to run from Windows Boot Manager? Also, is FreeDOS also read-only?

Edited by Kaos-Industries, 16 July 2017 - 08:21 PM.

[Wonko the Sane]

Regardless, I'm now considering using FreeDOS. Would FreeDOS be easier or harder than DOS 6.22 to run from Windows Boot Manager? Also, is FreeDOS also read-only?

It will be exactly at the same level of difficulty.

 

It's not MS-DOS (or FreeDOS) that are read only, you manifested the intention of booting a .iso.

 

A .iso (by definition) is read only as it is an image of a CD (or DVD) ROM i.e. a read only media (more correctly a WORM, Write Once Read Many media in the case of a "burned" CD/DVD).

 

I explained (hopefully) how this is not usually appropriate in the reply to your other thread, here:

http://reboot.pro/to...files/?p=204127

 

The idea is that the simpler the setup/build/whatever is the less are the probabilities that *something* will get in the way of the software managing the "very expensive hardware" you talked about.

 

But of course you can add each and every possible (and impossible) level of (unneeded) complication, actually most of the time that is the most fun part .

 

Wonko

[Kaos-Industries]

It will be exactly at the same level of difficulty.

 

It's not MS-DOS (or FreeDOS) that are read only, you manifested the intention of booting a .iso.

 

A .iso (by definition) is read only as it is an image of a CD (or DVD) ROM i.e. a read only media (more correctly a WORM, Write Once Read Many media in the case of a "burned" CD/DVD).

 

I explained (hopefully) how this is not usually appropriate in the reply to your other thread, here:

http://reboot.pro/to...files/?p=204127

 

The idea is that the simpler the setup/build/whatever is the less are the probabilities that *something* will get in the way of the software managing the "very expensive hardware" you talked about.

 

But of course you can add each and every possible (and impossible) level of (unneeded) complication, actually most of the time that is the most fun part .

 

Wonko

 

I see.

 

True, it is the fun part. My insistence on using DOS in this case is mainly because I don't want to break anything, but a lot of it is just plain curiosity - I'd like to run as close to a real DOS system rather than FreeDOS, just cause I prefer how it looks and operates, and am only willing to abandon that dream if DOS is looking like it'll be impossible to run with these programs.

 

I suppose I'll leave this particular thread until I'm positive on the specifics of which OS I'll be going with, which will be decided by the other thread. Either way, I think I'd like to learn about the specifics of what you're describing here and whether it's too much work or not - it does sound intriguing. Would you mind going more into depth on how exactly it's done, or would that also be dependent on the OS I'm using?

[Wonko the Sane]

Esssentially *all* DOS versions (both MS-DOS and FreeDos AND a number of other DOSes) behave (more or less) the same.

 

So there is not any particular "added difficulty" in using the one or the other, only some (small and anyway known) diffferences in the specific way they need to be installed/deployed/booted.

 

The whole point is that the older the version of DOS is, the more limitations it will have, be them filesystem or device size, memory used or accessible, incompatibility with this or that specific program, etc.

 

I will give you a small example for MS-DOS up to 6.22.

IO.SYS needs to be the first entry in the FAT table.

This limitation has been removed in MS-DOS 7.00 (and it never existed in FreeDos that uses kernel.sys as OS kernel).

 

This is not normally a problem (the IO.SYS is placed correctly when you install via the SYS command, and anyway there is BootPart that can re-write it in the right position if needed) and can be worked around AFAICR by bypassing the bootsector code (let's say via grub4dos).

 

BUT - for all we know - your specific software may well be checking for the presence of IO.SYS exactly where it should be (at the time it was a "standard") and throw a fit if it isn't there, or it may not, (no way to know without experimenting).

 

Mind you it is very improbable that this check is made, but if your software does not work when you do not put the IO.SYS where it should be AND you use (still say) grub4dos for the booting AND you use it chainloaded via BOOTMGR, AND you boot via USB AND you have it inside a (read only) .ISO image AND you <insert here *something else*> it would be more complicated to find out which of the listed changes is affecting the software functions.

 

Wonko