Cygwin is a distribution of popular GNU and other Open Source tools running on Microsoft Windows. The core part is the Cygwin library which provides the POSIX system calls and environment these programs expect.

The Cygwin distribution contains thousands of packages from the Open Source world including most GNU tools, many BSD tools, an X server and a full set of X applications. If you're a developer you will find tools, headers and libraries allowing to write Windows console or GUI applications that make use of significant parts of the POSIX API. Cygwin allows easy porting of many Unix programs without the need for extensive changes to the source code. This includes configuring and building most of the available GNU or BSD software, including the packages included with the Cygwin distribution themselves. They can be used from one of the provided Unix shells like bash, tcsh or zsh.

Cygwin can be expected to run on all modern, released versions of Windows. This includes Windows 7, Windows Server 2008 R2 and all later versions of Windows, except Windows S mode due to its limitations, on 64 bit AMD/Intel compatible PCs, and under x64 emulation on ARM PCs running Windows 11.

Keep in mind that Cygwin can only do as much as the underlying OS supports. Because of this, Cygwin will behave differently, and exhibit different limitations, on the various versions of Windows.

The home page for the Cygwin project is https://cygwin.com/. There you should find everything you need for Cygwin, including links for download and setup, a current list of mirror sites, a User's Guide, an API Reference, mailing lists and archives.

You can find documentation for the individual GNU tools typically as man pages or info pages as part of the Cygwin net distribution. Additionally you can get the latest docs at http://www.gnu.org/manual.

Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are covered by the standard X11 license, some of it is public domain, some of it was written by Red Hat (or the former Cygnus Solutions) and placed under the GPL. None of it is shareware. You don't have to pay anyone to use it but you should be sure to read the copyright section of the FAQ for more information on how the GNU General Public License may affect your use of these tools.

Note that when we say "free" we mean freedom, not price. The goal of such freedom is that the people who use a given piece of software should be able to change it to fit their needs, learn from it, share it with their friends, etc. The GPL or LGPL licenses allows you those freedoms, so it is free software.

To find the version of the Cygwin DLL installed, you can use uname -r as you would for a Unix kernel. As the Cygwin DLL takes the place of a Unix kernel, you can also use the Unix compatible command: head /proc/version, or the Cygwin specific command: cygcheck -V. Refer to each command's --help output and the Cygwin User's Guide for more information.

If you are looking for the version number for the whole Cygwin release, there is none. Each package in the Cygwin release has its own version, and the cygwin package containing the Cygwin DLL and Cygwin system specific utilities is just another (but very important!) package. The packages in Cygwin are continually improving, thanks to the efforts of volunteers who maintain the Cygwin ports. Each package has its own version numbers and its own release process.

So, how do you get the most up-to-date version of Cygwin? Easy. Just download the Cygwin Setup program by following the installation instructions. The Setup program will handle the task of updating the packages on your system to the latest version. For more information about using Cygwin's Setup program, see Setting Up Cygwin in the Cygwin User's Guide.

(Please note that if you have cygwin-specific questions, all of these people will appreciate it if you use the cygwin mailing lists rather than sending personal email.)

Corinna Vinschen is the current project lead, responsible for the Cygwin library and a lot more.

Yaakov Selkowitz is the guy behind the current build and packaging system and maintained by far the most packages in the Cygwin distribution.

Jon Turney is maintainer of the Cygwin X server and related packages.

The packages are maintained by a large group of volunteers.

Please note that all of us volunteering on Cygwin try to be as responsive as possible and deal with patches and questions as we get them, but realistically we don't have time to answer all of the email that is sent to the main mailing list. Making releases of the tools and packages is an activity in our spare time, helping people out is not our primary focus, so some email will have to go unanswered.

Many thanks to everyone using the tools for their many contributions in the form of advice, bug reports, and code fixes. Keep them coming!

There is only one recommended way to install Cygwin, which is to use the Cygwin Setup program, a GUI installer. It is flexible and easy to use. You can pick and choose the packages you wish to install, and update them individually. Full source code is available for all packages and tools. More information is available on using the Cygwin Setup program.

If you do it any other way, you're on your own! If something doesn't work right for you, and it's not covered here or in the latest Cygwin test package (see Install Test Releases), then by all means report it to the mailing list.

For a searchable list of packages that can be installed with Cygwin, see https://cygwin.com/packages/.

The Cygwin Setup program is designed to be interactive, but there are a few different ways to automate it. If you are deploying to multiple systems, the best way is to run through a full installation once, saving the entire downloaded package tree. Then, on target systems, run the Cygwin Setup program as a "Local Install" pointed at your downloaded package tree. You could do this non-interactively with the command line options -q -L -l x:\cygwin-local\, where your downloaded package tree is in x:\cygwin-local\ (see the next FAQ for an explanation of those options.)

For other options, search the mailing lists with terms such as cygwin automated setup or automated cygwin install.

Yes, run the Cygwin Setup program with option --help for an up to date list:

    --allow-unsupported-windows    Allow old, unsupported Windows versions
 -a --arch                         Architecture to install (x86_64 or x86)
 -C --categories                   Specify categories to install
    --compact-os                   Compress installed files with Compact OS
                                   (xpress4k, xpress8k, xpress16k, lzx)
 -o --delete-orphans               Remove orphaned packages
 -A --disable-buggy-antivirus      Disable known or suspected buggy anti virus
                                   software packages during execution
 -D --download                     Download packages from internet
 -f --force-current                Select the current version for all packages
 -h --help                         Print help
 -I --include-source               Automatically install source for every
                                   package installed
 -i --ini-basename                 Use a different basename, e.g. "foo",
                                   instead of "setup"
 -U --keep-untrusted-keys          Use untrusted keys and retain all
    --lang                         Specify GUI language langid
 -L --local-install                Install packages from local directory
 -l --local-package-dir            Local package directory
 -m --mirror-mode                  Skip package availability check when
                                   installing from local directory (requires
                                   local directory to be clean mirror!)
 -B --no-admin                     Do not check for and enforce running as
                                   Administrator
 -d --no-desktop                   Disable creation of desktop shortcut
 -r --no-replaceonreboot           Disable replacing in-use files on next reboot
 -n --no-shortcuts                 Disable creation of desktop and start menu
                                   shortcuts
 -N --no-startmenu                 Disable creation of start menu shortcut
 -X --no-verify                    Don't verify setup.ini signatures
    --no-version-check             Suppress checking if a newer version of
                                   setup is available
 -w --no-warn-deprecated-windows   Don't warn about deprecated Windows versions
    --enable-old-keys              Enable old cygwin.com keys
 -O --only-site                    Do not download mirror list.  Only use sites
                                   specified with -s.
 -M --package-manager              Semi-attended chooser-only mode
 -P --packages                     Specify packages to install
 -p --proxy                        HTTP/FTP proxy (host:port)
 -Y --prune-install                Prune the installation to only the requested
                                   packages
 -K --pubkey                       URL or absolute path of extra public key
                                   file (RFC4880 format)
 -q --quiet-mode                   Unattended setup mode
 -c --remove-categories            Specify categories to uninstall
 -x --remove-packages              Specify packages to uninstall
 -R --root                         Root installation directory
 -S --sexpr-pubkey                 Extra DSA public key in s-expr format
 -s --site                         Download site URL
    --symlink-type                 Symlink type (lnk, native, sys, wsl)
 -u --untrusted-keys               Use untrusted saved extra keys
 -g --upgrade-also                 Also upgrade installed packages
    --user-agent                   User agent string for HTTP requests
 -v --verbose                      Verbose output
 -V --version                      Show version
 -W --wait                         When elevating, wait for elevated child
                                   process

Yes. The default installation requests administrator rights because this allows to set up the Cygwin environment so that all users can start a Cygwin shell out of the box. However, if you don't have administrator rights for your machine, and the admins don't want to install it for you, you can install Cygwin just for yourself by downloading the Cygwin Setup program, and then start it from the command line or via the "Run..." dialog from the start menu using the --no-admin option, for instance:

  setup-x86_64.exe --no-admin

The Cygwin Setup program will prompt you for a "root" directory. The default is C:\cygwin, but you can change it. You are urged not to choose something like C:\ (the root directory on the system drive) for your Cygwin root. If you do, then critical Cygwin system directories like etc, lib and bin could easily be corrupted by other (non-Cygwin) applications or packages that use \etc, \lib or \bin. Perhaps there is no conflict now, but who knows what you might install in the future? It's also just good common sense to segregate your Cygwin "filesystems" from the rest of your Windows system disk.

(In the past, there had been genuine bugs that would cause problems for people who installed in C:\, but we believe those are gone now.)

The Cygwin Setup program can be used to install any packages that are on a Cygwin mirror, which usually includes at least one version previous to the current one. The complete list may be searched at https://cygwin.com/packages/. There is no complete archive of older packages. If you have a problem with the current version of a Cygwin package, please report it to the mailing list using the guidelines at https://cygwin.com/problems.html.

That said, if you really need an older package, you may be able to find an outdated or archival mirror by searching the web for an old package version (for example, gcc2-2.95.3-10-src.tar.bz2), but keep in mind that this older version will not be supported by the mailing list and that installing the older version will not help improve Cygwin.

Here is how Cygwin secures the installation and update process to counter man-in-the-middle (MITM) attacks:

