Date: Mon, 17 May 1999 23:24:37 -0500 (CDT) From: Jonathan Lemon <jlemon@americantv.com> To: ctapang@easystreet.com, current@freebsd.org Subject: Re: FBSDBOOT.EXE Message-ID: <199905180424.XAA02905@free.pcs> In-Reply-To: <local.mail.freebsd-current/006201bea0ae$7e656340$0d787880@apex.tapang>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/006201bea0ae$7e656340$0d787880@apex.tapang> you write: >Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I >would like to fix it, so please describe exactly what the problem is. What >do you mean by the "need to reboot the system to restore various vectors >that DOS destroys"? Do you mean that prior to executing the FreeBSD kernel >init routines, DOS does something to the loaded area? I'm sorry I can't find >any info on this either in the mail threads or in freebsd.org. Probably I'm >not looking hard enough, but I believe it would be more efficient to just >ask you. In a nutshell, there is a table of interrupt vectors which is set by the BIOS at boot time, which are used by the loader (and by the FreeBSD kernel, if VM86 is turned on). DOS, when it boots, loads itself into memory somewhere, and then changes the interrupt vectors to point to itself. The problem is, when the kernel/loader is loaded by fbsdboot.exe, DOS is overwritten. This results in the interrupt vectors pointing to garbage, which causes "bad things" (tm) when the they are used. Even if we don't stomp on DOS, I don't quite think that a BIOS call that ends up calling a DOS routine will do the right thing. There isn't any way (AFAIK) to restore the vectors to the original BIOS boot state. You may want to search the archives for "vm86" and "terry lambert", (IIRC), for some hypothetical solutions that have been proposed for this problem. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905180424.XAA02905>