"Fossies" - the Fresh Open Source Software Archive

Member "emacs-26.1/doc/emacs/msdos.texi" (25 May 2018, 53098 Bytes) of package /linux/misc/emacs-26.1.tar.xz:

Caution: As a special service "Fossies" has tried to format the requested Texinfo source page into HTML format but that may be not always succeeeded perfectly. Alternatively you can here view or download the uninterpreted Texinfo source code. A member file download can also be achieved by clicking within a package contents listing on the according byte size field. See also the latest Fossies "Diffs" side-by-side code changes report for "msdos.texi": 25.3_vs_26.1.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

Appendix A Emacs and Microsoft Windows/MS-DOS

This section describes peculiarities of using Emacs on Microsoft Windows. Some of these peculiarities are also relevant to Microsoft’s older MS-DOS operating system. However, Emacs features that are relevant only to MS-DOS are described in a separate section (see section Emacs and MS-DOS).

MS-Windows is a non-free operating system; that means it denies its users the freedom that every computer user deserves. That is an injustice. For your freedom’s sake, we urge you to switch to a free operating system.

We support GNU Emacs on proprietary operating systems because we hope this taste of freedom will inspire users to escape from them.

The behavior of Emacs on MS-Windows is reasonably similar 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, a few special considerations apply, and they are described here.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.1 How to Start Emacs on MS-Windows

There are several ways of starting Emacs on MS-Windows:

  1. From the desktop shortcut icon: either double-click the left mouse button on the icon, or click once, then press <RET>. The desktop shortcut should specify as its “Target” (in the “Properties” of the shortcut) the full absolute file name of ‘runemacs.exe’, not of ‘emacs.exe’. This is because ‘runemacs.exe’ hides the console window that would have been created if the target of the shortcut were ‘emacs.exe’ (which is a console program, as far as Windows is concerned). If you use this method, Emacs starts in the directory specified by the shortcut. To control where that is, right-click on the shortcut, select “Properties”, and in the “Shortcut” tab modify the “Start in” field to your liking.
  2. From a task-bar shortcut icon, by clicking once the left mouse button. Windows versions since Vista allow you to create such shortcuts by pinning the icon of a running program that appears in the task bar. You can do that with Emacs, but afterwards you will have to change the properties of the pinned shortcut to run ‘runemacs.exe’, not of ‘emacs.exe’. You can also pin Emacs to the task bar by clicking the right mouse button on its icon in the Start menu, then selecting ‘Pin to taskbar’. Once again, be sure to specify ‘runemacs.exe’ as the program to run. You can control where Emacs starts by setting the “Start in” field of the shortcut’s Properties.
  3. From the Command Prompt window, by typing emacs <RET> at the prompt. The Command Prompt window where you did that will not be available for invoking other commands until Emacs exits. In this case, Emacs will start in the current directory of the Windows shell.
  4. From the Command Prompt window, by typing runemacs <RET> at the prompt. The Command Prompt window where you did that will be immediately available for invoking other commands. In this case, Emacs will start in the current directory of the Windows shell.
  5. From the Windows Run dialog (normally reached by clicking the Start button). Typing runemacs <RET> into the dialog will start Emacs in the parent directory of the Windows equivalent of your user’s HOME directory, see HOME and Startup Directories on MS-Windows.
  6. Via ‘emacsclient.exe’ or ‘emacsclientw.exe’, which allow you to invoke Emacs from other programs, and to reuse a running Emacs process for serving editing jobs required by other programs. @xref{Emacs Server}. The difference between ‘emacsclient.exe’ and ‘emacsclientw.exe’ is that the former is a console program, while the latter is a Windows GUI program. Both programs wait for Emacs to signal that the editing job is finished, before they exit and return control to the program that invoked them. Which one of them to use in each case depends on the expectations of the program that needs editing services. If that program is itself a console (text-mode) program, you should use ‘emacsclient.exe’, so that any of its messages and prompts appear in the same command window as those of the invoking program. By contrast, if the invoking program is a GUI program, you will be better off using ‘emacsclientw.exe’, because ‘emacsclient.exe’ will pop up a command window if it is invoked from a GUI program. A notable situation where you would want ‘emacsclientw.exe’ is when you right-click on a file in the Windows Explorer and select “Open With” from the pop-up menu. Use the ‘--alternate-editor=’ or ‘-a’ options if Emacs might not be running (or not running as a server) when emacsclient is invoked—that will always give you an editor. When invoked via emacsclient, Emacs will start in the current directory of the program that invoked emacsclient.

