🚀 go-pugleaf

[This doesn't look entirely useless... -mdw]

==== The Unofficial, Unwarranted, (generally Useless) DOS emulator FAQ ========

Posted once for general perusal, perhaps never again.  Get it while it's hot!

   This is a FAQ in the literal sense of the acronym: just a bunch of
Frequently Asked Questions, not anything helpful.  If you DO find
some helpful advice, it most probably was not intentional.  Please report
the offending material to me, and I'll have it removed as soon as possible.


Q: Er, DOS emulator?  
A: Yes, in what must be the height of tragic irony, all of us who have
bought big fast boxes so that we can escape from DOS have suddenly
noticed that DOS had an awful lot of useful programs that we can't
seem to find the source for.  
    Matthias Lautner is the apparent author of the emulator
that comes with SLS (in your /usr/src dir); this emulator is now at
version 0.4.
    I don't know how the vm86 support got into the kernel; there
probably isn't much use for it without the emulator.  Maybe Matthias
wrote that, too.


Q: When will it be useful?
A: Well, it's kinda useful now.  It can run almost all of the DOS 5.0
commands (qbasic, therefore edit, breaks; so does dosshell; very probably
others).  Of course, you have to make a slight modification to get it to boot
MS-DOS 5.0 at all.  It runs Turbo Pascal 5.5 beautifully (unless you want
to use the help functions; alt/ctrl-fkeys don't work yet).  It probably
will run most non-windows Borland language products as well.  4DOS 4.0?
runs pretty well, except that it's command history doesn't (neither does
DOSKEY).  MKS vi.exe will run on my new version*, as will elvis.  Qedit
seems to work.  
   Many programs run well; many more do not.  Unless you know that it OUGHT
to run under the emulator, comp.os.linux probably doesn't need to hear
about it.  Programs that OUGHT to run are those that run in text mode with
few assumptions about your video setup, that do not do direct hardware access,
that use the BIOS only (but not too extensively), that are basically meek,
well-behaved creatures content to rely on the OS services (?) provided by
DOS.

* There are several of us who seem to have independently taken up the
  gauntlet since dosemu0.4.  Corey Minyard seems to be writing a DOS
  emulator with a different twist; the rest of us are mostly extending
  Matthias' work.  My version (not due for release until January,
  at best) will be my best attempt at a complete DOS virtual machine.
  Not only will the BIOS be more semi-complete than in dosemu0.4, but
  I am reworking the keyboard and display, and adding hardware-register-level
  emulation of all the most important chips.  My goal is to be able to
  run programs that want the whole machine; I'm not willing to give
  it to them, but I'm not willing to give them up, either.  I hope
  the other programmers succeed in providing other solutions to running DOS
  programs.  Maybe a few months down the road we can all meet and
  integrate our work.


Q: How do I get in touch with these people to get their newest, shiniest
versions?
A: I dunno.  They probably don't want you to until they've gotten things
working.


Q: Why don't I just boot into DOS?
A: Because you still want to multitask, because you need to run multiple
DOS sessions, because your machine is an HP Snake, but there's a Linux
machine on the network and this is cheaper than HP's DOS emulation board,
because you'll really impress your friends, because you've got a background
process calculating what might be the new world's largest prime number
and you'd hate to stop it now that it's mere decades from finishing just
to run your address book program, because maybe one day the DOS emulator
will offer some added functionality that you can't get under DOS (one
very distant day), because you hate that beep your computer makes when
it reboots, etc.  
   I don't know.
   One neato application will be debugging DOS programs.  Say you have
a program like a DOS device driver which is pretty difficult to debug
using normal debugging tools.  Since the DOS emulator traps and
translates all 8086 I/O instructions, you can see exactly what's going
on.  And you can give it back whatever values you need to simulate
conditions.  Take the Diamond video cards with programmable video
clocks, for example :-).


Q: Can I use the printer and serial ports?
A: No one's really asked this.  Oh, well.  I have an answer anyway.  I
have implemented printer ports LPT1-3 (BIOS accessed), serial ports
COM1-4 (BIOS accessed), and am in the midst of implementing serial
ports COM1-4 in pseudo-hardware.  Soft hardware, I guess.  Emuware.
The COM ports will just echo to/from the ttysX ports (or wherever your
heart desires), and the LPT ports will package up your print jobs and
send them to lpr.  Alternately, you can just save the output to a
file.
   If you care, just wait for my version to be released.


Q: Why can't I type CTRL-F2 in my program and get my options window?
A: Linux doesn't care what shift keys you have down, F2 is F2.  Someone
(like me) might one day implement extended-prefix operations (like ESC-C F2
means ctrl-f2) for this sort of thing.  My solution is to turn on
Linux's RAW keyboard mode and let my emulator process all the scancodes.
This is very arguably a bad approach.  For example, the code in keyboard.c
will return the scancode without ever doing the virtual console switching
stuff if RAW mode is on.  ALT-F1 won't get you tty1; it'll get you 
whatever DOS feels like doing with ALT-F1.  I have thought of several ideas
(and implemented some) that would get around the VC problem.  One is
a kernel patch, one is something within the emulator.  It's not a real
problem.  Of course, the emulator can accept normal keystrokes just
fine; my version will run in an xterm and run over a serial link. (i.e. I
left all the nice things Matthias did in there, with some improvements).  
You just won't be able to use the more complete keyboard.
   Linus feels that this is a kludge.  I tend to agree.  On the other
