From: jpo@informatik.tu-chemnitz.de (Joerg Pommnitz) Subject: Re: DOS EMULATION Date: 4 May 1992 13:51:32 GMT
elan@cheme.tn.cornell.edu writes:
>HI everybody, just a few ideas on DOS emulation. I don't claim to know much
>about the subject, but I do have some feelings on the matter. I just
>downloaded gde and built it on a DECstation 5000. Not bad... Pretty neat
>actually, and as soon as the new version comes in I plan to get it. I ran
>a few programs under the emulator (pkzip, pc-lisp, etc.) Actually I got
>a floating point exception with pc-list, doesn't supprise me.
> Anyway, I don't think gde is the way to go for LINUX. It seems silly to
>emulate a chip with the chip that is being emulated :-). Also, I
>believe that there must be some way to allow the DOS program running under
>LINUX to make use of the perfectly good BIOS that is in your x86 box
>already. I think we need a TRANSLATOR. I can see it already... Harvard
>Grahpics running in one VC, Word Perfect in the other! Or maybe HG
>running in one xterm, WP in the other. Allright, enough drooling...
> I don't know how to go about doing this, but I have a few ideas:
> * All normal code can go straight across. Lets here it for raw
> speed here...
> * DOS functions can maybe be done by translating the system files
> with the translator, and mapping int's to calls (i.e. link
> the translated program with the DOS "library"????
> * As for direct screen access, SVGA, etc., if the program writes
> directly to memory it shouldn't need much at all, just as with
> in/out commands to the Video Card.
> * BIOS - hum, I don't know if under LINUX the BIOS is accessable???
> I claim total ignorance here...
>Of course if the program needed to be run in a x-term, many more changes
>would be necesary, i.e. trap all direct video access, but the point is,
>99% of the code does NOT NEED TO BE TOUCHED... Who wants to emulate the
>fetch decode execute cycles when this is not necesary. Imagine the speed
>of emulating a 386 with a 386. Need I say more...
> Flames, comments, ideas, death threats to elan@tasha.cheme.cornell.edu
>Elan Feingold
>School of Electrical Engineering at Cornell University
It`s not so simple!
The main problem is that most DOS programs directly modify the 8086 segment
segment registers. The protected mode doesn`t allow this.
To solve this problem Intel implemented the V86 mode into the 80386 CPU.
This mode gives the chance to run real mode programs in an protected mode
environment. This is done for instance in OS/2 2.0 or even EMM386.
The next problem is that DOS programs normally acess the whole hardware.
This would be killing an multitasking environment. Thats why the port acesses
must be caught by the OS/DOS emulator.