Note that, due to limitations of MS-Windows, Emacs cannot have both GUI and text-mode frames in the same session. It also cannot open text-mode frames on more than a single Command Prompt window, because each Windows program can have only one console at any given time. For these reasons, if you invoke emacsclient with the ‘-c’ option, and the Emacs server runs in a text-mode session, Emacs will always create a new text-mode frame in the same Command Prompt window where it was started; a GUI frame will be created only if the server runs in a GUI session. Similarly, if you invoke emacsclient with the ‘-t’ option, Emacs will create a GUI frame if the server runs in a GUI session, or a text-mode frame when the session runs in text mode in a Command Prompt window. @xref{emacsclient Options}.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.2 Text Files and Binary Files

GNU Emacs uses newline characters to separate text lines. This is the convention used on GNU, Unix, and other POSIX-compliant systems.

By contrast, MS-DOS and MS-Windows normally use carriage return followed by 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 followed by linefeed into newline when reading files, and converts newline into carriage return followed by linefeed when writing files. The same mechanism that handles conversion of international character codes does this conversion also (@pxref{Coding Systems}).

One consequence of this special format-conversion of most files is that character positions as reported by Emacs (@pxref{Position Info}) 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 followed by 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, the MS-Windows build of Emacs displays a backslash ‘\’ after the coding system mnemonic near the beginning of the mode line (@pxref{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 followed by linefeed.

To visit a file and specify whether it uses DOS-style or Unix-style end-of-line, specify a coding system (@pxref{Text Coding}). 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 followed by 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 the dos2unix program.

When you use NFS, Samba, or some other similar method 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’ or ‘init.el’ init 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 default to creating new files with the Unix-style convention of using newline at the end of a line. @xref{Coding Systems}.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.3 File Names on MS-Windows

MS-Windows and MS-DOS normally use a backslash, ‘\’, to separate name units within a file name, instead of the slash used on other systems. Emacs on MS-DOS/MS-Windows permits use of either slash or backslash, and also knows about drive letters in file names.

On MS-DOS/MS-Windows, file names are case-insensitive, so Emacs by default ignores letter-case in file names during completion. To this end, the default value of read-file-name-completion-ignore-case is non-nil on MS-DOS/MS-Windows. @xref{Completion Options}.

The variable w32-get-true-file-attributes controls whether Emacs should issue additional system calls to determine more accurately file attributes in primitives like file-attributes and directory-files-and-attributes. These additional calls are needed to report correct file ownership, link counts and file types for special files such as pipes. Without these system calls, file ownership will be attributed to the current user, link counts will be always reported as 1, and special files will be reported as regular files.

If the value of this variable is local (the default), Emacs will issue these additional system calls only for files on local fixed drives. Any other non-nil value means do this even for removable and remote volumes, where this could potentially slow down Dired and other related features. The value of nil means never issue those system calls. Non-nil values are more useful on NTFS volumes, which support hard links and file security, than on FAT, FAT32, and exFAT volumes.

Unlike Unix, MS-Windows file systems restrict the set of characters that can be used in a file name. The following characters are not allowed:

In addition, referencing any file whose name matches a DOS character device, such as ‘NUL’ or ‘LPT1’ or ‘PRN’ or ‘CON’, with or without any file-name extension, will always resolve to those character devices, in any directory. Therefore, only use such file names when you want to use the corresponding character device.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.4 Emulation of ls on MS-Windows

Dired normally uses the external program ls to produce the directory listing displayed in Dired buffers (@pxref{Dired}). However, MS-Windows and MS-DOS systems don’t come with such a program, although several ports of GNU ls are available. Therefore, Emacs on those systems emulates ls in Lisp, by using the ‘ls-lisp.el’ package. While ‘ls-lisp.el’ provides a reasonably full emulation of ls, there are some options and features peculiar to that emulation; they are described in this section.

The ls emulation supports many of the ls switches, but it doesn’t support all of them. Here’s the list of the switches it does support: ‘-A’, ‘-a’, ‘-B’, ‘-C’, ‘-c’, ‘-G’, ‘-g’, ‘-h’, ‘-i’, ‘-n’, ‘-R’, ‘-r’, ‘-S’, ‘-s’, ‘-t’, ‘-U’, ‘-u’, ‘-v’, and ‘-X’. The ‘-F’ switch is partially supported (it appends the character that classifies the file, but does not prevent symlink following).

On MS-Windows and MS-DOS, ‘ls-lisp.el’ is preloaded when Emacs is built, so the Lisp emulation of ls is always used on those platforms. If you have a ported ls, setting ls-lisp-use-insert-directory-program to a non-nil value will revert to using an external program named by the variable insert-directory-program.

The order in which ‘ls-lisp.el’ sorts files depends on several customizable options described below.

The default sorting order follows locale-specific rules derived from your system locale. You can make the order locale-independent by customizing ls-lisp-use-string-collate to a nil value.

On GNU and Unix systems, when the locale’s encoding is UTF-8, the collation order follows the Unicode Collation Algorithm (UCA). To have a similar effect on MS-Windows, the variable ls-lisp-UCA-like-collation should have a non-nil value (this is the default). The resulting sorting order ignores punctuation, symbol characters, and whitespace characters, so ‘.foobar’, ‘foobar’ and ‘foo bar’ will appear together rather than far apart.

By default, ‘ls-lisp.el’ uses a case-sensitive sort order for the directory listing it produces; this is so the listing looks the same as on other platforms. If you wish that the files be sorted in case-insensitive order, set the variable ls-lisp-ignore-case to a non-nil value.

By default, files and subdirectories are sorted together, to emulate the behavior of ls. However, native MS-Windows/MS-DOS file managers list the directories before the files; if you want that behavior, customize the option ls-lisp-dirs-first to a non-nil value.

The variable ls-lisp-verbosity controls the file attributes that ‘ls-lisp.el’ displays. The value should be a list that contains one or more of the symbols links, uid, and gid. links means display the count of different file names that are associated with (a.k.a. links to) the file’s data; this is only useful on NTFS volumes. uid means display the numerical identifier of the user who owns the file. gid means display the numerical identifier of the file owner’s group. The default value is (links uid gid) i.e., all the 3 optional attributes are displayed.

The variable ls-lisp-emulation controls the flavor of the ls emulation by setting the defaults for the 3 options described above: ls-lisp-ignore-case, ls-lisp-dirs-first, and ls-lisp-verbosity. The value of this option can be one of the following symbols:


Emulate GNU systems; this is the default. This sets ls-lisp-ignore-case and ls-lisp-dirs-first to nil, and ls-lisp-verbosity to (links uid gid).


Emulate Unix systems. Like GNU, but sets ls-lisp-verbosity to (links uid).


Emulate macOS. Sets ls-lisp-ignore-case to t, and ls-lisp-dirs-first and ls-lisp-verbosity to nil.


Emulate MS-Windows. Sets ls-lisp-ignore-case and ls-lisp-dirs-first to t, and ls-lisp-verbosity to nil on Windows 9X and to t on modern versions of Windows. Note that the default emulation is not MS-Windows, even on Windows, since many users of Emacs on those platforms prefer the GNU defaults.

Any other value of ls-lisp-emulation means the same as GNU. Customizing this option calls the function ls-lisp-set-options to update the 3 dependent options as needed. If you change the value of this variable without using customize after ‘ls-lisp.el’ is loaded (note that it is preloaded on MS-Windows and MS-DOS), you can call that function manually for the same result.

The variable ls-lisp-support-shell-wildcards controls how file-name patterns are supported: if it is non-nil (the default), they are treated as shell-style wildcards; otherwise they are treated as Emacs regular expressions.

The variable ls-lisp-format-time-list defines how to format the date and time of files. The value of this variable is ignored, unless Emacs cannot determine the current locale. (However, if the value of ls-lisp-use-localized-time-format is non-nil, Emacs obeys ls-lisp-format-time-list even if the current locale is available; see below.)

The value of ls-lisp-format-time-list is a list of 2 strings. The first string is used if the file was modified within the current year, while the second string is used for older files. In each of these two strings you can use ‘%’-sequences to substitute parts of the time. For example:

("%b %e %H:%M" "%b %e  %Y")

Note that the strings substituted for these ‘%’-sequences depend on the current locale. See Time Parsing in The Emacs Lisp Reference Manual, for more about format time specs.

Normally, Emacs formats the file time stamps in either traditional or ISO-style time format. However, if the value of the variable ls-lisp-use-localized-time-format is non-nil, Emacs formats file time stamps according to what ls-lisp-format-time-list specifies. The ‘%’-sequences in ls-lisp-format-time-list produce locale-dependent month and day names, which might cause misalignment of columns in Dired display. The default value of ls-lisp-use-localized-time-format is nil.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.5 HOME and Startup Directories on MS-Windows

The Windows equivalent of HOME is the user-specific application data directory. The actual location depends on the Windows version; typical values are ‘C:\Documents and Settings\username\Application Data’ on Windows 2000 up to XP, ‘C:\Users\username\AppData\Roaming’ on Windows Vista and later, and either ‘C:\WINDOWS\Application Data’ or ‘C:\WINDOWS\Profiles\username\Application Data’ on Windows 9X/ME. If this directory does not exist or cannot be accessed, Emacs falls back to ‘C:\’ as the default value of HOME.

You can override this default value of HOME by explicitly setting the environment variable HOME to point to any directory on your system. HOME can be set either from the command shell prompt or from ‘Properties’ dialog of ‘My Computer’. HOME can also be set in the system registry, @pxref{MS-Windows Registry}.

For compatibility with older versions of Emacs(1), if there is a file named ‘.emacs’ in ‘C:\’, the root directory of drive ‘C:’, and HOME is set neither in the environment nor in the Registry, Emacs will treat ‘C:\’ as the default HOME location, and will not look in the application data directory, even if it exists. Note that only ‘.emacs’ is looked for in ‘C:\’; the older name ‘_emacs’ (see below) is not. This use of ‘C:\.emacs’ to define HOME is deprecated; Emacs will display a warning about its use during startup.

Whatever the final place is, Emacs sets the internal value of the HOME environment variable to point to it, and it will use that location for other files and directories it normally looks for or creates in your home directory.

You can always find out what Emacs thinks is your home directory’s location by typing C-x d ~/ <RET>. This should present the list of files in the home directory, and show its full name on the first line. Likewise, to visit your init file, type C-x C-f ~/.emacs <RET> (assuming the file’s name is ‘.emacs’).

Your init file can have any name mentioned in @ref{Init File}.

Because MS-DOS does not allow file names with leading dots, and older Windows systems made it hard to create files with such names, the Windows port of Emacs supports an init file name ‘_emacs’, if such a file exists in the home directory and ‘.emacs’ does not. This name is considered obsolete, so Emacs will display a warning if it is used.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.6 Keyboard Usage on MS-Windows

This section describes the Windows-specific features related to keyboard input in Emacs.

Many key combinations (known as “keyboard shortcuts”) that have conventional uses in MS-Windows programs conflict with traditional Emacs key bindings. (These Emacs key bindings were established years before Microsoft was founded.) Examples of conflicts include C-c, C-x, C-z, C-a, and W-<SPC>. You can redefine some of them with meanings more like the MS-Windows meanings by enabling CUA Mode (@pxref{CUA Bindings}). Another optional feature which will make Emacs behave like other Windows applications is Delete Selection mode (@pxref{Using Region}).

By default, the key labeled <Alt> is mapped as the <Meta> key. If you wish it to produce the Alt modifier instead, set the variable w32-alt-is-meta to a nil value.

MS-Windows reserves certain key combinations, such as <Alt>-<TAB> and a number of Windows key combinations, for its own use. These key combinations are intercepted by the system before Emacs can see them. Also, on Windows 10, all Windows key combinations are reserved by the system in such a way that they are never propagated to applications, even if the system does not currently define a hotkey on the specific combination. You can use the w32-register-hot-key function to allow a key sequence to be seen by Emacs instead of being grabbed by Windows. When registered as a hot key, the key combination is pulled out of the system’s input queue before it is handled by Windows, effectively overriding the special meaning of that key sequence for Windows. The override is only effective when Emacs is active; with other applications on the foreground the keys behave normally.

The argument to w32-register-hot-key must be a single key with a single modifier, in vector form that would be acceptable to define-key. The control and shift modifiers have no effect on the argument. The meta modifier is interpreted as the <Alt> key if w32-alt-is-meta is t (the default), and the super and hyper modifiers are interpreted according to the bindings of w32-lwindow-modifier and w32-rwindow-modifier. Additionally, a modifier with the trailing dash but with no key indicates that all Windows defined hotkeys for that modifier are to be overridden in the favor of Emacs.

For example, (w32-register-hot-key [M-tab]) lets you use M-<TAB> normally in Emacs; for instance, to complete the word or symbol at point at top level, or to complete the current search string against previously sought strings during incremental search. (w32-register-hot-key [s-]) with w32-lwindow-modifier bound to super disables all the Windows’ own Windows key based shortcuts.(2)

Note that w32-register-hot-key checks the w32-[lr]window-modifier values at the time of the function call. Thus, you can set w32-lwindow-modifier as super, then call (w32-register-hot-key [s-r]), and finally set w32-rwindow-modifier as super as well. The result is that the left Windows key together with R invokes whichever function you have bound for the combination in Emacs, and the right Windows key and R opens the Windows Run dialog.

The hotkey registrations always also include all the shift and control modifier combinations for the given hotkey; that is, registering s-a as a hotkey gives you S-s-a, C-s-a and C-S-s-a as well.

On Windows 98 and ME, the hotkey registration is more restricted. The desired hotkey must always be fully specified, and w32-phantom-key-code can be customized to achieve desired results.

The function w32-unregister-hot-key reverses the effect of w32-register-hot-key for its argument key sequence.

By default, the <CapsLock> key only affects normal character keys (it converts lower-case characters to their upper-case variants). However, if you set the variable w32-capslock-is-shiftlock to a non-nil value, the <CapsLock> key will affect non-character keys as well, as if you pressed the <SHIFT> key while typing the non-character key.

If the variable w32-enable-caps-lock is set to a nil value, the <CapsLock> key produces the symbol capslock instead of the shifted version of typed keys. The default value is t.

Similarly, if w32-enable-num-lock is nil, the <NumLock> key will produce the symbol kp-numlock. The default is t, which causes <NumLock> to work as expected: toggle the meaning of the keys on the numeric keypad.

The variable w32-apps-modifier controls the effect of the <Apps> key (usually located between the right <Alt> and the right <Ctrl> keys). Its value can be one of the symbols hyper, super, meta, alt, control, or shift for the respective modifier, or nil to appear as the key apps. The default is nil.

The variable w32-lwindow-modifier determines the effect of the left Windows key (usually labeled with <start> and the Windows logo). If its value is nil (the default), the key will produce the symbol lwindow. Setting it to one of the symbols hyper, super, meta, alt, control, or shift will produce the respective modifier. A similar variable w32-rwindow-modifier controls the effect of the right Windows key, and w32-scroll-lock-modifier does the same for the <ScrLock> key. If these variables are set to nil, the right Windows key produces the symbol rwindow and <ScrLock> produces the symbol scroll. If you want <ScrLock> to produce the same effect as in other applications, i.e. toggle the Scroll Lock LED indication on the keyboard, set w32-scroll-lock-modifier to t or any non-nil value other than the above modifier symbols.

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> 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 re-enable Windows’s default handling of tapping the <Alt> key by setting w32-pass-alt-to-system to a non-nil value.

The variables w32-pass-lwindow-to-system and w32-pass-rwindow-to-system determine whether the respective keys are passed to Windows or swallowed by Emacs. If the value is nil, the respective key is silently swallowed by Emacs, otherwise it is passed to Windows. The default is t for both of these variables. Passing each of these keys to Windows produces its normal effect: for example, <Lwindow> opens the Start menu, etc.

The variable w32-recognize-altgr controls whether the <AltGr> key (if it exists on your keyboard), or its equivalent, the combination of the right <Alt> and left <Ctrl> keys pressed together, is recognized as the <AltGr> key. The default is t, which means these keys produce AltGr; setting it to nil causes <AltGr> or the equivalent key combination to be interpreted as the combination of <Ctrl> and <Meta> modifiers.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.7 Mouse Usage on MS-Windows

This section describes the Windows-specific variables related to the mouse.

The variable w32-mouse-button-tolerance specifies the time interval, in milliseconds, for faking middle mouse button press on 2-button mice. If both mouse buttons are depressed within this time interval, Emacs generates a middle mouse button click event instead of a double click on one of the buttons.

If the variable w32-pass-extra-mouse-buttons-to-system is non-nil, Emacs passes the fourth and fifth mouse buttons to Windows.

The variable w32-swap-mouse-buttons controls which of the 3 mouse buttons generates the mouse-2 events. When it is nil (the default), the middle button generates mouse-2 and the right button generates mouse-3 events. If this variable is non-nil, the roles of these two buttons are reversed.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.8 Subprocesses on Windows 9X/ME and Windows NT/2K/XP/Vista/7/8/10

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 all versions of MS-Windows, as long as you run only 32-bit or 64-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 9X 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 and later, 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 <Ctrl>-<Alt>-<DEL> and then choose Shutdown. That usually works, although it may take a few minutes to do its job.

The variable w32-quote-process-args controls how Emacs quotes the process arguments. Non-nil means quote with the " character. If the value is a character, Emacs uses that character to escape any quote characters that appear; otherwise it chooses a suitable escape character based on the type of the program.

The variable w32-pipe-buffer-size controls the size of the buffer Emacs requests from the system when it creates pipes for communications with subprocesses. The default value is zero, which lets the OS choose the size. Any valid positive value will request a buffer of that size in bytes. This can be used to tailor communications with subprocesses to programs that exhibit unusual behavior with respect to buffering pipe I/O.

The function w32-shell-execute can be useful for writing customized commands that run MS-Windows applications registered to handle a certain standard Windows operation for a specific type of document or file. This function is a wrapper around the Windows ShellExecute API. See the MS-Windows API documentation for more details.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.9 Printing and MS-Windows

Printing commands, such as lpr-buffer (@pxref{Printing}) and ps-print-buffer (@pxref{PostScript}) 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, but in some cases they have different default values on MS-DOS and MS-Windows.

Emacs on MS Windows attempts to determine your default printer automatically (using the function default-printer-name). But in some rare cases this can fail, or you may wish to use a different printer from within Emacs. The rest of this section explains how to tell Emacs which printer to use.

If you want to use your local printer, then set the Lisp variable lpr-command to "" (its default value on Windows) and printer-name to the name of the printer port—for example, "PRN", the usual local printer port, 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).

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’ from the 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 that 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(3) 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’.

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.

If the value of printer-name is correct, but printing does not produce the hardcopy on your printer, it is possible that your printer does not support printing plain text (some cheap printers omit this functionality). In that case, try the PostScript print commands, described below.

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 Coreutils), 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 the appropriate value.) 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 (@pxref{PostScript Variables}), 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 the system’s default printer, put this in your ‘.emacs’ file:

