About Cygwin 1.1. 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.

SmartPCFixer™ is a fully featured and easy-to-use system optimization suite. With it, you can clean windows registry, remove cache files, fix errors, defrag disk.

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. What versions of Windows are supported? Cygwin can be expected to run on all modern, released versions of Windows. State January 2016 this includes Windows Vista, Windows Server 2008 and all later versions of Windows up to Windows 10 and Windows Server 2016. The 32 bit version of Cygwin also runs in the WOW64 32 bit environment on released 64 bit versions of Windows, the 64 bit version of course only on 64 bit Windows.

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. Where can I get it? The home page for the Cygwin project is. 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. Is it free software? 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.

What version of Cygwin is this, anyway? To find the version of the Cygwin DLL installed, you can use uname as on Linux or cygcheck. Refer to each command's --help output and the 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. The packages in Cygwin are continually improving, thanks to the efforts of net volunteers who maintain the Cygwin binary 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? Just download the Cygwin Setup program by following the 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.exe, see in the Cygwin User's Guide. Who's behind the project?

(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. Corinna is a senior Red Hat engineer. Corinna is responsible for the Cygwin library and maintains a couple of packages, for instance OpenSSH, OpenSSL, and a lot more.

Yaakov Selkowitz is another Red Hat engineer working on the Cygwin project. He's the guy behind the current build and packaging system and maintains by far the most packages in the Cygwin distribution. Jon Turney is developer and maintainer of the Cygwin X server and a couple of related packages. The packages in the Net release are maintained by a large group of people; a complete list can be found. Please note that all of us working 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 Net releases of the Win32 tools and helping people on the Net out is not our primary job function, 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! Setting up Cygwin 2.1. What is the recommended installation procedure? There is only one recommended way to install Cygwin, which is to use the GUI installer setup-*.exe.

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 on using Cygwin Setup may be found. 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 development snapshot at, then by all means report it to the mailing list. For a searchable list of packages that can be installed with Cygwin, see.

What about an automated Cygwin installation? 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 Cygwin Setup 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. Does Setup accept command-line arguments? Yes, run setup-x86.exe --help or setup-x86_64.exe --help for a list.

--allow-unsupported-windows Allow old, unsupported Windows versions -a --arch architecture to install (x86_64 or x86) -C --categories Specify entire categories to install -o --delete-orphans remove orphaned packages -A --disable-buggy-antivirus Disable known or suspected buggy anti virus software packages during execution. -D --download Download from internet -f --force-current select the current version for all packages -h --help print help -I --include-source Automatically include source download -i --ini-basename Use a different basename, e.g. 'foo', instead of 'setup' -U --keep-untrusted-keys Use untrusted keys and retain all -L --local-install Install from local directory -l --local-package-dir Local package directory -m --mirror-mode Skip 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.

• Download setup-x86.exe or setup-x86_64.exe and scan it explicitly. • Turn off the anti-virus software. • Run setup to download and extract all the tar files. • Re-activate your anti-virus software and scan everything in C: cygwin (or wherever you chose to install), or your entire hard disk if you are paranoid. This should be safe, but only if Cygwin Setup is not substituted by something malicious. See also for a description of how the Cygwin project counters man-in-the-middle (MITM) attacks. See also for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin.

What packages should I download? Where are 'make', 'gcc', 'vi', etc? When using Cygwin Setup 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 for a searchable list of available packages, or use cygcheck -p as described in the Cygwin User's Guide. 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'. How do I just get everything? 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.

Cygwin Setup is designed to make it easy to browse categories and select what you want to install or omit from those categories. It's also easy to install everything. • At the ``Select Packages' screen, in ``Categories' view, at the line marked ``All', click on the word ``default' so that it changes to ``install'.

(Be patient, there is some computing to do at this step. It may take a second or two to register the change.) This tells Setup to install everything, not just what it thinks you should have by default. • Now click on the ``View' button (twice) until you get to the ``Pending' view. This shows exactly which packages are about to be downloaded and installed. This procedure only works for packages that are currently available. There is no way to tell Cygwin Setup to install all packages by default from now on.

As new packages become available that would not be installed by default, you have to repeat the above procedure to get them. In general, a better method (in my opinion), is to. • If HOME is set in the Windows environment, translated to POSIX form. • Otherwise, use the pw_home field from the passwd entry as returned by getent passwd. If you want to learn how this field is set by Cygwin and how you can change it, this is explained in great detail in the Cygwin User's Guide. 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. How do I uninstall individual packages? Run Cygwin Setup as you would to install packages. In the list of packages to install, browse the relevant category or click on the ``View' button to get a full listing. Click on the cycle glyph until the action reads ``Uninstall'.

Proceed by clicking ``Next'. How do I uninstall a Cygwin service? • List all services you have installed with cygrunsrv -L.

If you do not have cygrunsrv installed, skip this FAQ. • Before removing the service, you should stop it with cygrunsrv --stop service_name. If you have inetd configured to run as a standalone service, it will not show up in the list, but cygrunsrv --stop inetd will work to stop it as well. • Lastly, remove the service with cygrunsrv --remove service_name.

How do I uninstall all of Cygwin? Setup has no automatic uninstall facility.

The recommended method to remove all of Cygwin is as follows. • One common cause of slow Cygwin Terminal starts is a bad DNS setup. This particularly affects AD clients, but there may be other things in your Cygwin startup that depend on getting fast answers back from a network server. Keep in mind that this may affect Cygwin even when the domain controller is on the same machine as Cygwin, or is on a nearby server. A bad DNS server IP can cause long delays while the local TCP/IP stack times out on a connection to a server that simply isn't there, for example. • Another cause for AD client system is slow DC replies, commonly observed in configurations with remote DC access. The Cygwin DLL queries information about every group you're in to populate the local cache on startup.

You may speed up this process a little by caching your own information in local files. Run these commands in a Cygwin terminal with write access to /etc: getent passwd $(id -u) >/etc/passwd getent group $(id -G) >/etc/group Also, set /etc/nsswitch.conf as follows: passwd: files db group: files db This will limit the need for Cygwin to contact the AD domain controller (DC) while still allowing for additional information to be retrieved from DC, such as when listing remote directories. • Either in addition to the previous item or instead of it, you can run as a local caching service to speed up DC requests. Cygwin programs will check with cygserver before trying to query the DC directly. • A less preferable option is to create a static read-only cache of the authentication data.

This is the old-fashioned method of making Cygwin integrate with AD, the only method available in releases before 1.7.34. To do this, run mkpasswd and mkgroup, then put the following into /etc/nsswitch.conf to make Cygwin treat these files as the only sources of user and group information: passwd: files group: files By leaving out the db option, we are telling the Cygwin DLL not to even try to do AD lookups. If your AD servers are slow, this local cache will speed things up. The downside is that you open yourself up to the: any time the AD databases change, your local cache will go out of date until you update the files manually. 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. Why is Cygwin suddenly so slow? 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. Why can't my services access network shares? 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. 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). How should I set my PATH? 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 setup.exe. 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. Bash (or another shell) says 'command not found', but it's right there! 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. 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! How do I convert between Windows and UNIX paths?

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. Why doesn't bash read my.bashrc file on startup? 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. How can I get bash filename completion to be case insensitive? Add the following to your ~/.bashrc file: shopt -s nocaseglob and add the following to your ~/.inputrc file: set completion-ignore-case on 4.10.

Can I use paths/filenames containing spaces in them? 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 4.11. Why can't I cd into a shortcut to a directory?

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. I'm having basic problems with find.

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. Directories on some filesystems, such as DVD-R UDF, can confuse find.

See the documentation for the option -noleaf in the man page. Why doesn't su work? 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 and related messages. Why doesn't man -k, apropos or whatis work?

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). Why doesn't chmod work? 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 for more information on how Cygwin maps Windows permissions. Why doesn't my shell script work? 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. How do I print under Cygwin?

