newlib-cygwin/winsup/doc/what.texinfo

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