From owner-freebsd-hackers Sat Oct 26 14:56:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA15310 for hackers-outgoing; Sat, 26 Oct 1996 14:56:00 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA15301 for ; Sat, 26 Oct 1996 14:55:57 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA17662; Sat, 26 Oct 1996 14:51:46 -0700 From: Terry Lambert Message-Id: <199610262151.OAA17662@phaeton.artisoft.com> Subject: Re: DOS emulation (was Re: Networking in PCEMU (1/2)) To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Sat, 26 Oct 1996 14:51:46 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, erich@lodgenet.com, hackers@freebsd.org In-Reply-To: <199610260510.OAA22149@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 26, 96 02:40:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Once _that_ works, we can do some _serious_ DOS emulation. > > > > Which only works on Intel platforms. 8-(. > > ... until someone takes one of the freely-available CPU emulators > (from PCEmu, Bochs, Willows TWIN etc), makes it an LKM and teaches the > kernel to run processes with the synthetic PSL_VM bit set using it. > > Geez Terry, I even took this idea from your old postings on the topic 8) Actually, I think I suggested making the execution class loader for the magic number for foreign binaries load a CPU emulation module and pass the arguments from 0 on unadulterated. The emulation module then mmap's the program as if it were a native loader, and manages system call traps by calling the native system calls for the OS. I think the LKM I mentioned was the execution class loader... I'm pretty sure this was the case because, at the time, people were trying to break the architectural support for this kind of emulation by moving to passing system call arguemnts in registers to blindly "keep up" with Linux. I'm pretty sure this was the case, since I was using a hacked up version of SPIM to run MIPS binaries on Alpha hardware at the time as a proof of concept. 8-). > BTW, you mentioned a RedBook on the whole v86 thing in the OS/2 > perspective; I had a look at the RedBOoks site but it's a pain to > navigate and I found nothing. Do you still have the reference? Is > the book available online? I was referencing a Willows list posting... the redbook I had access to was owned by Novell, and my access went away when I quit. Justin T. Gibbs had a copy... the message I was referring to said he had just sent it to Gary (Clark? Sorry, the Willows stuff all happened more than a year ago -- fuzzy memory). Shortly afterward Jordan posted that he and Justin and I-don't-remember-who had talked about it extensively at Usenix, and VM86() support was a priority. The current topic is actually different than just VM86() support; I'm more concerned with being able to use commercial (ie: Intel) binaries on non-Intel platforms. I think processor emulation wins over direct VM86() support for that reason (also for DOS emulation on non-Intel platforms). I'd like to see VM86() pursued to support the PC equivalent of OpenBoot (use of BIOS interfaces from protected mode) so FreeBSD can run on all hardware DOS can run on. But if I were given a choice about which of the technologies to exclusively pursue, I'd pick processor emulation: it's the more general one, and it's more important in the long run; IMO, x86 processor dependence, like ISA and IDE, is a fad not long for this world. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.