(setq ps-printer-name t)
(setq ps-lpr-command "D:/gs6.01/bin/gswin32c.exe")
(setq ps-lpr-switches '("-q" "-dNOPAUSE" "-dBATCH"

(This assumes that Ghostscript is installed in the ‘D:/gs6.01’ directory.)

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.10 Specifying Fonts on MS-Windows

Starting with Emacs 23, fonts are specified by their name, size and optional properties. The format for specifying fonts comes from the fontconfig library used in modern Free desktops:


The old XLFD based format is also supported for backwards compatibility.

Emacs 23 and later supports a number of font backends. Currently, the gdi and uniscribe backends are supported on Windows. The gdi font backend is available on all versions of Windows, and supports all fonts that are natively supported by Windows. The uniscribe font backend is available on Windows 2000 and later, and supports TrueType and OpenType fonts. Some languages requiring complex layout can only be properly supported by the Uniscribe backend. By default, both backends are enabled if supported, with uniscribe taking priority over gdi. To override that and use the GDI backend even if Uniscribe is available, invoke Emacs with the -xrm Emacs.fontBackend:gdi command-line argument, or add a Emacs.fontBackend resource with the value gdi in the Registry under either the ‘HKEY_CURRENT_USER\SOFTWARE\GNU\Emacs’ or the ‘HKEY_LOCAL_MACHINE\SOFTWARE\GNU\Emacs’ key (@pxref{Resources}).

Optional properties common to all font backends on MS-Windows are:


Specifies the weight of the font. Special values light, medium, demibold, bold, and black can be specified without weight= (e.g., Courier New-12:bold). Otherwise, the weight should be a numeric value between 100 and 900, or one of the named weights in font-weight-table. If unspecified, a regular font is assumed.


Specifies whether the font is italic. Special values roman, italic and oblique can be specified without slant= (e.g., Courier New-12:italic). Otherwise, the slant should be a numeric value, or one of the named slants in font-slant-table. On Windows, any slant above 150 is treated as italics, and anything below as roman.


Specifies the font family, but normally this will be specified at the start of the font name.


Specifies the font size in pixels. This can be used instead of the point size specified after the family name.


Specifies additional style information for the font. On MS-Windows, the values mono, sans, serif, script and decorative are recognized. These are most useful as a fallback with the font family left unspecified.


Specifies the character set registry that the font is expected to cover. Most TrueType and OpenType fonts will be Unicode fonts that cover several national character sets, but you can narrow down the selection of fonts to those that support a particular character set by using a specific registry from w32-charset-info-alist here.


Specifies how the font is spaced. The p spacing specifies a proportional font, and m or c specify a monospaced font.


Not used on Windows, but for informational purposes and to prevent problems with code that expects it to be set, is set internally to raster for bitmapped fonts, outline for scalable fonts, or unknown if the type cannot be determined as one of those.

Options specific to GDI fonts:


Specifies a Unicode subrange the font should support.

The following scripts are recognized on Windows: latin, greek, coptic, cyrillic, armenian, hebrew, arabic, syriac, nko, thaana, devanagari, bengali, gurmukhi, gujarati, oriya, tamil, telugu, kannada, malayam, sinhala, thai, lao, tibetan, myanmar, georgian, hangul, ethiopic, cherokee, canadian-aboriginal, ogham, runic, khmer, mongolian, symbol, braille, han, ideographic-description, cjk-misc, kana, bopomofo, kanbun, yi, byzantine-musical-symbol, musical-symbol, and mathematical.


Specifies the antialiasing method. The value none means no antialiasing, standard means use standard antialiasing, subpixel means use subpixel antialiasing (known as Cleartype on Windows), and natural means use subpixel antialiasing with adjusted spacing between letters. If unspecified, the font will use the system default antialiasing.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.11 Miscellaneous Windows-specific features

This section describes Windows-specific features that don’t fit anywhere else.

The variable w32-use-visible-system-caret is a flag that determines whether to make the system caret visible. The default when no screen reader software is in use is nil, which means Emacs draws its own cursor to indicate the position of point. A non-nil value means Emacs will indicate point location with the system caret; this facilitates use of screen reader software, and is the default when such software is detected when running Emacs. When this variable is non-nil, other variables affecting the cursor display have no effect.

The variable w32-grab-focus-on-raise, if set to a non-nil value causes a frame to grab focus when it is raised. The default is t, which fits well with the Windows default click-to-focus policy.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.12 Emacs and MS-DOS

This section briefly describes the peculiarities of using Emacs on MS-DOS. Information about peculiarities common to MS-DOS and Microsoft’s current operating systems Windows is in Emacs and Microsoft Windows/MS-DOS.

If you build Emacs for MS-DOS, the binary will also run on Windows 3.X, Windows NT, Windows 9X/ME, or Windows 2000/XP as a DOS application; all of this chapter applies for all of those systems, if you use an Emacs that was built for MS-DOS.

See section Text Files and Binary Files, for information about Emacs’s special handling of text files under MS-DOS (and Windows).

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.12.1 Keyboard Usage on MS-DOS

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 <Delete> 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 (@pxref{Quitting}). 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 (@pxref{Emergency Escape}).

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])

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.12.2 Mouse Usage on MS-DOS

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 (@pxref{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 (@pxref{Mouse References}) 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 (@pxref{Mouse Commands}). 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] [ ? ]

A.12.3 Display on MS-DOS

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 (@pxref{Colors}) and the list-faces-display command (@pxref{Faces}) to see what colors and faces are available and what they look like.

See section 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 (@pxref{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. For this reason, the bar and hbar cursor types produce the same effect on MS-DOS. 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 terminals (@pxref{Frames}). 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 dos-mode4350 command switches the display to 43 or 50 lines, depending on your hardware; the dos-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] [ ? ]

A.12.4 File Names on MS-DOS

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 (@pxref{Init File}) 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 (@pxref{Backup Names}) 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/XP, 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 the 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 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] [ ? ]

A.12.5 Printing and MS-DOS

Printing commands, such as lpr-buffer (@pxref{Printing}) and ps-print-buffer (@pxref{PostScript}) can work on MS-DOS 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, but in some cases they have different default values on MS-DOS.

See section Printing and MS-Windows, for details about setting up printing to a networked printer.

Some printers expect DOS codepage encoding of non-ASCII text, even though they are connected to a Windows machine that 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 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.

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.

[ << ] [ < ] [ Up ] [ > ] [ >> ]         [Top] [Contents] [Index] [ ? ]

A.12.6 International Support on MS-DOS

Emacs on MS-DOS supports the same international character sets as it does on GNU, Unix and other platforms (@pxref{International}), 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.

The description below is largely specific to the MS-DOS port of Emacs, especially where it talks about practical implications for Emacs users.

M-x dos-codepage-setup

Set up Emacs display and coding systems as appropriate for the current DOS codepage.

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(4). Much the same limitation applies when you run DOS executables on other systems such as MS-Windows.

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 that correspond to one of the ISO character sets, Emacs knows the character set 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.(5)

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\-’. @xref{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 (@pxref{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.

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] [ ? ]

A.12.7 Subprocesses on MS-DOS

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 a native Windows application does support asynchronous subprocesses. See section Subprocesses on Windows 9X/ME and Windows NT/2K/XP/Vista/7/8/10.

Printing commands, such as lpr-buffer (@pxref{Printing}) and ps-print-buffer (@pxref{PostScript}), 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. 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 (see section Emulation of ls on MS-Windows). 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’.

[Top] [Contents] [Index] [ ? ]



Older versions of Emacs didn’t check the application data directory.


There is one known exception: The combination <Windows>-L that locks the workstation is handled by the system on a lower level. For this reason, w32-register-hot-key cannot override this key combination - it always locks the computer.


Note that the ‘net use’ command requires the UNC share name to be typed with the Windows-style backslashes, while the value of printer-name can be set with either forward- or backslashes.


Normally, one particular codepage is burnt into the display memory, while other codepages can be installed by modifying system configuration files, such as ‘CONFIG.SYS’, and rebooting. While there is third-party software that allows changing the codepage without rebooting, we describe here how a stock MS-DOS system behaves.


The standard Emacs coding systems for ISO 8859 are not quite right for the purpose, because typically the DOS codepage does not match the standard ISO character codes. For example, the letter ‘ç’ (‘c’ with cedilla) has code 231 in the standard Latin-1 character set, but the corresponding DOS codepage 850 uses code 135 for this glyph.

[Top] [Contents] [Index] [ ? ]

About This Document

This document was generated on May 29, 2018 using texi2html.

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[ << ] FastBack Beginning of this chapter or previous chapter 1
[ < ] Back Previous section in reading order 1.2.2
[ Up ] Up Up section 1.2
[ > ] Forward Next section in reading order 1.2.4
[ >> ] FastForward Next chapter 2
[Top] Top Cover (top) of document  
[Contents] Contents Table of contents  
[Index] Index Index  
[ ? ] About About (help)  

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

This document was generated on May 29, 2018 using texi2html.