The Cygwin tools are ports of the popular GNU development tools for Windows 9x/ME/NT/2000. 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.
The main WWW page for the Cygwin project is http://cygwin.com/. There you should find everything you need for Cygwin, including links for download and setup, a current list of ftp mirror sites, a User's Guide, an API Reference, mailing lists and archives, and additional ported software.
You can find documentation for the individual GNU tools at http://www.fsf.org/manual/. (You should read GNU manuals from a local mirror. Check http://www.fsf.org/server/list-mirrors.html for a list of them.)
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@cygwin.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 was a "commercial" distribution of cygwin. As such, it included such non-software things as printed manuals, support, and aggregation of useful utilities. There was nothing (software-wise) in there that you couldn't get off the net already, if you took the time to find and download everything (and usually, build it yourself), although the versions available for download may have been different than those distributed with the commercial product. We tested it all to make sure it worked together, and packaged it in a convenient form. We considered such testing and packaging to be a valuable service and thus charged a fee for it. Plus, it provided income for the cygwin project so we could continue working on it. However, Red Hat is no longer offering Cygwin 1.0 on CD. There are tentative plans to offer a new Cygwin CD sometime in early 2001. So far, however, there are no definite plans. The latest news about this can be found at http://cygwin.com/cygwin-cd.html.
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 FULL.EXE or 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
(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
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 http://cygwin.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.
For some "ancient" history of the project (rather, just woefully out of date), visit the Project History page at http://cygwin.com/history.html.
Unlike previous net releases such as B20.1 and earlier, there is no monolithic "full" or "usertools" installation. Rather, you can pick and choose the packages you wish to install, and update them individually.
The following packages are available with the current release, in their respective directories:
Full source code is available for all packages and tools.
There is one recommended way to install Cygwin, which is to use the GUI installer `setup.exe'. There are some variations on how you go about that.
Do it any other way, and you're on your own! That said, keep in mind that the GUI installer is a "work in progress", so there might be a few difficulties, especially if you are behind a firewall or have other specific requirements. If something doesn't work right for you, and it's not covered here or elsewhere, then by all means report it to the mailing list.
IMPORTANT: First read the README file in the `latest' directory at any ftp mirror. DO THIS NOW! Information in the README file is not repeated here. You can find a mirror site near you from http://cygwin.com/mirrors.html.
The `setup.exe' program is the recommended way to install Cygwin,
but it is still a work in progress. Expect features and functionality
to change. For this reason, it is a good idea to note the version and
build time reported by setup.exe when you run it. This will help
diagnose problems, should you have any. Check the cygwin mailing list
for the latest news about setup.exe.
The setup.exe program will prompt you for a "root" directory.
The default is `C:\cygwin', but you can change it. You are urged not to
choose something like 'C:\' (the root directory on the system drive) for
your Cygwin root. If you do, then critical Cygwin system directories
like 'etc', 'lib' and 'bin' could easily be corrupted by other (non-Cygwin)
applications or packages that use \etc, \lib or \bin. Perhaps there is
no conflict now, but who knows what you might install in the future?
It's also just good common sense to segregate your Cygwin "filesystems"
from the rest of your Windows system disk. (In the past, there had been
genuine bugs that would cause problems for people who installed in C:\,
but we believe those are gone now.)
No, you must start from scratch with the new setup. The overall structure has changed so much that it would be silly to try to accomodate old installations of Cygwin. You'll probably be much better off with a whole new installation anyway. You may backup or rename your old installation first, or just install the new one somewhere else. Be sure to make note of your current mount table, because this will be overwritten during the new setup.
Once you've installed the latest net release, the new setup will update just the individual packages that need it.
Only Network Associates (formerly McAfee) products have been reported to "hang" when extracting Cygwin tar archives. Other products have been reported to detect false positives in Cygwin files. Depending on how your anti-virus software is configured, it may then delete the file(s) without prompting you. Any problems will depend on the particular engine and/or signature file in use, and possibly other factors. If you don't mind this risk, then just leave your anti-virus software running.
Otherwise, you can download setup.exe and scan it. Then turn off
the anti-virus software, then run setup to download and extract all the
tar files. Then re-activate your anti-virus software and scan
everything in C:\cygwin (or wherever you chose to install). This should
be safe, as long as nobody substitutes a malicious setup.exe!
Just get everything, if you have room for it. But if you must be selective:
mount). Not much else, and no shell!
/bin/sh, which is essential for running scripts (and
`make' and ...).
If you want to build programs, of course you'll need `gcc', but you'll also need `binutils', probably `make' and `fileutils', and possibly lots more. (Again, consider just getting everything!)
First, make sure that you are using the latest version of
setup.exe. It's a work in progress, with improvements and
bugfixes being made often. The latest version is always available from
the 'Install Cygwin now' link on the Cygwin Home Page at
http://cygwin.com/.
If you are downloading from the internet, setup will fail if it cannot download the list of mirrors at http://cygwin.com/mirrors.html. It could be that the network is too busy. Similarly for an ftp download site that isn't working. Try another mirror, or try again later.
If setup refuses to download a package that you know needs to be upgraded, try deleting that package's entry from /etc/setup. If you are reacting quickly to an announcement on the mailing list, it could be that the mirror you are using doesn't have the latest copy yet. Try another mirror, or try again tomorrow.
If setup has otherwise behaved strangely, check the files
`setup.log' and `setup.log.full' in the Cygwin root directory
(C:\cygwin by default). It may provide some clues as to what
went wrong and why.
If you're still baffled, search the Cygwin mailing list for clues. Others may have the same problem, and a solution may be posted there. If that search proves fruitless, send a query to the Cygwin mailing list. You must provide complete details in your query: version of setup, options you selected, contents of setup.log and setup.log.full, what happened that wasn't supposed to happen, etc.
Good question! That very issue has been debated on the `cygwin-apps' mailing list. Check the list archives if you want to know more. Start at http://cygwin.com/lists.html.
But it really doesn't matter, and there is no distinction as far as
setup.exe is concerned. By default, it will install all packages
from both latest and contrib directories.
Most definitely yes! UNIX shells (and thus Cygwin) use the space character as a word delimiter. Under certain circumstances, it is possible to get around this with various shell quoting mechanisms, but you are much better off if you can avoid the problem entirely.
In particular, the environment variables `USER' and `HOME' are set for you in /etc/profile. By default these derive from your Windows logon name. You may edit this file and set them explicitly to something without spaces.
(If you use the `login' package or anything else that reads /etc/passwd, you may need to make corresponding changes there. See the README file for that package.)
Setup will remove the following mounts, should you have them:
/
/usr
/usr/bin
/usr/lib
/var
/lib
/bin
/etc
It will then restore (or create new) mounts for /, /usr/bin and /usr/lib as follows (assuming the default install root C:\cygwin):
Device Directory C:\cygwin\bin /usr/bin C:\cygwin\lib /usr/lib C:\cygwin /
Since setup is not a Cygwin program, it cannot know about your mounts (or symlinks, for that matter), and so must impose and enforce this structure. You should not try to defeat it, unless you know what you are doing and can deal with the consequences.
Setup has no automatic uninstall facility. Just delete everything manually:
HKEY_LOCAL_MACHINE and/or HKEY_CURRENT_USER.
It's up to you to deal with other changes you made to your system, such as installing the inetd service, altering system paths, etc. Setup would not have done any of these things for you.
Yes. If experimenting with developer snapshots from
http://cygwin.com/snapshots/, you should generally install the
full cygwin-inst-YYYYMMDD.tar.bz2 update, rather than just the
DLL, otherwise some components may be out of sync. However, Cygwin tar
won't work because it will load the DLL that you're trying to update,
and a non-Cygwin program like WinZip will put everything in the wrong
place. The solution is to use setup.exe.
Just bunzip2 the cygwin-inst tarball, rename it to cygwin-YYYYMMDD.tar,
gzip it, put it in an empty directory, and run setup.exe there.
You should be given the option to install it.
The obvious warnings about updating the cygwin package and using developer snapshots apply:
This is the beginning of documentation listing the calls supported by the Cygwin library.
All POSIX.1/1996 and ANSI C calls are listed in this file. Note that while almost all POSIX.1/1990 calls are included in Cygwin, most POSIX.1/1996 calls are not (yet at least!). Additional Unix compatibility calls and extended libc/libm calls are provided by Cygwin but may or may not be listed yet.
To see if a function is implemented but not listed here, check for the presence of the call in the file winsup/cygwin.din in the sources. In addition, you may want to read the source code corresponding to the call to verify that it is not a stub. Finally, libc/libm functions (including extended calls not listed here) may be documented in the newlib texinfo documentation.
Calls are implemented on both Windows 95 and NT unless otherwise noted. Included are references to relevant standards, if any. Calls starting with "cygwin_" are Cygwin-specific calls.
(Please note: This section has not yet been updated for the latest net release.)
(Please note: This section has not yet been updated for the latest net release.)
(Please note: This section has not yet been updated for the latest net release.)
There are links to quite a lot of it on the main Cygwin project web page: http://cygwin.com/. Be sure to at least read any 'Release Notes' or 'Readme' or 'read this' links on the main web page, if there are any.
There is a comprehensive Cygwin User's Guide at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html and an API Reference at http://cygwin.com/cygwin-api/cygwin-api.html.
There is an interesting paper about Cygwin from the 1998 USENIX Windows NT Workshop Proceedings at http://cygwin.com/usenix-98/cygwin.html.
You can find documentation for the individual GNU tools at http://www.fsf.org/manual/. (You should read GNU manuals from a local mirror, check http://www.fsf.org/server/list-mirrors.html for a list of them.)
Comprehensive information about the Cygwin mailing lists can be found at http://cygwin.com/lists.html.
To subscribe to the main list, send a message to cygwin-subscribe@cygwin.com. To unsubscribe from the main list, send a message to cygwin-unsubscribe@cygwin.com. In both cases, the subject and body of the message are ignored.
Similarly, to subscribe to the Cygwin annoucements list, send a message to cygwin-announce-subscribe@cygwin.com. To unsubscribe, send a message to cygwin-announce-unsubscribe@cygwin.com.
If you are going to help develop the Cygwin library by volunteering for the project, you will want to subscribe to the Cygwin developers list, called cygwin-developers. If you are contributing to Cygwin tools & applications, rather than the library itself, then you should subscribe to cygwin-apps. The same mechanism as described for the first two lists works for these as well. Both cygwin-developers and cygwin-apps are by-approval lists.
There is a searchable archive of the main mailing list at http://cygwin.com/ml/cygwin/. There is an alternate archive, also searchable, at http://www.delorie.com/archives/.
Cygwin mailing lists are not gatewayed to USENET, so anti-spam measures in your email address are neither required nor appreciated. Also, avoid sending HTML content to Cygwin mailing lists.
If you follow these guidelines, you are much more likely to get a helpful response from the Cygwin developers and/or the Cygwin community at large:
If you do not follow the above guidelines, you may still elicit a response, but you may not appreciate it!
Inquiries about support contracts and commercial licensing should go to info@cygnus.com. If you want to purchase the Cygwin 1.0 CD-ROM, visit http://www.cygnus.com/cygwin/ or write to cygwin-info@cygnus.com. While not strictly unappreciated in the main cygwin list, you'll get the information you need more quickly if you write to the correct address in the first place.
Beyond that, perhaps nobody has time to answer your question. Perhaps nobody knows the answer.
If you look at the "Cygwin 1.1.0" (or similar) shortcut created in the
"Cygnus Solutions" programs folder, you'll see that it runs
C:\cygwin\bin\cygwin.bat (assuming your root is
C:\cygwin). The contents should look something like this:
@echo off SET MAKE_MODE=unix SET PATH=C:\cygwin\bin;C:\cygwin\usr\local\bin;%PATH% bash
Effectively, this prepends /usr/bin and /usr/local/bin to your
Windows system path. If you choose to reset your PATH, say in
$HOME/.bashrc, 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 haven't messed up the default mounts, then /bin and
/usr/bin are the same location, so you only need one of them in
your PATH. You should use /usr/local/bin for installing
additional Cygwin applications that are not part of the core net
release. (That is, anything not found in an ftp mirror of latest
and installed by setup.exe.)
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 Windows, bash does not look for programs in `.' (the current directory) by default. You can add `.' to your PATH (see above), but this is not recommended (at least on UNIX) for security reasons. Just tell bash where to find it, when you type it on the command line:
bash$ gcc -o hello hello.c
bash$ ./hello
Hello World!
Use the 'cygpath' utility. Type 'cygpath' with no arguments to
get usage information. For example (on my installation):
bash$ cygpath --windows ~/.bashrc
D:\starksb\.bashrc
bash$ cygpath --unix C:/cygwin/bin/cygwin.bat
/usr/bin/cygwin.bat
bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat
/usr/bin/cygwin.bat
Note that bash interprets the backslash '\' as an escape character, so you must type it twice in the bash shell if you want it to be recognized as such.
Your .bashrc is read from your home directory specified by the HOME environment variable. It uses /.bashrc if HOME is not set. So you need to set HOME correctly, or move your .bashrc to the top of the drive mounted as / in Cygwin.
"shopt -s nocaseglob" should do the trick.
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
This is only valid up to but not including version 1.3.0:
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.
Some people have suggested replacing the current symbolic link scheme with shortcuts. The major problem with this is that .LNK files would then be used to symlink Cygwin paths that may or may not be valid under native Win32 non-Cygwin applications such as Explorer.
Since version 1.3.0, Cygwin treats shortcuts as symlinks.
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.
Even after installing the `man' package, you get an error like this:
bash-2.03$ man man Error executing formatting or display command. System command (cd /usr/man ; (echo -e ".pl 1100i"; cat /usr/man/man1/man.1; echo ".pl \n(nlu+10") | /usr/bin/tbl | /usr/bin/groff -Tascii -mandoc | less -is) exited with status 32512. No manual entry for man
You also need /bin/sh, which is found in the `ash' package. Install this too.
`ntsec' will allow UNIX permissions in Windows NT on NTFS file systems.
`ntea' works on NTFS and FAT but it creates a huge, undeletable file on FAT filesystems.
(The `ntsec' and `ntea' settings are values for the `CYGWIN' environment variable. See the Cygwin User's Guide at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html for more information on this variable and its settings.)
There is no solution at all for Windows 9x.
If you have an application that requires a certain permission mode on a file, you may be able to work around this requirement by modifying the application's source code. For a hint, based on work done by Corinna Vinschen for OpenSSH, see this message from the cygwin mailing list: http://cygwin.com/ml/cygwin/2000-11/msg01176.html.
Unfortunately, you cannot do something like this:
bash$ mkdir -p //MACHINE/Share/path/to/new/dir mkdir: cannot create directory `//MACHINE': No such file or directory
This is because mkdir checks for the existence of each directory on the path, creating them as necessary. Since `//MACHINE' is not a directory (you can't cd to it either), mkdir tries to create it, and fails.
This might get fixed someday, but for now, you have to work around it:
bash$ cd //MACHINE/Share bash$ mkdir -p path/to/new/dir
There are two basic problems you might run into. One is the fact that /bin/sh is really ash, and is missing some features you might expect in /bin/sh. For example:
Or it could be a permission problem, and Cygwin doesn't understand that your script is executable. Because `chmod' may not work (see FAQ entry above), 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 `mount -x' 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.
(Please note: This section has not yet been updated for the latest net release.)
Careful examination shows that they not just non-functional, but rather behave strangely, for example, with NumLock off, keys on numeric keyboard work, until you press usual cursor keys, when even numeric stop working, but they start working again after hitting alphanumeric key, etc. This reported to happen on localized versions of Win98 and Win95, and not specific to Cygwin (there're known cases of Alt+Enter (fullscreen/windowed toggle) not working and shifts sticking with other programs). The cause of this problem is Microsoft keyboard localizer which by default installed in 'autoexec.bat'. Corresponding line looks like:
keyb ru,,C:\WINDOWS\COMMAND\keybrd3.sys
(That's for russian locale.) You should comment that line if you want your keys working properly. Of course, this will deprive you of your local alphabet keyboard support, so you should think about another localizer. exUSSR users are of course knowledgeable of Keyrus localizer, and it might work for other locales too, since it has keyboard layout editor. But it has russian messages and documentation ;-( Reference URL is http://www.hnet.ru/software/contrib/Utils/KeyRus/ (note the you may need to turn off Windows logo for Keyrus to operate properly).
You should only have one copy of the Cygwin DLL on your system. If you have multiple versions, they will conflict and cause problems.
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. This could happen, for example, if you update cygwin1.dll without exiting all Cygwin apps (including inetd) beforehand.
If you're trying to find multiple versions of the DLL that are causing this problem, reboot first, in case DLL's 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).
If you are looking for the "more" pager, you should use the "less" pager instead.
There is no "which" command with Cygwin. However, you can use the bash shell builtin "type" which does something similar.
Probably because there is nobody willing or able to maintain it. It takes time, and the priority for the Cygwin Team is the Cygwin package. The rest is a volunteer effort. Want to contribute? See below.
You have some flexibility here.
Cygwin has a builtin "cygdrive prefix" for drives that are not mounted. You can access any drive, say Z:, as '/cygdrive/z/'.
In some applications (notably bash), you can use the familiar windows <drive>:/path/, using posix forward-slashes ('/') instead of Windows backward-slashes ('\'). (But see the warning below!) This maps in the obvious way to the Windows path, but will be converted internally to use the Cygwin path, following mounts (default or explicit). For example:
bash$ cd C:/Windows
bash$ pwd
/cygdrive/c/Windows
and
bash$ cd C:/cygwin
bash$ pwd
/
for a default setup. You could also use backward-slashes in the Windows path, but these would have to be escaped from the shell.
Warning: There is some ambiguity in going from a Windows path to the posix path, because different posix paths, through different mount points, could map to the same Windows directory. This matters because different mount points may be binmode or textmode, so the behavior of Cygwin apps will vary depending on the posix path used to get there.
You can avoid the ambiguity of Windows paths, and avoid typing "/cygdrive", by explicitly mounting drives to posix paths. For example:
bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c
Then `/cygdrive/c/Windows' becomes `/c/Windows' which is a little less typing.
Note that you only need to mount drives once. The mapping is kept in the registry so mounts stay valid pretty much indefinitely. You can only get rid of them with umount, or the registry editor.
The '-b' option to mount mounts the mountpoint in binary mode ("binmode") where text and binary files are treated equivalently. This should only be necessary for badly ported Unix programs where binary flags are missing from open calls. It is also the setting for /, /usr/bin and /usr/lib in a default Cygwin installation. The default for new mounts is text mode ("textmode"), which is also the mode for all "cygdrive" mounts.
You can change the default `cygdrive' prefix and whether it is
binmode or textmode using the mount command. For example,
bash$ mount -b --change-cygdrive-prefix cygdrive
will change all /cygdrive/... mounts to binmode.
Under Windows NT, open the properties dialog of the console window. The options contain a toggle button, named "Quick edit mode". It must be ON. Save the properties.
Under Windows 9x, open the properties dialog of the console window. Select the Misc tab. Uncheck Fast Pasting. Check QuickEdit.
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
(Please note: This section has not yet been updated for the latest net release.)
This usually means that you are trying to mount to a location already in use by mount. For example, if c: is mounted as '/' and you try to mount d: there as well, you will get this error message. First "umount" the old location, then "mount" the new one and you should have better luck.
If you are trying to umount '/' and are getting this message, you may
need to run regedit.exe and change the "native" key for the '/'
mount in one of the mount points kept under
HKEY_CURRENT_USER/Software/Cygnus Solutions/CYGWIN.DLL setup/<version>
where <version> is the latest registry version associated with the
Cygwin library.
During development, we have both Unix boxes running Samba and NT/Windows 95/98 machines. We often build with cross-compilers under Unix and copy binaries and source to the Windows system or just toy with them directly off the Samba-mounted partition. On dual-boot NT/Windows 9x machines, we usually use the FAT filesystem so we can also access the files under Windows 9x.
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. WIN32 can't tell the difference between files with
just different case, so the configuration fails.
In releases prior to beta 16, mount had a special mixed case option which renamed files in such a way as to allow mixed case filenames. We chose to remove the support when we rewrote the path handling code for beta 16. The standard Windows apps -- explorer.exe, cmd.exe/command.com, etc. -- do not distinguish filenames that differed only in case, resulting in some (very) undesirable behavior.
Sergey Okhapkin had maintained a mixed-case patch ('coolview') until about B20.1, but this has not been updated to recent versions of Cygwin.
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.
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. This should never be necessary under Windows NT.
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:
Device Directory Type Flags C:\cygwin\bin /usr/bin user binmode C:\cygwin\lib /usr/lib user binmode C:\cygwin / user binmode
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?)
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.
The Windows port of GNU Emacs (aka "NT emacs") uses the Windows command shell by default. Also, since Emacs is not a Cygwin application, it has no knowledge of Cygwin mounts. With those points in mind, you need to add the following code to your ~/.emacs or ~/_emacs file in order to use bash. This is particularly useful for the JDE package (http://sunsite.dk/jde/).
;; This assumes that Cygwin is installed in C:\cygwin (the
;; default) and that C:\cygwin\bin is not already in your
;; Windows Path (it generally should not be).
;;
(setq exec-path (cons "C:/cygwin/bin" exec-path))
(setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH")))
;;
;; NT-emacs assumes a Windows command shell, which you change
;; here.
;;
(setq process-coding-system-alist '(("bash" . undecided-unix)))
(setq w32-quote-process-args ?\")
(setq shell-file-name "bash")
(setenv "SHELL" shell-file-name)
(setq explicit-shell-file-name shell-file-name)
;;
;; This removes unsightly ^M characters that would otherwise
;; appear in the output of java applications.
;;
(add-hook 'comint-output-filter-functions
'comint-strip-ctrl-m)
Cygwin packages install their info documentation in the /usr/info
directory. But you need to create a dir file there before the
standalone info program (probably /usr/bin/info) can be used to
read those info files. This is how you do it:
bash$ cd /usr/info bash$ for f in *.info ; do install-info $f dir ; done
This may generate warnings:
install-info: warning: no info dir entry in `gzip.info' install-info: warning: no info dir entry in `time.info'
The install-info command cannot parse these files, so you will
have to add their entries to /usr/info/dir by hand.
(Please note: This section has not yet been updated for the latest net release.)
"Out of queue slots!" generally occurs when you're trying to remove many files that you do not have permission to remove (either because you don't have permission, they are opened exclusively, etc). What happens is Cygwin queues up these files with the supposition that it will be possible to delete these files in the future. Assuming that the permission of an affected file does change later on, the file will be deleted as requested. However, if too many requests come in to delete inaccessible files, the queue overflows and you get the message you're asking about. Usually you can remedy this with a quick chmod, close of a file, or other such thing. (Thanks to Larry Hall for this explanation).
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.
(Please note: This section has not yet been updated for the latest net release.)
There is a bug in the Win32 API function GetFreeDiskSpace that makes it return incorrect values for disks larger than 2 GB in size. Perhaps that may be your problem?
There's a C library which provides a Unix-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 run on Unix 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/Unix translation layer, providing that dll changes stay backward-compatible.
For a good overview of Cygwin, you may want to read the paper on Cygwin published by the Usenix Association in conjunction with the 2d Usenix NT Symposium in August 1998. It is available in html format on the project WWW site.
Yes. 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 http://cygwin.com/snapshots/
Let's start with some background.
In UNIX, 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) written to the file will prepend a \r (carriage return) 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 dependant 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 easily mix Cygwin-ported Unix programs with generic Windows programs. As a result, Cygwin opens files in text mode as is normal under Windows. In the accompanying tools, tools that deal with binaries (e.g. objdump) operate in unix binary mode and tools that deal with text files (e.g. bash) operate in text mode.
Some people push the notion of globally setting the default processing mode to binary via mount point options or by setting the CYGWIN environment variable. But that creates a different problem. In binary mode, the program receives all of the data in the file, including a \r. Since the programs will no longer deal with these properly for you, you would have to remove the \r from the relevant text files, especially scripts and startup resource files. This is a porter "cop out", forcing the user to deal with the \r for the porter.
It is rather easy for the porter 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).
Note that because the open/fopen switches are defined by ANSI, they exist under most flavors of Unix; open/fopen will just ignore the switch since they have no meaning to UNIX.
Also note that lseek only works in binary mode.
Explanation adapted from mailing list email by Earnie Boyd <earnie_boyd@yahoo.com>.
Multi-thread-safe support is turned on by default in 1.1.x releases (i.e., in the latest net release). That does not mean that it is bug free!
There is also limited support for 'POSIX threads', see the file
cygwin.din for the list of POSIX thread functions provided.
Windows 9x: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.
But seriously, Windows 9x lacks most of the security-related calls and has several other deficiencies with respect to its version of the Win32 API. See the calls.texinfo document for more information as to what is not supported in Win 9x.
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 childs .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.
If the DLL thinks it was invoked from a DOS style prompt, it runs a
`globber' over the arguments provided on the command line. This means
that if you type LS *.EXE from DOS, it will do what you might
expect.
Beware: globbing uses malloc. If your application defines
malloc, that will get used. This may do horrible things to you.
Cygwin knows of two ways to create symlinks.
The old method is the only valid one up to but not including version 1.3.0. If it's enabled (from 1.3.0 on by setting `nowinsymlinks' in the environment variable CYGWIN) Cygwin 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.
The new method which is introduced with Cygwin version 1.3.0 is enabled by default or 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, the old and the new symlinks can live peacefully together since Cygwin treats both as symlinks regardless of the setting of `(no)winsymlinks' in the environment variable CYGWIN.
When working out the unix-style attribute bits on a file, the library has to fill out some information not provided by the WIN32 API.
It guesses that files ending in .exe and .bat are executable, as are ones which have a "#!" as their first characters.
Cygwin is not secure in a multi-user environment. For example if you have a long running daemon such as "inetd" running as admin while ordinary users are logged in, or if you have a user logged in remotely while another user is logged into the console, one cygwin client can trick another into running code for it. In this way one user may gain the priveledge of another cygwin program running on the machine. This is because cygwin has shared state that is accessible by all processes.
(Thanks to Tim Newsham (newsham@lava.net) for this explanation).
(Please note: This section has not yet been updated for the latest net release.)
The network support in Cygwin is supposed to provide the Unix API, not the Winsock API.
There are differences between the semantics of functions with the same name under the API.
E.g., the select system call on Unix can wait on a standard file handles and handles to sockets. The select call in winsock can only wait on sockets. Because of this, 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 using the net support in Cygwin is wrong.
But you can still use native Winsock, and use Cygwin. The functions which cygwin.dll exports are called 'cygwin_<name>'. There are a load of defines which map the standard Unix names to the names exported by the dll -- check out include/netdb.h:
..etc.. void cygwin_setprotoent (int); void cygwin_setservent (int); void cygwin_setrpcent (int); ..etc.. #ifndef __INSIDE_CYGWIN_NET__ #define endprotoent cygwin_endprotoent #define endservent cygwin_endservent #define endrpcent cygwin_endrpcent ..etc..
The idea is that you'll get the Unix->Cygwin mapping if you include the standard Unix header files. If you use this, you won't need to link with libwinsock.a - all the net stuff is inside the dll.
The mywinsock.h file is a standard winsock.h which has been hacked to remove the bits which conflict with the standard Unix API, or are defined in other headers. E.g., in mywinsock.h, the definition of struct hostent is removed. This is because on a Unix box, it lives in netdb. It isn't a good idea to use it in your applications.
As of the b19 release, this information may be slightly out of date.
(Please note: This section has not yet been updated for the latest net release.)
To use the vanilla Win32 winsock, you just need to #define Win32_Winsock and #include "windows.h" at the top of your source file(s). You'll also want to add -lwsock32 to the compiler's command line so you link against libwsock32.a.
(Please note: This section has not yet been updated for the latest net release.)
There is a cygwin.dll major version number that gets incremented every time we make a new Cygwin release available. This corresponds to the name of the release (e.g. beta 19's major number is "19"). There is also a cygwin.dll minor version number. If we release an update of the library for an existing release, the minor number would be incremented.
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 compatibity version number. It is incremented when incompatible changes are made to the shared memory region or to any named shared mutexes, semaphores, etc.
Finally there is a mount point registry version number which keeps track of non-backwards-compatible changes to the registry mount table layout. This has been "B15.0" since the beta 15 release.
(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.
There is no way to capture mouse events from Cygwin. There are currently no plans to add support for this.
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.
There will be a separate web page where all the details are documented, but this is not prepared yet. Meanwhile, pore through the cygwin-apps mailing archives (start at http://cygwin.com/lists.html), and subscribe. Charles Wilson posted a short recipe of what's involved, using texinfo as an example, at http://cygwin.com/ml/cygwin-apps/2000-11/msg00055.html. This should give you an idea of what is required.
You should announce your intentions to the general cygwin list, in case others were thinking the same thing.
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.
Cygwin does not provide glibc. It uses newlib instead, which provides much (but not all) of the same functionality. Porting glibc to Cygwin would be difficult.
First of all, if you are using `make -j[N]', then stop. It doesn't work well.
Otherwise, read on...
Make has two operating modes, UNIX and WIN32. You need to make sure that you are operating in the right mode.
In UNIX mode, make uses sh.exe as a subshell. The path list separator is ':', '\' is the escape character, POSIX paths are expected, and Cygwin mounts will be understood. Use this for Makefiles written for UNIX.
In WIN32 mode, make uses the "native" command shell (cmd.exe or command.com), with all the restrictions that implies. The path list separator is ';', the path separator is '\', "copy" and "del" work, but the Cygwin mount table is not understood. Use this for nmake-style Makefiles.
The default mode for the Net Release of make (the one installed by
setup.exe) is UNIX. The default mode for commercial releases to
Redhat (formerly Cygnus) customers is WIN32.
You can override the default by setting the environment variable MAKE_MODE to "UNIX" (actually case is not significant) or "WIN32" (actually anything other than "UNIX"). You can also specify the options --unix or --win32 on the make command line.
Try adding an empty main() function to one of your sources.
Or, perhaps you have `-lm' too early in the link command line. It should be at the end:
bash$ gcc hello.c -lm
bash$ ./a.exe
Hello World!
works, but
bash$ gcc -lm hello.c
/c/TEMP/ccjLEGlU.o(.text+0x10):hello.c: multiple definition of `main'
/usr/lib/libm.a(libcmain.o)(.text+0x0):libcmain.c: first defined here
/usr/lib/libm.a(libcmain.o)(.text+0x6a):libcmain.c: undefined reference to `WinMain@16'
collect2: ld returned 1 exit status
This is an artifact of libm.a being a symbolic link to libcygwin.a.
(Please note: This section has not yet been updated for the latest net release.)
It's pretty simple actually. Cygwin tools require that you explicitly link the import libraries for whatever Win32 API functions that you are going to use, with the exception of kernel32, which is linked automatically (because the startup and/or built-in code uses it).
For example, to use graphics functions (GDI) you must link with gdi32 like this:
gcc -o foo.exe foo.o bar.o -lgdi32
or (compiling and linking in one step):
gcc -o foo.exe foo.c bar.c -lgdi32
The following libraries are available for use in this way:
advapi32 largeint ole32 scrnsave vfw32 cap lz32 oleaut32 shell32 win32spl comctl32 mapi32 oledlg snmp winmm comdlg32 mfcuia32 olepro32 svrapi winserve ctl3d32 mgmtapi opengl32 tapi32 winspool dlcapi mpr penwin32 th32 winstrm gdi32 msacm32 pkpd32 thunk32 wow32 glaux nddeapi rasapi32 url wsock32 glu32 netapi32 rpcdce4 user32 wst icmp odbc32 rpcndr uuid imm32 odbccp32 rpcns4 vdmdbg kernel32 oldnames rpcrt4 version
The regular setup allows you to use the option -mwindows on the command line to include a set of the basic libraries (and also make your program a GUI program instead of a console program), including user32, gdi32 and, IIRC, comdlg32.
Note that you should never include -lkernel32 on your link line unless you are invoking ld directly. Do not include the same import library twice on your link line. Finally, it is a good idea to put import libraries last on your link line, or at least after all the object files and static libraries that reference them.
The first two are related to problems the linker has (as of b18 at least) when import libraries are referenced twice. Tables get messed up and programs crash randomly. The last point has to do with the fact that gcc processes the files listed on the command line in sequence and will only resolve references to libraries if they are given after the file that makes the reference.
The -mno-cygwin flag to gcc makes gcc link against standard Microsoft DLLs instead of Cygwin. This is desirable for native Windows programs that don't need a UNIX emulation layer.
This is not to be confused with 'MinGW' (Minimalist GNU for Windows), which is a completely separate effort. That project's home page is http://www.mingw.org/index.shtml.
No, you must use one or the other, they are mutually exclusive.
The default during compilation is to produce a console application. It you are writing a GUI program, you should either compile with -mwindows as explained above, or add the string "-Wl,--subsystem,windows" to the GCC commandline.
This problem usually occurs as a result of someone editing a Makefile with a text editor that replaces tab characters with spaces. Command lines must start with tabs. This is not specific to Cygwin.
Subsection 2.d.f of the `Microsoft Open Tools License agreement' looks like it says that one may not "permit further redistribution of the Redistributables to their end users". We take this to mean that we can give them to you, but you can't give them to anyone else, which is something that Cygnus (err... Red Hat) can't agree to. Fortunately, we have our own Win32 headers which are pretty complete.
(Please note: This section has not yet been updated for the latest net release.)
1. Build a C file with a function table. Put all functions you intend to use in that table. This forces the linker to include all the object files from the .lib. Maybe there is an option to force LINK.EXE to include an object file. 2. Build a dummy 'LibMain'. 3. Build a .def with all the exports you need. 4. Link with your .lib using link.exe.
or
1. Extract all the object files from the .lib using LIB.EXE. 2. Build a dummy C file referencing all the functions you need, either with a direct call or through an initialized function pointer. 3. Build a dummy LibMain. 4. Link all the objects with this file+LibMain. 5. Write a .def. 6. Link.
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@jacob.remcomp.fr) for this explanation)
Note: You must build in a directory outside the source tree.
Assuming that you have the src installed as /src, will build in the directory /obj, and want to install the tools in /install:
bash cd /obj /src/configure --prefix=/install -v > configure.log 2>&1 make > make.log 2>&1 make install > install.log 2>&1
Normally, this will also attempt to build the documentation, which additionally requires db2html, texi2html and possibly others. These tools are not included in the Cygwin distribution, but are readily obtainable:
To check a cygwin1.dll, run "make check" in the winsup/cygwin directory. If that 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 all the places where the old dll was (if there is more than one on your machine). Then start up a bash window and see what happens. (Or better, run a cygwin program from the Windows command prompt.)
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.
(Please note: This section has not yet been updated for the latest net release.)
Unfortunately, this will be difficult. It hasn't been built for some time (late 1996) since Microsoft has dropped development of powerpc NT. Exception handling/signals support semantics/args have been changed for x86 and not updated for ppc so the ppc specific support would have to be rewritten. We don't know of any other incompatibilities. Please send us patches if you do this work!
(Please note: This section has not yet been updated for the latest net release.)
We have not ported the tools to Alpha NT and do not have plans to do so at the present time. We would be happy to add support for Alpha NT if someone contributes the changes to us.
(Please note: This section has not yet been updated for the latest net release.)
Pass heap/stack linker arguments to gcc. To create foo.exe with a heap size of 1024 and a stack size of 4096, you would invoke gcc as:
gcc -Wl,--heap,1024,--stack,4096 -o foo foo.c
`objdump -p' provides this information, but is rather verbose.
`cygcheck' will do this much more concisely, and operates recursively, provided the command is in your path.
Note there is currently a bug in cygcheck in that it will not report on a program in a Windows system dir (e.g., C:\Windows or C:\WINNT) even if it's in your path. To work around this, supply the full Win32 path to the executable, including the .exe extension:
cygcheck c:\\winnt\\system32\\cmd.exe
(Note the windows path separator must be escaped if this is typed in bash.)
(Please note: This section has not yet been updated for the latest net release.)
There's documentation that explains the process on the main Cygwin project web page (http://cygwin.com/).
(Please note: This section has not yet been updated for the latest net release.)
Set a breakpoint at *0x401000 in gdb and then run the program in question.
(Please note: This section has not yet been updated for the latest net release. However, there was a discussion on the cygwin mailing list recently that addresses this issue. Read http://cygwin.com/ml/cygwin/2000-06/msg00688.html and related messages.)
You must execute the following sequence of five commands, in this order:
$(LD) -s --base-file BASEFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) -s --base-file BASEFILE EXPFILE -dll -o DLLNAME OBJS LIBS -e ENTRY
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE \
--base-file BASEFILE --output-exp EXPFILE
$(LD) EXPFILE --dll -o DLLNAME OBJS LIBS -e ENTRY
In this example, $(LD) is the linker, ld.
$(DLLTOOL) is dlltool.
$(AS) is the assembler, as.
DLLNAME is the name of the DLL you want to create, e.g., tcl80.dll.
OBJS is the list of object files you want to put into the DLL.
LIBS is the list of libraries you want to link the DLL against. For example, you may or may not want -lcygwin. You may want -lkernel32. Tcl links against -lcygwin -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lkernel32.
DEFFILE is the name of your definitions file. A simple DEFFILE would consist of "EXPORTS" followed by a list of all symbols which should be exported from the DLL. Each symbol should be on a line by itself. Other programs will only be able to access the listed symbols.
BASEFILE is a temporary file that is used during this five stage process, e.g., tcl.base.
EXPFILE is another temporary file, e.g., tcl.exp.
ENTRY is the name of the function which you want to use as the entry point. This function should be defined using the WINAPI attribute, and should take three arguments: int WINAPI startup (HINSTANCE, DWORD, LPVOID)
This means that the actual symbol name will have an appended @12, so if your entry point really is named `startup', the string you should use for ENTRY in the above examples would be `startup@12'.
If your DLL calls any Cygwin API functions, the entry function will need to initialize the Cygwin impure pointer. You can do that by declaring a global variable `_impure_ptr', and then initializing it in the entry function. Be careful not to export the global variable `_impure_ptr' from your DLL; that is, do not put it in DEFFILE.
/* This is a global variable. */
struct _reent *_impure_ptr;
extern struct _reent *__imp_reent_data;
int entry (HINSTANT hinst, DWORD reason, LPVOID reserved)
{
_impure_ptr = __imp_reent_data;
/* Whatever else you want to do. */
}
You may put an optional `--subsystem windows' on the $(LD) lines. The Tcl build does this, but I admit that I no longer remember whether this is important. Note that if you specify a --subsytem <x> flag to ld, the -e entry must come after the subsystem flag, since the subsystem flag sets a different default entry point.
You may put an optional `--image-base BASEADDR' on the $(LD) lines. This will set the default image base. Programs using this DLL will start up a bit faster if each DLL occupies a different portion of the address space. Each DLL starts at the image base, and continues for whatever size it occupies.
Now that you've built your DLL, you may want to build a library so that other programs can link against it. This is not required: you could always use the DLL via LoadLibrary. However, if you want to be able to link directly against the DLL, you need to create a library. Do that like this:
$(DLLTOOL) --as=$(AS) --dllname DLLNAME --def DEFFILE --output-lib LIBFILE
$(DLLTOOL), $(AS), DLLNAME, and DEFFILE are the same as above. Make sure you use the same DLLNAME and DEFFILE, or things won't work right.
LIBFILE is the name of the library you want to create, e.g., libtcl80.a. You can then link against that library using something like -ltcl80 in your linker command.
You can debug your application using gdb. Make sure you
compile it with the -g flag! If your application calls functions in
MS dlls, gdb will complain about not being able to load debug information
for them when you run your program. This is normal since these dlls
don't contain debugging information (and even if they did, that debug
info would not be compatible with gdb).
Yes. You can use the strace.exe utility to run other cygwin
programs with various debug and trace messages enabled. For information
on using strace, see the Cygwin User's Guide or the file
winsup/utils/utils.sgml.
Unfortunately, there is only minimal signal handling support in gdb currently. Signal handling only works with Windows-type signals. SIGINT may work, SIGFPE may work, SIGSEGV definitely does. You cannot 'stop', 'print' or 'nopass' signals like SIGUSR1 or SIGHUP to the process being debugged.
(Please note: This section has not yet been updated for the latest net release.)
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++.
(Please note: This section has not yet been updated for the latest net release.)
The function probably isn't declared in the header files, or the UNICODE stuff for it isn't filled in.
(Please note: This section has not yet been updated for the latest net release.)
Yes.
(Please note: This section has not yet been updated for the latest net release.)
Include stdlib.h instead of malloc.h.
If you define a function called malloc in your own code, and link
with the DLL, the DLL will call your malloc. Needless to
say, you will run into serious problems if your malloc is buggy.
If you run any programs from the DOS command prompt, rather than from in
bash, the DLL will try and expand the wildcards on the command line.
This process uses malloc before your main line is started.
If you have written your own malloc to need some initialization
to occur after main is called, then this will surely break.
Moreover, there is an outstanding issue with _malloc_r in
newlib. This re-entrant version of malloc will be called
directly from within newlib, by-passing your custom version, and
is probably incompatible with it. But it may not be possible to replace
_malloc_r too, because cygwin1.dll does not export it and
Cygwin does not expect your program to replace it. This is really a
newlib issue, but we are open to suggestions on how to deal with it.
Yes, but only if you are combining C object files. MSVC C++ uses a different mangling scheme than GNU C++, so you will have difficulties combining C++ objects.
No, not for full (high level source language) debugging. The Microsoft compilers generate a different type of debugging symbol information, which gdb does not understand.
However, the low-level (assembly-type) symbols generated by Microsoft compilers are coff, which gdb DOES understand. Therefore you should at least be able to see all of your global symbols; you just won't have any information about data types, line numbers, local variables etc.
CPU reference manuals for Intel's current chips are available in downloadable PDF form on Intel's web site:
http://developer.intel.com/design/pro/manuals/
If your scripts are in the current directory, you must have `.' (dot) in your $PATH. (It is not normally there by default.) Otherwise, you would need to add /bin/sh in front of each and every shell script invoked in your Makefiles.
(Please note: This section has not yet been updated for the latest net release.)
We use _WIN32 to signify access to the Win32 API and __CYGWIN__ for access to the Cygwin environment provided by the dll.
We chose _WIN32 because this is what Microsoft defines in VC++ and we thought it would be a good idea for compatibility with VC++ code to follow their example. We use _MFC_VER to indicate code that should be compiled with VC++.
(Please note: This section has not yet been updated for the latest net release.)
B20-compatible versions of the f77 and objc components are available from http://www.xraylith.wisc.edu/~khan/software/gnu-win32/.
(Please note: This section has not yet been updated for the latest net release.)
There are two basic strategies for porting Unix GUIs to Windows.
The first is to use a portable graphics library such as tcl/tk, X11, or V (and others?). Typically, you will end up with a GUI on Windows that requires some runtime support. With tcl/tk, you'll want to include the necessary library files and the tcl/tk DLLs. In the case of X11, you'll need everyone using your program to have an X11 server installed.
The second method is to rewrite your GUI using Win32 API calls (or MFC with VC++). If your program is written in a fairly modular fashion, you may still want to use Cygwin if your program contains a lot of shared (non-GUI-related) code. That way you still gain some of the portability advantages inherent in using Cygwin.
DJGPP is a similar idea, but for DOS instead of Win32. DJGPP uses a "DOS extender" to provide a more reasonable operating interface for its applications. The Cygwin toolset doesn't have to do this since all of the applications are native WIN32. Applications compiled with the Cygwin tools can access the Win32 API functions, so you can write programs which use the Windows GUI.
You can get more info on DJGPP by following http://www.delorie.com/.
For now you'll just have to kill them manually.
This is a difficult problem, related to the implementation of select() and pipes on Windows 9x. It has been discussed at length on the cygwin mailing list. For an excellent technical description of the problem, see http://sources.redhat.com/ml/cygwin/2000-12/msg00470.html, and related threads.
Win9x does not support the API used by the Cygwin fhandler_dev_tape class. Details at http://sources.redhat.com/ml/cygwin/2000-12/msg00331.html.
Nothing currently.
(Please note: This section has not yet been updated for the latest net release.)
This is a bug fix update to the Beta 20 release.
The main change is an improved version of the Cygwin library although there are also a couple of other minor changes to the tools.
The "-mno-cygwin" flag to gcc now include the correct headers. In 20.0, it included the Cygwin headers which was incorrect.
The "-pipe" flag to gcc works correctly now.
The cygcheck program now reassures users that not finding cpp is the correct behavior.
The "-b" flag to md5sum can now be used to generate correct checksums of binary files.
The libtermcap library has been added to the compiler tools sources. It is the new source of the termcap library and /etc/termcap file.
The less pager (using libtermcap) has been added to the binary distribution.
This version of Cygwin is backwards-compatible with the beta 20 and 19 releases. The library is now much more stable under Windows 9x and the bugs affecting configures under 9x (and NT to a lesser extent) have also been fixed.
The bug that made it necessary to start the value of the CYGWIN environment variable with two leading spaces has been fixed.
The serial support in the select call has been fixed.
Handling of DLLs loaded by non-cygwin apps has been improved. Bugs in dlopen have been fixed.
Passing _SC_CHILD_MAX to the sysconf function now yields CHILD_MAX (63) instead of _POSIX_CHILD_MAX (3).
Several minor path bugs have been fixed. Including the one that caused "mkdir a/" to fail.
The include file sys/sysmacros.h has been added. Added missing protos for wcslen and wcscmp to wchar.h.
__P is now defined in include/sys/cdefs.h. To support that last change, the top-level Makefile.in now sets CC_FOR_TARGET and CXX_FOR_TARGET differently.
Cygwin now exports the following newlib bessel functions: j1, jn, y1, yn.
Several tty ioctl options have been added: TCGETA, TCSETA, TCSETAW, and TCSETAF.
Several functions cope with NULL pointer references more gracefully.
Problems with execution of relative paths via #! should be fixed.
This is a significant update to the Beta 19 release. In addition to an EGCS-based compiler and updated tools, this release includes a new version of the Cygwin library that contains many improvements and bugfixes over the last one.
Starting with this release, we are retiring the "GNU-Win32" name for the releases. We have also dropped the "32" from Cygwin32. This means that you should now refer to the tools as "the Cygwin toolset", the library as "the Cygwin library" or "the Cygwin DLL", and the library's interface as "the Cygwin API".
Because of this name change, we have changed any aspects of the library that involved the name "Cygwin32". For example, the CYGWIN32 environment variable is now the CYGWIN environment variable. API functions starting with cygwin32_ are still available under that form for backwards-compatibility as well as under the new cygwin_-prefixed names. The same goes for the change of preprocessor define from __CYGWIN32__ to __CYGWIN__. We will remove the old names in a future release so please take the minute or two that it will take to remove those "32"s. Thanks and I apologize for the hassle this may cause people. We would have changed the name to "Bob" but that name's already taken by Microsoft... :-)
Why change it? For one thing, not all of the software included in the distributions is GNU software, including the Cygwin library itself. So calling the project "GNU-Win32" has always been a bit of a misnomer. In addition, we think that calling the tools the "Cygwin tools" that use the "Cygwin library" will be less confusing to people.
Also notice that we are now on the spiffy new sourceware.cygnus.com web/ftp site. The old address will work for some unknown period of time (hopefully at least until we get all of the mirrors adjusted).
The latest public EGCS release is now the basis for the compiler used in Cygwin distributions. As a result, EGCS 1.1 is the compiler in this release, with a few additional x86/Cygwin-related patches.
Those of you who are more interested in native Windows development than in porting Unix programs will be glad to know that a new gcc flag "-mno-cygwin" will link in the latest Mingw32 libs and produce an executable that does not use Cygwin.
All of the other development tools have been updated to their latest versions. The linker (ld) includes many important bug fixes. It is now possible to safely strip a DLL with a .reloc section. The windres resource compiler is significantly improved.
Beta 20 also includes upgrades to a number of packages: ash-0.3.2-4, bash 2.02.1, grep-2.2, ncurses 4.2, and less 332. We have added bzip2 0.9.0 to the distribution. And you'll now find that the df utility has joined its other friends from the fileutils package.
The sh executable is still ash from the Debian Linux distribution but no longer has the problematic quoting bug that was present in the Beta 19 release. Control-Cs in the bash shell no longer kill background tasks.
Tcl/tk are upgraded to version 8.1a2 (with additional patches). Compatible versions of tix and itcl are included. These all include Cygwin-compatible configury files so you can do a Unix-style build of the Win32 ports of tcl/tk. expect has been upgraded to 5.26 with some additional Cygwin patches.
In response to customer requests and feedback, Cygnus has developed a better graphical front end to GDB than GDBtk or WinGDB. This tcl-based GUI is shipping today to customers of the GNUPro Toolkit. The instrumentation changes to GDB and the tcl interpreter that was built into GDB are part of the GPL'd source base. But the tcl scripts are not being made available to the net at this time. For this reason, you will only find a command-line version of gdb in this Cygwin release.
DJ Delorie has written a new "cygcheck" program that will print out useful information about how your Cygwin environment is set up, what DLLs a named executable is loading from where, etc. We hope this will make it easier to help diagnose common setup problems.
The ps utility has been upgraded. It now has several options including shorter and longer output formats.
This version of Cygwin is backwards-compatible with the beta 19 release. You can use the new "cygwin1.dll" with your old B19-compiled executables if you move the old "cygwinb19.dll" out of the way and install a copy of "cygwin1.dll" as "cygwinb19.dll".
Quite a lot of the Cygwin internals have been rewritten or modified to address various issues. If you have a question about specific changes, the winsup/ChangeLog file in the development tools sources lists all changes made to the DLL over the last three years. Following are a few highlights:
We are now using a new versioning scheme for Cygwin. There is now a separate version number for the DLL, the API, the shared memory region interfaces, and the registry interface. This will hopefully make it easier for multiple Cygwin toolsets to coexist in one user environment.
Windows 98 is now supported (it is like Windows 95 from Cygwin's perspective). We still recommend upgrading to Windows NT.
While there is still a lot left to do in improving Cygwin's runtime performance, we have put some effort into this prior to the B20 release. Hopefully you will find that the latest version of Cygwin is faster than ever. In addition, we have plugged several nasty handle leaks associated with opening/closing files and with using ttys.
The lseek call now uses WriteFile to fill gaps with zeros whenever a write is done past an EOF, rather than leaving "undefined" data as Win32 specifies.
Significant work has been done to improve the Cygwin header files.
The Cygwin Support for Unix-style serial I/O is much improved.
Path handling has had another round of fixes/rewrites. We no longer use NT Extended Attributes by default for storing Unix permissions/execute status because the file NT creates on FAT partitions is not scalable to thousands of files (everything slows to a crawl).
Signal handling has also gotten a fair amount of attention. Unfortunately, there are still some problems combining itimers and Windows 9x.
The number of ttys has been upped from 16 to 128.
New API calls included in the DLL: sethostent, endhostent.
As mentioned earlier, all cygwin32_-prefixed functions are now exported with a cygwin_ prefix instead. Please adjust your code to call the newly named functions.
reads of `slow' devices are now correctly interrupted by signals, i.e. a read will receive an EINTR.
This is a major release. It includes a much-updated version of the Cygwin32 library. Because the Cygwin API has changed in incompatible ways, the dll has been renamed cygwinb19.dll to avoid invalidating previously built executables.
Note that a B19-compiled application exec()ing a B18-compiled application will treat the B18-compiled executable as an ordinary Win32 executable. This means that open file descriptors and some other internals will not be inheritted on exec() calls. The reason for this is that different shared memory areas are used by the different versions of the cygwin library. This may or may not be of importance to you depending on what you're doing.
The Beta 19 release of the Cygwin32 library continues to be licensed under the GNU General Public License (GPL).
The PE format definition used by the compiler tools now matches Microsoft's more closely. This should allow better interoperability with other vendors' development tools although more work probably remains to be done in this area. This change invalidates all previously built object (.o) and static library (.a) files so be sure to delete/rebuild old .o and .a files you are using!
Finally, old symlinks are invalidated by this release. The "system" attribute is now used to mark symlinks which significantly speeds up fstat and other file related calls. Either recreate old ones or set their "system" attribute flag so they will be recognized properly.
The new installer takes care of all environment variable settings automatically by installing a shortcut in program files that pulls up a bash prompt with all the correct environment variables set. As a result, the setup process should be much cleaner than in the last release.
For those of you who end up moving the tools around, the batch file that sets up the default environment is called cygnus.bat and is installed in the root of the install directory. Because the tools have been compiled to install in /cygnus/b19, when installed in this location, the tools should "just work" if the bin directory is in your path (no special environment variables are needed). The only exception is MAKE_MODE which needs to be set if you want to get ordinary Unix-like make behavior -- see the make notes below for more information.
Ian Lance Taylor has written a resource compiler called "windres". It can be used to compile windows resources from a textual rc file into a COFF file. The sources are in the binutils subdirectory of the sources.
We have upgraded many of the utilities. Beta 19 includes bash 2.01.1, fileutils 3.16, gawk 3.0.3, patch 2.5, shellutils 1.16, tar 1.12, textutils 1.22, and texinfo 3.11. Bash under Cygwin32 now includes working job control among other improvements.
The sh executable is now ash 0.2 from the Debian Linux distribution. Using this more minimal shell as /bin/sh.exe speeds up configures significantly.
Bison 1.25 has been added.
Tcl/tk are upgraded to version 8.0. Compatible versions of tix and itcl have been added. These all include Cygwin32-compatible configury files so you can do a Unix-style build of the Win32 ports of tcl/tk.
Expect 5.21.3 is included and basically works.
The binaries have been compiled with i686 optimizations turned on which may result in a speed increase on Pentium-based systems although the tools should work on i386 and later chips.
The linker (ld) has been enhanced -- it will now add the idata3 terminator automatically when linking dlls.
kill now supports signal names in arguments. ps now shows process start time information.
Although the default install of the tools should hide this detail, the make utility now defaults to a Win32 mode which uses cmd.exe/command.com as the subshell. This mode allows the use of backslashes in filenames. To build Unix programs, you need to set the MAKE_MODE environment variable to "UNIX". This way you will get the old behavior of using sh.exe as the subshell.
The interface is now better defined. It contains libc, libm, and Unix compatability calls. It no longer contains exports for libgcc.a. This should result in a more stable interface. See the calls.texinfo document for interface documentation.
There is now only one environment variable called CYGWIN32 that controls the overall behavior of the dll:
set CYGWIN32=[no]title [no]strip_title [no]binmode [no]glob strace=mask:cache,file [no]tty
So if you "set CYGWIN32=title tty", then you would get tty support (see below) and have the current running process listed in the title bar.
B19 adds support for:
* tty and pseudo-tty devices. For now, ttys default to off because taking over the console causes problems with using non-Cygwin console programs in a Cygwin console. To turn it on, set the environment variable CYGWIN32 to include "tty". * Hard links (requires NT on an NTFS filesystem). When not possible (on non-NTFS filesystems), link() will make a copy of the file in question as it has done in previous releases. * The SIGWINCH signal. If tty handling is enabled then the process will receive a SIGWINCH signal when the screen size changes. * Additional terminal escape sequences recognized: scroll region setting via <ESC>[n1;n2r and setting the console title using xterm escape sequence: <ESC>]2;new title^G .
The following calls have been added:
* ptsname, grantpt, unlockpt * login, logout, ttyslot, ctermid * cfgetispeed, cfgetospeed, cfsetispeed, cfsetospeed * setitimer, getitimer, ftime, tzset * wait3, wait4, pause, sigpause * getpgid, killpg, setegid (stub) * strlwr, strupr * sexecve, sexecl, sexecle, sexeclp, sexeclpe, sexecv, sexecp, sexecvpe * rcmd, rresvport, rexec * strsignal, strtosigno * dlopen, dlsym, dlclose, dlerror * inet_netof, inet_makeaddr * socketpair * fpathconf, realpath, chroot (stub) * initgroups (stub), getgroups * random, srandom
The following calls have been removed:
* ScreenCols, ScreenGetCursor, ScreenRows, ScreenSetCursor * getkey, kbhit * crypt (stub) * all libgcc.a exports
The Winsock dll (wsock32.dll) is no longer implicitly linked into the Cygwin32 dll. Instead, it is explicitly loaded with LoadLibrary the first time a process calls a Cygwin32 networking function. This speeds up most processes significantly (configures by about 20%).
The signal-related code has been rewritten from scratch. Ditto for most of the path handling code.
The globbing and getopt code has been replaced with BSD-derived code. The regexp code has been replaced with Henry Spencer's PD implementation.
Doug Lea's malloc is now being used as the default malloc exported by cygwin. This malloc balances speed and compactness very nicely but is more unforgiving when attempts are made to free already freed memory, i.e., a segmentation violation will occur.
The bsearch call has been rewritten.
Alt Gr-key behavior has been changed in this release. The left alt-key still produces ESC-key sequence. The right alt (Alt Gr)-key now produces characters according to national keyboard layouts.
Processes no longer write their name in the title bar unless you include "title" in the CYGWIN32 environment variable (see above).
Multiple cygwin.dlls no longer use the same memory space unless they are identical (built at the same time). This allows multiple dlls with incompatible shared memory usage to be run simultaneously. It also facilitates debugging a buggy cygwin.dll. By keeping only a single copy of the latest cygwin.dll on your system, you can be assured of having all cygwin processes exist in the same shared memory space.
The slash mount no longer defaults to C:. It now defaults to the system drive letter (where the OS is installed).
The standard dl* dynamic library loader functions are now available. Cygwin32 B19 now correctly copies data after a fork and automatically reloads any DLLs loaded in the parent process. In addition, dlls will now be correctly initialized when loaded and global constructors will be called. Global destructors will be called when the DLL is detached. Handles gotten from dlopen or dlsym in the parent will be accessible in a forked child. The LD_LIBRARY_PATH environment variable is used in the dlopen search.
Include the file <cygwin32/cygwin_dll.h> in a cygwin32 created .dll and use the line DECLARE_CYGWIN_DLL(dll-entry-point) to produce .dlls that can be used with these functions.
This is a major release. The new cygwin.dll is still backwards-compatible with previously linked applications but contains significant changes.
We have completely changed the installation process to make use of an InstallShield5-based installer. This should reduce the number of installation problems people have experienced in the past. However, it is still necessary to set environment variables by hand, as explained in the README.txt accompanying the distribution. (Future gnu-win32 installers may include the capability to do this automatically).
GCC compilation times have been improved by 20-30% by using spawn() instead of fork().
GCC accepts both Win32 and POSIX paths/path lists in its environment variables (COMPILER_PATH, LIBRARY_PATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH)
GDB comes with a tcl/tk-based GUI (gdbtk). You can still invoke the command line gdb by invoking it with "gdb -nw".
Bash verifies that /tmp exists and is a directory upon startup. It complains if this isn't the case.
Running gcc or ld with "-s" used to create invalid executables. The bug in bfd that was responsible for this has been fixed.
The conflict between String.h and string.h (and other such pairs of header files) where you include one and get the other has been fixed.
The top level install-sh script tries to install foo.exe if asked to install foo when foo's not present. This fixes many installs of Unix software.
Dlltool has preliminary support for the IMPORT declaration in .def files when invoked with -I. Feel free to experiment with it but once this functionality is tested more extensively this flag may go away.
Time is upgraded to version 1.7.
Make is upgraded to version 3.75.
Make accepts both Win32 and POSIX path lists in the VPATH variable.
The following is now supported:
* UNC paths * Reverse index escapes in console code * Blocking select()s on a combination of sockets/handles * Directory symlinks. * Reparenting of child processes.
The following calls have been added:
* mmap(), mprotect(), msync(), munmap(). fork() changed to support these. * fsync(), statfs(), fstatfs(). * getprotobynumber() and getservbyport(). * get_osfhandle(), cwait(). * spawnl(), spawnle(), spawnlp(), spawnlpe(), spawnv(), spawnve(), spawnvp(), spawnvpe(). * nice(). * sigpending(), sigsuspend() * Under NT only, chown(), getgrgid(), getgrnam(), endgrent(), getgrent(), setpwend(), getpwent(), endpwent(). Win95 still has these as stubs.
Significantly better signals / exception handling support added. The kill signal works much better now (control-C works in bash).
Shell scripts now run the shell specified after the #! instead of always defaulting to /bin/sh.
Floating point registers are now properly initialized in the crt0.o.
Opening non-disk files such as com ports no longer check to see if they are symlinks or executables.
The console title now is set to the name of the running process.
Winsock is now initialized upon app startup.
Moved reent_data from private address space to cygwin.dll.
The system() call now invokes spawnvp() instead of fork()/exec().
Support for NT extended attributes has been added but is disabled for now because it slowed things down too much. We want to use them to remember info about symlink and executable status of files.
Under NT only, utilities mkpasswd and mkgroup can generate a valid /etc/passwd and /etc/group.
Earlier releases stored mount points in the registry under "Cygnus Support". This changed to "Cygnus Solutions" starting with beta 18. Either use a registry editor (regedit under NT) to rename the old entry or just redo your mount points and the cygwin.dll will automatically create the new one for you.
Mount points can now be up to MAX_PATH in length instead of 30 characters.
A patch has been applied to make Win 95 configure work again.
ld has been changed to make "a.exe" be the default executable name.
It is now possible to rebuild the tools natively under x86 NT when the full Cygnus Developers' Kit (CDK) and the User Tools are both installed correctly.
While the cygwin.dll underwent substantial changes, none of them prevent you from using previously built applications The new dll is compatible with beta 16 to the best of our knowledge. Beta 14-built programs will continue to fail with the beta 17 dll -- you will have to relink them before they will work.
The winsup files that make up the Cygwin32 API are now under the GNU General Public License. See the accompanying press release for more information.
Gcc now links by default against -lkernel32 and also against -luser32 -lgdi32 -lcomdlg32 when mwindows is set. Another major change is that when creating an executable, gcc will now create foo.exe when given a -o argument of foo.
Dlltool has patches to make it better handle the --subsystem argument that allows choosing console vs. GUI among other options. ld has been changed to have a much larger stack reserve size. This is necessary when rebuilding the toolchain natively under NT.
The C++ headers can now be found given a correctly set GCC_EXEC_PREFIX environment variable.
New versions of fileutils and make are included. Findutils has been added.
Scott Christley's headers and def files for the standard Win32 dlls have been integrated. Anything present only in the previous Cygnus headers has been added in the appropriate places. There are placeholder files with the standard Win32 header names that pull in our headers so programs that try to include specific headers should continue to work. Having more complete headers should make Win32 native programming easier.
Select has been rewritten from scratch. The new one can deal with all sockets, handles and sockets always ready, all handles. Handles and sockets with timeout not implemented yet. Select now does blocking and doesn't spin cpu.
File handling has been largely rewritten: The fhandler array has been moved into local memory instead of shared memory. This makes a number of things behave better. Lots of changes to support this. There is now fairly complete ansi/vt100 console support. Some new file locking support has been added. Arrow keys are now supported.
Process handling much improved.
Significant serious bugs in fork() fixed.
The system() call now works.
unlink() now chmods read-only files to writable before attempting to delete a file. This fixes the outstanding problem where rm can't delete read-only files saying "out of queue slots" repeatedly.
Text mode read has been rewritten.
New syslog code allows logging to event log under NT, file under Win 95.
Symlinks are enabled.
readv() and writev() have been written and exported.
For MS compatibility, we now export functions in the dll as _funcname in addition to funcname. I would suggest not making use of this fact unless you are building code that already accesses C library calls in this way.
Almost all of the source code is now in C++ files.
Path handling has been completely rewritten. To refer to drive Q: in bash, you can now refer to //q/. Alternatively, type "mount Q: /q" to have drive Q: show up as /q.
We now pass the Plum Hall positive C conformance tests on the i386 under Windows 95 and NT 4.0b2.
Fork was previously not accessible inside the dll. This is no longer the case which should allow us to add working system and popen calls.
getdomainname works (it used to just return "cygnus.com") by getting information from registry.
Fixed readdir bug that set errno improperly. This fixed the problem with diff not working across directories.
Better error checking in signal functions. Initialize winsock in cygwin32_socket with checkinit call (fixes bug that required calling any function that did this first).
New functions: sigaddset, sigismember, sigfillset, sigemptyset.
Removed extra underscores present in sysdef files.
There is a now a major and a minor version number associated with the cygwin.dll. The major number changes only when incompatible changes are made, the minor number changes when significant changes are made to the dll that don't require relinking of old apps.
Changed value of HZ in include/sys/param.h to correct value of 1000. (Fixes bug people reported about "time sleep 5" returning 50).
Assorted exception handling fixes for both i386 and ppc processors.
Assorted time-related fixes required for Cygnus Kerberos work. New time functions: gmtime, corelocaltime
Assorted spawn and fork fixes.
Pseudo-Unix process handling added -- new ps and kill commands added
Control-Z's are now handled as a valid EOF token in files opened as text. lseek now always operates in binary mode.
Select revamped.
Various other changes. For more detailed information, consult the file in the source code winsup/ChangeLog.
Preprocessor define scheme changed. Apps should now use _WIN32 instead of __WIN32__ to check for access to Win32 API and __CYGWIN32__ to check for presence of the Cygwin32 environment.
We are no longer including GNU findutils, GNU dbm, GNU bison, GNU less, ncurses, ftp, finger, rcl, cvtres, or V. This may or may not change in the future.
You must relink old apps you built with prior releases with the new cygwin.dll.
Some bugs have been fixed. GDBM and m4 are in the release. GCC now uses the standard install directories for cc1 etc.
A port of V to gnu-win32 is included. You can now write graphics applications which will run on Unix or Windows unchanged. Some parts of V work on the PPC too.
If you call any programs from the standard DOS shell, then the DLL will expand all the wildcards (glob) found in the arguments on the command line. So ls *.exe will do what you think it should, even if you're not in bash.
ncurses and less are included. The DLL's emulation of a vt100 isn't complete, so ncurses doesn't do all that it should. Hence less is more or less useless. This can be fixed with a new DLL. (If you want to use something which uses curses, be sure to set your TERM and HOME envirionment variables)
If you leave out main, then the libraries will try and call WinMain in the usual way.
^C works much better on Windows 95. It's still not quite right, but at least most times it quits what you're doing, and most times doesn't crash your machine.
You can start more than one concurrent bash session.
Some networking support has been added. Even though telnet.exe is provided, I know that it doesn't work, so please don't send me bug reports.
You will have to relink your applications to go with the new DLL.
The DLL is released in its own .zip file too, so you don't have to download a load of other stuff if you dont want to.
Files are opened in binary mode, unless the registry is fiddled with.
The `cat >foo <<EOF bug is fixed.
The symlink cookie has changed, so old links wont work any more.
Two resource tools are provided (untested).
More windows header files are provided. WxWindows almost compiles.
You can get to a raw floppy with `/dev/fd0 or `/dev/fd1.
You can have two filenames with the same name and different case in the same directory.
Stat now fills in the st_nlink field for directories, so find works better.
This version is much more stable than any previous version, and will stay running long enough to configure and build itself on my NT box.
This version is also available in PowerPC versions. The PowerPC compiler doesn't do stack probing, so some applications won't work, or they'll only work on some input data - e.g. the demo "hello world" will compile, but gcc will crash compiling the dhrystone benchmark.
There's a new registry variable "fmode=binary" which controls whether the tools always open files in binary mode (unless overridden with O_TEXT), or always open files in text mode (unless overridden with O_BINARY).
Filesystems can be mounted with the mixed_case flag. This allows you to use filenames with the same spelling, but different case in the same directory.
I haven't tested or even used some of the packages that I've provided. I compiled them, and then fixed the obvious "the file should have been opened in binary mode" problems.
I've already had reports of some of it not working correctly on Windows 95. I don't have a simple to use Windows 95 configuration, but when I did try "it worked for me". This may be another manifestation of the bug which makes bash hang sometimes under NT.
You can call non- gnu-win32 applications from bash.
You can mount other directories using the mount command.
Minimal ANSI terminal emulation included.
Packages split into smaller and more logical lumps.
/d<name> mechanism gone.
Initial support for the PowerPC added.
Something broke on the way to the ftp site.
You can pass environment variables around in bash.
Lots more stuff provided precompiled.
Diffs to standard FSF release provided.
It self-hosts.
It supports symbolic links.
The directory layout has changed to be more unix like.
The way that you get to non-c drives is new - i:\foo.cc is now /di/foo.cc
Nasty bug found and fixed in fork.
CPP will now search the directories you supply in env names.
I've put all of libc and libm into a shared library, This drastically reduces the size of some binaries. e.g., ls goes from 82,949 bytes to 26,624. "Hello World" is 2564 bytes long. This is the first stage in greatly speeding up some of the stuff that's going on behind the curtain.
Different processes communicate using shared memory.
Some trivial use of the registry is made.
DLLTOOL is now *much* faster.
Some small problems have been fixed in the way that DLLs were layed out.
GDB works.
GCC now emits debug info which can make **huge** executables Fortunately, strip works too.
More work has been done to make quoting work.
Simple termios support added to newlib.
Much nicer way of describing paths, eg //c/foo is c:\foo.
Works again on Win 95 (which is why -6 wasn't advertised).
Permissions are faked better.
Source of demos available without having to ftp the entire win32 binary tree.
Can now generate DLLs, tiny demo included. tcl, byacc, fileutils, diff, make included.
Bug preventing anything from running on recent versions of Win95 fixed.
vfork and exec oddities fixed.
Import libraries are now really libraries and not just .o files.
Debugging info stripped from images and libraries; it's just bloat until gdb works.
I've filled in the four major import libraries.
The win*.h files are now installed into <foo>/include rather that <foo>/include/sys, so more things will compile out of the box.
PE support is fixed. Programs run on NT 3.1, NT 3.5, NT 3.51 and Windows 95.
You can build GUI programs.
.DEF files for three other DLL's started.
New GUI demo program.
C library distinguishes between text and binary files consequently the text files generated by the tools have the familiar ^M at the end of the line which DOS likes so much.
Doug Evans of Cygnus has added a load of fancy support for execve, opendir and various other cool things.
Exception handling is better.
Was so long ago we don't remember.
(Please note: This section has not yet been updated for the latest net release.)
Chris Faylor (cgf@cygnus.com) is behind many of the recent changes in Cygwin. Prior to joining Cygnus, he contributed significant fixes to the process control and environ code, reworked the strace mechanism, and rewrote the signal-related code from scratch as a Net contributor. In addition to continuing to make technical contributions, Chris is also currently the group's manager.
Geoffrey Noer (noer@cygnus.com) took over the Cygwin project from its' initial author Steve Chamberlain in mid-1996. As maintainer, he produced Net releases beta 16 through 20; made the development snapshots; worked with Net contributors to fix bugs; made many various code improvements himself; wrote a paper on Cygwin for the 1998 Usenix NT Symposium; authored the project WWW pages, FAQ, README; etc.
DJ Delorie (dj@cygnus.com) has done important work in profiling Cygwin, worked on the Dejagnu automated testing framework, merged the dlltool functionality into ld, wrote a good deal of the Cygwin Users' Guide, authored the cygcheck utility, and made automated snapshots available from our project WWW page.
Steve Chamberlain (sac@transmeta.com) designed and implemented Cygwin in 1995-1996 while working for Cygnus. He worked with the Net to improve the technology, ported/integrated many of the user tools for the first time to Cygwin, and produced all of the releases up to beta 14.
Marco Fuykschot (marco@ddi.nl) and Peter Boncz (boncz@ddi.nl) of Data Distilleries contributed nearly all of the changes required to make Cygwin thread-safe. They also provided the pthreads interface.
Sergey Okhapkin (sos@prospect.com.ru) has been an invaluable Net contributor. He implemented the tty/pty support, has played a significant role in revamping signal and exception handling, and has made countless contributions throughout the library. He also provided binaries of the development snapshots to the Net after the beta 19 release.
Mumit Khan (khan@xraylith.wisc.edu) has been most helpful on the EGCS end of things, providing quite a large number of stabilizing patches to the compiler tools for the B20 release.
Corinna Vinschen <corinna@vinschen.de> has contributed several useful fixes to the path handling code, console support, improved security handling, and raw device support.
Philippe Giacinti (giac@dalim.de) contributed the implementation of dlopen, dlclose, dlsym, dlfork, and dlerror in Cygwin.
Many other people at Cygnus have made important contributions to Cygwin. Tobin Brockett wrote the InstallShield-based installer for the beta 19 and 20 releases. Ian Lance Taylor did a much-needed rework of the path handling code for beta 18, and has made many assorted fixes throughout the code. Jeremy Allison made significant contributions in the area of file handling and process control, and rewrote select from scratch. Doug Evans rewrote the path-handling code in beta 16, among other things. Kim Knuttila and Michael Meissner put in many long hours working on the now-defunct PowerPC port. Jason Molenda and Mark Eichin have also made important contributions.
Please note that those of us here at Cygnus that work 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!
Most of the tools are covered by the GNU General Public License (GPL), although some are public domain, and others have a X11-style copyright. To cover the GNU GPL requirements, the basic rule is if you give out any binaries, you must also make the source available. For the full details, be sure to read the text of the GNU GPL which follows.
The Cygwin API library found in the winsup subdirectory of the source code is also covered by the GNU GPL. By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all.
Cygwin is currently available for proprietary use only through a proprietary-use license. Please contact sales@cygnus.com for more information.
In accordance with section 10 of the GPL, Cygnus permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL.
This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e., you must provide sources for the cygwin DLL.
See http://www.opensource.org/osd.html for the precise Open Source Definition referenced above.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
675 Mass Ave, Cambridge, MA 02139, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Appendix: How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
This document was generated on 17 March 2001 using texi2html 1.56k.