> > > > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > > > and hence the whole system. > > > > > > Obviously it makes no sense at all to make special DOS boot floppy with > > > old > er DOS > > > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot > > > flopp > y with > > > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > > > dri > ve, so it > > > seems that FBSDBOOT now totally useless :( > > > > > > Sincerely, > > > > > > Maxim > > > > > Why can't we make a copy of the vector table and save to file and have > > fbsdboot use the table from the file? > > How do we get this vector table in the first place? > > How do we keep it updated?
The flags and values in the BIOS data area would not necessarily be at their default values, so restoring the vectors might itself crash the BIOS (because it's reconfigured itself for the present vectors/drivers, not the default ones). Some hardware (eg. popular SCSI controllers) also configures itself differently when it finds it's running on DOS/Windows. This kind of thing in any scenario in which we start DOS then kill it would have the potential to seriously confuse matters. Incidentally (to correct a point made in an earlier post) *all* versions of DOS since 1.x have changed interrupt vectors. This is not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at this stage is that, in the future, VM86 will be increasingly relied on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a VM86 context. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