Lpr is available in the cygutils package. Some 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).

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. Why don't international (Unicode) characters work?

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 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. My application prints international characters but I only see gray boxes 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. Is it OK to have multiple copies of the DLL? 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, 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 setup.exe.

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). I read the above but I want to bundle Cygwin with a product, and ship it to customer sites.

How can I do this without conflicting with any Cygwin installed by the user? 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) 4.22. Can I bundle Cygwin with my product for free?

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. But doesn't that mean that if some application installs an older Cygwin DLL on top of a newer DLL, my application will break?

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 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. Why isn't package XYZ available in Cygwin? 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? Why is the Cygwin package of XYZ so out of date? (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'.

How can I access other drives? 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:/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 for more details. How can I copy and paste into Cygwin console windows? 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 4.28. What firewall should I use with Cygwin? 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 for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin. How can I share files between Unix and Windows? 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. Is Cygwin case-sensitive??

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. What about DOS special filenames? 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 for a detailed description of what's possible with filenames and what is not.

When it hangs, how do I get it back? 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 the weird directory structure? 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 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?) 4.34. How do anti-virus programs like Cygwin? 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 for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin. Is there a Cygwin port of GNU Emacs? 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 () GUI, install the emacs-X11 package.

In either case, you run emacs by typing 'emacs' or '/usr/bin/emacs'. Is there a Cygwin port of XEmacs? It can be used in three different modes. • xemacs-sumo - XEmacs standard packages • xemacs-mule-sumo - XEmacs MULE (MUlti Lingual Emacs) packages 4.37. Why don't some of my old symlinks work anymore? 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. Why don't symlinks work on Samba-mounted filesystems? Symlinks are marked with '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' 4.39. How do I setup sshd in a domain?

