@chapter What is it? The Cygwin tools are ports of the popular GNU development tools for Windows NT, 95, and 98. They run thanks to the Cygwin library which provides the UNIX system calls and environment these programs expect. With these tools installed, it is possible to write Win32 console or GUI applications that make use of the standard Microsoft Win32 API and/or the Cygwin API. As a result, it is possible to easily port many significant Unix programs without the need for extensive changes to the source code. This includes configuring and building most of the available GNU software (including the packages included with the Cygwin development tools themselves). Even if the development tools are of little to no use to you, you may have interest in the many standard Unix utilities provided with the package. They can be used both from the bash shell (provided) or from the standard Windows command shell. @section Is it free software? Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are covered by the standard X11 license, some of it is public domain, some of it was written by Cygnus 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 more more information on how the GNU General Public License may affect your use of these tools. In particular, if you intend to port a proprietary (non-GPL'd) application using Cygwin, you will need the proprietary-use license for the Cygwin library. This is available for purchase; please contact sales@@cygnus.com for more information. All other questions should be sent to the project mailing list cygwin@@sources.redhat.com. 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 Cygwin license allows you those freedoms, so it is free software. The Cygwin 1.0 product is a "commercial" distribution of cygwin. As such, it includes such non-software things as printed manuals, support, and aggregation of useful utilities. There is nothing (software-wise) in there that you can't already get off the net already, if you take the time to find and download everything (and usually, build it yourself), although the @emph{versions} available for download may be different than those distributed with the commercial product. We test it all to make sure it works together, and package it in a convenient form. We consider such testing and packaging to be a valuable service and thus charge a fee for it. Plus, it provides income for the cygwin project so we can continue working on it. For further details about the commercial product, see @file{http://www.cygnus.com/cygwin/}. @section Recent history of the project: What version @emph{is} this, anyway? Starting on April 17, 2000, the Cygwin team changed the procedure for doing net releases. Previously, net releases entailed downloading one or two large files (called something like @code{FULL.EXE} or @code{USER.EXE}). These files unpacked a "Cygwin Distribution" to a static (and arcane) directory structure. This distribution contained lots of .exe, .a, .h, and other files. These distributions were named after the version of the Cygwin DLL which they contained. The last version released with this method was Cygwin B20.1. This distribution method has the advantage that everything was "all in one place". You could copy the huge FULL.EXE file around and know that you were getting the complete "Cygwin Distribution". The method had several disadvantages, however. 1) it was huge, 2) it was hard to download in one error-free piece, and 3) it was hard to update. Why was it hard to update? Because any change to any package in FULL.EXE meant re-generating all of FULL.EXE. This process was not easy to automate since FULL.EXE was an InstallShield executable. As a result, until recently, Cygwin development was relatively static. To rectify these problems, the Cygwin team decided, early in January 2000, to break up the packages in the release and make a small program (@code{setup.exe}) available to use in downloading packages. After much development and internal discussion on the cygwin-developers mailing list, the new, improved version of a Cygwin release was made available on April 17, 2000. This new release also had a new version of the Cygwin DLL -- 1.1.0. Most of the other packages were updated and some packages from the Cygwin CD were included. Meanwhile, the Cygwin DLL continues to be updated, and is more generically referred to as "1.1.x". Users obtain this package by first downloading a version of @code{setup.exe}. This program started as a simple command line tool, has metamorphosed into a GUI, and is in the process of continual improvement. However, its purpose is simple -- it is designed to install packages from the cygwin web site at sources.redhat.com. In effect, it is a smaller, more intelligent replacement for FULL.EXE. It does not require the downloading a huge executable but rather downloads individual small packages. Does this mean that the new net release of the Cygwin package is 1.1.x? No. We no longer label the releases with the Cygwin version number. Each package in the cygwin release has its own version now. Does this mean that Cygwin 1.1.x is newer than B20.1? Yes! The cygwin 1.1.x versions all represent continual improvement in the Cygwin DLL. Although the 1.1.x code is still considered "beta quality", the Cygwin team felt comfortable enough with the cygwin technology to bump the version number to "1". The other packages in the latest directory are also continually improving, some 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? Easy. Just download the setup.exe program from your closest mirror. This program will handle the task of updating the packages on your system to the latest version. The Cygwin team frequently updates and adds new packages to the soureware web site. The setup.exe program is the easiest way to determine what you need on your system. @section Ancient history of the project The first thing done was to enhance the development tools (gcc, gdb, gas, et al) so that they could generate/interpret Win32 native object files. The next task was to port the tools to Win NT/95. We could have done this by rewriting large portions of the source to work within the context of the Win32 API. But this would have meant spending a huge amount of time on each and every tool. Instead, we took a substantially different approach by writing a shared library (cygwin.dll) that adds the necessary unix-like functionality missing from the Win32 API (fork, spawn, signals, select, sockets, etc.). We call this new interface the Cygwin API. Once written, it was possible to build working Win32 tools using unix-hosted cross-compilers, linking against this library. From this point, we pursued the goal of producing native tools capable of rebuilding themselves under Windows 95 and NT (this is often called self-hosting). Since neither OS ships with standard UNIX user tools (fileutils, textutils, bash, etc...), we had to get the GNU equivalents working with the Cygwin API. Most of these tools were previously only built natively so we had to modify their configure scripts to be compatible with cross-compilation. Other than the configuration changes, very few source-level changes had to be made. Running bash with the development tools and user tools in place, Windows 95 and NT look like a flavor of UNIX from the perspective of the GNU configure mechanism. Self hosting was achieved as of the beta 17.1 release. After adding Windows 98 support to Cygwin in mid-1998, we added support for the native Microsoft libraries in the compiler which allows compilation of executables that do not use Cygwin. This is important to those people who want to use the tools to develop Win32 applications that do not need the UNIX emulation layer.