Cygwin uses the cryptographic hash algorithm SHA-512 as of 2015-03-23. The earlier 2015-02-06 update of the setup program added support for SHA-512 (Cygwin previously used MD5). There are no known practical exploits of SHA-512 (SHA-512 is part of the widely-used SHA-2 suite of cryptographic hashes).

To best secure your installation and update process, download the Cygwin Setup program, and then check its signature (using a signature-checking tool you trust) using the Cygwin public key (https://cygwin.com/key/pubring.asc). This was noted on the front page for installing and updating.

If you use the actual Cygwin public key, and have an existing secure signature-checking process, you will counter many other attacks such as subversion of the Cygwin website and malicious certificates issued by untrustworthy certificate authorities (CAs). One challenge, of course, is ensuring that you have the actual Cygwin public key. You can increase confidence in the Cygwin public key by checking older copies of the Cygwin public key (to see if it's been the same over time). Another challenge is having a secure signature-checking process. You can use GnuPG to check signatures; if you have a trusted Cygwin installation you can install GnuPG. Otherwise, to check the signature you must use an existing trusted tool or install a signature-checking tool you can trust.

Not everyone will go through this additional effort, but we make it possible for those who want that extra confidence. We also provide automatic mechanisms (such as our use of HTTPS) for those with limited time and do not want to perform the signature checking on the Cygwin Setup program itself. Once the correct Setup program is running, it will counter other attacks as described in Q: 2.7.

Unlikely. Unless you can confirm it, please don't report it to the mailing list. Anti-virus products have been known to detect false positives when extracting compressed tar archives. If this causes problems for you, consider disabling your anti-virus software when running the Cygwin Setup program. Read the next entry for a fairly safe way to do this.

Both Network Associates (formerly McAfee) and Norton anti-virus products have been reported to "hang" when extracting Cygwin tar archives. If this happens to you, consider disabling your anti-virus software when running the Cygwin Setup program. The following procedure should be a fairly safe way to do that:

This should be safe, but only if the Cygwin Setup program is not substituted by something malicious. See also Q: 2.7 for a description of how the Cygwin project counters man-in-the-middle (MITM) attacks.

See also BLODA for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

When using the Cygwin Setup program for the first time, the default is to install a minimal subset of all available packages. If you want anything beyond that, you will have to select it explicitly. See https://cygwin.com/packages/ for a searchable list of available packages, or use cygcheck -p as described in the Cygwin User's Guide at https://cygwin.com/cygwin-ug-net/cygcheck.html.

If you want to build programs, of course you'll need gcc, binutils, make and probably other packages from the ``Devel'' category. Text editors can be found under ``Editors''.

Long ago, the default was to install everything, much to the irritation of most users. Now the default is to install only a basic core of packages. The Cygwin Setup program is designed to make it easy to browse categories and select what you want to install or omit from those categories. There are now more than 10000 Cygwin packages requiring more than 150GB of disk space just to download and hundreds of GB more to install so you are strongly advised not to attempt to install everything at once, unless you have a lot of free disk space, a very high speed network connection, and the system will not be required for any other purpose for many hours (or days) until installation completes.

That depends, obviously, on what you've chosen to download and install. A full installation today is many hundreds of GB installed, not including the package archives themselves nor the source code.

After installation, the package archives remain in your ``Local Package Directory''. By default the location of the Cygwin Setup program. You may conserve disk space by deleting the subdirectories there. These directories will have very weird looking names, being encoded with their URLs (named http%3a%2f...cygwin...%2f).

Of course, you can keep them around in case you want to reinstall a package. If you want to clean out only the outdated packages, Michael Chase has written a script called clean_setup.pl, available at unsupported/clean_setup.pl in a Cygwin mirror.

Detailed logs of the most recent Cygwin Setup session can be found in /var/log/setup.log.full and less verbose information about prior actions is in /var/log/setup.log.

First, make sure that you are using the latest version of the Cygwin Setup program. The latest version is always available from the Cygwin Home Page at https://cygwin.com/.

If you are downloading from the Internet, setup will fail if it cannot download the list of mirrors at https://cygwin.com/mirrors.lst. It could be that the network is too busy. Something similar could be the cause of a download site not working. Try another mirror, or try again later.

If the Cygwin Setup program refuses to download a package that you know needs to be upgraded, try deleting that package's entry from /etc/setup. If you are reacting quickly to an announcement on the mailing list, it could be that the mirror you are using doesn't have the latest copy yet. Try another mirror, or try again tomorrow.

If the Cygwin Setup program has otherwise behaved strangely, check the files setup.log and setup.log.full in /var/log (C:\cygwin\var\log by default). It may provide some clues as to what went wrong and why.

If you're still baffled, search the Cygwin mailing list for clues. Others may have the same problem, and a solution may be posted there. If that search proves fruitless, send a query to the Cygwin mailing list. You must provide complete details in your query: version of the Cygwin Setup program, options you selected, contents of setup.log and setup.log.full, what happened that wasn't supposed to happen, etc.

Most definitely yes! UNIX shells (and thus Cygwin) use the space character as a word delimiter. Under certain circumstances, it is possible to get around this with various shell quoting mechanisms, but you are much better off if you can avoid the problem entirely.

You have two choices:

When starting Cygwin from Windows, HOME is determined as follows:

When using Cygwin from a network login (via ssh for instance), HOME is always taken from the passwd entry.

If your HOME is set to a value such as /cygdrive/c, it is likely that it was set in Windows. Start a DOS Command Window and type "set HOME" to verify if this is the case.

Access to shared drives is often restricted when starting from the network, thus Domain users may wish to have a different HOME in the Windows environment (on shared drive) than in Cygwin (on local drive). Note that ssh only considers the account information as retrieved by getpwnam(3), disregarding HOME.

Run the Cygwin Setup program as you would to install packages. In the ``Select packages to install'' dialog, choose ``Up To Date'' in the View drop-down menu, and locate the package. Choose the ``Uninstall'' action from the drop-down menu in the ``New'' column. Proceed by clicking ``Next''.

Setup has no automatic uninstall facility. The recommended method to remove all of Cygwin is as follows:

You can install Cygwin test releases just like test releases of any other package using the Cygwin Setup program. Ideally, you install not only the cygwin test package, but also the cygwin-debuginfo test package with the same version number. The cygwin-debuginfo package allows source code debugging using gdb. Install the cygwin-devel test package, if you also want to test building against a new API.

However, are you sure you want to do this? Test releases are risky. They have only been marginally tested most of the time. Use them only if there is a feature or bugfix that you need to try, and you are willing to deal with any problems, or at the request of a Cygwin developer.

The operative word in trying the test releases is "trying". If you notice a problem with the snapshot that was not present in the release DLL (what we call a "regression"), please report it to the Cygwin mailing list (see https://cygwin.com/problems.html for problem reporting guidelines). If you wish to go back to the most recent non-test release of the Cygwin DLL, close all Cygwin processes, as usual, start the Cygwin Setup program and choose the most recent non-test release of the cygwin package, as well as the cygwin-debuginfo and cygwin-devel packages. That's all there is to it.

NO. The Cygwin Setup program cannot do this for you. Use a tool designed for this purpose. See http://rsync.samba.org/, http://www.gnu.org/software/wget/ for utilities that can do this for you. For more information on setting up a custom Cygwin package server, see the Cygwin Package Server page.

While some users have successfully done this, for example Indiana University's XLiveCD http://racinfo.indiana.edu/research/xlivecd.php, there is no easy way to do it. Full instructions for constructing a portable Cygwin on CD by hand can be found on the mailing list at https://www.cygwin.com/ml/cygwin/2003-07/msg01117.html (Thanks to fergus at bonhard dot uklinux dot net for these instructions.) Please note that these instructions are very old and are referring to the somewhat different setup of a Cygwin 1.5.x release. As soon as somebody set this up for recent Cygwin releases, we might add this information here.

Cygwin doesn't store anything important in the registry anymore for quite some time. There's no reason to save, restore or delete it.

If you have installed Cygwin, you can find lots of documentation in /usr/share/doc/. Some packages have Cygwin specific instructions in a file /usr/share/doc/Cygwin/package_name.README. In addition, many packages ship with standard documentation, which you can find in /usr/share/doc/package_name or by using the man or info tools. (Hint: use cygcheck -l package_name to list what man pages the package includes.) Some older packages still keep their documentation in /usr/doc/ instead of /usr/share/doc/.

There are links to quite a lot of documentation on the main Cygwin project web page, https://cygwin.com/, including this FAQ. Be sure to at least read any 'Release Notes' or 'Readme' or 'read this' links on the main web page, if there are any.

There is a comprehensive Cygwin User's Guide at https://cygwin.com/cygwin-ug-net/cygwin-ug-net.html and an API Reference at https://cygwin.com/cygwin-api/cygwin-api.html.

You can find documentation for the individual GNU tools at http://www.gnu.org/manual/.

Comprehensive information about the Cygwin mailing lists can be found at https://cygwin.com/lists.html.

Comprehensive information about reporting problems with Cygwin can be found at https://cygwin.com/problems.html.

Well, something has gone wrong somehow...

To repair the damage, you must run the Cygwin Setup program again, and re-install the package which provides the missing DLL package.

If you already installed the package at one point, the Cygwin Setup program won't show the option to install the package by default. In the ``Select packages to install'' dialog, choose ``Full'' in the View drop-down menu. This lists all packages, even those that are already installed. Scroll down to locate the missing package, for instance libncurses8. Choose the ``Reinstall'' action from the drop-down menu in the ``New'' column. Continue with the installation.

For a detailed explanation of the general problem, and how to extend it to other missing DLLs and identify their containing packages, see https://cygwin.com/ml/cygwin/2002-01/msg01619.html.

There are many possible causes for this.

If your terminal windows suddenly began starting slowly after a Cygwin upgrade, it may indicate issues in the authentication setup.

For almost all its lifetime, Cygwin has used Unix-like /etc/passwd and /etc/group files to mirror the contents of the Windows SAM and AD databases. Although these files can still be used, since Cygwin 1.7.34, new installations now use the SAM/AD databases directly.

To switch to the new method, move these two files out of the way and restart the Cygwin terminal. That runs Cygwin in its new default mode.

If you are on a system that isn't using AD domain logins, this makes Cygwin use the native Windows SAM database directly, which may be faster than the old method involving /etc/passwd and such. At worst, it will only be a bit slower. (The speed difference you see depends on which benchmark you run.) For the AD case, it can be slower than the old method, since it is trading a local file read for a network request. Version 1.7.35 will reduce the number of AD server requests the DLL makes relative to 1.7.34, with the consequence that you will now have to alter /etc/nsswitch.conf in order to change your Cygwin home directory, instead of being able to change it from the AD configuration.

If you are still experiencing very slow shell startups, there are a number of other things you can look into:

If none of the above helps, the best troubleshooting method is to run your startup scripts in debug mode. Right-click your Cygwin Terminal icon, go to Properties, and edit the command. It should be something like C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico -. Assuming you are using Bash for your login shell, change it to C:\cygwin\bin\mintty /bin/bash -lx then try running Cygwin Terminal again. The -x option tells Bash to write every command it runs to the terminal before launching it. If the terminal immediately starts filling with lines of text but then pauses, the line where the output paused is your clue as to what's going on. The Cygwin DLL proper probably isn't the cause of the slowdown in this case, since those delays happen before the first line of text appears in the terminal.

If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.

If your service is one of those which switch the user context (sshd, inetd, etc), then it depends on the method used to switch to another user. This problem as well as its solution is described in detail in the Cygwin User's Guide, see https://cygwin.com/cygwin-ug-net/ntsec.html.

Workarounds include using public network share that does not require authentication (for non-critical files), providing your password to a net use command, or running the service as your own user with cygrunsrv -u (see /usr/share/doc/Cygwin/cygrunsrv.README for more information).

This is done for you in the file /etc/profile, which is sourced by bash when you start it from the Desktop or Start Menu shortcut, created by the Cygwin Setup program. The line is

	PATH="/usr/local/bin:/usr/bin:/bin:$PATH"

Effectively, this prepends /usr/local/bin and /usr/bin to your Windows system path. If you choose to reset your PATH, say in $HOME/.bashrc, or by editing etc/profile directly, then you should follow this rule. You must have /usr/bin in your PATH before any Windows system directories. (And you must not omit the Windows system directories!) Otherwise you will likely encounter all sorts of problems running Cygwin applications.

If you're using another shell than bash (say, tcsh), the mechanism is the same, just the names of the login scripts are different.

If you compile a program, you might find that you can't run it:

	bash$ gcc -o hello hello.c
        bash$ hello
        bash: hello: command not found

Unlike the Windows default behaviour, Unix shells like bash do not look for programs in . (the current directory) by default. You can add . to your PATH (see above), but this is not recommended (at least on UNIX) for security reasons. Just tell bash where to find it, when you type it on the command line:

	bash$ gcc -o hello hello.c
        bash$ ./hello
        Hello World!

Use the 'cygpath' utility. Type 'cygpath --help' for information. For example (on my installation):

	bash$ cygpath --windows ~/.bashrc
        D:\starksb\.bashrc
        bash$ cygpath --unix C:/cygwin/bin/ls.exe
        /usr/bin/ls.exe
        bash$ cygpath --unix C:\\cygwin\\bin\\ls.exe
        /usr/bin/ls.exe

Note that bash interprets the backslash '\' as an escape character, so you must type it twice in the bash shell if you want it to be recognized as such.

Your .bashrc is read from your home directory specified by the HOME environment variable. It uses /.bashrc if HOME is not set. So you need to set HOME (and the home dir in your passwd account information) correctly.

Add the following to your ~/.bashrc file:

	shopt -s nocaseglob

and add the following to your ~/.inputrc file:

	set completion-ignore-case on

Cygwin does support spaces in filenames and paths. That said, some utilities that use the library may not, since files don't typically contain spaces in Unix. If you stumble into problems with this, you will need to either fix the utilities or stop using spaces in filenames used by Cygwin tools.

In particular, bash interprets space as a word separator. You would have to quote a filename containing spaces, or escape the space character. For example:

	bash-2.03$ cd '/cygdrive/c/Program Files'

or

	bash-2.03$ cd /cygdrive/c/Program\ Files

Cygwin does not follow MS Windows Explorer Shortcuts (*.lnk files). It sees a shortcut as a regular file and this you cannot "cd" into it.

Cygwin is also capable to create POSIX symlinks as Windows shortcuts (see the CYGWIN environment variable option "winsymlinks"), but these shortcuts are different from shortcuts created by native Windows applications. Windows applications can usually make use of Cygwin shortcuts but not vice versa. This is by choice. The reason is that Windows shortcuts may contain a bunch of extra information which would get lost, if, for example, Cygwin tar archives and extracts them as symlinks.

Changing a Cygwin shortcut in Windows Explorer usually changes a Cygwin shortcut into a Windows native shortcut. Afterwards, Cygwin will not recognize it as symlink anymore.

Make sure you are using the find that came with Cygwin and that you aren't picking up the Win32 find command instead. You can verify that you are getting the right one by doing a "type find" in bash.

If the path argument to find, including current directory (default), is itself a symbolic link, then find will not traverse it unless you specify the -follow option. This behavior is different than most other UNIX implementations, but is not likely to change.

If find does not seem to be producing enough results, or seems to be missing out some directories, you may be experiencing a problem with one of find's optimisations. The absence of . and .. directories on some filesystems, such as DVD-R UDF, can confuse find. See the documentation for the option -noleaf in the man page.

The su command has been in and out of Cygwin distributions, but it has not been ported to Cygwin and has never worked. It is currently installed as part of the sh-utils, but again, it does not work.

You should rather install sshd and use ssh username@localhost as a su replacement.

For some technical background into why su doesn't work, read https://www.cygwin.com/ml/cygwin/2003-06/msg00897.html and related messages.

Before you can use man -k, apropos or whatis, you must create the whatis database. Just run the command

	mandb

(it may take a few minutes to complete).

If you're using FAT32 instead of NTFS, chmod will fail since FAT32 does not provide any permission information. You should really consider converting the drive to NTFS with CONVERT.EXE. FAT and FAT32 are barely good enough for memory cards or USB sticks to exchange pictures...

For other cases, understand that Cygwin attempts to show UNIX permissions based on the security features of Windows, so the Windows ACLs are likely the source of your problem. See the Cygwin User's Guide at https://cygwin.com/cygwin-ug-net/ntsec.html for more information on how Cygwin maps Windows permissions.

There are two basic problems you might run into. One is the fact that /bin/sh is really bash. It could be missing some features you might expect in /bin/sh, if you are used to /bin/sh actually being zsh (MacOS X "Panther") or ksh (Tru64).

Or, it could be a permission problem, and Cygwin doesn't understand that your script is executable. On NTFS or NFS just make the script executable using chmod +x. However, chmod may not work due to restrictions of the filesystem (see FAQ entry above). In this case Cygwin must read the contents of files to determine if they are executable. If your script does not start with

	#! /bin/sh

(or any path to a script interpreter, it does not have to be /bin/sh) then Cygwin will not know it is an executable script. The Bourne shell idiom

	:
	# This is the 2nd line, assume processing by /bin/sh

also works.

Note that you can use the filesystem flag cygexec in /etc/fstab to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable.

lpr is available in the cygutils package. Some usage hints are available courtesy of Rodrigo Medina.

Jason Tishler has written a couple of messages that explain how to use a2ps (for nicely formatted text in PostScript) and ghostscript (to print PostScript files on non-PostScript Windows printers). Start at https://cygwin.com/ml/cygwin/2001-04/msg00657.html. Note that these are old mails and a2ps as well as file are long available as part of the Cygwin distribution.

Alternatively, you can use the Windows print command. Type

	bash$ print /\?

for usage instructions (note the ? must be escaped from the shell).

Finally, you can simply cat the file to the printer's share name:

	bash$ cat myfile > //host/printer

You may need to press the formfeed button on your printer or append the formfeed character to your file.

Internationalization is a complex issue. The short answer is that Cygwin relies on the setting of the setting of LANG/LC_xxx environment variables. The long answer can be found in the User's Guide in the section Internationalization

Cygwin uses UTF-8 by default. To use a different character set, you need to set the LC_ALL, LC_CTYPE or LANG environment variables.

In the case of Cygwin programs, this likely means that the character set as determined by the LC_ALL, LC_CTYPE or LANG environment variables does not match the one set on the Text page of the Cygwin Terminal's options. Setting the locale in the terminal's options will set the LANG variable accordingly.

Non-Cygwin programs in the Cygwin Terminal do not usually take heed of the locale environment variables. Instead, they often use the so-called console codepage, which can be determined with the command cmd /c chcp followed by the appropriate Windows codepage number. The codepage number for Cygwin's default UTF-8 character set is 65001.

Yes, as long as they are used in strictly separated installations.

The Cygwin DLL has to handle various sharing situations between multiple processes. It has to keep a process table. It has to maintain a mount table which is based on the installation path of the Cygwin DLL.

For that reason, the Cygwin DLL maintains shared resources based on a hash value created from its own installation path. Each Cygwin DLL on the machine constitutes a Cygwin installation, with the directory the Cygwin DLL resides in treated as "/bin", the parent directory as "/".

Therefore, you can install two or more separate Cygwin distros on a single machine. Each of these installations use their own Cygwin DLL, and they don't share the default POSIX paths, nor process tables, nor any other shared resource used to maintain the installation.

However, a clean separation requires that you don't try to run executables of one Cygwin installation from processes running in another Cygwin installation. This may or may not work, but the chances that the result is not what you expect are pretty high.

If you get the error "shared region is corrupted" or "shared region version mismatch" it means you have multiple versions of cygwin1.dll running at the same time which conflict with each other. Apart from mixing executables of different Cygwin installations, this could also happen if you have one a single Cygwin installation, for example, if you update the Cygwin package without exiting all Cygwin apps (including services like sshd) beforehand.

The only DLL that is sanctioned by the Cygwin project is the one that you get by running the Cygwin Setup program, installed in a directory controlled by this program. If you have other versions on your system and desire help from the cygwin project, you should delete or rename all DLLs that are not installed by the Cygwin Setup program.

If you're trying to find multiple versions of the DLL that are causing this problem, reboot first, in case DLLs still loaded in memory are the cause. Then use the Windows System find utility to search your whole machine, not just components in your PATH (as 'type' would do) or cygwin-mounted filesystems (as Cygwin 'find' would do).

Usually, if you keep your installation separate, nothing bad should happen. However, for the user's convenience, and to avoid potential problems which still can occur, consider to integrate your product with an already existing Cygwin installation on the user's machine, or, if there is none, consider to install the official Cygwin distro on behalf of the user and integrate your tools from there. (If you write a tool to make this easy, consider contributing it for others to use)

Starting with Cygwin version 2.5.2, which is LGPL licensed, yes, albeit it's not recommended for interoperability reasons.

Cygwin versions prior to 2.5.2 were GPL licensed. If you choose to distribute an older cygwin1.dll, you must be willing to distribute the exact source code used to build that copy of cygwin1.dll as per the terms of the GPL. If you ship applications that link with older cygwin1.dll, you must provide those applications' source code under a GPL-compatible license.

It depends on what you mean by "break". If the application installs a version of the Cygwin DLL in another location than Cygwin's /bin directory then the rules in Q: 4.21 apply. If the application installs an older version of the DLL in /bin then you should complain loudly to the application provider.

Remember that the Cygwin DLL strives to be backwards compatible so a newer version of the DLL should always work with older executables. So, in general, it is always best to keep one version of the DLL on your system and it should always be the latest version which matches your installed distribution.

Probably because there is nobody willing or able to maintain it. It takes time, and the priority for the Cygwin Team is the Cygwin package. The rest is a volunteer effort. Want to contribute? See https://cygwin.com/packaging.html.

(Also: Why is the version of package XYZ older than the version that I can download from the XYZ web site? Why is the version of package XYZ older than the version that I installed on my linux system? Is there something special about Cygwin which requires that only an older version of package XYZ will work on it?)

Every package in the Cygwin distribution has a maintainer who is responsible for sending out updates of the package. This person is a volunteer who is rarely the same person as the official developer of the package. If you notice that a version of a package seems to be out of date, the reason is usually pretty simple -- the person who is maintaining the package hasn't gotten around to updating it yet. Rarely, the newer package actually requires complex changes that the maintainer is working out.

If you urgently need an update, sending a polite message to the cygwin mailing list pinging the maintainer is perfectly acceptable. There are no guarantees that the maintainer will have time to update the package or that you'll receive a response to your request, however.

Remember that the operative term here is "volunteer".

You have some flexibility here.

Cygwin has a builtin "cygdrive prefix" for drives that are not mounted. You can access any drive, say Z:, as '/cygdrive/z/'.

In some applications (notably bash), you can use the familiar windows <drive>:/path/, using posix forward-slashes ('/') instead of Windows backward-slashes ('\'). (But see the warning below!) This maps in the obvious way to the Windows path, but will be converted internally to use the Cygwin path, following mounts (default or explicit). For example:

	bash$ cd C:/Windows
	bash$ pwd
        /cygdrive/c/Windows

and

	bash$ cd C:/cygwin
	bash$ pwd
        /

for a default setup. You could also use backward-slashes in the Windows path, but these would have to be escaped from the shell.

Warning: There is some ambiguity in going from a Windows path to the posix path, because different posix paths, through different mount points, could map to the same Windows directory. This matters because different mount points may be binmode or textmode, so the behavior of Cygwin apps will vary depending on the posix path used to get there.

You can avoid the ambiguity of Windows paths, and avoid typing "/cygdrive", by explicitly mounting drives to posix paths. For example:

	bash$ mkdir /c
	bash$ mount c:/ /c
	bash$ ls /c

Then /cygdrive/c/Windows becomes /c/Windows which is a little less typing.

Note that you have to enter the mount point into the /etc/fstab file to keep it indefinitely. The mount command will only add the mount point for the lifetime of your current Cygwin session.

You can change the default cygdrive prefix and whether it is binmode or textmode using the /etc/fstab file as well. See the Cygwin User's Guide at https://cygwin.com/cygwin-ug-net/using.html#mount-table for more details.

First, consider using mintty instead of the standard console window. In mintty, selecting with the left-mouse also copies, and middle-mouse pastes. It couldn't be easier!

In Windows's console window, open the properties dialog. The options contain a toggle button, named "Quick edit mode". It must be ON. Save the properties.

You can also bind the insert key to paste from the clipboard by adding the following line to your .inputrc file:

	"\e[2~": paste-from-clipboard 

We have had good reports about Kerio Personal Firewall, ZoneLabs Integrity Desktop, and the Windows built-in firewall. Other well-known products including ZoneAlarm and Norton Internet Security have caused problems for some users but work fine for others. At last report, Agnitum Outpost did not work with Cygwin. If you are having strange connection-related problems, disabling the firewall is a good troubleshooting step (as is closing or disabling all other running applications, especially resource-intensive processes such as indexed search).

On the whole, Cygwin doesn't care which firewall is used. The few rare exceptions have to do with socket code. Cygwin uses sockets to implement many of its functions, such as IPC. Some overzealous firewalls install themselves deeply into the winsock stack (with the 'layered service provider' API) and install hooks throughout. Sadly the mailing list archives are littered with examples of poorly written firewall-type software that causes things to break. Note that with many of these products, simply disabling the firewall does not remove these changes; it must be completely uninstalled.

See also BLODA for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

During development, we have Linux boxes running Samba and NFS as well as Windows machines. We often build with cross-compilers under Linux and copy binaries and source to the Windows system or just toy with them directly off the Samba-mounted partition. Or, we use the Microsoft NFS client and just use NFS shares on Linux from Windows. And then there are tools like scp, ftp, rsync, ...

Several Unix programs expect to be able to use to filenames spelled the same way, but with different case. A prime example of this is perl's configuration script, which wants Makefile and makefile. Windows can't tell the difference between files with just different case, so the configuration fails.

To help with this problem, Cygwin supports case sensitivity. For a detailed description how to use that feature see the Cygwin User's Guide at https://cygwin.com/cygwin-ug-net/using-specialnames.html.

In Windows, files cannot be named com1, lpt1, or aux (to name a few); either as the root filename or as the extension part. If you do, you'll have trouble. Unix programs don't avoid these names which can make things interesting. E.g., the perl distribution has a file called aux.sh. The perl configuration tries to make sure that aux.sh is there, but an operation on a file with the magic letters 'aux' in it will hang.

At least that's what happens when using native Windows tools. Cygwin can deal with these filenames just fine. Again, see the User's Guide at https://cygwin.com/cygwin-ug-net/using-specialnames.html for a detailed description of what's possible with filenames and what is not.

If something goes wrong and the tools hang on you for some reason (easy to do if you try and read a file called aux.sh), first try hitting ^C to return to bash or the cmd prompt.

If you start up another shell, and applications don't run, it's a good bet that the hung process is still running somewhere. Use the Task Manager, pview, or a similar utility to kill the process.

And, if all else fails, there's always the reset button/power switch. In theory this should never be necessary, though.

Why do /lib and /usr/lib (and /bin, /usr/bin) point to the same thing?

Why use mounts instead of symbolic links?

Can I use a disk root (e.g., C:\) as Cygwin root? Why is this discouraged?

After a new installation in the default location, your mount points will look something like this:

	bash$ mount
	C:\cygwin\bin on /usr/bin type ntfs (binary,auto)
	C:\cygwin\lib on /usr/lib type ntfs (binary,auto)
	C:\cygwin on / type ntfs (binary,auto)
	C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)

Note that /bin and /usr/bin point to the same location, as do /lib and /usr/lib. This is intentional, and you should not undo these mounts unless you really know what you are doing.

Various applications and packages may expect to be installed in /lib or /usr/lib (similarly /bin or /usr/bin). Rather than distinguish between them and try to keep track of them (possibly requiring the occasional duplication or symbolic link), it was decided to maintain only one actual directory, with equivalent ways to access it.

Symbolic links had been considered for this purpose, but were dismissed because they do not always work on Samba drives. Also, mounts are faster to process because no disk access is required to resolve them.

Note that non-cygwin applications will not observe Cygwin mounts (or most symlinks for that matter). For example, if you use WinZip to unpack the tar distribution of a Cygwin package, it may not get installed to the correct Cygwin path. So don't do this!

It is strongly recommended not to make the Cygwin root directory the same as your drive's root directory, unless you know what you are doing and are prepared to deal with the consequences. It is generally easier to maintain the Cygwin hierarchy if it is isolated from, say, C:\. For one thing, you avoid possible collisions with other (non-cygwin) applications that may create (for example) \bin and \lib directories. (Maybe you have nothing like that installed now, but who knows about things you might add in the future?)

Users have reported that NAI (formerly McAfee) VirusScan for NT (and others?) is incompatible with Cygwin. This is because it tries to scan the newly loaded shared memory in cygwin1.dll, which can cause fork() to fail, wreaking havoc on many of the tools. (It is not confirmed that this is still a problem, however.)

There have been several reports of NAI VirusScan causing the system to hang when unpacking tar.gz archives. This is surely a bug in VirusScan, and should be reported to NAI. The only workaround is to disable VirusScan when accessing these files. This can be an issue during Setup, and is discussed in that FAQ entry.

Some users report a significant performance hit using Cygwin when their anti-virus software is enabled. Rather than disable the anti-virus software completely, it may be possible to specify directories whose contents are exempt from scanning. In a default installation, this would be C:\cygwin\bin. Obviously, this could be exploited by a hostile non-Cygwin program, so do this at your own risk.

See also BLODA for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

Yes. Install the emacs package. This provides everything you need in order to run GNU emacs in a terminal window. If you also want to be able to use the X11 (https://x.cygwin.com/) GUI, install the emacs-X11 package. In either case, you run emacs by typing 'emacs' or '/usr/bin/emacs'.

Yes. It can be used in three different modes:

You have to set the DISPLAY environment variable before starting xemacs.

	bash$ DISPLAY=127.0.0.1:0 xemacs &

You have to unset the DISPLAY environment variable before starting xemacs.

	bash$ DISPLAY= xemacs &

Start xemacs with -nw in a terminal (native or X11) window

	bash$ xemacs -nw

To use all the standard packages with XEmacs you should download the following two packages:

Cygwin supports multiple character sets. Symlinks created with Cygwin are using the UTF-16 character set, which is portable across all character sets. Old symlinks were written using your current Windows codepage, which is not portable across all character sets. If the target of the symlink doesn't resolve anymore, it's very likely that the symlink points to a target filename using native, non-ASCII characters, and you're now using another character set than way back when you created the symlink.

Solution: Delete the symlink and create it again under you new Cygwin. The new symlink will be correctly point to the target no matter what character set you're using in future.

Default symlinks on Samba are marked with DOS SYSTEM file attribute. Samba does not enable this attribute by default. To enable it, consult your Samba documentation and then add these lines to your samba configuration file:

	map system = yes
	create mask = 0775

Note that the 0775 can be anything as long as the 0010 bit is set.

Alternatively, use Windows shortcuts as symlinks. See the CYGWIN environment variable option "winsymlinks:lnk" https://cygwin.com/cygwin-ug-net/using-cygwinenv.html Note that Samba does not support reparse points so some methods to create symlinks are just not available.

This is the result of fixing a long-standing security problem in Cygwin's POSIX ACL handling. IEEE 1003.1e draft 17 defines that the permissions of secondary user and group entries in an ACL are reflected in the group permission mask by or'ing the permissions of the file's primary group with all permissions of secondary users and groups in the ACL. The background is that this way the standard POSIX permission bits reflect the fact that somebody else has additional, otherwise potentially invisible permissions on the file. This relatively complex interface has been defined in order to ensure that applications that are compliant with IEEE 1003.1 (“POSIX.1”) will still function as expected on systems with ACLs.

So, what does that mean for your situation? Typically this means the private key file, for instance ~/.ssh/id_rsa, has too open permissions. OpenSSH expects the permissions of the private key file to be 0600. Let's use the default SSH2 RSA keyfile as example:

  $ ls -l .ssh/id_rsa
  -rw-------  1 user group 1766 Aug 26  2013 .ssh/id_rsa

However, if other accounts can read the file, the key is potentially compromised. Consider the file has additional rw- permissions for a group bad_guys. Up to Cygwin 1.7.33 that would have looked like this:

  $ ls -l .ssh/id_rsa
  -rw-------+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa

Notice the extra + character following the permission string. This shows that additional ACL entries are in the ACL. But an application only checking the POSIX permission bits (and ssh is one of them!), will not notice the fact, because it gets the permissions 0600 for the file.

Starting with Cygwin 1.7.34, the extra permissions are reflected in the group permission bits per IEEE 1003.1e draft 17:

  $ ls -l .ssh/id_rsa
  -rw-rw----+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa

So now ssh will notice that the file has extra permissions and it will complain. The same problem occurs if the file ~/.ssh/authorized_keys has too open permissions. On the client side you won't get any helping text, though, other than that you're suddenly asked for a password. That's a rather good hint to have a closer look at the server's ~/.ssh/authorized_keys file.

To fix the permissions of your private key file or your ~/.ssh/authorized_keys file, simply use the setfacl command with the -b option. This removes all additional ACL entries and thus fixes the permissions to be not too open:

  $ ls -l .ssh/id_rsa
  -rw-rw----+ 1 user group 1766 Aug 26  2013 .ssh/id_rsa
  $ setfacl -b .ssh/id_rsa
  $ ls -l .ssh/id_rsa
  -rw-------  1 user group 1766 Aug 26  2013 .ssh/id_rsa

If the second ls command still gives you -rw-rw---- permissions after running the above commands, it is proably because the file's primary group is your user's personal group:

  $ ls -l .ssh/id_rsa
  -rw-rw----  1 Fred Fred 1766 Aug 26  2013 .ssh/id_rsa

Since the Windows security system treats groups and users as much the same thing, a change to the user or group permissions on such a file reflects the change to both user and group. In effect, mode 0600 becomes mode 0660. Because we are saying we want these files to be readable only by our user, the fix for this is easy:

  $ chgrp `id -g` ~/.ssh/*

That resets the group on these files to your default group which should be something like Users, depending on your local configuration. If that doesn't work, you can try something like this instead:

  $ chgrp None ~/.ssh/*

That group always exists, but its name is different on non-English versions of Windows. You might also want to use a domain group instead of a local group if your site uses Windows domains. For example, you might want to use the Domain Users group instead.

For more information on setfacl, see https://cygwin.com/cygwin-ug-net/setfacl.html

The problem is exactly the same as with the key files of SSH. See Q: 4.39.

The solution is the same:

  $ ls -l .rhosts
  -rw-rw----+ 1 user group 42 Nov 12  2010 .rhosts
  $ setfacl -b .rhosts
  $ ls -l .rhosts
  -rw-------  1 user group 42 Nov 12  2010 .rhosts

The problem is exactly the same as with the key files of SSH. See Q: 4.39.

The solution is the same:

  $ ls -l *
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file1
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 file2
  $ setfacl -b *
  $ ls -l *
  -rw-r--r--  1 user group 42 Nov 12  2010 file1
  -rw-r--r--  1 user group 42 Nov 12  2010 file2

You may find that newly-created files also have unexpected permissions:

  $ touch foo
  $ ls -l foo
  -rw-rwxr--+ 1 user group 42 Nov 12  2010 foo

This probably means that the directory in which you're creating the files has unwanted default ACL entries that are inherited by newly-created files and subdirectories. The solution is again the same:

  $ setfacl -b .
  $ touch bar
  $ ls -l bar
  -rw-r--r--  1 user group 42 Nov 12  2010 bar

Previous versions of Tcl/Tk distributed with Cygwin (e.g. tclsh84.exe, wish84.exe) were not actually "Cygwin versions" of those tools. They were built as native libraries, which means they did not understand Cygwin mounts or symbolic links. This lead to all sorts of problems interacting with true Cygwin programs.

As of February 2012, this was replaced with a version of Tcl/Tk which uses Cygwin's POSIX APIs and X11 for GUI functionality. If you get a message such as this when trying to start a Tk app:

  Application initialization failed: couldn't connect to display ""

Then you need to start an X server, or if one is already running, set the DISPLAY variable to the proper value. The Cygwin distribution includes an X server; please see the Cygwin/X User Guide for installation and startup instructions.

From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation. Among the most common symptoms they report are fork failures, memory leaks, and file access denied problems. These problems, when they have been traced, often appear to be caused by interference from other software installed on the same PC. Security software, in particular, such as anti-virus, anti-spyware, and firewall applications, often implements its functions by installing hooks into various parts of the system, including both the Explorer shell and the underlying kernel. Sometimes these hooks are not implemented in an entirely transparent fashion, and cause changes in the behaviour which affect the operation of other programs, such as Cygwin.

Among the software that has been found to cause difficulties are:

Sometimes these problems can be worked around, by temporarily or partially disabling the offending software. For instance, it may be possible to disable on-access scanning in your antivirus, or configure it to ignore files under the Cygwin installation root. Often, unfortunately, this is not possible; even disabling the software may not work, since many applications that hook the operating system leave their hooks installed when disabled, and simply set them into what is intended to be a completely transparent pass-through mode. Sometimes this pass-through is not as transparent as all that, and the hooks still interfere with Cygwin; in these cases, it may be necessary to uninstall the software altogether to restore normal operation.

Some of the symptoms you may experience are:

Unfortunately, Windows does not use the fork/exec model of process creation found in UNIX-like OSes, so it is difficult for Cygwin to implement a reliable and correct fork(), which can lead to error messages such as:

Potential solutions for the above errors:

See the process creation section of the User's Guide for the technical reasons it is so difficult to make fork() work reliably.

Older Cygwin releases asked users to report problems to the mailing list with the message:

	find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer. Please report
	this problem to the public mailing list cygwin@cygwin.com

Recent Cygwin releases changed this to the message:

	This typically occurs if you're using an older Cygwin version on a newer Windows.
	Please update to the latest available Cygwin version from https://cygwin.com/.
	If the problem persists, please see https://cygwin.com/problems.html.

This is not serious, just a warning that Cygwin may not always be able to exactly emulate all aspects of Unix current directory handling under your Windows release.

Unfortunately some projects and products still distribute older Cygwin releases which may not fully support newer Windows releases, instead of installing the current release from the Cygwin project. They also may not provide any obvious way to keep the Cygwin packages their application uses up to date with fixes for security issues and upgrades.

The solution is simply downloading and running the Cygwin Setup program, following the instructions in the Internet Setup section of ``Setting Up Cygwin'' in the Cygwin User's Guide.

Please exit from all applications before running the Cygwin Setup program. When running Setup, you should not change most of the values presented, just select the Next button in most cases, as you already have a Cygwin release installed, and only want to upgrade your current installation. You should make your own selection if the internet connection to your system requires a proxy; and you must always pick an up to date Cygwin download (mirror) site, preferably the site nearest to your system for faster downloads, as shown, with more details to help you choose, on the Mirror Sites web page.

The Cygwin Setup program will download and apply upgrades to all packages required for Cygwin itself and installed applications. Any problems with applying updates, or the application after updates, should be reported to the project or product supplier for remedial action.

As Cygwin is a volunteer project, unable to provide support for older releases installed by projects or products, it would be helpful to let other users know what project or product you installed, in a quick email.

There's a C library which provides a POSIX-style API. The applications are linked with it and voila - they run on Windows.

The aim is to add all the goop necessary to make your apps run on Windows into the C library. Then your apps should (ideally) run on POSIX systems (Unix/Linux) and Windows with no changes at the source level.

The C library is in a DLL, which makes basic applications quite small. And it allows relatively easy upgrades to the Windows/POSIX translation layer, providing that DLL changes stay backward-compatible.

For a good overview of Cygwin, you may want to read the Cygwin User's Guide.

Starting December 2022, the old developer snapshots have been deprecated by regular, automated test releases. See the next FAQ entry Test Releases

Yes. Starting December 2022, regular, automated test releases are created whenever a significant patch is pushed to the Cygwin git repo at https://cygwin.com/cgit/newlib-cygwin/. You can download the cygwin package test releases just like any other test release for any Cgywin package using the Cygwin Setup program. For more info, see Install Test Releases.

Let's start with some background.

On POSIX systems, a file is a file and what the file contains is whatever the program/programmer/user told it to put into it. In Windows, a file is also a file and what the file contains depends not only on the program/programmer/user but also the file processing mode.

When processing in text mode, certain values of data are treated specially. A \n (new line, NL) written to the file will prepend a \r (carriage return, CR) so that if you `printf("Hello\n") you in fact get "Hello\r\n". Upon reading this combination, the \r is removed and the number of bytes returned by the read is 1 less than was actually read. This tends to confuse programs dependent on ftell() and fseek(). A Ctrl-Z encountered while reading a file sets the End Of File flags even though it truly isn't the end of file.

One of Cygwin's goals is to make it possible to mix Cygwin-ported POSIX programs with generic Windows programs. As a result, Cygwin allows to open files in text mode. In the accompanying tools, tools that deal with binaries (e.g. objdump) operate in POSIX binary mode and many (but not all) tools that deal with text files (e.g. bash) operate in text mode. There are also some text tools which operate in a mixed mode. They read files always in text mode, but write files in binary mode, or they write in the mode (text or binary) which is specified by the underlying mount point. For a description of mount points, see the Cygwin User's Guide.

Actually there's no really good reason to do text mode processing since it only slows down reading and writing files. Additionally many Windows applications can deal with POSIX \n line endings just fine (unfortunate exception: Notepad). So we suggest to use binary mode as much as possible and only convert files from or to DOS text mode using tools specifically created to do that job, for instance, dos2unix and unix2dos from the dos2unix package.

It is rather easy for the porter of a Unix package to fix the source code by supplying the appropriate file processing mode switches to the open/fopen functions. Treat all text files as text and treat all binary files as binary. To be specific, you can select binary mode by adding O_BINARY to the second argument of an open call, or "b" to second argument of an fopen call. You can also call setmode (fd, O_BINARY). To select text mode add O_TEXT to the second argument of an open call, or "t" to second argument of an fopen call, or just call setmode (fd, O_TEXT).

You can also avoid to change the source code at all by linking an additional object file to your executable. Cygwin provides various object files in the /usr/lib directory which, when linked to an executable, changes the default open modes of any file opened within the executed process itself. The files are

  binmode.o      - Open all files in binary mode.
  textmode.o     - Open all files in text mode.
  textreadmode.o - Open all files opened for reading in text mode.
  automode.o     - Open all files opened for reading in text mode,
                   all files opened for writing in binary mode.

Note that of the above flags only the "b" fopen flags are defined by ANSI. They exist under most flavors of Unix. However, using O_BINARY, O_TEXT, or the "t" flag is non-portable.

Yes.

There is also extensive support for 'POSIX threads', see the file cygwin.din for the list of POSIX thread functions provided.

Cygwin fork() essentially works like a non-copy on write version of fork() (like old Unix versions used to do). Because of this it can be a little slow. In most cases, you are better off using the spawn family of calls if possible.

Here's how it works:

Parent initializes a space in the Cygwin process table for child. Parent creates child suspended using Windows CreateProcess call, giving the same path it was invoked with itself. Parent calls setjmp to save its own context and then sets a pointer to this in the Cygwin shared memory area (shared among all Cygwin tasks). Parent fills in the child's .data and .bss subsections by copying from its own address space into the suspended child's address space. Parent then starts the child. Parent waits on mutex for child to get to safe point. Child starts and discovers if has been forked and then longjumps using the saved jump buffer. Child sets mutex parent is waiting on and then blocks on another mutex waiting for parent to fill in its stack and heap. Parent notices child is in safe area, copies stack and heap from itself into child, releases the mutex the child is waiting on and returns from the fork call. Child wakes from blocking on mutex, recreates any mmapped areas passed to it via shared area and then returns from fork itself.

When the executable or any dll in use by the parent was renamed or moved into the hidden recycle bin, fork retries with creating hardlinks for the old executable and any dll into per-user subdirectories in the /var/run/cygfork/ directory, when that one exists and resides on NTFS.

If the DLL thinks it was invoked from a DOS style prompt, it runs a `globber' over the arguments provided on the command line. This means that if you type LS *.EXE from DOS, it will do what you might expect.

Beware: globbing uses malloc. If your application defines malloc, that will get used. This may do horrible things to you.

Cygwin knows of five ways to create symlinks. This is really complicated stuff since we started out way back when Windows didn't know symlinks at all. The rest is history...

When working out the POSIX-style attribute bits on a file stored on certain filesystems (FAT, FAT32), the library has to fill out some information not provided by these filesystems.

It guesses that files ending in .exe and .bat are executable, as are ones which have a "#!" as their first characters. This guessing doesn't take place on filesystems providing real permission information (NTFS, NFS), unless you switch the permission handling off using the mount flag "noacl" on these filesystems.

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.

The network support in Cygwin is supposed to provide the POSIX API, not the Winsock API.

There are differences between the semantics of functions with the same name under the API.

E.g., the POSIX select system call can wait on a standard file handles and handles to sockets. The select call in Winsock can only wait on sockets. Because of this, the Cygwin dll does a lot of nasty stuff behind the scenes, trying to persuade various Winsock/Windows functions to do what a Unix select would do.

If you are porting an application which already uses Winsock, then porting the application to Cygwin means to port the application to using the POSIX net functions. You should never mix Cygwin net functions with direct calls to Winsock functions. If you use Cygwin, use the POSIX API.

You don't. Look for the Mingw-w64 project to port applications using native Windows API/Winsock functions. Cross compilers packages to build Mingw-w64 targets are available in the Cygwin distro.

Cygwin versioning is relatively complicated because of its status as a shared library. First of all, since October 1998 every Cygwin DLL has been named cygwin1.dll and has a 1 in the release name. Additionally, there are DLL major and minor numbers that correspond to the name of the release, and a release number. In other words, cygwin-2.4.1-1 is cygwin1.dll, major version 2, minor version 4, release 1. -1 is a subrelease number required by the distro versioning scheme. It's not actually part of the Cygwin DLL version number.

The cygwin1.dll major version number gets incremented only when a change is made that makes existing software incompatible. For example, the first major version 5 release, cygwin-1.5.0-1, added 64-bit file I/O operations, which required many libraries to be recompiled and relinked. The minor version changes every time we make a new backward compatible Cygwin release available. There is also a cygwin1.dll release version number. The release number is only incremented if we update an existing release in a way that does not effect the DLL (like a missing header file).

There are also Cygwin API major and minor numbers. The major number tracks important non-backward-compatible interface changes to the API. An executable linked with an earlier major number will not be compatible with the latest DLL. The minor number tracks significant API additions or changes that will not break older executables but may be required by newly compiled ones.

Then there is a shared memory region compatibility version number. It is incremented when incompatible changes are made to the shared memory region or to any named shared mutexes, semaphores, etc. For more exciting Cygwin version number details, check out the /usr/include/cygwin/version.h file.

Daylight saving (Summer time) and other time zone changes are decided on by politicians, and announced by government officials, sometimes with short or no notice, so time zone updates are released at least a few, and sometimes several, times a year. Details of changes are not known until they are announced publicly by officials, often in foreign languages. Those details then have to be noticed, possibly translated, passed to, picked up, and applied by the official tzdata source package maintainers. That information has to be compiled, checked, and released publicly in an update to the official tzdata source package. Then those changes have to be picked up and applied to the Cygwin tzdata package, which has to be updated, built, tested, and released publicly.

Time zone settings are updates to the daylight saving (Summer time) rules for dates of changes, hour offsets from UTC of time zones, and the geographic regions to which those rules and offsets apply, provided in the tzdata package included in all Cygwin installations. Have you run the Cygwin Setup program recently to update at least the tzdata package?

Are you developing applications using times which may be affected by time zones? Since the ctime(), localtime(), mktime(), and strftime() functions are required to set time zone information as if by calling tzset(), there is no need for an explicit tzset() call before using these functions. However, if none of the above functions are called first, applications should ensure tzset() is called explicitly before using any other time functions, or checking or using time zone information.

If you're using X then use the X API to handle mouse events. In a Windows console window you can enable and capture mouse events using the xterm escape sequences for mouse events.

If you are willing to be a package maintainer, great! We urgently need volunteers to prepare and maintain packages, because the priority of the Cygwin Team is Cygwin itself.

The Cygwin Package Contributor's Guide at https://cygwin.com/packages.html details everything you need to know about Cygwin packaging.

For questions about package maintenance, use the cygwin-apps mailing list (start at https://cygwin.com/lists.html) after searching and browsing the cygwin-apps list archives, of course. Be sure to look at the Submitting a package checklist at https://cygwin.com/packaging-contributors-guide.html#submitting before sending an ITP (Intent To Package) email to cygwin-apps.

You should also announce your intentions to the general cygwin list, in case others were thinking the same thing.

If you want to contribute to Cygwin itself, see https://cygwin.com/contrib.html.

By default, gcc compiles in all symbols. You'll also find that gcc creates large executables on UNIX.

If that bothers you, just use the 'strip' program, part of the binutils package. Or compile with the -s option to gcc.

The Cygwin x86_64 toolchain is using the LP64 data model. That means, in contrast to Windows, which uses an LLP64 data model, sizeof(long) != sizeof(int), just as on Linux.

For comparison:

                 Cygwin   Windows  Cygwin
                 Linux    x86_64   Linux
                 Windows           x86_64
                 i686

sizeof(int)         4        4        4
sizeof(long)        4        4        8
sizeof(size_t)      4        8        8
sizeof(void*)       4        8        8

This difference can result in interesting problems, especially when using Windows API functions using pointers to Windows datatypes like LONG, ULONG, DWORD. Given that Windows is LLP64, all of the aforementioned types are 4 byte in size, on 32 as well as on 64 bit Windows, while `long' on 64 bit Cygwin is 8 bytes.

Take the example ReadFile:

  ReadFile (HANDLE, LPVOID, DWORD, LPDWORD, LPOVERLAPPED);

In the 32 bit Cygwin and Mingw-w64 environments, as well as in the 64 bit Mingw-w64 environment, it is no problem to substitute DWORD with unsigned long:

  unsigned long number_of_bytes_read;
  [...]
  ReadFile (fhdl, buf, buflen, &number_of_bytes_read, NULL);

However, in 64 bit Cygwin, using LP64, number_of_bytes_read is 8 bytes in size. But since ReadFile expects a pointer to a 4 byte type, the function will only change the lower 4 bytes of number_of_bytes_read on return, while the content of the upper 4 bytes stays undefined.

Here are a few donts which should help porting applications from the known ILP32 data model of 32 bit Cygwin, to the LP64 data model of 64 bit Cygwin. Note that these are not Cygwin-only problems. Many Linux applications suffered the same somewhat liberal handling of datatypes when the AMD64 CPU was new.

Typically reasons for that are:

In all of this cases, please make sure to fix that upstream, or send your patches to the upstream maintainers, so the problems get fixed for the future.

There is no __CYGWIN64__ because we would like to have a unified way to handle Cygwin code in portable projects. Using __CYGWIN32__ and __CYGWIN64__ only complicates the code for no good reason. Along the same lines you won't find predefined macros __linux32__ and __linux64__ on Linux.

If you really have to differ between 32 and 64 bit in some way, you have three choices.

Cygwin does not provide glibc. It uses newlib instead, which provides much (but not all) of the same functionality. Porting glibc to Cygwin would be difficult.

Support for compiling Objective C is available in the gcc-objc package; resulting binaries will depend on the libobjc2 package at runtime.

Beware of using non-portable shell features in your Makefiles (see tips at Using Shell Scripts).

Errors of make: execvp: /bin/sh: Illegal Argument or make: execvp: /bin/sh: Argument list too long are often caused by the command-line being to long for the Windows execution model. To circumvent this, mount the path of the executable using the -X switch to enable cygexec for all executables in that folder; you will also need to exclude non-cygwin executables with the -x switch. Enabling cygexec causes cygwin executables to talk directly to one another, which increases the command-line limit. To enable cygexec for /bin and /usr/bin, you can add or change these entries in /etc/fstab:

C:/cygwin/bin /bin ntfs binary,cygexec 0 0
C:/cygwin/bin /usr/bin ntfs binary,cygexec 0 0

If you have added other non-Cygwin programs to a path you want to mount cygexec, you can find them with a script like this:

#!/bin/sh
cd /bin; for f in `find . -type f -name '*.exe'`; do
	cygcheck $f | (grep -Fqi cygwin1.dll || echo $f)
done

See https://cygwin.com/cygwin-ug-net/using.html#mount-table for more information on using mount.

Try running cygserver. Read https://cygwin.com/cygwin-ug-net/using-cygserver.html. If you're trying to use PostgreSQL, also read /usr/share/doc/Cygwin/postgresql-*.README.

If you're using gcc, try adding an empty main() function to one of your sources. Or, perhaps you have -lm too early in the link command line. It should be at the end:

    bash$ gcc hello.c -lm
    bash$ ./a.exe
    Hello World!

works, but

    bash$  gcc -lm hello.c
    /c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main'
    /usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here
    /usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@16'
    collect2: ld returned 1 exit status

If you're using GCJ, you need to pass a "--main" flag:

gcj --main=Hello Hello.java

Cygwin tools require that you explicitly link the import libraries for whatever Windows API functions that you are going to use, with the exception of kernel32, which is linked automatically (because the startup and/or built-in code uses it).

For example, to use graphics functions (GDI) you must link with gdi32 like this:

gcc -o foo.exe foo.o bar.o -lgdi32

or (compiling and linking in one step):

gcc -o foo.exe foo.c bar.c -lgdi32

The regular setup allows you to use the option -mwindows on the command line to include a set of the basic libraries (and also make your program a GUI program instead of a console program), including user32, gdi32 and comdlg32.

It is a good idea to put import libraries last on your link line, or at least after all the object files and static libraries that reference them.

The compilers provided by the mingw64-i686-gcc and mingw64-x86_64-gcc packages link against standard Microsoft DLLs instead of Cygwin. This is desirable for native Windows programs that don't need a UNIX emulation layer.

No. If your program uses the Cygwin API, then your executable cannot run without cygwin1.dll. In particular, it is not possible to statically link with a Cygwin library to obtain an independent, self-contained executable.

If this is an issue because you intend to distribute your Cygwin application, then you had better read and understand https://cygwin.com/licensing.html, which explains the licensing options.

No, you must use one or the other, they are mutually exclusive.

The default during compilation is to produce a console application. It you are writing a GUI program, you should either compile with -mwindows as explained above, or add the string "-Wl,--subsystem,windows" to the GCC command line.

This problem usually occurs as a result of someone editing a Makefile with a text editor that replaces tab characters with spaces. Command lines must start with tabs. This is not specific to Cygwin.

Subsection 2.d.f of the `Microsoft Open Tools License agreement' looks like it says that one may not "permit further redistribution of the Redistributables to their end users". We take this to mean that we can give them to you, but you can't give them to anyone else, which is something that we can't agree to. Fortunately, we have our own Windows API headers which are pretty complete.

If you want to load the DLL dynamically, read winsup/cygwin/how-cygtls-works.txt and the sample code in winsup/testsuite/cygload to understand how this works. The short version is:

If you want to link statically from Visual Studio, to my knowledge none of the Cygwin developers have done this, but we have this report from the mailing list that it can be done this way:

Note that if you are using any other Cygwin based libraries that you will probably need to build them as DLLs using gcc and then generate import libraries for the MS VC linker.

Thanks to Alastair Growcott (alastair dot growcott at bakbone dot co dot uk) for this tip.

If your .lib file is a normal static or import library with C-callable entry points, you can list foo.lib as an object file for gcc/g++, just like any *.o file. Otherwise, here are some steps:

or

You can use these methods to use MSVC (and many other runtime libs) with Cygwin development tools.

Note that this is a lot of work (half a day or so), but much less than rewriting the runtime library in question from specs...

Thanks to Jacob Navia (root at jacob dot remcomp dot fr) for this explanation.

First, you need to make sure you have the necessary build tools installed; you at least need gcc-g++, make, automake, autoconf, git, perl, cocom and patch.

Additionally, building the dumper utility requires gettext-devel, libiconv-devel, libzstd-devel and zlib-devel. Building this program can be disabled with the --disable-dumper option to configure.

Building those Cygwin utilities which are not themselves Cygwin programs (e.g. cygcheck and strace) also requires mingw64-x86_64-gcc-g++ and mingw64-x86_64-zlib. Building these programs can be disabled with the --without-cross-bootstrap option to configure.

Building the documentation also requires the dblatex, docbook2X, docbook-xml45, docbook-xsl, and xmlto packages. Building the documentation can be disabled with the --disable-doc option to configure.

Next, check out the Cygwin sources from the Cygwin GIT source repository). This is the preferred method for acquiring the sources. Otherwise, if you are trying to duplicate a cygwin release then you should download the corresponding source package (cygwin-x.y.z-n-src.tar.bz2).

You must build cygwin in a separate directory from the source, so create something like a build/ directory. Assuming you checked out the source to /oss/src/newlib-cygwin/, and you want to install to the temporary location /oss/install/, these are the required steps to build Cygwin:

$ mkdir -p /oss/src/newlib-cygwin/build    # create build dir
$ mkdir -p /oss/install                    # create install dir
$ cd /oss/src/newlib-cygwin/winsup         # chdir into Cygwin source dir and...
$ ./autogen.sh                             # create config files
$ cd /oss/src/newlib-cygwin/build          # chdir into build dir
$                                          # create makefiles...
$ /oss/src/newlib-cygwin/configure --prefix=/oss/install
$ make                                     # build Cygwin
$ make install                             # install Cygwin into install dir

If the build worked, you can install everything you like into the currently running system, except the Cygwin DLL cygwin1.dll itself. For installing the DLL, close down all Cygwin programs (including bash windows, any servers like cygserver, etc.), save your old dll, and copy the new dll to the correct place. Then, for first testing, start up a Cygwin program from the Windows command prompt and see what happens.

If you get a lengthy error messages like "user shared memory version mismatch detected", it's very likely a Cygwin process still running using the old DLL. Kill it in Windows' Task Manager or taskkill and try again. If it's still not working, and if you're sure there's no older Cygwin process still running, it's probably a bug you introduced with your changes. From here on, you're on your own or discuss problems on the Cygwin-developers mailing list.

Debugging symbols are stripped from distibuted Cygwin binaries, so to debug with gdb you will need to install the cygwin-debuginfo package to obtain the debug symbols for cygwin1.dll

If your bug causes an exception inside cygwin1.dll you will need to use the gdb command set cygwin-exceptions on to tell gdb to stop on exceptions inside the Cygwin DLL (by default they are ignored, as they may be generated during normal operation e.g. when checking a pointer is valid)

It is also a good idea to use the latest code in case the bug has been fixed, so we recommend trying the latest cygwin test release (see Install Test Releases) or building the DLL from git.

To build a debugging version of the Cygwin DLL, you will need to follow the instructions at Build Cygwin.

You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome).

Unfortunately, this will be difficult. Exception handling and signals support semantics and args have been designed for x86_64 so you would need to write specific support for your platform. We don't know of any other incompatibilities. Please send us patches if you do this work!

If you need to change the maximum amount of memory available to Cygwin, see https://cygwin.com/cygwin-ug-net/setup-maxmem.html. Otherwise, just pass heap/stack linker arguments to gcc. To create foo.exe with a heap size of 200MB and a stack size of 8MB, you would invoke gcc as:

gcc -Wl,--heap,200000000,--stack,8000000 -o foo foo.c

objdump -p provides this information, but is rather verbose.

cygcheck will do this much more concisely, and operates recursively, provided the command is in your path.

There's documentation that explains the process in the Cygwin User's Guide here: https://cygwin.com/cygwin-ug-net/dll.html.

Set a breakpoint in gdb with b *0x401000 (for i686), or b *0x100401000 (for x86_64).

This entrypoint address can be computed as the sum of the ImageBase and AddressOfEntryPoint values given by objdump -p.

Note that the DllMain entrypoints for linked DLLs will have been executed before this breakpoint is hit.

(It may be necessary to use the gdb command set disable-randomization on to turn off ASLR for the debuggee to prevent the base address getting randomized.)

You can debug your application using gdb. Make sure you compile it with the -g flag! If your application calls functions in MS DLLs, gdb will complain about not being able to load debug information for them when you run your program. This is normal since these DLLs don't contain debugging information (and even if they did, that debug info would not be compatible with gdb).

Yes. You can use the strace.exe utility to run other cygwin programs with various debug and trace messages enabled. For information on using strace, see the Cygwin User's Guide.

gdb maps known Windows exceptions to signals such as SIGSEGV, SIGFPE, SIGTRAP, SIGINT and SIGILL. Other Windows exceptions are passed on to the handler (if any), and reported as an unknown signal if an unhandled (second chance) exception occurs.

There is also an experimental feature to notify gdb of purely Cygwin signals like SIGABRT, SIGHUP or SIGUSR1. This currently has some known problems, for example, single-stepping from these signals may not work as expected.

A common error is to put the library on the command line before the thing that needs things from it.

This is wrong gcc -lstdc++ hello.cc. This is right gcc hello.cc -lstdc++.

The first command above (usually) works on Linux, because:

Note that this won't work if the linker flags --as-needed or --no-undefined are used, or if the library being linked with is a static library.

PE/COFF executables work very differently, and the dynamic library which provides a symbol must be fully resolved at link time (so the library which provides a symbol must follow a reference to it).

See point 3 in Q: 6.40 for more discussion of how this affects plugins.

This also has consequences for how weak symbols are resolved. See https://cygwin.com/ml/cygwin/2010-04/msg00281.html for more discussion of that.

struct stat64 is not used in Cygwin, just use struct stat. It's 64 bit aware.

Yes.

It exists, but you should rather include stdlib.h instead of malloc.h. stdlib.h is POSIX standard for defining malloc and friends, malloc.h is definitely non-standard.

If you define a function called malloc in your own code, and link with the DLL, the DLL will call your malloc. Needless to say, you will run into serious problems if your malloc is buggy.

If you run any programs from the DOS command prompt, rather than from in bash, the DLL will try and expand the wildcards on the command line. This process uses malloc before your main line is started. If you have written your own malloc to need some initialization to occur after main is called, then this will surely break.

Moreover, there is an outstanding issue with _malloc_r in newlib. This re-entrant version of malloc will be called directly from within newlib, by-passing your custom version, and is probably incompatible with it. But it may not be possible to replace _malloc_r too, because cygwin1.dll does not export it and Cygwin does not expect your program to replace it. This is really a newlib issue, but we are open to suggestions on how to deal with it.

Yes, but only if you are combining C object files. MSVC C++ uses a different mangling scheme than GNU C++, so you will have difficulties combining C++ objects.

No, not for full (high level source language) debugging. The Microsoft compilers generate a different type of debugging symbol information, which gdb does not understand.

However, the low-level (assembly-type) symbols generated by Microsoft compilers are coff, which gdb DOES understand. Therefore you should at least be able to see all of your global symbols; you just won't have any information about data types, line numbers, local variables etc.

If your scripts are in the current directory, you must have . (dot) in your $PATH. (It is not normally there by default.) Better yet, add /bin/sh in front of each and every shell script invoked in your Makefiles.

gcc for Cygwin defines __CYGWIN__ when building for a Cygwin environment.

Microsoft defines the preprocessor symbol _WIN32 in their Windows development environment.

In gcc for Cygwin, _WIN32 is only defined when you use the -mwin32 gcc command line options. This is because Cygwin is supposed to be a POSIX emulation environment in the first place and defining _WIN32 confuses some programs which think that they have to make special concessions for a Windows environment which Cygwin handles automatically.

Check out the predefined symbols in detail by running, for example

       $ gcc  -dM -E -xc /dev/null >gcc.txt
       $ gcc -mwin32 -dM -E -xc /dev/null >gcc-mwin32.txt

Then use the diff and grep utilities to check what the difference is.

Like other Unix-like platforms, the Cygwin distribution includes many of the common GUI toolkits, including X11, X Athena widgets, Motif, Tk, GTK+, and Qt. Many programs which rely on these toolkits will work with little, if any, porting work if they are otherwise portable. However, there are a few things to look out for:

Please see https://cygwin.com/licensing.html for more information about Cygwin copyright and licensing.