Bernd Blaauw wrote:

Kenneth J. Davis schreef:

It is documented, within kernel source doc directory and at

Strange that it says WinME is unsupported, and doesn't mention if Win9x FAT16/32 bootsector works or is (still) broken.
somewhere 'segent' --> 'segment'

WinME is special since MS partially crippled it. I'm not sure if it works asis or only if you use the emergency boot disk version; from sys' standpoint it is treated as Win9x (has same boot requirements), but there is no intention to add any special code for it.

But yes the Fat16 bootsector is still broken (I think I need to drop about 9 more bytes from my current shared Fat12/Fat16 all DOS bootsector [patched by sys with specific instructions to fit the selected DOS]. Technically Fat12 is broke to, but because the FAT is small enough it still works.

looks like I confused SAVEBS with BACKUPBS, my apologies.

:-)  I added them and I still have to look them up

I need to verify that the description for /RESTORBS is correct (does not modify it only writes it to disk. Which if that is the case then I need to add another option, perhaps /UPDATEBS which will take a bootsector supplied by the user same as /RESTORBS, but will update the geometry information in the BPB. [/RESTORBS may do that, in which case it will need changing to reflect the documentation and new switch added].

To summarize for all those wondering about these switches,
/BACKUPBS indicates that when sys works as usual, it will save the existing boot sector prior to any modifications that would occur /DUMPBS does the same action as /BACKUPBS, but exits without doing the normal sys actions (ie just save current boot sector to a file) /RESTORBS reverses any actions sys did to the bootsector by restoring the bootsector saved by either /BACKUPBS or /DUMPBS to be added /UPDATEBS would take the bootsector as saved by /DUMPBS or possibly /BACKUPBS and adjust its geometry information to match to drive applied to; so in theory you could apply vendor X's boot sector originally saved from disk A to disk B and it would boot [where disk A and disk B are do not have identical geometry].

Regarding the MS install issue, one could do something like format with FreeDOS format, then use FreeDOS sys to install MS-DOS files/bootsector via its /UPDATEBS (and obtained by its /DUMPBS, winimage, any other bootsector extracting program, or even from a disk image), etc.

/OEM:XX where XX determines which DOS you want to boot; it chooses/alters the bootsector to be compatible with the given DOS. For FreeDOS all that is really required is passing boot drive in BX and loading full kernel (Enhanced DR-DOS is similar, except uses DX), and MS/PC DOS have a heap of expectations (less so in newer releases). The AUTO option (which is the default) determines based on which files are present (with a hard coded list, the order of which determines the one selected should multiple kernels be present); however due to the similarities, EDR-DOS will be used instead of PC-DOS so PC-DOS must always be manually selected.

/OEM:AUTO usually will mean FreeDOS is preferred, yes.
When you want to force writing a FreeDOS bootsector , use /OEM:FD
/OEM:MS and OEM:W9x are difficult to use, as you cannot determine in batchfile or commandline when looking at the system files which operating system is used. Only thing you can determine it's Windows instead of MSDOS is if you see IO.SYS on a fat32 partition.

does this imply you think an /OEM:?? that indicates generically MS DOS (version 6 or earlier and win9x DOS version 7+)? What two letters abbreviation would you suggest? I'd prefer not removing W9x and merging them both into MS; but will if the consensus is this is preferred (since the filenames are the same it is unlikely for both to be on the same disk; but if they were using alternate names how would a user select the correct one?)



SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
Freedos-user mailing list

Reply via email to