If you want to be able to logon with domain accounts to a domain member machine, you should make sure that the 'cyg_server' account under which the sshd service is usually running, is a domain account. Otherwise you might end up with weird problems. For instance, sshd might fail to load the child process when trying to login with a domain account. A potential, confirmed error message is *** fatal error - unable to load user32.dll, Win32 error 1114 Here's how you set up a sshd with a domain service account. First of all, create a new domain account called 'cyg_server'.

This account must be an administrative account, so make sure it's in the 'Administrators' group. Now create a domain policy which is propagated to all machines which are supposed to run an sshd service. This domain policy should give the following user rights to the 'cyg_server' account: Act as part of the operating system (SeTcbPrivilege) Create a token object (SeCreateTokenPrivilege) Replace a process level token (SeAssignPrimaryTokenPrivilege) Now to install sshd on the member machine, logon to that machine as an admin. Make sure the aforementioend global policy has been propagated to this machine. Examine the Local Security Policy settings and, if necessary, call gpupdate. If everything looks ok, run bash.

Starting with Windows Vista, make sure you're running bash elevated. Then run ssh-host-config. Answer all questions so that 'cyg_server' is used to run the service. When done, check ownership of /var/empty and all /etc/ssh* files. All of them must be owned by 'cyg_server'. If that's ok, you're usually all set and you can start the sshd service via $ cygrunsrv -S sshd or $ net start sshd 4.40.

Why does public key authentication with ssh fail after updating to Cygwin 1.7.34 or later? 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. • Random fork() failures Caused by hook DLLs that load themselves into every process in the system. POSIX fork() semantics require that the memory map of the child process must be an exact duplicate of the parent process' layout. If one of these DLLs loads itself at a different base address in the child's memory space as compared to the address it was loaded at in the parent, it can end up taking the space that belonged to a different DLL in the parent. When Cygwin can't load the original DLL at that same address in the child, the fork() call has to fail. • File access problems Some programs (e.g., virus scanners with on-access scanning) scan or otherwise operate on every file accessed by all the other software running on your computer.

In some cases they may retain an open handle on the file even after the software that is really using the file has closed it. This has been known to cause operations such as deletes, renames and moves to fail with access denied errors. In extreme cases it has been known for scanners to leak file handles, leading to kernel memory starvation. • Networking issues Firewall software sometimes gets a bit funny about Cygwin. It's not currently understood why; Cygwin only uses the standard Winsock2 API, but perhaps in some less-commonly used fashion that doesn't get as well tested by the publishers of firewalls. Symptoms include mysterious failures to connect, or corruption of network data being sent or received.

• Memory and/or handle leaks Some applications that hook into the Windows operating system exhibit bugs when interacting with Cygwin that cause them to leak allocated memory or other system resources. Symptoms include complaints about out-of-memory errors and even virtual memory exhaustion dialog boxes from the O/S; it is often possible to see the excess memory allocation using a tool such as Task Manager or Sysinternals' Process Explorer, although interpreting the statistics they present is not always straightforward owing to complications such as virtual memory paging and file caching.

How do I fix fork() failures? 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. • Restart whatever process is trying (and failing) to use fork(). Sometimes Windows sets up a process environment that is even more hostile to fork() than usual. • Ensure that you have eliminated (not just disabled) all software on the. • Switch from 32-bit Cygwin to 64-bit Cygwin, if your OS and CPU support that.

