[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.X, Windows NT, Windows 9X/ME, Windows 2000, 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/2K or Windows 9X/ME. 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. There are also two sections at the end of this chapter which apply specifically for the Windows version.
AH.1 Keyboard and Mouse on MS-DOS | Keyboard and mouse usage on MS-DOS. | |
AH.2 Display on MS-DOS | Fonts, frames and display size on MS-DOS. | |
AH.3 File Names on MS-DOS | File name conventions on MS-DOS. | |
AH.4 Text Files and Binary Files | Text files on MS-DOS use CRLF to separate lines. | |
AH.5 Printing and MS-DOS | How to specify the printer on MS-DOS. | |
AH.6 International Support on MS-DOS | Support for internationalization on MS-DOS. | |
AH.7 Subprocesses on MS-DOS | Running subprocesses on MS-DOS. | |
AH.8 Subprocesses on Windows 9X/ME and Windows NT/2K | Running subprocesses on Windows. | |
AH.9 Using the System Menu on Windows | Controlling what the ALT key does. |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The PC keyboard maps use the left ALT key as the META key.
You have two choices for emulating the SUPER and HYPER keys:
choose either the right CTRL key or the right ALT key by
setting the variables dos-hyper-key
and dos-super-key
to 1
or 2 respectively. If neither dos-super-key
nor
dos-hyper-key
is 1, then by default the right ALT key is
also mapped to the META key. However, if the MS-DOS international
keyboard support program `KEYB.COM' is installed, Emacs will
not map the right ALT to META, since it is used for
accessing characters like ~ and @ on non-US keyboard
layouts; in this case, you may only use the left ALT as META
key.
The variable dos-keypad-mode
is a flag variable that controls
what key codes are returned by keys in the numeric keypad. You can also
define the keypad ENTER key to act like C-j, by putting the
following line into your `_emacs' file:
;; Make the ENTER key from the numeric keypad act as C-j. (define-key function-key-map [kp-enter] [?\C-j]) |
The key that 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 built for MS-DOS recognizes C-BREAK as a quit character, just like C-g. This is because Emacs cannot detect that you have typed C-g until it is ready for more input. As a consequence, you cannot use C-g to stop a running command (see section AD.8 Quitting and Aborting). By contrast, C-BREAK is detected as soon as you type it (as C-g is on other systems), so it can be used to stop a running command and for emergency escape (see section AD.9.8 Emergency Escape).
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 B.4 The Menu Bar). 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. If the mouse does have 3 buttons, Emacs detects that at startup, and all the 3 buttons function normally, as on X.
Help strings for menu-bar and pop-up menus are displayed in the echo area when the mouse pointer moves across the menu items. Highlighting of mouse-sensitive text (see section P.4 Following References with the Mouse) is also supported.
Some versions of mouse drivers don't report the number of mouse buttons correctly. For example, mice with a wheel report that they have 3 buttons, but only 2 of them are passed to Emacs; the clicks on the wheel, which serves as the middle button, are not passed. In these cases, you can use the M-x msdos-set-mouse-buttons command to tell Emacs how many mouse buttons to expect. You could make such a setting permanent by adding this fragment to your `_emacs' init file:
;; Treat the mouse like a 2-button mouse. (msdos-set-mouse-buttons 2) |
Emacs built for MS-DOS supports clipboard operations when it runs on Windows. Commands that put text on the kill ring, or yank text from the ring, check the Windows clipboard first, just as Emacs does on the X Window System (see section P.1 Mouse Commands for Editing). Only the primary selection and the cut buffer are supported by MS-DOS Emacs on Windows; the secondary selection always appears as empty.
Due to the way clipboard access is implemented by Windows, the length of text you can put into the clipboard is limited by the amount of free DOS memory that is available to Emacs. Usually, up to 620KB of text can be put into the clipboard, but this limit depends on the system configuration and is lower if you run Emacs as a subprocess of another program. If the killed text does not fit, Emacs outputs a message saying so, and does not put the text into the clipboard.
Null characters also cannot be put into the Windows clipboard. If the killed text includes null characters, Emacs does not put such text into the clipboard, and displays in the echo area a message to that effect.
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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Display on MS-DOS cannot use font variants, like bold or italic,
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
that 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
command (see section P.12 Setting Frame Parameters) and the
list-faces-display
command (see section J.1 Using Multiple Typefaces) to see what colors and
faces are available and what they look like.
See section AH.6 International Support on MS-DOS, later in this chapter, for information on how Emacs displays glyphs and characters that aren't supported by the native font built into the DOS display.
When Emacs starts, it changes the cursor shape to a solid box. This
is for compatibility with other systems, where the box cursor is the
default in Emacs. This default shape can be changed to a bar by
specifying the cursor-type
parameter in the variable
default-frame-alist
(see section P.7 Creating Frames). The MS-DOS
terminal doesn't support a vertical-bar cursor, so the bar cursor is
horizontal, and the width
parameter, if specified by the
frame parameters, actually determines its height. As an extension,
the bar cursor specification can include the starting scan line of the
cursor as well as its width, like this:
'(cursor-type bar width . start) |
In addition, if the width parameter is negative, the cursor bar begins at the top of the character cell.
The MS-DOS terminal can only display a single frame at a time. The Emacs frame facilities work on MS-DOS much as they do on text-only terminals (see section P. Frames and X Windows). When you run Emacs from a DOS window on MS-Windows, you can make the visible frame smaller than the full screen, but Emacs still cannot display more than a single frame at a time.
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, 28, 35, 40, 43 or 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 frame to
n rows by m columns 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 40x80 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 38x80 dimensions and you define a variable
screen-dimensions-38x80
with a suitable value, you will still get
40x80 screen when you ask for a 36x80 frame. If you want to get the
38x80 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-38x80
.
Changing frame dimensions on MS-DOS has the effect of changing all the other frames to the new dimensions.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 AD.7 The Init File, `~/.emacs') is called `_emacs' on MS-DOS. Excess characters before or after the period are generally ignored by MS-DOS itself; thus, if you visit the 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 M.3.1.1 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.
If you run Emacs as a DOS application under Windows 9X, Windows ME, or
Windows 2000, you can turn on support for long file names. If you do
that, Emacs doesn't truncate file names or convert them to lower case;
instead, it uses the file names that you specify, verbatim. To enable
long file name support, set the environment variable LFN
to
`y' before starting Emacs. Unfortunately, Windows NT doesn't allow
DOS programs to access long file names, so Emacs built for MS-DOS will
only see their short 8+3 aliases.
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 on GNU or 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 handles the directory name `/dev' specially, because of a feature in the emulator libraries of DJGPP that pretends I/O devices have names in that directory. We recommend that you avoid using an actual directory named `/dev' on any disk.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Emacs uses newline characters to separate text lines. This is the convention used on GNU and Unix.
MS-DOS and MS-Windows normally use carriage-return linefeed, a two-character sequence, to separate text lines. (Linefeed is the same character as newline.) Therefore, convenient editing of typical files with Emacs requires conversion of these end-of-line (EOL) sequences. And that is what Emacs normally does: it converts carriage-return linefeed into newline when reading files, and converts newline into carriage-return linefeed when writing files. The same mechanism that handles conversion of international character codes does this conversion also (see section Q.7 Coding Systems).
One consequence of this special format-conversion of most files is that character positions as reported by Emacs (see section D.9 Cursor Position Information) do not agree with the file size information known to the operating system.
In addition, if Emacs recognizes from a file's contents that it uses newline rather than carriage-return linefeed as its line separator, it does not perform EOL conversion when reading or writing that file. Thus, you can read and edit files from GNU and Unix systems on MS-DOS with no special effort, and they will retain their Unix-style end-of-line convention after you edit them.
The mode line indicates whether end-of-line translation was used for the current buffer. If MS-DOS end-of-line translation is in use for the buffer, a backslash `\' is displayed after the coding system mnemonic near the beginning of the mode line (see section B.3 The Mode Line). If no EOL translation was performed, the string `(Unix)' is displayed instead of the backslash, to alert you that the file's EOL format is not the usual carriage-return linefeed.
To visit a file and specify whether it uses DOS-style or Unix-style
end-of-line, specify a coding system (see section Q.9 Specifying a Coding System). For
example, C-x RET c unix RET C-x C-f foobar.txt
visits the file `foobar.txt' without converting the EOLs; if some
line ends with a carriage-return linefeed pair, Emacs will display
`^M' at the end of that line. Similarly, you can direct Emacs to
save a buffer in a specified EOL format with the C-x RET f
command. For example, to save a buffer with Unix EOL format, type
C-x RET f unix RET C-x C-s. If you visit a file
with DOS EOL conversion, then save it with Unix EOL format, that
effectively converts the file to Unix EOL style, like dos2unix
.
When you use NFS or Samba to access file systems that reside on
computers using GNU or Unix systems, Emacs should not perform
end-of-line translation on any files in these file systems--not even
when you create a new file. To request this, designate these file
systems as untranslated file systems by calling the function
add-untranslated-filesystem
. It takes one argument: the file
system name, including a drive letter and optionally a directory. For
example,
(add-untranslated-filesystem "Z:") |
designates drive Z as an untranslated file system, and
(add-untranslated-filesystem "Z:\\foo") |
designates directory `\foo' on drive Z as an untranslated file system.
Most often you would use add-untranslated-filesystem
in your
`_emacs' file, or in `site-start.el' so that all the users at
your site get the benefit of it.
To countermand the effect of add-untranslated-filesystem
, use
the function remove-untranslated-filesystem
. This function takes
one argument, which should be a string just like the one that was used
previously with add-untranslated-filesystem
.
Designating a file system as untranslated does not affect character set conversion, only end-of-line conversion. Essentially, it directs Emacs to create new files with the Unix-style convention of using newline at the end of a line. See section Q.7 Coding Systems.
Some kinds of files should not be converted at all, because their
contents are not really text. Therefore, Emacs on MS-DOS distinguishes
certain files as binary files. (This distinction is not part of
MS-DOS; it is made by Emacs only.) Binary files include executable
programs, compressed archives, etc. Emacs uses the file name to decide
whether to treat a file as binary: the variable
file-name-buffer-file-type-alist
defines the file-name patterns
that indicate binary files. If a file name matches one of the patterns
for binary files (those whose associations are of the type
(pattern . t)
, Emacs reads and writes that file using the
no-conversion
coding system (see section Q.7 Coding Systems) which turns
off all coding-system conversions, not only the EOL conversion.
file-name-buffer-file-type-alist
also includes file-name patterns
for files which are known to be DOS-style text files with
carriage-return linefeed EOL format, such as `CONFIG.SYS'; Emacs
always writes those files with DOS-style EOLs.
If a file which belongs to an untranslated file system matches one of
the file-name patterns in file-name-buffer-file-type-alist
, the
EOL conversion is determined by file-name-buffer-file-type-alist
.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Printing commands, such as lpr-buffer
(see section AC.18 Hardcopy Output) and
ps-print-buffer
(see section AC.19 PostScript Hardcopy) can work in MS-DOS and
MS-Windows by sending the output to one of the printer ports, if a
Posix-style lpr
program is unavailable. The same Emacs
variables control printing on all systems (see section AC.18 Hardcopy Output), but in
some cases they have different default values on MS-DOS and
MS-Windows.
If you want to use your local printer, printing on it in the usual DOS
manner, then set the Lisp variable lpr-command
to ""
(its
default value) and printer-name
to the name of the printer
port--for example, "PRN"
, the usual local printer port (that's
the default), or "LPT2"
, or "COM1"
for a serial printer.
You can also set printer-name
to a file name, in which case
"printed" output is actually appended to that file. If you set
printer-name
to "NUL"
, printed output is silently
discarded (sent to the system null device).
On MS-Windows, when the Windows network software is installed, you can
also use a printer shared by another machine by setting
printer-name
to the UNC share name for that printer--for example,
"//joes_pc/hp4si"
. (It doesn't matter whether you use forward
slashes or backslashes here.) To find out the names of shared printers,
run the command `net view' at a DOS command prompt to obtain a list
of servers, and `net view server-name' to see the names of printers
(and directories) shared by that server. Alternatively, click the
`Network Neighborhood' icon on your desktop, and look for machines
which share their printers via the network.
If the printer doesn't appear in the output of `net view', or
if setting printer-name
to the UNC share name doesn't produce a
hardcopy on that printer, you can use the `net use' command to
connect a local print port such as "LPT2"
to the networked
printer. For example, typing net use LPT2:
\\joes_pc\hp4si(18)
causes Windows to capture the LPT2 port and redirect the printed
material to the printer connected to the machine joes_pc
.
After this command, setting printer-name
to "LPT2"
should produce the hardcopy on the networked printer.
With some varieties of Windows network software, you can instruct
Windows to capture a specific printer port such as "LPT2"
, and
redirect it to a networked printer via the Control
Panel->Printers
applet instead of `net use'.
Some printers expect DOS codepage encoding of non-ASCII text, even
though they are connected to a Windows machine which uses a different
encoding for the same locale. For example, in the Latin-1 locale, DOS
uses codepage 850 whereas Windows uses codepage 1252. See section AH.6 International Support on MS-DOS. When you print to such printers from Windows, you can use the
C-x RET c (universal-coding-system-argument
) command before
M-x lpr-buffer; Emacs will then convert the text to the DOS
codepage that you specify. For example, C-x RET c cp850-dos RET
M-x lpr-region RET will print the region while converting it to the
codepage 850 encoding. You may need to create the cpnnn
coding system with M-x codepage-setup.
If you set printer-name
to a file name, it's best to use an
absolute file name. Emacs changes the working directory according to
the default directory of the current buffer, so if the file name in
printer-name
is relative, you will end up with several such
files, each one in the directory of the buffer from which the printing
was done.
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 and MS-Windows don't
normally have these programs, so by default, the variable
lpr-headers-switches
is set so that the requests to print page
headers are silently ignored. Thus, print-buffer
and
print-region
produce the same output as lpr-buffer
and
lpr-region
, respectively. If you do have a suitable pr
program (for example, from GNU Textutils), set
lpr-headers-switches
to nil
; Emacs will then call
pr
to produce the page headers, and print the resulting output as
specified by printer-name
.
Finally, if you do have an lpr
work-alike, you can set the
variable lpr-command
to "lpr"
. Then Emacs will use
lpr
for printing, as on other systems. (If the name of the
program isn't lpr
, set lpr-command
to specify where to
find it.) The variable lpr-switches
has its standard meaning
when lpr-command
is not ""
. If the variable
printer-name
has a string value, it is used as the value for the
-P
option to lpr
, as on Unix.
A parallel set of variables, ps-lpr-command
,
ps-lpr-switches
, and ps-printer-name
(see section AC.20 Variables for PostScript Hardcopy), defines how PostScript files should be printed. These
variables are used in the same way as the corresponding variables
described above for non-PostScript printing. Thus, the value of
ps-printer-name
is used as the name of the device (or file) to
which PostScript output is sent, just as printer-name
is used for
non-PostScript printing. (There are two distinct sets of variables in
case you have two printers attached to two different ports, and only one
of them is a PostScript printer.)
The default value of the variable ps-lpr-command
is ""
,
which causes PostScript output to be sent to the printer port specified
by ps-printer-name
, but ps-lpr-command
can also be set to
the name of a program which will accept PostScript files. Thus, if you
have a non-PostScript printer, you can set this variable to the name of
a PostScript interpreter program (such as Ghostscript). Any switches
that need to be passed to the interpreter program are specified using
ps-lpr-switches
. (If the value of ps-printer-name
is a
string, it will be added to the list of switches as the value for the
-P
option. This is probably only useful if you are using
lpr
, so when using an interpreter typically you would set
ps-printer-name
to something other than a string so it is
ignored.)
For example, to use Ghostscript for printing on an Epson printer connected to the `LPT2' port, put this in your `_emacs' file:
(setq ps-printer-name t) ; Ghostscript doesn't understand -P (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.)
For backwards compatibility, the value of dos-printer
(dos-ps-printer
), if it has a value, overrides the value of
printer-name
(ps-printer-name
), on MS-DOS and MS-Windows
only.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs on MS-DOS supports the same international character sets as it does on GNU, Unix and other platforms (see section Q. International Character Set Support), including coding systems for converting between the different character sets. However, due to incompatibilities between MS-DOS/MS-Windows and other systems, there are several DOS-specific aspects of this support that you should be aware of. This section describes these aspects.
MS-DOS is designed to support one character set of 256 characters at any given time, but gives you a variety of character sets to choose from. The alternative character sets are known as DOS codepages. Each codepage includes all 128 ASCII characters, but the other 128 characters (codes 128 through 255) vary from one codepage to another. Each DOS codepage is identified by a 3-digit number, such as 850, 862, etc.
In contrast to X, which lets you use several fonts at the same time, MS-DOS normally doesn't allow use of several codepages in a single session. MS-DOS was designed to load a single codepage at system startup, and require you to reboot in order to change it(19). Much the same limitation applies when you run DOS executables on other systems such as MS-Windows.
If you invoke Emacs on MS-DOS with the `--unibyte' option (see section AE.2 Initial Options), Emacs does not perform any conversion of non-ASCII characters. Instead, it reads and writes any non-ASCII characters verbatim, and sends their 8-bit codes to the display verbatim. Thus, unibyte Emacs on MS-DOS supports the current codepage, whatever it may be, but cannot even represent any other characters.
For multibyte operation on MS-DOS, Emacs needs to know which
characters the chosen DOS codepage can display. So it queries the
system shortly after startup to get the chosen codepage number, and
stores the number in the variable dos-codepage
. Some systems
return the default value 437 for the current codepage, even though the
actual codepage is different. (This typically happens when you use the
codepage built into the display hardware.) You can specify a different
codepage for Emacs to use by setting the variable dos-codepage
in
your init file.
Multibyte Emacs supports only certain DOS codepages: those which can display Far-Eastern scripts, like the Japanese codepage 932, and those that encode a single ISO 8859 character set.
The Far-Eastern codepages can directly display one of the MULE character sets for these countries, so Emacs simply sets up to use the appropriate terminal coding system that is supported by the codepage. The special features described in the rest of this section mostly pertain to codepages that encode ISO 8859 character sets.
For the codepages which correspond to one of the ISO character sets,
Emacs knows the character set name based on the codepage number. Emacs
automatically creates a coding system to support reading and writing
files that use the current codepage, and uses this coding system by
default. The name of this coding system is cpnnn
, where
nnn is the codepage number.(20)
All the cpnnn
coding systems use the letter `D' (for
"DOS") as their mode-line mnemonic. Since both the terminal coding
system and the default coding system for file I/O are set to the proper
cpnnn
coding system at startup, it is normal for the mode
line on MS-DOS to begin with `-DD\-'. See section B.3 The Mode Line.
Far-Eastern DOS terminals do not use the cpnnn
coding
systems, and thus their initial mode line looks like the Emacs default.
Since the codepage number also indicates which script you are using,
Emacs automatically runs set-language-environment
to select the
language environment for that script (see section Q.3 Language Environments).
If a buffer contains a character belonging to some other ISO 8859 character set, not the one that the chosen DOS codepage supports, Emacs displays it using a sequence of ASCII characters. For example, if the current codepage doesn't have a glyph for the letter `ò' (small `o' with a grave accent), it is displayed as `{`o}', where the braces serve as a visual indication that this is a single character. (This may look awkward for some non-Latin characters, such as those from Greek or Hebrew alphabets, but it is still readable by a person who knows the language.) Even though the character may occupy several columns on the screen, it is really still just a single character, and all Emacs commands treat it as one.
Not all characters in DOS codepages correspond to ISO 8859
characters--some are used for other purposes, such as box-drawing
characters and other graphics. Emacs maps these characters to two
special character sets called eight-bit-control
and
eight-bit-graphic
, and displays them as their IBM glyphs.
However, you should be aware that other systems might display these
characters differently, so you should avoid them in text that might be
copied to a different operating system, or even to another DOS machine
that uses a different codepage.
Emacs supports many other characters sets aside from ISO 8859, but it
cannot display them on MS-DOS. So if one of these multibyte characters
appears in a buffer, Emacs on MS-DOS displays them as specified by the
dos-unsupported-character-glyph
variable; by default, this glyph
is an empty triangle. Use the C-u C-x = command to display the
actual code and character set of such characters. See section D.9 Cursor Position Information.
By default, Emacs defines a coding system to support the current codepage. To define a coding system for some other codepage (e.g., to visit a file written on a DOS machine in another country), use the M-x codepage-setup command. It prompts for the 3-digit code of the codepage, with completion, then creates the coding system for the specified codepage. You can then use the new coding system to read and write files, but you must specify it explicitly for the file command when you want to use it (see section Q.9 Specifying a Coding System).
These coding systems are also useful for visiting a file encoded using a DOS codepage, using Emacs running on some other operating system.
MS-Windows provides its own codepages, which are different from the DOS codepages for the same locale. For example, DOS codepage 850 supports the same character set as Windows codepage 1252; DOS codepage 855 supports the same character set as Windows codepage 1251, etc. The MS-Windows version of Emacs uses the current codepage for display when invoked with the `-nw' option.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 Shell mode and GUD. When in doubt, try and see; commands that don't work output an error message saying that asynchronous processes aren't supported.
Compilation under Emacs with M-x compile, searching files with M-x grep and displaying differences between files with M-x diff do work, by running the inferior processes synchronously. This means you cannot do any more editing until the inferior process finishes.
Spell checking also works, by means of special support for synchronous
invocation of the ispell
program. This is slower than the
asynchronous invocation on other platforms
Instead of the Shell mode, which doesn't work on MS-DOS, you can use the M-x eshell command. This invokes the Eshell package that implements a Posix-like shell entirely in Emacs Lisp.
By contrast, Emacs compiled as native Windows application does support asynchronous subprocesses. See section AH.8 Subprocesses on Windows 9X/ME and Windows NT/2K.
Printing commands, such as lpr-buffer
(see section AC.18 Hardcopy Output) and
ps-print-buffer
(see section AC.19 PostScript Hardcopy), work in MS-DOS by sending
the output to one of the printer ports. See section AH.5 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. Pressing C-c or C-BREAK might sometimes help in these cases.
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'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs compiled as a native Windows application (as opposed to the DOS version) includes full support for asynchronous subprocesses. In the Windows version, synchronous and asynchronous subprocesses work fine on both Windows 9X and Windows NT/2K as long as you run only 32-bit Windows applications. However, when you run a DOS application in a subprocess, you may encounter problems or be unable to run the application at all; and if you run two DOS applications at the same time in two subprocesses, you may have to reboot your system.
Since the standard command interpreter (and most command line utilities) on Windows 95 are DOS applications, these problems are significant when using that system. But there's nothing we can do about them; only Microsoft can fix them.
If you run just one DOS application subprocess, the subprocess should work as expected as long as it is "well-behaved" and does not perform direct screen access or other unusual actions. If you have a CPU monitor application, your machine will appear to be 100% busy even when the DOS application is idle, but this is only an artifact of the way CPU monitors measure processor load.
You must terminate the DOS application before you start any other DOS application in a different subprocess. Emacs is unable to interrupt or terminate 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 attempt to run two DOS applications at the same time in separate subprocesses, the second one that is started will be suspended until the first one finishes, even if either or both of them are asynchronous.
If you can go to the first subprocess, and tell it to exit, the second subprocess should continue normally. However, if the second subprocess is synchronous, Emacs itself will be hung until the first subprocess finishes. If it will not finish without user input, then you have no choice but to reboot if you are running on Windows 9X. If you are running on Windows NT/2K, you can use a process viewer application to kill the appropriate instance of ntvdm instead (this will terminate both DOS subprocesses).
If you have to reboot Windows 9X 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.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Emacs compiled as a native Windows application normally turns off the Windows feature that tapping the ALT key invokes the Windows menu. The reason is that the ALT also serves as META in Emacs. When using Emacs, users often press the META key temporarily and then change their minds; if this has the effect of bringing up the Windows menu, it alters the meaning of subsequent commands. Many users find this frustrating.
You can reenable Windows's default handling of tapping the ALT key
by setting w32-pass-alt-to-system
to a non-nil
value.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |