If you are new to the world of UNIX, you may find it difficult to understand at first. This guide is not meant to be comprehensive, so we recommend that you use the many available Internet resources to become acquainted with UNIX basics (search for "UNIX basics" or "UNIX tutorial"). To install a basic Cygwin environment, run the setup.exe program and click Next at each page. The default settings are correct for most users. If you want to know more about what each option means, see . Use setup.exe any time you want to update or install a Cygwin package. If you are installing Cygwin for a specific purpose, use it to install the tools that you need. For example, if you want to compile C++ programs, you need the gcc-g++ package and probably a text editor like nano. When running setup.exe, clicking on categories and packages in the package installation screen will provide you with the ability to control what is installed or updated. Another option is to install everything by clicking on the Default field next to the All category. However, be advised that this will download and install several hundreds of megabytes of software to your computer. The best plan is probably to click on individual categories and install either entire categories or packages from the categories themselves. After installation, you can find Cygwin-specific documentation in the /usr/share/doc/Cygwin/ directory. Developers coming from a Windows background will be able to write console or GUI executables that rely on the Microsoft Win32 API instead of Cygwin using the -mno-cygwin option to GCC. The -shared option allows to write Windows Dynamically Linked Libraries (DLLs). The resource compiler windres is also provided. If you are an experienced UNIX user who misses a powerful command-line environment, you will enjoy Cygwin. Note that there are some workarounds that cause Cygwin to behave differently than most UNIX-like operating systems; these are described in more detail in . Any time you want to update or install a Cygwin package, use the graphical setup.exe program. Note that, differently from what happens under most Unix and Linux systems, presence of updated packages isn't checked automatically in the default installation, but you have to run manuallysetup.exe to check for updates. By default, setup.exe only installs a minimal set of packages, so look around and choose your favorite utilities on the package selection screen. You may also search for specfic tools on the Cygwin website's Setup Package Search For more information about what each option in setup.exe means, see . Another option is to install everything by clicking on the Default field next to the All category. However, be advised that this will download and install several hundreds of megabytes of software to your computer. The best plan is probably to click on individual categories and install either entire categories or packages from the categories themselves. After installation, you can find Cygwin-specific documentation in the /usr/share/doc/Cygwin/ directory. Developers coming from a UNIX background will find a set of utilities they are already comfortable using, including a working UNIX shell. The compiler tools are the standard GNU compilers most people will have previously used under UNIX, only ported to the Windows host. Programmers wishing to port UNIX software to Windows NT will find that the Cygwin library provides an easy way to port many UNIX packages, with only minimal source code changes. When a binary linked against the library is executed, the Cygwin DLL is loaded into the application's text segment. Because we are trying to emulate a UNIX kernel which needs access to all processes running under it, the first Cygwin DLL to run creates shared memory areas and global synchronization objects that other processes using separate instances of the DLL can access. This is used to keep track of open file descriptors and to assist fork and exec, among other purposes. Every process also has a per_process structure that contains information such as process id, user id, signal masks, and other similar process-specific information. The DLL is implemented as a standard DLL in the Win32 subsystem. Under the hood it's using the Win32 API, as well as the native NT API, where appropriate. Because processes run under the standard Win32 subsystem, they can access both the UNIX compatibility calls provided by Cygwin as well as any of the Win32 API calls. This gives the programmer complete flexibility in designing the structure of their program in terms of the APIs used. For example, they could write a Win32-specific GUI using Win32 API calls on top of a UNIX back-end that uses Cygwin. The native NT API is used mainly for speed, as well as to access NT capabilities which are useful to implement certain POSIX features, but are hidden to the Win32 API. Due to some restrictions in Windows, it's not always possible to strictly adhere to existing UNIX standards like POSIX.1. Fortunately these are mostely border cases. Windows NT includes a sophisticated security model based on Access Control Lists (ACLs). Cygwin maps Win32 file ownership and permissions to ACLs by default, on file systems supporting them (usually NTFS). Solaris style ACLs and accompanying function calls are also supported. The chmod call maps UNIX-style permissions back to the Win32 equivalents. Because many programs expect to be able to find the /etc/passwd and /etc/group files, we provide utilities that can be used to construct them from the user and group information provided by the operating system. Users with Administrator rights are permitted to chown files. With version 1.1.3 Cygwin introduced a mechanism for setting real and effective UIDs. This is described in . As of version 1.5.13, the Cygwin developers are not aware of any feature in the Cygwin DLL that would allow users to gain privileges or to access objects to which they have no rights under Windows. However there is no guarantee that Cygwin is as secure as the Windows it runs on. Cygwin processes share some variables and are thus easier targets of denial of service type of attacks. Cygwin supports both POSIX- and Win32-style paths, using either forward or back slashes as the directory delimiter. Paths coming into the DLL are translated from POSIX to native NT as needed. From the application perspective, the file system is a POSIX-compliant one. The implementation details are safely hidden in the Cygwin DLL. UNC pathnames (starting with two slashes) are supported for network paths. Since version 1.7.0, the layout of this POSIX view of the Windows file system space is stored in the /etc/fstab file. Actually, there is a system-wide /etc/fstab file as well as a user-specific fstab file /etc/fstab.d/${USER}. At startup the DLL has to find out where it can find the /etc/fstab file. The mechanism used for this is simple. First it retrieves it's own path, for instance C:\Cygwin\bin\cygwin1.dll. From there it deduces that the root path is C:\Cygwin. So it looks for the fstab file in C:\Cygwin\etc\fstab. The layout of this file is very similar to the layout of the fstab file on Linux. Just instead of block devices, the mount points point to Win32 paths. An installation with setup.exe installs a fstab file by default, which can easily be changed using the editor of your choice. In addition to selecting the root partition, the fstab file allows mounting arbitrary Win32 paths into the POSIX file system space. A special case is the so-called cygdrive prefix. It's the path under which every available drive in the system is mounted under its drive letter. The default value is /cygdrive, so you can access the drives as /cygdrive/c, /cygdrive/d, etc... The cygdrive prefix can be set to some other value (/mnt for instance) in the fstab file(s). The library exports several Cygwin-specific functions that can be used by external programs to convert a path or path list from Win32 to POSIX or vice versa. Shell scripts and Makefiles cannot call these functions directly. Instead, they can do the same path translations by executing the cygpath utility program that we provide with Cygwin. Win32 applications handle filenames case preserving but case insensitive. Cygwin supports case sensitivity on file systems supporting that. Since Windows XP, the OS only supports case sensitivity when a specific registry value is changed. Therefore case sensitivity is not the default usually. Symbolic links are not present and supported on Windows up to and including Windows Server 2003 R2. Only starting with Windows Vista, native symlinks are available. Unfortunately they are strangly implemented and so not very useful for a POSIX emulation layer. Consequentially Cygwin recognizes them as symlinks but does not create them. Symbolic links are potentially created in two different ways. The file style symlinks are files containing a magic cookie followed by the path to which the link points. They are marked with the System DOS attribute so that only files with that attribute have to be read to determine whether or not the file is a symbolic link. The shortcut style symlinks are Windows shortcut files with a special header and the Readonly DOS attribute set. The advantage of file symlinks is speed, the advantage of shortcut symlinks is the fact that they can be utilized by non-Cygwin Win32 tools as well. Hard links are fully supported on NTFS and NFS file systems. On FAT and some other file systems, the call falls back to simply copying the file, a strategy that works in many cases. On file systems which don't support unique persistent file IDs (FAT, older Samba shares) the inode number for a file is calculated by hashing its full Win32 path. The inode number generated by the stat call always matches the one returned in d_ino of the dirent structure. It is worth noting that the number produced by this method is not guaranteed to be unique. However, we have not found this to be a significant problem because of the low probability of generating a duplicate inode number. chroot(2) is supported since Cygwin 1.1.3. However, chroot is not a concept known by Windows. This implies some restrictions. First of all, the chroot call isn't a privileged call. Each user may call it. Second, the chroot environment isn't safe against native windows processes. If you want to support a chroot environment as, for example, by allowing an anonymous ftp with restricted access, you'll have to care that only native Cygwin applications are accessible inside of the chroot environment. Since those applications are only using the Cygwin POSIX API to access the file system their access can be restricted as it is intended. This includes not only POSIX paths but Win32 paths containing drive letter and/or backslashes as well as UNC paths (//server/share or \\server\share). Interoperability with other Win32 programs such as text editors was critical to the success of the port of the development tools. Most Red Hat customers upgrading from the older DOS-hosted toolchains expected the new Win32-hosted ones to continue to work with their old development sources. Unfortunately, UNIX and Win32 use different end-of-line terminators in text files. Consequently, carriage-return newlines have to be translated on the fly by Cygwin into a single newline when reading in text mode. This solution addresses the compatibility requirement at the expense of violating the POSIX standard that states that text and binary mode will be identical. Consequently, processes that attempt to lseek through text files can no longer rely on the number of bytes read as an accurate indicator of position in the file. For this reason, the CYGWIN environment variable can be set to override this behavior. We chose to include Red Hat's own existing ANSI C library "newlib" as part of the library, rather than write all of the lib C and math calls from scratch. Newlib is a BSD-derived ANSI C library, previously only used by cross-compilers for embedded systems development. Other functions, which are not supported by newlib have been added to the Cygwin sources using BSD implementations as much as possible. The reuse of existing free implementations of such things as the glob, regexp, and getopt libraries saved us considerable effort. In addition, Cygwin uses Doug Lea's free malloc implementation that successfully balances speed and compactness. The library accesses the malloc calls via an exported function pointer. This makes it possible for a Cygwin process to provide its own malloc if it so desires. The fork call in Cygwin is particularly interesting because it does not map well on top of the Win32 API. This makes it very difficult to implement correctly. Currently, the Cygwin fork is a non-copy-on-write implementation similar to what was present in early flavors of UNIX. The first thing that happens when a parent process forks a child process is that the parent initializes a space in the Cygwin process table for the child. It then creates a suspended child process using the Win32 CreateProcess call. Next, the parent process calls setjmp to save its own context and sets a pointer to this in a Cygwin shared memory area (shared among all Cygwin tasks). It then fills in the child's .data and .bss sections by copying from its own address space into the suspended child's address space. After the child's address space is initialized, the child is run while the parent waits on a mutex. The child discovers it has been forked and longjumps using the saved jump buffer. The child then sets the mutex the parent is waiting on and blocks on another mutex. This is the signal for the parent to copy its stack and heap into the child, after which it releases the mutex the child is waiting on and returns from the fork call. Finally, the child wakes from blocking on the last mutex, recreates any memory-mapped areas passed to it via the shared area, and returns from fork itself. While we have some ideas as to how to speed up our fork implementation by reducing the number of context switches between the parent and child process, fork will almost certainly always be inefficient under Win32. Fortunately, in most circumstances the spawn family of calls provided by Cygwin can be substituted for a fork/exec pair with only a little effort. These calls map cleanly on top of the Win32 API. As a result, they are much more efficient. Changing the compiler's driver program to call spawn instead of fork was a trivial change and increased compilation speeds by twenty to thirty percent in our tests. However, spawn and exec present their own set of difficulties. Because there is no way to do an actual exec under Win32, Cygwin has to invent its own Process IDs (PIDs). As a result, when a process performs multiple exec calls, there will be multiple Windows PIDs associated with a single Cygwin PID. In some cases, stubs of each of these Win32 processes may linger, waiting for their exec'd Cygwin process to exit. When a Cygwin process starts, the library starts a secondary thread for use in signal handling. This thread waits for Windows events used to pass signals to the process. When a process notices it has a signal, it scans its signal bitmask and handles the signal in the appropriate fashion. Several complications in the implementation arise from the fact that the signal handler operates in the same address space as the executing program. The immediate consequence is that Cygwin system functions are interruptible unless special care is taken to avoid this. We go to some lengths to prevent the sig_send function that sends signals from being interrupted. In the case of a process sending a signal to another process, we place a mutex around sig_send such that sig_send will not be interrupted until it has completely finished sending the signal. In the case of a process sending itself a signal, we use a separate semaphore/event pair instead of the mutex. sig_send starts by resetting the event and incrementing the semaphore that flags the signal handler to process the signal. After the signal is processed, the signal handler signals the event that it is done. This process keeps intraprocess signals synchronous, as required by POSIX. Most standard UNIX signals are provided. Job control works as expected in shells that support it. Socket-related calls in Cygwin basically call the functions by the same name in Winsock, Microsoft's implementation of Berkeley sockets, but with lots of tweaks. All sockets are non-blocking under the hood to allow to interrupt blocking calls by POSIX signals. Additional bookkeeping is necessary to implement correct socket sharing POSIX semantics and especially for the select call. Some socket-related functions are not implemented at all in Winsock, as, for example, socketpair. Starting with Windows Vista, Microsoft removed the legacy calls rcmd(3), rexec(3) and rresvport(3). Recent versions of Cygwin now implement all these calls internally. An especially troublesome feature of Winsock is that it must be initialized before the first socket function is called. As a result, Cygwin has to perform this initialization on the fly, as soon as the first socket-related function is called by the application. In order to support sockets across fork calls, child processes initialize Winsock if any inherited file descriptor is a socket. AF_UNIX (AF_LOCAL) sockets are not available in Winsock. They are implemented in Cygwin by using local AF_INET sockets instead. This is completely transparent to the application. Cygwin's implementation also supports the getpeereid BSD extension. A yet missing feature is descriptor passing, though. Starting with release 1.7.0, Cygwin gets IPv6 support. However, this depends on the availability of the Windows IPv6 stack. Up to Windows 2003, the IPv6 stack is treated as "experimental" and it's not feature complete. Full support is only available starting with Windows Vista and Windows Server 2008. The newly implemented getaddrinfo and getnameinfo functions are not dependent on the OS, though. Cygwin 1.7.0 adds replacement functions which implement the full functionality for IPv4. The UNIX select function is another call that does not map cleanly on top of the Win32 API. Much to our dismay, we discovered that the Win32 select in Winsock only worked on socket handles. Our implementation allows select to function normally when given different types of file descriptors (sockets, pipes, handles, and a custom /dev/windows Windows messages pseudo-device). Upon entry into the select function, the first operation is to sort the file descriptors into the different types. There are then two cases to consider. The simple case is when at least one file descriptor is a type that is always known to be ready (such as a disk file). In that case, select returns immediately as soon as it has polled each of the other types to see if they are ready. The more complex case involves waiting for socket or pipe file descriptors to be ready. This is accomplished by the main thread suspending itself, after starting one thread for each type of file descriptor present. Each thread polls the file descriptors of its respective type with the appropriate Win32 API call. As soon as a thread identifies a ready descriptor, that thread signals the main thread to wake up. This case is now the same as the first one since we know at least one descriptor is ready. So select returns, after polling all of the file descriptors one last time.