With the bigger address space fork() is less likely to fail. • Try setting the environment variable CYGWIN to 'detect_bloda', which enables some extra debugging, which may indicate what other software is causing the problem. See for more information. • Force a full rebase: Run rebase-trigger fullrebase, exit all Cygwin programs and run Cygwin setup.

By default, Cygwin's setup program automatically performs an incremental rebase of newly installed files. Forcing a full rebase causes the rebase map to be cleared before doing the rebase. See /usr/share/doc/rebase/README and /usr/share/doc/Cygwin/_autorebase.README for more details. Please note that installing new packages or updating existing ones undoes the effects of rebase and often causes fork() failures to reappear. See the section of the User's Guide for the technical reasons it is so difficult to make fork() work reliably. How do I fix find_fast_cwd warnings? 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 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. If the problem persists, please see. 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 Cygwin Setup, following the instructions in the Internet Setup section of in the Cygwin User's Guide.

Please exit from all applications before running Cygwin Setup. 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 web page. Cygwin Setup 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.

Cygwin API Questions 5.1. How does everything work? 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 Win32/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. Are development snapshots for the Cygwin library available? They're made whenever anything interesting happens inside the Cygwin library (usually roughly on a nightly basis, depending on how much is going on).

They are only intended for those people who wish to contribute code to the project. If you aren't going to be happy debugging problems in a buggy snapshot, avoid these and wait for a real release. The snapshots are available from. How is the DOS/Unix CR/LF thing handled? 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, d2u and u2d from the cygutils 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 Linking against these object files does not change the open mode of files propagated to a process by its parent process, for instance, if the process is part of a shell pipe expression.

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.

Is the Cygwin library multi-thread-safe? There is also extensive support for 'POSIX threads', see the file cygwin.din for the list of POSIX thread functions provided.

How is fork() implemented? 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 Win32 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. How does wildcarding (globbing) work?

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. How do symbolic links work?

Cygwin knows of two ways to create symlinks. The default method generates link files with a magic header. When you open a file or directory that is a link to somewhere else, it opens the file or directory listed in the magic header. Because we don't want to have to open every referenced file to check symlink status, Cygwin marks symlinks with the system attribute. Files without the system attribute are not checked. Because remote samba filesystems do not enable the system attribute by default, symlinks do not work on network drives unless you explicitly enable this attribute or use the second method to create symlinks.

The second method is enabled if `winsymlinks' is set in the environment variable CYGWIN. Using this method, Cygwin generates symlinks by creating Windows shortcuts. Cygwin created shortcuts have a special header (which is in that way never created by Explorer) and the R/O attribute set. A DOS path is stored in the shortcut as usual and the description entry is used to store the POSIX path. While the POSIX path is stored as is, the DOS path has perhaps to be rearranged to result in a valid path.

This may result in a divergence between the DOS and the POSIX path when symlinks are moved crossing mount points. When a user changes the shortcut, this will be detected by Cygwin and it will only use the DOS path then.

While Cygwin shortcuts are shown without the '.lnk' suffix in `ls' output, non-Cygwin shortcuts are shown with the suffix. However, both are treated as symlinks. Both, types of symlinks can live peacefully together since Cygwin treats both as symlinks regardless of the setting of `(no)winsymlinks' in the environment variable CYGWIN. Why do some files, which are not executables have the 'x' type. 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.

How secure is Cygwin in a multi-user environment? 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. How do the net-related functions work? 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/Win32 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. I don't want Unix sockets, how do I use normal Win32 winsock? Look for the Mingw-w64 project to port applications using native Win32/Winsock functions. Cross compilers packages to build Mingw-w64 targets are available in the Cygwin distro. What version numbers are associated with Cygwin? 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. Why isn't timezone set correctly?

(Please note: This section has not yet been updated for the latest net release.) Did you explicitly call tzset() before checking the value of timezone? If not, you must do so. Is there a mouse interface?

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.

Programming Questions 6.1. How do I contribute a package? 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 details everything you need to know about Cygwin packaging. For questions about package maintenance, use the cygwin-apps mailing list (start at ) after searching and browsing the cygwin-apps list archives, of course. Be sure to look at the Submitting a package checklist at 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. How do I contribute to Cygwin?