hand, the whole idea of a DOS emulator is a kludge.  VM86 mode is a
kludge.  DOS...yes, well, we needn't stress that here.  My point is
that a lot of us will take the benefits of a kludge and not worry
about the ugliness.  What we SHOULD worry about are the drawbacks:
    1) Will only work on VC's (although I would be interested in hearing
       whether I can get some sort of uncooked key stream from X)
    2) Violates the UNIX principle of not going directly to the
       hardware.  Well, not to the hardware, but sort of circumventing the
       natural driver process.   
    3) Can leave the keyboard in a very insane state in case of a crash (very
       likely at this stage of the development).  

   That said, I have to say that I've written the RAW keyboard mode,
debugged it, and am happily using it.  It's very convenient.  It'll be
even better when I figure out how to get TSR's to recognize my key
combinations.  But, more importantly, the reason I bring this up is
that it's prototypical of the sort of problems the DOS emulator will
face: how do we handle DOS programs' arrogant use of machine
resources?  When my program flips to VGA mode so that it can have a
pretty pointer, what will the DOS emulator do?  Should it just die, or
report a non-graphics screen, or should it somehow actually do VGA?
It's a serious question.  All the really hard work on the emulator
from now on will be pleasing these programs while not turning Linux
into a dedicated DOS-server :-).


Q: Where can I get it?  
A: On tsx-11.mit.edu somewhere (pub/linux/ALPHA/...) and on
sunsite.unc.edu (pub/Linux/system/Emulators/dos, I think).  I forget.
If I ever write a real FAQ, maybe I'll put correct info here.


Q: Can the emulator run EXE files or not??!?
A: Yes, it can run EXE files just fine.  Here's the situation:

  There are 4 ways the DOS emulator accesses your magnetic media.
  1) Floppy drives. (referred to as A: and B: like normal)
  2) The hdimage file in the dosemu directory (/usr/src if you have SLS).
     This is a virtual drive accessed as a file through your Linux
     file system.  It is on the smallish size (default is 1 MB, I think),
     but it's enough to boot from and have a few programs on.  This is the
     emulator's C: drive.  You can run EXE files from this drive.
  3) Direct access of your DOS partition (i.e. not going through any
     Linux file system).  This is first documented in dosemu0.4, although
     I think I rembember the code was in 0.3.  You edit the emu.c file
     as directed in the README and tell it your disk's geometry (as known
     to DOS).  Voila!  You now have your hard drive mounted as D:.  You
     can run EXE files from this drive.
  4) Phantom drive access of your hard drive through /usr/dos.  This is
     going to be the best way when it works well.  When you boot the DOS
     emulator, you change to your C: drive (which is the hdimage drive 
     mentioned in 2) and run a program called LINUX.EXE which should be
     on there.  This program is a DOS redirector as documented in the
     book _Undocumented_DOS_ :-).  Given a letter as a parameter, this
     drive redirects all accesses to that drive to the Linux directory
     /usr/dos.  If you, from Linux, mount your DOS partition onto /usr/dos,
     you now have access to that partition.  However YOU CANNOT RUN EXE
     FILES FROM THIS DRIVE!  If you have the book _Undocumented_DOS_, and
     you feel competent, get the linux.pas.cd (contex diffs) that come 
     with the emulator and try to get it working.

   We'd all be happiest using method 4, as this method actually goes THROUGH
a Linux file system.  Linux file systems tend to be more multitasking-aware
than DOS's direct disk access, and this is good.  Try copying a file
to your DOS partition using method 3, then seeing if mtools under Linux
sees it (without rebooting).  It probably won't.


Q: How do I mount my DOS partition?
Q: How do I boot DOS from the hard disk?
Q: How do I change the size of the hdimage disk?
Q: What are all these funny messages I get?
A: These are all in the README file that comes with the emulator.  The
funny messages happen if you forgot to redirect standard output to 
somewhere other than standard out.


Q: How do I run Windows in non-enhanced mode under X11?

A: Simple.  You modify the DOS emulator so that all Windows calls are
trapped and converted into something a Windows->X11 API (which you
also must write, of course) can understand.  If you're feeling frisky,
work out a way to use Windows in enhanced mode.
   I'm sure Quarterdeck will be happy to share all the information they
learned while implementing their resource-sucking DesqView/X Windows
support.


Q: How do I boot DOS 5.0?
A: For now, a quick patch will do.  Edit emu.c so that, somewhere under
   a printf about "general protection,"  the line "error = 4" is changed
   to "error = 0"


Q: How do I boot from the hard disk?
A: Make a bootable floppy under DOS. Put the SYS command on it, too.  Now,
   in Linux, type
       dos a > dbgmsg
   This boots DOS from the a drive, redirecting the "funny messages" to
   a file.  This file will be useful if you have any weird behavior to 
   report.  Now, type "sys c:" which will make the hdimage drive bootable.
   From then on, you should be able to type
      dos c > dbgmsg
   and boot the emulator from the hdimage file.


Q: How can this FAQ be almost as long as (insert your favorite FAQ here) and
   yet tell me so much less?
A: I'm a frustrated author.


Robert Sanders
gt8134b@prism.gatech.edu
-- 
Matt Welsh     mdw@tc.cornell.edu     Cornell Theory Center
  "It's a Katana, ya Midwestern Computer Geek." --Tom Payne