This section briefly describes the peculiarities of using Emacs under the MS-DOS "operating system" (also known as "MS-DOG"). If you build Emacs for MS-DOS, the binary will also run on Windows 3, Windows NT, Windows 95, or OS-2 as a DOS application; the information in this chapter applies for all of those systems, if you use an Emacs that was built for MS-DOS.
Note that it is possible to build Emacs specifically for Windows NT or Windows 95. If you do that, most of this chapter does not apply; instead, you get behavior much closer to what is documented in the rest of the manual, including support for long file names, multiple frames, scroll bars, mouse menus, and subprocesses. However, the section on text files and binary files does still apply.
The PC keyboard maps use the left Alt key as the META
key. You have two choices for emulating the SUPER and
HYPER keys: either the right CONTROL key or the right
ALT key by setting the variables dos-hyper-key and
dos-super-key to 1 or 2 respectively.
The variable dos-keypad-mode is a flag variable which controls
what key codes are returned by keys in the numeric keypad. There is
no dedicated LFD key; use C-j instead. You can also
define the kp-enter key to act as LFD, by putting the
following line into your `_emacs' file:
;; Make the Enter key from the Numeric keypad act as LFD. (define-key function-key-map [kp-enter] [?\C-j])
The key which is called DEL in Emacs (because that's how it is designated on most workstations) is known as BS (backspace) on a PC. That is why the PC-specific terminal initialization remaps the BS key to act as DEL; the DEL key is remapped to act as C-d for the same reasons.
Emacs on MS-DOS supports a mouse (on the default terminal only). The mouse commands work as documented, including those that use menus and the menu bar (see section Menu Bars). Scroll bars don't work in MS-DOS Emacs. PC mice usually have only two buttons; these act as Mouse-1 and Mouse-2, but if you press both of them together, that has the effect of Mouse-3.
The variable dos-display-scancodes, when non-nil,
directs Emacs to display the ASCII value and the keyboard scan code of
each keystroke; this feature serves as a complement to the
view-lossage command, for debugging.
Display on MS-DOS cannot use multiple fonts, but it does support
multiple faces, each of which can specify a foreground and a background
color. Therefore, you can get the full functionality of Emacs
packages which use fonts (such as font-lock, Enriched Text
mode, and others) by defining the relevant faces to use different
colors. Use the list-colors-display and
list-faces-display commands (see section Modifying Faces) to see
what colors and faces are available and what they look like.
Multiple frames (see section Frames and X Windows) are not supported on MS-DOS. You have only a single frame which occupies the entire screen. When you run Emacs under MS-Windows 3.x, the single frame can take less than the full screen, but you still cannot have more than a single frame.
The mode4350 command switches the display to 43 or 50
lines, depending on your hardware; the mode25 command switches
to the default 80x25 screen size.
By default, Emacs only knows how to set screen sizes of 80 columns
by 25 or 43/50 rows. However, if your video adapter has special video
modes that will switch the display to other sizes, you can have Emacs
support those too. When you ask Emacs to switch the (single) frame to
n rows by m cols dimensions, it checks if there is a
variable called screen-dimensions-nxm, and if so,
uses its value (which must be an integer) as the video mode to switch
to. (Emacs switches to that video mode by calling the BIOS Set
Video Mode function with the value of
screen-dimensions-nxm in the AL register.)
For example, suppose your adapter will switch to 66x80 dimensions when
put into video mode 85. Then you can make Emacs support this screen
size by putting the following into your `_emacs' file:
(setq screen-dimensions-66x80 85)
Since Emacs on MS-DOS can only set the frame size to specific supported dimensions, it cannot honor every possible frame resizing request. When an unsupported size is requested, Emacs chooses the next larger supported size beyond the specified size. For example, if you ask for 36x80 frame, you will get 50x80 instead.
The variables screen-dimensions-nxm are used only
when they exactly match the specified size; the search for the next
larger supported size ignores them. In the above example, even if your
VGA supports 44x80 dimensions and you define a variable
screen-dimensions-44x80 with a suitable value, you will still get
50x80 screen when you ask for a 36x80 frame. If you want to get the
44x80 size in this case, you can do it by setting the variable named
screen-dimensions-36x80 with the same video mode value as
screen-dimensions-44x80.
MS-DOS normally uses a backslash, `\', to separate name units within a file name, instead of the slash used on other systems. Emacs on MS-DOS permits use of either slash or backslash, and also knows about drive letters in file names.
On MS-DOS, file names are case-insensitive and limited to eight characters, plus optionally a period and three more characters. Emacs knows enough about these limitations to handle file names that were meant for other operating systems. For instance, leading dots `.' in file names are invalid in MS-DOS, so Emacs transparently converts them to underscores `_'; thus your default init file (see section The Init File, `~/.emacs') is called `_emacs' on MS-DOS. Excess characters before or after the period are generally ignored by MS-DOS itself, so if you, e.g., visit a file `LongFileName.EvenLongerExtension', you will silently get `longfile.eve'; but Emacs will still display the long file name on the mode line. Other than that, it's up to you to specify file names which are valid under MS-DOS; the transparent conversion as described above only works on file names built into Emacs.
The above restrictions on the file names on MS-DOS make it almost impossible to construct the name of a backup file (see section Single or Numbered Backups) without losing some of the original file name characters. For example, the name of a backup file for `docs.txt' is `docs.tx~' even if single backup is used.
When Emacs runs as DOS application under Win95, it can support long
filenames like other Win95 programs. If long filenames are supported,
Emacs doesn't truncate and doesn't change filenames you type, but uses
them verbatim. It also doesn't convert filenames to lower case. To get
long filename support, you should set LFN to y in the
environment before starting Emacs.
MS-DOS has no notion of home directory, so Emacs on MS-DOS pretends
that the directory where it is installed is the value of HOME
environment variable. That is, if your Emacs binary,
`emacs.exe', is in the directory `c:/utils/emacs/bin', then
Emacs acts as if HOME were set to `c:/utils/emacs'. In
particular, that is where Emacs looks for the init file `_emacs'.
With this in mind, you can use `~' in file names as an alias for
the home directory, as you would in Unix. You can also set HOME
variable in the environment before starting Emacs; its value will then
override the above default behavior.
Emacs on MS-DOS distinguishes between text and binary files. This
distinction is not part of MS-DOS; it is made by Emacs only. Emacs
treats files of human-readable text (including program source code) as
text files, and treats executable programs, compressed archives, etc.,
as binary files. Emacs uses the file name to decide whether to treat
a file as text or binary: the variable
file-name-buffer-file-type-alist defines the file name patterns
which denote binary files.
Emacs reads and writes binary files verbatim. Text files use a two character sequence to end a line: carriage-return (control-m) followed by newline (control-j). When you visit a text file, Emacs strips off these control-m characters; when you write a text file to disk, Emacs puts them back in. Thus, the text appears within Emacs with just a newline character at the end of each line.
You can tell whether Emacs considers the visited file as text or binary based on the mode line (see section The Mode Line). Text files have a `T:' marker prefixed to the major mode name; binary files have a `B:' prefix.
One consequence of this special format-conversion of text files is that character positions as reported by Emacs (see section Cursor Position Information) do not agree with the file size information known to the operating system.
Printing commands, such as lpr-buffer (see section Hardcopy Output) and
ps-print-buffer (see section Postscript Hardcopy) can work in MS-DOS by
sending the output to one of the printer ports, if Unix-style lpr
program is is unavailable. A few DOS-specific variables determine how
this works. If you want to use your local printer in the usual
DOS-style printing, set the dos-printer variable to the name of
the port to which your printer is connected, like "LPT2" or
"COM1" (for serial printers); the default is "PRN", the
default local printer port. You can set dos-printer to a name of
the file, in which case the output will be appended to that file; or you
can set it to "NUL" to make the printed output silently disappear
into the great void. If you set dos-printer to a name of a file,
it's best to make its pathname absolute or relative to the Emacs home
directory (like `"~/printed.dat"'). That is because Emacs actually
changes the working directory to the directory of the file you are
editing, so if the name of the file in dos-printer is relative,
you will end up with several such files, each one in the directory of
the buffer from which the printing was done, which is probably not what
you wanted.
The commands print-buffer and print-region call the
pr program, or use special switches to the lpr program, to
produce headers on each printed page. MS-DOS doesn't have these programs
usually, so by default, the variable lpr-headers-switches is set
so that the requests to print page headers are silently ignored, and
print-buffer and print-region produce the same output as
lpr-buffer and lpr-region, respectively. If you have a
port of pr program (e.g., from GNU Textutils), set
lpr-headers-switches to nil; Emacs will then call pr to
produce the page headers, and will then write the output to the printer
port named by dos-printer.
Finally, if you do have an lpr work-alike, you can set
print-region-function to nil. This will cause Emacs to use
lpr for printing, as it does under Unix. (If the name of the
program isn't lpr, you can set lpr-command variable and
lpr-switches as appropriate.)
A separate variable, dos-ps-printer, defines how PostScript
files should be printed. If its value is a string, it is used as the
name of the device (or a file) to which PostScript output is sent, like
dos-printer is used for non-PostScript printing. (These are two
distinct variables because on MS-DOS, you might have two different
printers attached to two different ports, only one of which is a
PostScript printer.) If dos-ps-printer is anything else but a
string, Emacs will use the variables ps-lpr-command and
ps-lpr-switches (see section Postscript Hardcopy) to print PostScript files.
Thus, if you have a non-PostScript printer, you can set these variables
to the name and the switches appropriate for a PostScript interpreter
program (e.g., Ghostscript). For example, to use Ghostscript for
printing on an Epson printer connected to "LPT2" port, put this
on your `.emacs' file:
(setq dos-ps-printer t) ; anything but a string
(setq ps-lpr-command "c:/gs/gs386")
(setq ps-lpr-switches '("-q" "-dNOPAUSE"
"-sDEVICE=epson"
"-r240x72"
"-sOutputFile=LPT2"
"-Ic:/gs"
"-"))
(This assumes that Ghostscript is installed in the `"c:/gs"' directory.)
Because MS-DOS is a single-process "operating system", asynchronous subprocesses are not available. In particular, Shell mode and its variants do not work. Most Emacs features that use asynchronous subprocesses also don't work on MS-DOS, including spelling correction and GUD. When in doubt, try and see; commands that don't work print an error message saying that asynchronous processes aren't supported.
Compilation under Emacs with M-x compile and grep with M-x grep do work, by running the inferior processes synchronously. This means you cannot do any more editing until the compilation or the grep process finishes.
Printing commands, such as lpr-buffer (see section Hardcopy Output) and
ps-print-buffer (see section Postscript Hardcopy), work in MS-DOS by sending
the output to one of the printer ports. See section Printing and MS-DOS.
When you run a subprocess synchronously on MS-DOS, make sure the program terminates and does not try to read keyboard input. If the program does not terminate on its own, you will be unable to terminate it, because MS-DOS provides no general way to terminate a process.
Accessing files on other machines is not supported on MS-DOS. Other network-oriented commands such as sending mail, Web browsing, remote login, etc., don't work either, unless network access is built into MS-DOS with some network redirector.
Dired on MS-DOS uses the ls-lisp package where other
platforms use the system ls command. Therefore, Dired on
MS-DOS supports only some of the possible options you can mention in
the dired-listing-switches variable. The options that work are
`-A', `-a', `-c', `-i', `-r', `-S',
`-s', `-t', and `-u'.
Subprocesses, both synchronous and asynchronous, work fine on Windows 95 as long as you run only 32-bit Windows applications in them. However, when you run a DOS application in a subprocess, it doesn't completely work; and if you run two DOS applications at the same time in two subprocesses, the operating system can get badly confused.
Since the command interpreter shells run as DOS applications, these problems are significant. But there's nothing we can do about them; only Microsoft can fix them. Windows 95 simply cannot cope when one Windows process tries to run two separate DOS subprocesses.
If you run just one DOS application subprocess, then the application is likely to busy-wait when idle, which means that your machine will be 100% busy as long as the application is running. However, aside from the heavy load, the subprocess will work as expected--provided you terminate it before you start any other DOS application as a subprocess.
Emacs is unable to terminate or interrupt a DOS subprocess. The only way you can terminate such a subprocess is by giving it a command that tells its program to exit.
If you run two DOS applications at the same time in two separate subprocesses, even if one of them is asynchronous, you will probably find that one of the subprocesses is hung. If the second subprocess is asynchronous, then Emacs itself will be hung. Meanwhile, your machine will be 100% busy.
If you can go to the first subprocess (possible if Emacs is not hung), and tell it to exit, that should clear up the problem. Otherwise you will have to reboot.
If you have to reboot in this situation, do not use the Shutdown
command on the Start menu; that usually hangs the system.
Instead, type CTL-ALT-DEL and then choose Shutdown.
That usually works, although it may take a few minutes to do its job.
Go to the first, previous, next, last section, table of contents.