If you want to contribute to Cygwin itself, see. Why are compiled executables so huge?!? 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. What do I have to look out for when porting applications to 64 bit Cygwin? The Cygwin x86_64 toolchain is using the data model. That means, in contrast to Windows, which uses an 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 Win32 functions, especially when 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. NoteUsing -Wall (optionally with -Werror to drive the point home) makes a lot of sense in general, not only when porting code to a new platform. • Don't mix int and long pointers.

Long *long_ptr = (long *) &my_int; /* Uh oh! */ *long_ptr = 42; The assignment will write 8 bytes to the address of my_int. Since my_int is only 4 bytes, something else gets randomly overwritten. Finding this kind of bug is very hard, because you will often see a problem which has no immediate connection to the actual bug. • Don't mix int and pointers at all! This will not work as expected anymore: void *ptr; printf ('Pointer value is%x n', ptr);%x denotes an int argument. The value printed by printf is a 4 byte value, so on x86_64 the printed pointer value is missing its upper 4 bytes; the output is very likely wrong.

Use%p instead, which portable across architectures: void *ptr; printf ('Pointer value is%p n', ptr); • Along the same lines don't use the type int in pointer arithmetic. Don't cast pointers to int, don't cast pointer differences to int, and don't store pointer differences in an int type. Use the types intptr_t, uintptr_t and ptrdiff_t instead, they are designed for performing architecture-independent pointer arithmetic. • Don't make blind assumptions about the size of a POSIX type. For instance, time_t is 8 bytes on 64 bit Cygwin, while it is (still, at the time of writing this) 4 bytes on 32 bit Cygwin, since time_t is based on the type long.

• Don't use functions returning pointers without declaration. For instance printf ('Error message is:%s n', strerror (errno)); This code will crash, unless you included string.h. The implicit rule in C is that an undeclared function is of type int. But int is 4 byte and pointers are 8 byte, so the string pointer given to printf is missing the upper 4 bytes. • Don't use C base types together with Win32 functions.

Keep in mind that DWORD, LONG, ULONG are not the same as long and unsigned long. Try to use only Win32 datatypes in conjunction with Win32 API function calls to avoid type problems. See the above ReadFile example. Windows functions in printf calls should be treated carefully as well. This code is common for 32 bit code, but probably prints the wrong value on 64 bit: printf ('Error message is:%lu n', GetLastError ()); Using gcc's -Wformat option would warn about this. Casting to the requested base type helps in this case: printf ('Error message is:%lu n', (unsigned long) GetLastError ()); • Don't mix Windows datatypes with POSIX type-specific MIN/MAX values.

Unsigned long l_max = ULONG_MAX; /* That's right. */ ULONG w32_biggest = ULONG_MAX;/* Hey, wait! */ ULONG w32_biggest = UINT_MAX;/* Ok, but borderline. */ Again, keep in mind that ULONG (or DWORD) is not unsigned long but rather unsigned int on 64 bit. My project doesn't build at all on 64 bit Cygwin.

Typically reasons for that are. Note There are a few restrictions for calls to the Win32 API. Dj Drama Oh My Instrumental Free Download. For details, see the User's Guide section, as well as the User's Guide section. How do I compile a Win32 executable that doesn't use Cygwin?

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. Can I build a Cygwin program that does not require cygwin1.dll at runtime? 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, which explains the licensing options. Can I link with both MSVCRT*.DLL and cygwin1.dll? No, you must use one or the other, they are mutually exclusive. How do I make the console window go away? 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. Why does make complain about a 'missing separator'?

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. Why can't we redistribute Microsoft's Win32 headers? 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 Win32 headers which are pretty complete. How do I use cygwin1.dll with Visual Studio or Mingw-w64? 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. • Extract all the object files from the.lib using LIB.EXE. • Build a dummy C file referencing all the functions you need, either with a direct call or through an initialized function pointer. • Build a dummy LibMain. • Link all the objects with this file+LibMain. • Write a.def.

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. How do I build Cygwin on my own? First, you need to make sure you have the necessary build tools installed; you at least need gcc-g++, make, perl, cocom, gettext-devel, libiconv-devel and zlib-devel. Building for 32-bit Cygwin also requires mingw64-x86_64-gcc-core (for building the cyglsa64 DLL for WoW64), mingw64-i686-gcc-g++ and mingw64-i686-zlib.

