Date: Fri, 8 Aug 1997 00:10:11 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Randall Hopper <rhh@ct.picker.com> Cc: "Pedro Giffuni S," <pgiffuni@fps.biblos.unal.edu.co>, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <19970808001011.36692@right.PCS> In-Reply-To: <19970807194755.37948@ct.picker.com>; from Randall Hopper on Aug 08, 1997 at 07:47:55PM -0400 References: <19970806075054.63235@ct.picker.com> <199708061320.WAA08867@genesis.atrad.adelaide.edu.au> <19970806220031.07191@ct.picker.com> <33EA058A.42B9@fps.biblos.unal.edu.co> <19970807194755.37948@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 08, 1997 at 07:47:55PM -0400, Randall Hopper wrote: > > Ok. Mostly I just wanted to step through some of it to help get a faster > line on how the internals work. I figured it'd be a easier than picking > through the source and printfs. > > Is there a rough architecture overview or some notes/scribbles lying around > anywhere on-line that might give someone a head start with this? Not really. However, here's a short overview: We create a single process for doscmd, and reserve the lower 1MB for DOS to run in. Since you can't access more than 1MB in vm86 mode, the doscmd executable itself is protected from DOS. This 1MB region is then set up to look similar to what the system BIOS would leave a real machine looking like, (setting up the interrupt descriptor table other data structures) before actually turning control over to the DOS program. In a real machine, BIOS services are provided via INTn calls. All INTn calls, and several other instructions, are trapped under vm86 mode, and cause a fault to the kernel. The kernel portion of the emulator recognizes this, packages up the state of the vm86 machine at the time of the fault, and then turns control over to doscmd by sending it a SIGBUS signal. Doscmd then catches the SIGBUS in it's signal handler, and examines the saved vm86 state to see what caused the fault. If it is an INTn call, then it essentially emulates the work that the BIOS would do. It also does the work of several other instructions that vm86 is not permitted to do. Callbacks to doscmd are also permitted by executing a HLT instruction in vm86 mode, then running a function in doscmd based on the address of the HLT instruction. We don't want to call the system BIOS directly, since it attempts to do nasty things like turning off interrupts for a long time, and mucking around with the I/O ports. After doscmd is done, it returns from it's signal handler, at which point the kernel re-loads the state of the vm86 machine and continues running. That's a really simple overview of how doscmd works, while glossing over a lot of details. It should be enough to give you a 'head-start', or at least tell you where to look. If you already knew all of this... ah, well. -- Jonathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970808001011.36692>