Emacs and Microsoft Windows
***************************

This section describes peculiarities of using Emacs on Microsoft Windows.  Information about Emacs and Microsoft's older MS-DOS ``operating system'' (also known as ``MS-DOG'') is now in a separate manual (see MS-DOG (emacs-xtra)).

Iif you want to use Emacs on Windows, you would normally build Emacs specifically for Windows.  If you do that, the behavior 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.

Text Files and Binary Files
===========================

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 Coding Systems).

One consequence of this special format-conversion of most files is that character positions as reported by Emacs (see 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 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 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 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 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 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 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.

Subprocesses on Windows 9X/ME and Windows NT/2K
===============================================

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.

Using the System Menu on Windows
================================

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