Building for 64-bit Cygwin also requires mingw64-x86_64-gcc-g++ and mingw64-x86_64-zlib. If you want to run the tests, dejagnu is also required. Normally, building ignores any errors in building the documentation, which requires the dblatex, docbook2X, docbook-xml45, docbook-xsl, and xmlto packages. For more information on building the documentation, see the README included in the cygwin-doc package. Next, get the Cygwin source.

Ideally, you should check out what you need from Git (). 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 in /oss/src/, and you also want to install to the temporary location install: mkdir /oss/build mkdir /oss/install cd build (/oss/src/configure --prefix=/oss/install -v; make) >& make.out make install >install.log 2>&1 If the build works, install everything except the dll (if you can). Then, close down all cygwin programs (including bash windows, inetd, etc.), save your old dll, and copy the new dll to the correct place. Then start up a bash window, or run a cygwin program from the Windows command prompt, and see what happens. If you get the error 'shared region is corrupted' it means that two different versions of cygwin1.dll are running on your machine at the same time. Remove all but one. I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)?

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 snapshot from or building the DLL from git.

To build a debugging version of the Cygwin DLL, you will need to follow the instructions. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). How can I compile Cygwin for an unsupported platform (PowerPC, Alpha, ARM, Itanium)?

Unfortunately, this will be difficult. Exception handling and signals support semantics and args have been designed for x86 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! How can I adjust the heap/stack size of an application? If you need to change the maximum amount of memory available to Cygwin, see.

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 6.25.

How can I find out which DLLs are needed by an executable? 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. How do I build a DLL?

There's documentation that explains the process in the Cygwin User's Guide here:. How can I set a breakpoint at mainCRTStartup? 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. How can I debug what's going on? 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).

Can I use a system trace mechanism instead? 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. How does gdb handle signals? 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. The linker complains that it can't find something. 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++. Why do I get an error using struct stat64?

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

Can you make DLLs that are linked against libc? Where is malloc.h?

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. Can I use my own malloc? 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. Can I mix objects compiled with msvc++ and gcc? 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.

Can I use the gdb debugger to debug programs built by VC++? 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. Shell scripts aren't running properly from my makefiles? 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.

What preprocessor macros do I need to know about? 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. How should I port my Unix GUI to Windows?

Like other Unix-like platforms, the Cygwin distribtion 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. • Some packages written for both Windows and X11 incorrectly treat Cygwin as a Windows platform rather than a Unix variant. Mixing Cygwin's Unix APIs with Windows' GDI is best avoided; rather, remove these assumptions so that Cygwin is treated like other X11 platforms. • GTK+ programs which use gtk_builder_connect_signals() or glade_xml_signal_autoconnect() need to be able to dlopen() themselves. In order for this to work, the program must be linked with the -Wl,--export-all-symbols linker flag.

This can be added to LDFLAGS manually, or handled automatically with the -export-dynamic libtool flag (requires libtool 2.2.8) or by adding gmodule-export-2.0 to the pkg-config modules used to build the package. • Programs which include their own loadable modules (plugins) often must have its modules linked against the symbols in the program. The most portable solution is for such programs to provide all its symbols (except for main()) in a shared library, against which the plugins can be linked. Otherwise, the symbols from the executable itself must be exported. If the package uses the CMake build system, this can be done by adding ENABLE_EXPORTS TRUE to the executable's set_target_properties command, then adding the executable's target name to the target_link_libraries command for the plugins.

For other build systems, the following steps are required.

A full Cygwin installation can range from 21 to 105 GiB, depending on how you define 'full.' Your 100 MB number tells me that you just clicked through the defaults presented by Cygwin's setup-*.exe program, selecting no optional packages, because that installs only the Base package set, which currently amounts to 100 MiB. Cygwin follows the modern net-connected software distribution model: it assumes you can just run setup-*.exe again and select new packages as you need them.

It's normal to start with that 0.1 GiB base installation, then add packages as you need them. The Cygwin maintainers try to keep the Base category's package set as small as practical.¹ A Cygwin Base install gives you something much like an old-style Unix installation, covering little more than. So How Do You Get a Full Installation? The Cygwin installer does not have an obvious way to get a 'full' installation, on purpose, because no one needs literally every package in the Cygwin repository.² There is, however, a sneaky way to install everything.

At the package selection screen.click the 'Default' text to the right of the 'All' group header. It will change to 'Install,' as will the corresponding text in all of the groups underneath it. This marks everything for installation.

