From: gt8134b@prism.gatech.edu (Howlin' Bob)
Subject: MSDOS emulator FAQ
Date: Thu, 14 Jan 1993 05:00:29 +0200
This is my unofficial DOS emulator FAQ. If all goes well, it will be
followed by my unofficial DOS emulator update (like it says over and
over, at the end of January). Please send suggestions/comments/etc.
before I post it to c.o.l.a.
Robert Sanders
gt8134b@prism.gatech.edu
=============== The Unofficial Linux DOS emulator FAQ ================
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.
This FAQ can be found sporadically on the newsgroup
comp.os.linux.announce. It can also be found on tsx-11.mit.edu as
/pub/linux/ALPHA/dosemu/dosemu.FAQ.Z.
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 original author of the DOS emulator; this
emulator is now at version 0.4. I don't know if he's working on a new
version; owing to the fact that he got a job and abandoned his school
account, I can't reach him by e-mail.
As I understand it, Matthias wrote the original kernel code to support
vm86 mode, but Linus eventually rewrote it all from scratch. If you're
into that sort of thing, take a look at it. I, at least, was pleasantly
surprised at how little of it there is.
Q: The DOS emulator that comes with SLS is broken.
A: Earlier releases of the SLS distribution had an outdated emulator.
As of the current release (the first that contains the kernel 0.99pl2),
the DOS emulator is supposed to work. Give Peter a break; he's probably
almost drowning trying to make sure that 30-60 megs of software-in-flux
stays up to date.
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 end of January 93,
at best) will be the beginnings of my 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.
(Read this as: "am adding hardware-reg..." not as "I have done"!) 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. Towards the end of the Jan '93, mine will be on tsx-11.mit.edu
in the directory /pub/linux/ALPHA/dosemu or somewhere thereunder.
You're always welcome to ask decent questions on the MSDOS mailing
list channel, and I would be thrilled to hear any suggestions, ideas,
improvements (with code, please :-), etc. through e-mail at:
gt8134b@prism.gatech.edu
Q: Why don't I just boot into DOS? Why run an emulator that is bound
to be some factor X slower than native DOS, X depending on the DOS
application and the skill of the emulator's author.
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: You mentioned multiple sessions of DOS: can I do that?
A: Well, you CAN do it, but not really gracefully. I wouldn't
recommend it for the time being. If you need to, I recommend that you
run each session in a different directory with a different "hdimage"
file, and that you use the LINUX.EXE method of hard drive access
(method #4 in the list somewhere below).
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 just save the output to a file.
Alternately, it will package up your print jobs and send them to lpr.
(I haven't done this yet, as it really isn't that useful a feature).
If you care, just wait for my version to be released.
I can use the BIOS serial ports to run DOS kermit just fine and dandy.
Why I would want to is currently under investigation, but there it is.
The bad news is that BIOS serial port access usually winds up with the
comm. program sitting in a tight busy loop of "is there data ready? is there
data ready?" forever until there is, so this is not the preferred method.
I have had interesting discussions with Adam Goldberg (adam@microware.com)
about whether emulated hardware serial ports (i.e. the UART's) is feasible
or not. He thinks not, I think so. He says he worked on the VPC DOS
emulator for OS-9000 on the 386, whereas I have done nothing of the sort.
I may write something that works, but works so slowly that only
those of us with Pentiums will tolerate it. If so, I'll just apologize
to everyone and see if I can impress one of my professors with it.
(waste not, want not).
Adam recommends a scheme wherein the emulator would grant the DOS
program access to whatever I/O ports it needs; in addition (and this is
the kicker), he says that the kernel would be modified to directly
call the DOS emulator as an INTERRUPT HANDLER. So, if I caught a DOS
program using an I/O address that refers to a serial port, I just
give it access to the range of address I know belong to that device,
then execute some system call (or whatever) to tell the kernel that I
want the kernel's serial driver to be disabled, and that all interrupt 0xC's
will be revectored to the DOS program's interrupt handler.
I think it's a horrible idea, although it could very probably give
optimum performance. It would require extensive kernel modifications, and
I just don't think many are willing to bend Linux to DOS's will.
I would love to hear from some of you about this: just send in your
thoughts to me at
gt8134b@prism.gatech.edu
not that I'll seriously consider doing it no matter what you say (isn't
that a rational stance? :-).
Q: Why can't I type CTRL-F1 in my DOS program and get my context-help
window? (translate this to whatever combination of odd-key-sequence
and response you expect, but fail to get.)
A: Linux doesn't care what ctrl or alt keys you have down, F2 is F2.
Someone (like me) might one day implement extended-prefix keys (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 only works on the console.) 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. My current version of the emulator uses some new kernel
hooks in 0.99pl2 + ALPHA-diff that allow the DOS emulator to make the
VC switching transparent. Left-Alt-Fx will take you to virtual
console x. Right-Alt-Fx looks to the DOS program like Alt-Fx. Seems
good enough to me. To use this, you'll have to be using the
0.99pl2+ALPHA-diff kernel, or wait until the next release (0.99pl3?
1.0?).
In case you're curious, this code was added to support the XFree86 1.2
server VC support; unlike the current version (1.1), this server will
allow you to have an X session in one VC, and normal Linux text sessions
on the rest. We have Zorst (obz@Raster.Kodak.com) to thank for this code.
Thanks, Zorst!
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.
Item three used to say:
3) Can leave the keyboard in a very insane state in case of a crash (very
likely at this stage of the development).
However, the kernel I'm using (0.99pl2+ALPHA-diff) will automatically
return the VC to non-RAW mode if the controlling process dies. In other
words, my RAW mode emulator is now completely safe :-).
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 get the interrupt routines written so that TSR's
will run. 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/dosemu) and on
sunsite.unc.edu (pub/Linux/system/Emulators/dos, I think). I forget.
I will be keeping fairly current versions of my emulator on tsx-11, after
I release the first version.
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 remember 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. This method is fairly unsafe,
as you're playing with the HD behind Linux's back. I recommend that
you not have your DOS partition mounted as a DOS filesystem under
Linux if you use this method. If you do, any changes you make to it
WILL NOT SHOW ON THE LINUX SIDE. That's scary enough for me.
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
BEFORE RUNNING LINUX.EXE, 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
(context diffs, included with the DOS emulator), patch the PHANTOM.PAS
that I suppose you have to type in, and 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. I start DOS like this:
dos c > doserr
The "c" tells it to boot from my hdimage file, and the file doserr receives
all the debugging messages.
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"
The current SLS version should boot DOS 5.0, and, of course, so will my
version.
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.
Q: How can you have released the SECOND version of your DOS emulator FAQ, yet
not yet even released your FIRST version of the modified DOS emulator
itself?
A: Shut up. I'm working on it.
Robert Sanders
gt8134b@prism.gatech.edu
From: gt8134b@prism.gatech.edu (Howlin' Bob)
Subject: DOS emulator update
Date: Fri, 15 Jan 1993 07:21:11 +0200
Hello, all!
I 've just spent an eventful evening implementing a nice little
feature for the DOS emulator: if you're running on the console, you
can specify the -c switch to allow the emulator direct access to the
video mem. Although it currently only runs in an 80x25 EGA/VGA mode
(because of assumptions about the location of the real display mem),
I still think it's handy. I really enjoy seeing the colors, graphics
characters, blinking, and the improved speeds it gives. I'm trying to
persuade Zorst to finish the implementation of the KDMAPDISP ioctl
(in linux/kernel/chr_drv/vt.c) before Linux 1.0 so that I can make
this a little more "portable" across display types. (strictly speaking,
this isn't necessary: I could grab the info I need from /dev/kmem,
but we don't want another ps situation, do we? I'd hate to see the
proc-filesystem version of the DOS emulator :-)
Although I'm excited by my success, the real purpose of this message
is to thank you all for the suggestions for the DOS emulator FAQ, and
to as a question myself:
Should I add a section explaining the basic principles of the DOS
emulator? Not just the 386 architecture's vm86 mode, but the actual
layout of the emulator software, as well as the kernel interface.
I don't know if any of you would want this, but it would really save
you some time if you decided to contribute. Anyway, mail me your
vote :-).
Robert Sanders
gt8134b@prism.gatech.edu
P.S. When doing the direct-mapped console I/O, I laid the basic framework
for console VGA graphics. With a couple day's extra effort, I could
implement this (using vgalib 1.1). However, I have some more pressing
issues, and I don't know how many of you really need non-windows
vanilla VGA, especially given that the current emulator won't
give you all kinds of necessary things like mouse support.
So, one day...
P.P.S. Get the 0.99pl3 kernel! You'll need it for my version of the DOS
emulator.
P.P.P.S. I think my site missed Linus's announcement of 0.99pl3. Could
someone mail me a copy, or just explain some of the changes from
0.99pl2 (besides the VC stuff).
|