I include this tip for completeness only. You do not want to do this! It will install gigs and gigs of stuff you will never use.

Currently, there are 9951 in Cygwin,³ and installing every last one of them takes 83.4 GiB of disk space for the installation tree plus 21.3 GiB for the download tree.⁴ That gives the 105 GiB upper limit above. All that unused software carries several costs. Even if disk space, download time, installation time,, and local bandwidth use are of no consequence to you, consider the the generous wasted bandwidth. I've done the experiment, so now you don't have to.

An Intelligent 'Complete' Installation I've come up with a simple set of package exclusion rules that results in a much smaller installation: • Skip all of the -debuginfo packages. Few people need these, and they take up a lot of space. Savings: 53.4 GiB in the installation tree alone; more in the download tree. It's easy to apply this rule.

After selecting all packages for installation with the sneaky trick above but before you move on to the next screen, click the 'Install' text next to the 'Debug' category header until it switches back to 'Default.' (Or if you've already installed them, click it until it says 'Uninstall' instead.) • Do not explicitly install any of the lib* packages.

Let Cygwin's setup-*.exe automatically install libraries to satisfy package dependencies. Savings: about 5.1 GiB ⁵ To apply this rule, switch the 'Libs' category to 'Default' or 'Uninstall' as you did with the 'Debug' category.

The installer will figure out which libraries you actually need in a later step. • Skip the and associated packages. Again, few people need these.⁶ Savings: 3.7 GiB There are basically two sets of cross-development tools in Cygwin: the set for creating Cygwin executables of the other (i.e. 64-bit tools and libraries for 32-bit Cygwin, or vice versa) and the set for building executables of the same word size as your Cygwin installation. To apply this rule for a 64-bit Cygwin installation, while still on the 'Select Packages' screen, type cygwin32- in the package name search box at the top of that screen, then click the Default text next to each top-level category until it cycles back to Default, thereby changing all the underlying matching packages' Install modes back to Default, which is not to install them if this is the first pass through setup-*.exe.

Or, if you have already installed these packages, change these modes to Uninstall. Repeat that for mingw64. The idea is the same for 32-bit Cygwin, except that you search for and exclude packages with cygwin64- and mingw32- in their names instead. By following this rule set, I was able to install nearly everything, taking only about 21 GiB.

Paring That Down We can get the installation to be even smaller by excluding several other notorious disk hogs: •, the desktop environments, and the GUI apps together require about 10.8 GiB.⁷ • A Cygwin Base + Devel installation comes to 9.6 GiB. • A Cygwin Base + TeX category installation takes about 4.8 GiB. If you installe only your native language's support package, it comes to about 3.7 GiB instead.

• All of the -doc packages combined chew up about 4.5 GiB of disk space Someone who isn't a software developer, who doesn't use Cygwin for GUI stuff, who uses the Web for docs, and who doesn't use TeX for document creation could thus have a 'full' Cygwin installation in only about 1 GiB.⁸ If you use Cygwin the way it is intended to be used, installing the base and only the extra packages you need at the moment, you probably won't even get your installation size to even those levels. I use Cygwin this way, and my installations are typically well under 1 GiB, yet they are 'complete,' in that they meet my current needs. For Extra Disk-Filling Fun. All of this testing was done with the 64-bit version of Cygwin. You can roughly double the above space requirements by installing a parallel 32-bit Cygwin installation.⁹ This is not pointless. It is a viable alternative to using cross-compilers, for one thing.

For another, the of the two Cygwins means you may have need of both. Footnotes • There are occasional threads on the Cygwin mailing list where someone argues that some very common package should be included in the Base category, such as Perl, and the result is usually that the maintainers decide not to add it to Base. You also occasionally see the opposite: some package accidentally slips into Base, usually via an incorrect dependency.

Shortly after the problem is brought to the attention of the Cygwin maintainers, the status quo ante is restored. () • Perhaps I am wrong. There could be a immigrant who completes on the side while not busy brushing up on his technical vocabulary by translating into his adopted. I want to meet him. He sounds like an interesting guy. Plus, I think I can help him with his plan to create a GUI front end for. Naturally, I will try to talk him into porting it from to /.

I mean, Tcl/Tk, seriously? Let's not be ridiculous. • curl -s grep -c x86_64/ • Cygwin's setup-*.exe doesn't delete the downloaded package files after installing them.

Nuovo Cinema Paradiso Torrent Tnt. This is useful at sites where you have multiple Cygwin installations, since you can put the download directory on a shared network drive. Each package then only has to be downloaded once at that site. My 105 GiB upper limit assumes you will download and install to the same drive, and that you will keep the download tree in case you need to reinstall it later. (All sizes in this answer are space-on-the-wire numbers, by the way, not space-on-disk numbers: will increase the size of the download and installation trees, the latter to a much greater degree, since the proportion of small files is much greater in the installation tree. Expect something like +1% in the download tree and +5% in the installation tree.) Not only does setup-*.exe not delete downloaded package files after installing them, it doesn't auto-purge old versions, so your download tree grows and grows over the years you use Cygwin.

(There are scripts floating about the net to solve this problem, such as.) • You may wonder why there are libraries in the Cygwin package repository that you don't need even though you've installed 'all' packages. There are several reasons: • some libraries are obsolete, but are still present on the mirrors • some libraries come in multiple alternative forms, so that people who know they need something other than the default can choose it • some libraries are there only for people writing their own programs, not to support any existing Cygwin package • Pretty much the only people who need the Cygwin cross-compilers are the people maintaining Cygwin packages, since maintainers are expected to build for both 32-bit and 64-bit Cygwin unless there is a good reason not to. There are probably more people with a good justification for MinGW cross-development tools, but there's also the option of using MinGW and MSYS instead of Cygwin. Also, I am guessing that the number of people who do dual-stack Cygwin + MinGW development is smaller than the set of people who use one or the other exclusively, or nearly so.

• It is not easy to do this exclusion, because GUI packages are scattered throughout the Cygwin packaging system, and their top-level category often contains non-GUI software, so you can't simply exclude the whole category. Math.) The first pass is to exclude the X11, GNOME, KDE, LXDE, MATE, Xfce, and Games categories using the same Categories view technique as above. Then, using the search box as we did for the cross-compiler exclusion above, remove packages matching gtk, gnome, qt, and kde, optionally excluding those in the Devel, Debug or Libs packages, if you need those. Finally, you'll have to switch to the Pending view and manually exclude a bunch of packages that weren't caught by either of those two broad exclusions:,,,,,,,,,,,,,,,,,,,,,,,,,,, and. If you don't exclude these, they'll drag back in much of what you excluded above as dependencies! • You may notice that the size of all the excluded package sets adds up to more than the 21 GiB of the 'intelligent complete' installation. This is because of shared dependencies.

That is to say, these sizes overlap to some extent. • If you put both setup-*.exe programs in the same directory, they will share the download tree so that all of the noarch packages are downloaded only once for both Cygwins.

Between that and the fact that 32-bit and 64-bit Intel compilers generate code that differs in size, installing both Cygwins doesn't quite double the disk space requirement. @SlySven: As for the Tcl/Tk comment, you do see that it's a joke, yes? Well, mostly a joke: Tk should have been reskinned to something better than its current Motif-inspired default roughly 20 years ago. And yes, I'm aware that there are alternate Tk skins; I'm talking about defaults here. As for gitk as an example, that doesn't count as 'in 2017,' since the program was created in 2005.

Though given that the Motif look was quite dated even then, it's still a questionable tooling choice. – Jul 31 at 12:58. I would like to add to this thread. This approach gives you a leaner, meaner, bare-bones, minimal Cygwin install, with just the tools/items you need.

No dependency bloat, no unwanted packages, files etc. I have been experimenting with Cygwin attempting to get a 'bare-bones', minimal install. I do find that installing utilities like grep, gawk, sed and similar tools has dependencies on cygwin, base-Cygwin and sometimes unwanted tools like bash, coreutils etc. I wanted to get only the tools and their required dlls installed and started examining the Cygwin package. I discovered that not using the setup.exe supplied by Cygwin is an alternative way to accomplish minimal Cygwin installs.

And this is how I got it done: • Download only the packages you want from any of the Cygwin mirror sites using ftp or http. Alternatively you can use the setup.exe supplied by Cygwin to download all the packages - download only and no install. • Once the download is successfully completed, individual packages like zlib, gawk, grep, libiconv are found under the x86/release or x86_64/release directory Each package is 'tar'red and compressed using tool 'xz' or bzip and stored in respective directories.