home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PC Plus SuperCD 45
/
SuperCD45.iso
/
talleres
/
perl
/
wintools
/
cygwin-b20
/
faq.txt
Wrap
Text File
|
1998-12-05
|
143KB
|
3,977 lines
The Cygwin Project FAQ 20.2 for Release B20.1
What is it?
***********
The Cygwin tools are ports of the popular GNU development tools for
Windows NT, 95, and 98. They run thanks to the Cygwin library which
provides the UNIX system calls and environment these programs expect.
With these tools installed, it is possible to write Win32 console or
GUI applications that make use of the standard Microsoft Win32 API
and/or the Cygwin API. As a result, it is possible to easily port many
significant Unix programs without the need for extensive changes to the
source code. This includes configuring and building most of the
available GNU software (including the packages included with the Cygwin
development tools themselves). Even if the development tools are of
little to no use to you, you may have interest in the many standard
Unix utilities provided with the package. They can be used both from
the bash shell (provided) or from the standard Windows command shell.
Is it free software?
====================
Yes. Parts are GNU software (gcc, gas, ld, etc...), parts are
covered by the standard Berkeley 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 commercial (non-GPL'd)
application using Cygwin, you will need the commercial license to Cygwin
that comes with the supported native Win32 GNUPro product. The price
for five users is $7495, which includes the GNUPro Toolkit, Mission
Critical Support for one year, and a commercially licensed version of
the Cygwin library. For more information about the commercial-use
license, please contact info@cygnus.com. All other questions should be
sent to the project mailing list gnu-win32@cygnus.com.
A brief history of the project
==============================
The first thing done was to enhance the development tools (gcc, gdb,
gas, et al) so that they could generate/interpret Win32 native object
files.
The next task was to port the tools to Win NT/95. We could have done
this by rewriting large portions of the source to work within the
context of the Win32 API. But this would have meant spending a huge
amount of time on each and every tool. Instead, we took a substantially
different approach by writing a shared library (cygwin.dll) that adds
the necessary unix-like functionality missing from the Win32 API (fork,
spawn, signals, select, sockets, etc.). We call this new interface the
Cygwin API. Once written, it was possible to build working Win32 tools
using unix-hosted cross-compilers, linking against this library.
From this point, we pursued the goal of producing native tools
capable of rebuilding themselves under Windows 95 and NT (this is often
called self-hosting). Since neither OS ships with standard UNIX user
tools (fileutils, textutils, bash, etc...), we had to get the GNU
equivalents working with the Cygwin API. Most of these tools were
previously only built natively so we had to modify their configure
scripts to be compatible with cross-compilation. Other than the
configuration changes, very few source-level changes had to be made.
Running bash with the development tools and user tools in place,
Windows 95 and NT look like a flavor of UNIX from the perspective of the
GNU configure mechanism. Self hosting was achieved as of the beta 17.1
release.
After adding Windows 98 support to Cygwin in mid-1998, we added
support for the native Microsoft libraries in the compiler which allows
compilation of executables that do not use Cygwin. This is important to
those people who want to use the tools to develop Win32 applications
that do not need the UNIX emulation layer.
Cygwin Resources on the Internet
********************************
FTP Sites
=========
The primary ftp site is
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/'. There are
also several mirrors:
* North America:
* Alberta: `ftp://ftp.reversion.ca/pub/mirrors/cygwin/'
* Arizona: `ftp://ftp.ninemoons.com/pub/cygwin/'
* California:
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/'
* California:
`ftp://ftp.yggdrasil.com/mirrors/site/ftp.cygnus.com/pub/gnu-win32/'
* California (secondary):
`ftp://sourceware.cygnus.com/pub/cygwin/'
* Kansas: `ftp://ftp.the-b.org/pub/cygwin/'
* Tennessee: `ftp://sunsite.utk.edu/pub/cygwin/'
* Central America:
* Costa Rica: `ftp://sunsite.ulatina.ac.cr/gnu-win32/'
* South America:
* Brazil: `ftp://ftp.unicamp.br/pub/gnu/=EXTRA=/cygnus/cygwin/'
* Africa:
* South Africa:
`ftp://ftp.sun.ac.za/sites/sourceware.cygnus.com/pub/cygwin/'
* Asia:
* Japan: `ftp://ring.aist.go.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.etl.go.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.asahi-net.or.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.crl.go.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.astem.or.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.jah.ne.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.saitama-u.ac.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.nacsis.ac.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.exp.fujixerox.co.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.so-net.ne.jp/archives/pc/gnu-win32/'
* Japan: `ftp://ring.ip-kyoto.ad.jp/archives/pc/gnu-win32/'
* Japan: `ftp://sysg.kek.jp/cygnus/cygwin/'
* Japan: `ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/'
* Korea: `ftp://cair-archive.kaist.ac.kr/pub/gnu/gnu-win32/'
* Australasia:
* Australia: `ftp://mirror.aarnet.edu.au/pub/cygwin/'
* Europe:
* Austria: `ftp://gd.tuwien.ac.at/gnu/cygwin/'
* Czech Republic:
`ftp://sunsite.ms.mff.cuni.cz/MIRRORS/sourceware.cygnus.com/pub/cygwin/'
* Denmark: `ftp://sunsite.auc.dk/pub/cygwin/'
* Germany:
`ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin32/mirrors/cygnus/'
* Greece: `ftp://ftp.ntua.gr/pub/pc/cygwin/'
* Hungary: `ftp://ftp.szrmkk.hu/pub/gnu-win32/ftp.cygnus.com/'
* Poland: `ftp://sunsite.icm.edu.pl/pub/cygnus/cygwin/'
* Slovenia: `ftp://sunsite.fri.uni-lj.si/pub/gnu-win32/'
* Spain: `ftp://ftp.rediris.es/mirror/gnu-win32/'
* Sweden: `ftp://ftp.sunet.se/pub/lang/cygwin/'
* Switzerland: `ftp://sunsite.cnlab-switch.ch/mirror/cygwin/'
* UK:
`ftp://sunsite.org.uk/Mirrors/sourceware.cygnus.com/pub/cygwin/'
* UK:
`ftp://ftp.ccp14.dl.ac.uk/ccp14/ftp-mirror/programming/cygnus-gnu-win32/pub/gnu-win32/'
The Cygwin Project WWW Site
===========================
The main WWW page for the Cygwin project is
`http://sourceware.cygnus.com/cygwin/'.
A page containing tool-specific information is
`http://www.cygnus.com/pubs/gnupro/'.
Links to additional documentation are accessible from the main web
page.
Installation Instructions
*************************
Contents
========
The following packages are included in the full release:
Development tools: binutils, bison, byacc, dejagnu, diff, expect,
flex, gas, gcc, gdb, itcl, ld, libstdc++, make, patch, tcl, tix, tk
User tools: ash, bash, bzip2, diff, fileutils, findutils, gawk,
grep, gzip, m4, sed, shellutils, tar, textutils, time
The user tools release only contains the user tools.
Full source code is available for these tools. It is split into
these two units.
Installing the binary release:
==============================
Important! Be sure to remove any older versions of the Cygwin tools
from your PATH environment variable so you do not execute them by
mistake.
Connect to one of the ftp servers listed above and cd to the
directory containing the latest release. On our primary server, that
would be:
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/'.
If you want the development tools and the programs necessary to run
the GNU configure mechanism, you should download the full binary release
called `full.exe'. If you only care about the user tools listed above,
download `user.exe' instead.
If you have an unreliable connection, download the appropriate
binary in smaller chunks instead. For the split cdk installer, get the
files in the `full-split' subdirectory. Once downloaded, combine the
split files at the command prompt by doing a:
copy /b xaa + xab + xac + ... + xak + xal full.exe
del xa*.*
A similar process can be used for the user tools.
Once you have an install executable on your system, run it. If a
previous version of the software is detected, it will offer to
uninstall it for you.
Next it will ask you to choose an install location. The default is
`<system-drive>:\cygnus\cygwin-b20'. Feel free to choose another
location if you would prefer.
Finally, it will ask you for the name of the Program Files folder
shortcut to add. By default, the installer will create a `Cygwin B20'
entry in a folder called `Cygnus Solutions'. When this step is
completed, it will install the tools and exit.
At this point, you should be able to look under the start menu and
select "Cygwin B20". This will pop up a bash shell with all special
environment variables set up for you. If you are running Windows 95 or
98 and are faced with the error message "Out of environment space", you
need to increase the amount of environment space in your config.sys and
try again. Adding the line `shell=C:\command.com /e:4096 /p' should do
the trick if `C:' is your system drive letter.
There are two remaining thing you should do from this prompt.
First, you need to type `mkdir -p /tmp' to ensure that a directory for
temporary files exists for programs that expect to find one there.
Second, if you are installing the full distribution (`full.exe'),
various programs will need to be able to find `/bin/sh'. You should
`mkdir -p /bin' and put a copy of `sh.exe' there, removing the older
version, if present. You can use the `mount' utility to select which
drive letter is mounted as `/'. See the Frequently Asked Questions
(FAQ) file for more information on `mount'.
If you should ever want to uninstall the tools, you may do so via
the "Add/Remove Programs" control panel.
Installing the source code
==========================
Before downloading the source code corresponding to the release, you
should install the latest release of the tools (either the full release
or just the user tools).
Create the directory that will house the source code. `cd' there.
Connect to one of the ftp servers listed above and cd to the
directory containing the latest release. On our primary server, that
would be:
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/'.
If you want the user tools source code, `cd' into the
`user-src-split' subdirectory. Download the files there. If you want
the development tools sources, `cd' into the `dev-src-split'
subdirectory. Download the files there.
Back in the Windows command shell, for the user tools source:
copy /b xba + xbb + xbc + xbd + xbe + xbf + xbg user-src.tar.bz2
del xb*.*
bunzip2 user-src.tar.bz2
tar xvf user-src.tar
For the development tools source:
copy /b xca + xcb + xcc + xcd + ... + xck + xcl dev-src.tar.bz2
del xc*.*
bunzip2 dev-src.tar.bz2
tar xvf dev-src.tar
Both expand into a directory called `src'.
And you should be done...
Upgrading to B20.1
==================
If you downloaded the original B20.0 release, you should definitely
at least upgrade the Cygwin library to the version present in B20.1.
To do this, download the file
`ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/cygwin-b20/cygwin1-20.1.dll.bz2',
decompress it with bunzip2, and then install the dll, replacing the
file cygwin-b20/H-i586-cygwin32/bin/cygwin1.dll in your original
installation of 20.0.
There are some additional patches in a few of the other tools
(including a gcc change that makes -mno-cygwin find the correct header
files). In addition, the tools have been built with a compiled-in path
of /cygnus/cygwin-b20/ which will make some tools such as bison find
their library files without help from environment variables. To
install the full 20.1 release, you will need to download the correct
installer from scratch. It will offer to uninstall the existing
release and replace it with 20.1 (You should choose to uninstall b20 and
proceed).
We have diff files on the ftp site that can be used to upgrade the
original B20.0 sources. 20.0-20.1-dev-src.diff.bz2 upgrades the
development tools sources. 20.0-20.1-user-src.diff.bz2 upgrades the
user tools sources. They come compressed so you'll need to bunzip2 them
before proceeding. As an example, if the development tools are in the
directory called "src" and the patch is in the directory above it, apply
the patch as follows:
cd src
patch -p1 -E < ../20.0-20.1-dev-src.diff
What Unix API calls are supported by Cygwin?
********************************************
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.
ANSI C Library Functions
========================
`' libc stdio (newlib/libc/stdio)
`' clearerr: C 4.9.10.1
`' fclose: C 4.9.5.1, P 8.2.3.2
`' feof: C 4.9.10.2
`' ferror: C 4.9.10.3
`' fflush: C 4.9.5.2, P 8.2.3.4
`' fgetc: C 4.9.7.1, P 8.2.3.5
`' fgetpos: C 4.9.9.1
`' fgets: C 4.9.7.2, P 8.2.3.5
`' fopen: C 4.9.5.3, P 8.2.3.1
`' fprintf: C 4.9.7.3, P 8.2.3.6
`' fputc: C 4.9.7.3, P 8.2.3.6
`' fputs: C 4.9.7.4, P 8.2.3.6
`' fread: C 4.9.8.1, P 8.2.3.5
`' freopen: C 4.9.5.4, P 8.2.3.3
`' fscanf: C 4.9.6.2, P 8.2.3.7
`' fseek: C 4.9.9.2, P 8.2.3.7
`' fsetpos: C 4.9.9.3
`' ftell: C 4.9.9.4, P 8.2.3.10
`' fwrite: C 4.9.8.2, P 8.2.3.6
`' getc: C 4.9.7.5, P 8.2.3.5
`' getchar: C 4.9.7.6, P 8.2.3.5
`' gets: C 4.9.7.7, P 8.2.3.5
`' perror: C 4.9.10.4, P 8.2.3.8
`' printf: C 4.9.6.3, P 8.2.3.6
`' putc: C 4.9.7.8, P 8.2.3.6
`' putchar: C 4.9.7.9, P 8.2.3.6
`' puts: C 4.9.7.10, P 8.2.3.6
`' remove: C 4.9.4.1, P 8.2.4
`' rename: C 4.9.4.2, P 5.5.3.1
`' rewind: C 4.9.9.5, P 8.2.3.7
`' scanf: C 4.9.6.4, P 8.2.3.5
`' setbuf: C 4.9.5.5
`' setvbuf: C 4.9.5.6
`' sprintf: C 4.9.6.5
`' sscanf: C 4.9.6.6
`' tmpfile: C 4.9.4.3, P 8.2.3.9
`' tmpnam: C 4.9.4.4, P 8.2.5
`' vfprintf: C 4.9.6.7
`' ungetc: C 4.9.7.11
`' vprintf: C 4.9.6.8
`' vsprintf: C 4.9.6.9
`' libc string (newlib/libc/string)
`' memchr: C 4.11.5.1
`' memcmp: C 4.11.4.1
`' memcpy: C 4.11.2.1
`' memmove: C 4.11.2.2
`' memset: C 4.11.6.1
`' strcat: C 4.11.3.1
`' strchr: C 4.11.5.2
`' strcmp: C 4.11.4.2
`' strcoll: C 4.11.4.3
`' strcpy: C 4.11.2.3
`' strcspn: C 4.11.5.3
`' strerror: C 4.11.6.2
`' strlen: C 4.11.6.3
`' strncat: C 4.11.3.2
`' strncmp: C 4.11.3.2
`' strncpy: C 4.11.2.4
`' strpbrk: C 4.11.5.4
`' strrchr: C 4.11.5.5
`' strspn: C 4.11.5.6
`' strstr: C 4.11.5.7
`' strtok: C 4.11.5.8
`' strxfrm: C 4.11.4.5
`' libc stdlib (newlib/libc/stdlib, environ.cc,
newlib/libc/include/machine/setjmp.h newlib/libc/include/assert.h)
`' abort: C 4.10.4.1, P 8.2.3.12
`' abs: C 4.10.6.1
`' assert: C 4.2.1.1
`' atexit: C 4.10.4.2
`' atof: C 4.10.1.1
`' atoi: C 4.10.1.2
`' atol: C 4.10.1.3
`' bsearch: C 4.10.5.1
`' calloc: C 4.10.3.1
`' div: C 4.10.6.2
`' exit: C 4.10.4.3, P 8.2.3.12
`' free: C 4.10.3.2
`' getenv: C 4.10.4.4, P 4.6.1.1
`' labs: C 4.10.6.3
`' ldiv: C 4.10.6.2
`' longjmp: C 4.6.2.1
`' malloc: C 4.10.3.3
`' mblen: C 4.10.7.1
`' mbstowcs: C 4.10.8.1
`' mbtowc: C 4.10.7.2
`' qsort: 4.10.5.2
`' rand: C 4.10.2.1
`' realloc: C 4.10.3.4
`' setjmp: C 4.6.1.1
`' srand: C 4.10.2.2
`' strtod: C 4.10.1.4
`' strtol: C 4.10.1.5
`' strtoul: C 4.10.1.6
`' system: C 4.10.4.5
`' wcstombs: C 4.10.8.2
`' wctomb: C 4.10.7.3
`' libc time (times.cc, newlib/libc/time)
`' asctime: C 4.12.3.1
`' gmtime: C 4.12.3.3
`' localtime: C 4.12.3.4, P 8.1.1
`' time: C 4.12.2.4, P 4.5.1.1
`' clock: C 4.12.2.1
`' ctime: C 4.12.3.2
`' difftime: C 4.12.2.2
`' mktime: C 4.12.2.3, P 8.1.1
`' strftime: C 4.11.6.2
`' libc signals (signal.cc, newlib/libc/signal)
`' raise: C 4.7.2.1
`' signal: C 4.7.1.1
`' libc ctype (newlib/libc/ctype)
`' isalnum: C 4.3.1.1
`' isalpha: C 4.3.1.2
`' iscntrl: C 4.3.1.3
`' isdigit: C 4.3.1.4
`' isgraph: C 4.3.1.5
`' islower: C 4.3.1.6
`' isprint: C 4.3.1.7
`' ispunct: C 4.3.1.8
`' isspace: C 4.3.1.9
`' isupper: C 4.3.1.10
`' isxdigit: C 4.3.1.11
`' tolower: C 4.3.2.1
`' toupper: C 4.3.2.2
`' libm math (newlib/libm/math)
`' acos: C 4.5.2.1
`' asin: C 4.5.2.2
`' atan: C 4.5.2.3
`' atan2: C 4.5.2.4
`' ceil: C 4.5.6.1
`' cos: C 4.5.2.5
`' cosh: C 4.5.3.2
`' exp: C 4.5.4.1
`' fabs: C 4.5.6.2
`' floor: C 4.5.6.3
`' fmod: C 4.5.6.4
`' frexp: C 4.5.4.2
`' ldexp: C 4.5.4.3
`' log: C 4.5.4.4
`' log10: C 4.5.4.5
`' modf: C 4.5.4.6
`' pow: C 4.5.5.1
`' sin: C 4.5.2.6
`' sinh: C 4.5.3.2
`' sqrt: C 4.5.5.2
`' tan: C 4.5.2.7
`' tanh: C 4.5.3.3
`' libc misc (newlib/libc/locale, gcc/ginclude/stdarg.h)
`' localeconv: C 4.4.2.1
`' setlocale: C 4.4.1.1, P 8.1.2.1
`' va_arg: C 4.8.1.2
`' va_end: C 4.8.1.3
`' va_start: C 4.8.1.1
POSIX.1/96 Functions
====================
`' Process Primitives (Section 3)
`' fork: P 3.1.1.1
`' execl: P 3.1.2.1
`' execle: P 3.1.2.1
`' execlp: P 3.1.2.1
`' execv: P 3.1.2.1
`' execve: P 3.1.2.1
`' execvp: P 3.1.2.1
`' pthread_atfork: P96 3.1.3.1 - unimplemented
`' wait: P 3.2.1.1
`' waitpid: P 3.2.1.1
`' _exit: P 3.2.2.1
`' kill: P 3.3.2.1
`' sigemptyset: P 3.3.3.1
`' sigfillset: P 3.3.3.1
`' sigaddset: P 3.3.3.1
`' sigdelset: P 3.3.3.1
`' sigismember: P 3.3.3.1
`' sigaction: P 3.3.4.1
`' pthread_sigmask: P96 3.3.5.1
`' sigprocmask: P 3.3.5.1
`' sigpending: P 3.3.6.1
`' sigsuspend: P 3.3.7.1
`' sigwait: P96 3.3.8.1 - unimplemented
`' sigwaitinfo: P96 3.3.8.1 - unimplemented
`' sigtimedwait: P96 3.3.8.1 - unimplemented
`' sigqueue: P96 3.3.9.1 - unimplemented
`' pthread_kill: P96 3.3.10.1 - unimplemented
`' alarm: P 3.4.1.1
`' pause: P 3.4.2.1
`' sleep: P 3.4.3.1
`' Process Environment (Section 4)
`' getpid: P 4.1.1.1
`' getppid: P 4.1.1.1
`' getuid: P 4.2.1.1
`' geteuid: P 4.2.1.1
`' getgid: P 4.2.1.1
`' getegid: P 4.2.1.1
`' setuid: P 4.2.2.1 (stub, sets ENOSYS, returns zero)
`' setgid: P 4.2.2.1 (stub, sets ENOSYS, returns zero)
`' getgroups: P 4.2.3.1
`' getlogin: P 4.2.4.1
`' getlogin_r: P 4.2.4.1 - unimplemented
`' getpgrp: P 4.3.1.1
`' setsid: P 4.3.2.1
`' setpgid: P 4.3.3.1
`' uname: P 4.4.1.1
`' time: C 4.12.2.4, P 4.5.1.1
`' times: P 4.5.2.1
`' getenv: C 4.10.4.4, P 4.6.1.1
`' ctermid: P 4.7.1.1
`' ttyname: P 4.7.2.1
`' ttyname_r: P 4.7.2.1 - unimplemented
`' isatty: P 4.7.2.1
`' sysconf: P 4.8.1.1
`' Files and Directories (Section 5)
`' opendir: P 5.1.2.1
`' readdir: P 5.1.2.1
`' readdir_r: P96 5.1.2.1 - unimplemented
`' rewinddir: P 5.1.2.1
`' closedir: P 5.1.2.1
`' chdir: P 5.2.1.1
`' getcwd: P 5.2.2.1
`' open: P 5.3.1.1
`' creat: P 5.3.2.1
`' umask: P 5.3.3.1
`' link: P 5.3.4.1 (copy file in Win 95, and when link fails in
NT)
`' mkdir: P 5.4.1.1
`' mkfifo: P 5.4.2.1 - unimplemented!!!
`' unlink: P 5.5.1.1
`' rmdir: P 5.5.2.1
`' rename: C 4.9.4.2, P 5.5.3.1
`' stat: P 5.6.2.1
`' fstat: P 5.6.2.1
`' access: P 5.6.3.1
`' chmod: P 5.6.4.1
`' fchmod: P96 5.6.4.1
`' chown: P 5.6.5.1 (stub in Win 95; always returns zero)
`' utime: P 5.6.6.1
`' ftruncate: P96 5.6.7.1
`' pathconf: P 5.7.1.1
`' fpathconf: P 5.7.1.1
`' Input and Output Primitives (Section 6)
`' pipe: P 6.1.1.1
`' dup: P 6.2.1.1
`' dup2: P 6.2.1.1
`' close: P 6.3.1.1
`' read: P 6.4.1.1
`' write: P 6.4.2.1
`' fcntl: P 6.5.2.1 (note: fcntl(fd, F_GETLK,...) is not
implemented (returns -1 with errno set to ENOSYS)).
`' lseek: P 6.5.3.1 (note: only works correctly on binary files)
`' fsync: P96 6.6.1.1
`' fdatasync: P96 6.6.2.1 - unimplemented
`' aio_read: P96 6.7.2.1 - unimplemented
`' aio_write: P96 6.7.3.1 - unimplemented
`' lio_listio: P96 6.7.4.1 - unimplemented
`' aio_error: P96 6.7.5.1 - unimplemented
`' aio_return: P96 6.7.6.1 - unimplemented
`' aio_cancel: P96 6.7.7.1 - unimplemented
`' aio_suspend: P96 6.7.8.1 - unimplemented
`' aio_fsync: P96 6.7.9.1 - unimplemented
`' Device- and Class-Specific Functions (Section 7)
`' cfgetispeed: P96 7.1.3.1
`' cfgetospeed: P96 7.1.3.1
`' cfsetispeed: P96 7.1.3.1
`' cfsetospeed: P96 7.1.3.1
`' tcdrain: P 7.2.2.1
`' tcflow: P 7.2.2.1
`' tcflush: P 7.2.2.1
`' tcgetattr: P96 7.2.1.1
`' tcgetpgrp: P 7.2.3.1
`' tcsendbreak: P 7.2.2.1
`' tcsetattr: P96 7.2.1.1
`' tcsetpgrp: P 7.2.4.1
`' Language-Specific Services for the C Programming Language
(Section 8)
`' abort: C 4.10.4.1, P 8.2.3.12
`' asctime_r: P96 8.3.4.1 - unimplemented
`' ctime_r: P96 8.3.5.1 - unimplemented
`' exit: C 4.10.4.3, P 8.2.3.12
`' fclose: C 4.9.5.1, P 8.2.3.2
`' fdopen: P 8.2.2.1
`' fflush: C 4.9.5.2, P 8.2.3.4
`' fgetc: C 4.9.7.1, P 8.2.3.5
`' fgets: C 4.9.7.2, P 8.2.3.5
`' fileno: P 8.2.1.1
`' flockfile: P96 8.2.6.1 - unimplemented
`' fopen: C 4.9.5.3, P 8.2.3.1
`' fprintf: C 4.9.7.3, P 8.2.3.6
`' fputc: C 4.9.7.3, P 8.2.3.6
`' fputs: C 4.9.7.4, P 8.2.3.6
`' fread: C 4.9.8.1, P 8.2.3.5
`' freopen: C 4.9.5.4, P 8.2.3.3
`' fscanf: C 4.9.6.2, P 8.2.3.7
`' fseek: C 4.9.9.2, P 8.2.3.7
`' ftell: C 4.9.9.4, P 8.2.3.10
`' ftrylockfile: P96 8.2.6.1 - unimplemented
`' funlockfile: P96 8.2.6.1 - unimplemented
`' fwrite: C 4.9.8.2, P 8.2.3.6
`' getc: C 4.9.7.5, P 8.2.3.5
`' getc_unlocked: P96 8.2.7.1 - unimplemented
`' getchar: C 4.9.7.6, P 8.2.3.5
`' getchar_unlocked: P96 8.2.7.1 - unimplemented
`' gets: C 4.9.7.7, P 8.2.3.5
`' gmtime_r: P96 8.3.6.1 - unimplemented
`' localtime_r: P96 8.3.7.1 - unimplemented
`' perror: C 4.9.10.4, P 8.2.3.8
`' printf: C 4.9.6.3, P 8.2.3.6
`' putc: C 4.9.7.8, P 8.2.3.6
`' putc_unlocked: P96 8.2.7.1 - unimplemented
`' putchar: C 4.9.7.9, P 8.2.3.6
`' putchar_unlocked: P96 8.2.7.1 - unimplemented
`' puts: C 4.9.7.10, P 8.2.3.6
`' rand_r: P96 8.3.8.1 - unimplemented
`' remove: C 4.9.4.1, P 8.2.4
`' rewind: C 4.9.9.5, P 8.2.3.7
`' scanf: C 4.9.6.4, P 8.2.3.5
`' setlocale: C 4.4.1.1, P 8.1.2.1
`' siglongjmp: P 8.3.1.1
`' sigsetjmp: P 8.3.1.1
`' strtok_r: P96 8.3.3.1 - unimplemented
`' tmpfile: C 4.9.4.3, P 8.2.3.9
`' tmpnam: C 4.9.4.4, P 8.2.5
`' tzset: P 8.3.2.1
`' System Databases (Section 9)
`' getgrgid: P 9.2.1.1
`' getgrgid_r: P96 9.2.1.1 - unimplemented
`' getgrnam: P 9.2.1.1
`' getgrnam_r: P96 9.2.1.1 - unimplemented
`' getpwnam: P 9.2.2.1
`' getpwnam_r: P96 9.2.2.1 - unimplemented
`' getpwuid: P 9.2.2.1
`' getpwuid_r: P96 9.2.2.1 - unimplemented
`' Synchronization (Section 11)
`' pthread_cond_broadcast: P96 11.4.3.1 - unimplemented
`' pthread_cond_destroy: P96 11.4.2.1 - unimplemented
`' pthread_cond_init: P96 11.4.2.1 - unimplemented
`' pthread_cond_signal: P96 11.4.3.1 - unimplemented
`' pthread_cond_timedwait: P96 11.4.4.1 - unimplemented
`' pthread_cond_wait: P96 11.4.4.1 - unimplemented
`' pthread_condattr_destroy: P96 11.4.1.1 - unimplemented
`' pthread_condattr_getpshared: P96 11.4.1.1 - unimplemented
`' pthread_condattr_init: P96 11.4.1.1 - unimplemented
`' pthread_condattr_setpshared: P96 11.4.1.1 - unimplemented
`' pthread_mutex_destroy: P96 11.3.2.1 - unimplemented
`' pthread_mutex_init: P96 11.3.2.1 - unimplemented
`' pthread_mutex_lock: P96 11.3.3.1 - unimplemented
`' pthread_mutex_trylock: P96 11.3.3.1 - unimplemented
`' pthread_mutex_unlock: P96 11.3.3.1 - unimplemente
`' sem_close: P96 11.2.4.1 - unimplemented
`' sem_destroy: P96 11.2.2.1 - unimplemented
`' sem_getvalue: P96 11.2.8.1 - unimplemented
`' sem_init: P96 11.2.1.1 - unimplemented
`' sem_open: P96 11.2.3.1 - unimplemented
`' sem_post: P96 11.2.7.1 - unimplemented
`' sem_trywait: P96 11.2.6.1 - unimplemented
`' sem_unlink: P96 11.2.5.1 - unimplemented
`' sem_wait: P96 11.2.6.1 - unimplemented
`' Memory Management (Section 12)
`' mlock: P96 12.1.2.1 - unimplemented
`' mlockall: P96 12.1.1.1 - unimplemented
`' mmap: P96 12.2.1.1
`' mprotect: P96 12.2.3.1
`' msync: P96 12.2.4.1
`' munlock: P96 12.1.2.1 - unimplemented
`' munlockall: P96 12.1.1.1 - unimplemented
`' munmap: P96 12.2.2.1
`' shm_open: P96 12.3.1.1 - unimplemented
`' shm_unlink: P96 12.3.2.1 - unimplemented
`' Execution Scheduling (Section 13)
`' pthread_attr_getinheritsched: P96 13.5.1.1 - unimplemented
`' pthread_attr_getschedparam: P96 13.5.1.1 - unimplemented
`' pthread_attr_getschedpolicy: P96 13.5.1.1 - unimplemented
`' pthread_attr_getscope: P96 13.5.1.1 - unimplemented
`' pthread_attr_setinheritsched: P96 13.5.1.1 - unimplemented
`' pthread_attr_setschedparam: P96 13.5.1.1 - unimplemented
`' pthread_attr_setschedpolicy: P96 13.5.1.1 - unimplemented
`' pthread_attr_setscope: P96 13.5.1.1 - unimplemented
`' pthread_getschedparam: P96 13.5.2.1 - unimplemented
`' pthread_mutex_getprioceiling: P96 13.6.2.1 - unimplemented
`' pthread_mutex_setprioceiling: P96 13.6.2.1 - unimplemented
`' pthread_mutexattr_getprioceiling: P96 13.6.1.1 -
unimplemented
`' pthread_mutexattr_getprotocol: P96 13.6.1.1 - unimplemented
`' pthread_mutexattr_setprioceiling: P96 13.6.1.1 -
unimplemented
`' pthread_mutexattr_setprotocol: P96 13.6.1.1 - unimplemented
`' pthread_setschedparam: P96 13.5.2.1 - unimplemented
`' sched_get_priority_max: P96 13.3.6.1 - unimplemented
`' sched_get_priority_min: P96 13.3.6.1 - unimplemented
`' sched_getparam: P96 13.3.2.1 - unimplemented
`' sched_getscheduler: P96 13.3.4.1 - unimplemented
`' sched_rr_get_interval: P96 13.3.6.1 - unimplemented
`' sched_setparam: P96 13.3.1.1 - unimplemented
`' sched_setscheduler: P96 13.3.3.1 - unimplemented
`' sched_yield: P96 13.3.5.1 - unimplemented
`' Clocks and Timers (Section 14)
`' clock_getres: P96 14.2.1.1 - unimplemented
`' clock_gettime: P96 14.2.1.1 - unimplemented
`' clock_settime: P96 14.2.1.1 - unimplemented
`' nanosleep: P96 14.2.5.1 - unimplemented
`' timer_create: P96 14.2.2.1 - unimplemented
`' timer_delete: P96 14.2.3.1 - unimplemented
`' timer_getoverrun: P96 14.2.4.1 - unimplemented
`' timer_gettime: P96 14.2.4.1 - unimplemented
`' timer_settime: P96 14.2.4.1 - unimplemented
`' Message Passing (Section 15)
`' mq_close: P96 15.2.2.1 - unimplemented
`' mq_getattr: P96 15.2.8.1 - unimplemented
`' mq_notify: P96 15.2.6.1 - unimplemented
`' mq_open: P96 15.2.1.1 - unimplemented
`' mq_receive: P96 15.2.5.1 - unimplemented
`' mq_send: P96 15.2.4.1 - unimplemented
`' mq_setattr: P96 15.2.7.1 - unimplemented
`' mq_unlink: P96 15.2.3.1 - unimplemented
`' Thread Management (Section 16)
`' pthread_attr_destroy: P96 16.2.1.1 - unimplemented
`' pthread_attr_getdetachstate: P96 16.2.1.1 - unimplemented
`' pthread_attr_getstackaddr: P96 16.2.1.1 - unimplemented
`' pthread_attr_getstacksize: P96 16.2.1.1 - unimplemented
`' pthread_attr_init: P96 16.2.1.1 - unimplemented
`' pthread_attr_setdetachstate: P96 16.2.1.1 - unimplemented
`' pthread_attr_setstackaddr: P96 16.2.1.1 - unimplemented
`' pthread_attr_setstacksize: P96 16.2.1.1 - unimplemented
`' pthread_create: P96 16.2.2.1 - unimplemented
`' pthread_detach: P96 16.2.4.1 - unimplemented
`' pthread_equal: P96 16.2.7.1 - unimplemented
`' pthread_exit: P96 16.2.5.1 - unimplemented
`' pthread_join: P96 16.2.3.1 - unimplemented
`' pthread_once: P96 16.2.8.1 - unimplemented
`' pthread_self: P96 16.2.6.1 - unimplemented
`' Thread-Specific Data (Section 17)
`' pthread_getspecific: P96 17.1.2.1 - unimplemented
`' pthread_key_create: P96 17.1.1.1 - unimplemented
`' pthread_key_delete: P96 17.1.3.1 - unimplemented
`' pthread_setspecific: P96 17.1.2.1 - unimplemented
`' Thread Cancellation (Section 18)
`' pthread_cancel: P96 18.2.1.1 - unimplemented
`' pthread_cleanup_pop: P96 18.2.3.1 - unimplemented
`' pthread_cleanup_push: P96 18.2.3.1 - unimplemented
`' pthread_setcancelstate: P96 18.2.2.1 - unimplemented
`' pthread_setcanceltype: P96 18.2.2.1 - unimplemented
`' pthread_testcancel: P96 18.2.2.1 - unimplemented
Misc Functions
==============
`' Networking (net.cc) (standardized by POSIX 1.g, which is probably
still in draft?)
`' accept
`' bind
`' connect
`' getdomainname
`' gethostbyaddr
`' gethostbyname
`' getpeername
`' getprotobyname
`' getprotobynumber
`' getservbyname
`' getservbyport
`' getsockname
`' getsockopt
`' herror
`' htonl
`' htons
`' inet_addr
`' inet_makeaddr
`' inet_netof
`' inet_ntoa
`' listen
`' ntohl
`' ntohs
`' rcmd
`' recv
`' recvfrom
`' rexec
`' rresvport
`' send
`' sendto
`' setsockopt
`' shutdown
`' socket
`' socketpair
Of these networking calls, rexec, rcmd and rresvport are
implemented in MS IP stack but may not be implemented in other
vendors' stacks.
`' Other
`' chroot (stub, sets ENOSYS, returns -1)
`' closelog
`' cwait
`' cygwin_conv_to_full_posix_path
`' cygwin_conv_to_full_win32_path
`' cygwin_conv_to_posix_path
`' cygwin_conv_to_win32_path
`' cygwin_posix_path_list_p
`' cygwin_posix_to_win32_path_list
`' cygwin_posix_to_win32_path_list_buf_size
`' cygwin_split_path
`' cygwin_win32_to_posix_path_list
`' cygwin_win32_to_posix_path_list_buf_size
`' cygwin_winpid_to_pid
`' dlclose
`' dlerror
`' dlfork
`' dlopen
`' dlsym
`' endgrent
`' endhostent
`' ffs
`' fstatfs
`' ftime
`' get_osfhandle
`' getdtablesize
`' getgrent
`' gethostname
`' getitimer
`' getmntent
`' getpagesize
`' getpgid
`' getpwent
`' gettimeofday: BSD
`' grantpt
`' initgroups (stub)
`' ioctl
`' killpg
`' login
`' logout
`' lstat
`' mknod (stub, sets ENOSYS, returns -1)
`' memccpy
`' nice
`' openlog
`' pclose
`' popen
`' ptsname
`' putenv
`' random
`' readv
`' realpath
`' regfree
`' rexec
`' select
`' setegid: SVR4 (stub, sets ENOSYS, returns zero)
`' endpwent
`' setenv
`' seterrno
`' seteuid (stub, sets ENOSYS, returns zero)
`' sethostent
`' setitimer
`' setmntent
`' setmode
`' setpassent
`' setpgrp
`' setpwent
`' settimeofday: BSD (stub, set ENOSYS, return -1)
`' sexecl
`' sexecle
`' sexeclp
`' sexeclpe
`' sexeclpe
`' sexecp
`' sexecv
`' sexecve
`' sexecvpe
`' sigpause
`' spawnl (spawn calls are from Windows C library)
`' spawnle
`' spawnlp
`' spawnlpe
`' spawnv
`' spawnve
`' spawnvp
`' spawnvpe
`' srandom
`' statfs
`' strsignal
`' strtosigno
`' swab
`' syslog
`' timezone
`' truncate (SVR4/4.3+BSD)
`' ttyslot
`' unlockpt
`' unsetenv
`' usleep
`' utimes
`' vfork: stub that calls fork
`' vhangup (stub, sets ENOSYS, returns -1)
`' wait3
`' wait4
`' wcscmp
`' wcslen
`' wprintf
`' writev
Question and Answers
********************
Where can I get more information?
=================================
Where's the documentation?
--------------------------
There are links to quite a lot of it on the main Cygwin project WWW
page: `http://sourceware.cygnus.com/cygwin/' Be sure to at least read
the Release Notes on the main WWW page, if there are any.
Tool-specific documentation is available at:
`http://www.cygnus.com/pubs/gnupro/'
How can I join the Cygwin mailing list?
---------------------------------------
Send email to
gnu-win32-request@cygnus.com
with a message body of:
subscribe gnu-win32 <your-email-address-here>
where <your-email-address-here> is your email address.
You can get off the mailing list by sending mail to
gnu-win32-request@cygnus.com
with a message body of:
unsubscribe gnu-win32 <your-email-address-here>
Note that because mail sometimes takes a day or two to get delivered
to the list, there is often a lag of a day or two before you stop
receiving messages after an unsubscribe request is made.
There's an archive of the mailing list in
`http://www.cygnus.com/ml/gnu-win32/'
Why won't you/the mailing list answer my questions?
---------------------------------------------------
Perhaps your question has an answer that's already in the FAQ.
Perhaps nobody has time to answer your question. Perhaps nobody knows
the answer...
Installation and Setup
======================
Why is the install of the tools failing?
----------------------------------------
If you are getting an error message saying "The decompression of %s
failed. There may not be enough free disk space in the TEMP
directory.", read on.
InstallShield has a bug where it fails with this message if there
are more than a certain number of files in your TEMP directory. You
can also get this message if you have files in your TEMP dir named the
same thing InstallShield wishes to name its files (probably from past
runs of other InstallShield install scripts) which it cannot, for some
reason, write over. Perhaps this will be fixed in a future release of
InstallShield.
Until then, clearing out your TEMP directory entirely should do it.
That will get rid of any files with conflicting names and solve the
"too many files" problem as well.
Help! I haven't created /tmp and tools are behaving strangely!
--------------------------------------------------------------
Many Unix tools (bash, byacc, etc.) expect that /tmp always exists.
This is not guaranteed in Win32 land. You should create /tmp or "mount"
the directory of your choice to /tmp to avoid this problem.
Why does bash spew out "49054596: No such file or directory"?
-------------------------------------------------------------
Are you sure you created a /tmp? The bash shell will print a
warning if it doesn't find a /tmp directory.
How do I set /etc up?
---------------------
If you want a valid /etc set up (so "ls -l" will display correct
user information for example) and if you are running NT (preferably
with an NTFS file system), you should just need to create the /etc
directory on the filesystem mounted as / and then use mkpasswd and
mkgroup to create /etc/passwd and /etc/group respectively. Since
Windows 95/98's Win32 API is less complete, you're out of luck if
you're running Windows 95/98.
Bash says that it can't vfork (or just hangs). Why?
----------------------------------------------------
Most often this is because it can't find itself in the path. Make
sure that your path includes the directory where bash lives, before you
start it.
Also make sure you have a valid `/bin/sh.exe'. If you get errors
like 'no such file or directory' when you're trying to run a shell
script, which you know is there, then your problem is probably that bash
can't find `/bin/sh'.
How can I get bash to read my .bashrc file on startup?
------------------------------------------------------
Your .bashrc is read from your home directory specified by the HOME
environment variable. It uses c:\ if HOME is not set. So you need to
set HOME correctly, or move your .bashrc to c:\.
Can I use paths/filenames containing spaces in them?
----------------------------------------------------
Cygwin does support spaces in filenames and paths. That said, some
utilities that use the library may not, since files don't typically
contain spaces in Unix. If you stumble into problems with this, you
will need to either fix the utilities or stop using spaces in filenames
used by Cygwin tools.
Why can't I cd into a shortcut to a directory?
----------------------------------------------
Cygwin does not follow MS Windows Explorer Shortcuts (*.lnk files)
yet. 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.
I'm having basic problems with find. Why?
------------------------------------------
Make sure you are using the find that came with the Cygwin tools 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.
Using Cygwin Releases
=====================
Why aren't man, groff, etc. included in the betas?
--------------------------------------------------
For obvious reasons, it isn't feasible for us to maintain and provide
binary distributions of every tool ported to work with the Cygwin
tools. Instead I think Cygnus should concentrate its efforts on the
Cygwin library and the core development tools. It's likely that a man
command will get added once we get it working to our satisfaction.
Other tools that have been ported should have their changes added to
the official releases so they can be compiled straight from normal
sources for that tool. In cases where that isn't possible, someone
else (possibly Cygnus if that made sense) could maintain the diffs and
have them up for ftp. Maybe we could keep a list of such tools on the
Cygwin Web site...
Where can I find "less"?
------------------------
The less pager binary is available for the first time in the 20.1
release. You will get it if you upgrade. It is also available from
various ftp locations on the Net. Search the mailing list archives for
the details.
Where can I find "more"?
------------------------
If you are looking for the "more" pager, you should use the "less"
pager instead. See the last question and answer for more information.
Where can I find "which"?
-------------------------
While we don't include a which command, you can use the bash built
in "type" command which does something fairly similar.
How can I access other drives?
------------------------------
The best way is to use the "mount" command to mount the drive letter
so that you can refer to it with only single slashes:
bash$ mkdir /c
bash$ mount c:/ /c
bash$ ls /c
....
This is done with textual substitution whenever a file is opened.
So if you're going to do `ls /c/bar' on a mount like the above the guts
will turn that into `ls c:/bar'.
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 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.
Since the beta 16 release, we also support a special means of
accessing other drive letters without using the `mount' command. This
support may disappear in a future Cygwin release because of the
collision between this scheme and UNC pathname support (one character
machine names don't work currently).
To do an "ls" on drive letter f:, do the following:
bash$ ls //f/
Note that you can also access UNC paths in the standard way.
Because of the drive letter shortcut mentioned above, machine names in
UNC paths must be more than one character long.
What does "mount failed: Device or resource busy" mean?
-------------------------------------------------------
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.
How can I share files between Unix and Windows?
-----------------------------------------------
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.
Are mixed-case filenames possible with Cygwin?
----------------------------------------------
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.
What about DOS special filenames?
---------------------------------
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.
When it hangs, how do I get it back?
------------------------------------
If something goes wrong and the tools hang on you for some reason
(easy to do if you try and read a file called aux.sh), first try
hitting ^C to return to bash or the cmd prompt.
If you start up another shell, and applications don't run, it's a
good bet that the hung process is still running somewhere. Use the Task
Manager, pview, or a similar utility to kill the process.
And, if all else fails, there's always the reset button/power switch.
This should never be necessary under Windows NT.
Why the weird directory structure?
----------------------------------
Why are cpp.exe, cc1.exe, etc., not in the bin directory?
Why more than one lib and include directory?
H-i586-cygwin32\lib\gcc-lib\...\egcs-2.91.57\include
x86-cygwin32\include
x86-cygwin32\H-i586-cygwin32\i586-cygwin32\include
This way multiple releases for different hosts and targets can all
coexist in the same tree. H-i586-cygwin32 means hosted on
i586-cygwin32, common files shared by all hosts are in the top level
directories, target-specific files are in the
H-i586-cygwin32/i586-cygwin32 directory, etc...
If you had a server sharing files to a ppc NT machine and an x86 NT
machine, you could have both an H-i586-cygwin32 and an
H-powerpcle-cygwin32 directory without having to duplicate the top level
files that are the same for both hosts. If you built and installed an
i586-cygwin32 x mips-elf cross-compiler, you would have an
H-i586-cygwin32/mips-elf with its target-specific files and some
mips-elf- prefixed binaries in H-i586-cygwin32/bin.
Normally we also have another higher level directory that identifies
the release. Then multiple Cygwin releases can coexist with different
dll versions, giving:
cygnus/b19/H-i586-cygwin32
cygnus/cygwin-b20/H-i586-cygwin32
...
In any case, this does add complexity to the directory structure but
it's worth it for people with more complex installations.
How do anti-virus programs like Cygwin?
---------------------------------------
One person reported that McAfee VirusScan for NT (and others?) is
incompatible with Cygwin. This is because it tries to scan the newly
loaded shared memory in the cygwin.dll, which can cause fork()s to
fail, wreaking havoc on many of the tools.
Why can't I run bash as a shell under NT Emacs?
-----------------------------------------------
Place the following code in your startup file and try again:
(load "comint")
(fset 'original-comint-exec-1 (symbol-function 'comint-exec-1))
(defun comint-exec-1 (name buffer command switches)
(let ((binary-process-input t)
(binary-process-output nil))
(original-comint-exec-1 name buffer command switches)))
Where did the man/info pages go?
--------------------------------
In order to save space and download times, we have stopped providing
the man/info files for the tools with the binary install since we are
not yet providing a man page or info reader. Both types of
documentation are available in a tar file available from the project ftp
site. Or consult the online documentation over the WWW.
Why can't B20's "cygcheck -s" find cpp?
---------------------------------------
This is a confusingly worded warning that will be reworded in future
versions. In fact, cygcheck should normally *not* find cpp; if it does,
it may be a problem (e.g. it might pick up Borland's cpp, which would
cause problems).
Why do I get a message saying Out of Queue slots?
-------------------------------------------------
"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).
Why don't symlinks work on samba-mounted filesystems?
-----------------------------------------------------
Symlinks are marked with "system" file attribute. Samba does not
support this attribute.
Why does df report sizes incorrectly.
-------------------------------------
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?
Has the screen program been ported yet?
---------------------------------------
Screen requires either unix domain sockets or fifoes. Neither of
them have been implemented in Cygwin yet.
Cygwin API Questions
====================
How does everything work?
-------------------------
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.
Are development snapshots for the Cygwin library available?
-----------------------------------------------------------
Yes. They're made whenever anything interesting happens inside the
Cygwin library (usually roughly on a weekly 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 ftp.cygnus.com in
/pub/noer/winsup-snapshot/.
How is the DOS/Unix CR/LF thing handled?
----------------------------------------
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
CYGWIN32 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>.
Is the Cygwin library multi-thread-safe?
----------------------------------------
Not yet but it soon will be.
Cygwin is not multi-thread-safe because:
1) Newlib (out libc/libm) isn't reentrant (although it almost is).
This would have to be fixed or we would have to switch to a libc/libm
that is reentrant.
2) Cygwin locks shared memory areas (shared by multiple processes),
but the per-process data is not locked. Thus, different threads in a
multi-threaded application would have access to it and give rise to
nasty race-conditions.
The Mingw package (what you get when you invoke gcc with
-mno-cygwin) is multi-thread-safe because that configuration doesn't
use Cygwin or newlib. Instead, it uses Microsoft libraries which are
multi-thread-safe for the most part. So as long as the programmer
avoids Microsoft APIs that aren't multi-thread-safe (most are ok), they
should be fine.
Why is some functionality only supported in Windows NT?
-------------------------------------------------------
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.
How is fork() implemented?
--------------------------
Cygwin fork() essentially works like a non-copy on write version of
fork() (like old Unix versions used to do). Because of this it can be
a little slow. In most cases, you are better off using the spawn
family of calls if possible.
Here's how fork works as of beta 18:
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.
How does wildcarding (globbing) work?
-------------------------------------
If an application using CYGWIN.DLL starts up, and can't find the
`PID' environment variable, it assumes that it has been started from
the a DOS style command prompt. This is pretty safe, since the rest of
the tools (including bash) set PID so that a new process knows what PID
it has when it starts up.
If the DLL thinks it has come from a DOS style prompt, it runs a
`globber' over the arguments provided on the command line. This means
that if you type `LS *.EXE' from DOS, it will do what you might expect.
Beware: globbing uses `malloc'. If your application defines
`malloc', that will get used. This may do horrible things to you.
How do symbolic links work?
---------------------------
CYGWIN.DLL 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 support the
system attribute, symlinks do not work on network drives.
Why do some files, which are not executables have the 'x' type.
---------------------------------------------------------------
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.
How secure is Cygwin in a multi-user environment?
-------------------------------------------------
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).
How do the net-related functions work?
--------------------------------------
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.
I don't want Unix sockets, how do I use normal Win32 winsock?
-------------------------------------------------------------
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.
What version numbers are associated with Cygwin?
------------------------------------------------
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.
Why isn't _timezone set correctly?
----------------------------------
Did you explicitly call tzset() before checking the value of
_timezone? If not, you must do so.
Programming Questions
=====================
Why is gcc failing?
-------------------
If the error is "gcc: installation problem, cannot exec `cpp': No
such file or directory", the GCC_EXEC_PREFIX environment variable
hasn't been set correctly. The current release does not need
GCC_EXEC_PREFIX set - it should be able to find cpp regardless of the
install location. But if you have it set incorrectly, you may still
see this message.
Why can't bison find bison.simple or bison.hairy?
-------------------------------------------------
If you are getting a warning to this effect, you need to set the
BISONLIB environment variable. The value should be the directory in
which bison.simple and bison.hairy are installed. This will be the
path leading up to and including the `share' directory of the top-level
of the binary distributions. For example, on some systems, you would
want to set it to `C:/cygnus/cygwin-b20/share'.
Why is make behaving badly?
---------------------------
Starting with the beta 19 release, make defaults to a win32 mode in
which backslashes in filenames are permitted and cmd.exe/command.com is
used as the sub-shell. In this mode, escape characters aren't allowed
among other restrictions. For this reason, you must set the
environment variable MAKE_MODE to UNIX to run make on ordinary Unix
Makefiles. Here is the full scoop:
MAKE_MODE selects between native Win32 make mode (the default) and a
Unix mode where it behaves like a Unix make. The Unix mode does allow
specifying Win32-style paths but only containing forward slashes as the
path separator. The path list separator character is a colon in Unix
mode.
Win32 mode expects path separators to be either / or \. Thus no
Unix-style \s as escape are allowed. Win32 mode also uses
cmd.exe/command.com as the subshell which means "copy" and "del" (and
other shell builtins) will work. The path list separator character is
semi-colon in Win32 mode. People who want an nmake-like make might
want to use this mode but no one should expect Unix Makefiles to
compile in this mode. That is why the default b19 install sets
MAKE_MODE to UNIX.
Why the undefined reference to "WinMain@16"?
--------------------------------------------
Try adding an empty main() function to one of your sources.
How do I use Win32 API calls?
-----------------------------
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.
How do I compile a Win32 executable that doesn't use Cygwin?
------------------------------------------------------------
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.
How do I make the console window go away?
-----------------------------------------
The default during compilation is to produce a console application.
It you are writing a GUI program, you should either compile with
-mwindows as explained above, or add the string
"-Wl,-subsystem,windows" to the GCC commandline.
Why does make complain about a "missing separator"?
---------------------------------------------------
This problem usually occurs as a result of someone editing a Makefile
with a text editor that replaces tab characters with spaces. Command
lines must start with tabs.
Why can't we redistribute Microsoft's Win32 headers?
----------------------------------------------------
Subsection 2.d.f of the `Microsoft Open Tools License agreement'
looks like it says that can 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 can't agree to. Fortunately, we have our own
Win32 headers which are pretty complete.
How do I link against .lib files?
---------------------------------
1. Build a C file with a function table. In that table you should
put all functions you want to use. This is to force 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 with 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)
How do I rebuild the tools on my NT box?
----------------------------------------
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
How can I compile a powerpc NT toolchain?
-----------------------------------------
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!
How can I compile an Alpha NT toolchain?
----------------------------------------
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.
How can I adjust the heap/stack size of an application?
-------------------------------------------------------
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'
How can I find out which dlls are needed by an executable?
----------------------------------------------------------
objdump -p provides this information.
How do I build a DLL?
---------------------
There's documentation that explains the process on the main Cygwin
project web page (http://sourceware.cygnus.com/cygwin/).
How can I set a breakpoint at MainCRTStartup?
---------------------------------------------
Set a breakpoint at *0x401000 in gdb and then run the program in
question.
How can I build a relocatable dll?
----------------------------------
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.
How can I debug what's going on?
--------------------------------
You can debug your application using `gdb'. Make sure you compile
it with the -g flag! If your application calls functions in MS dlls,
gdb will complain about not being able to load debug information for
them when you run your program. This is normal since these dlls don't
contain debugging information (and even if they did, that debug info
would not be compatible with gdb).
Can I use a system trace mechanism instead?
-------------------------------------------
Yes. At the most basic level, you can set the `STRACE' environment
variable to `1', and get a whole load of debug information on your
screen whenever a Cygwin app runs. This is an especially useful tool
to use when tracking bugs down inside the Cygwin library. `STRACE' can
be set to different values to achieve different amounts of granularity.
You can set it to `0x10' for information about syscalls or `0x800' for
signal/process handling-related info, to name two. The strace
mechanism is well documented in the Cygwin library sources in the file
`winsup/include/sys/strace.h'.
The linker complains that it can't find something.
--------------------------------------------------
A common error is to put the library on the command line before the
thing that needs things from it.
This is wrong `gcc -lstdc++ hello.cc'. This is right `gcc hello.cc
-lstdc++'.
I use a function I know is in the API, but I still get a link
-------------------------------------------------------------
error.
The function probably isn't declared in the header files, or the
UNICODE stuff for it isn't filled in.
Can you make DLLs that are linked against libc ?
------------------------------------------------
Yes.
Where is malloc.h?
------------------
Include stdlib.h instead of malloc.h.
Can I use my own malloc?
------------------------
If you define a function called `malloc' in your own code, and link
with the DLL, the DLL *will* call your `malloc'. Needless to say, you
will run into serious problems if your malloc is buggy.
If you run any programs from the DOS command prompt, rather than
from in bash, the DLL will try and expand the wildcards on the command
line. This process uses `malloc' *before* your main line is started.
If you have written your own `malloc' to need some initialization to
occur after `main' is called, then this will surely break.
Can I mix objects compiled with msvc++ and gcc?
-----------------------------------------------
Yes, this should work, as long as you are dealing with C object
files. MSVC C++ uses a different mangling scheme than GNU C++, so you
will have difficulties combining C++ objects.
Can I use the gdb debugger to debug programs built by VC++?
-----------------------------------------------------------
No, not for full (high level source language) debugging. The
Microsoft compilers generate a different type of debugging symbol
information, which gdb does not understand.
However, the low-level (assembly-type) symbols generated by
Microsoft compilers are coff, which gdb DOES understand. Therefore you
should at least be able to see all of your global symbols; you just
won't have any information about data types, line numbers, local
variables etc.
Where can I find info on x86 assembly?
--------------------------------------
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/'
Shell scripts aren't running properly from my makefiles?
--------------------------------------------------------
You need to have . (dot) in your $PATH. You should NOT need to add
/bin/sh in front of each and every shell script invoked in your
Makefiles.
What preprocessor do I need to know about?
------------------------------------------
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++.
Where can I get f77 and objc components for B20 EGCS 1.1?
---------------------------------------------------------
B20-compatible versions of the f77 and objc components are available
from `http://www.xraylith.wisc.edu/~khan/software/gnu-win32/'.
How should I port my Unix GUI to Windows?
-----------------------------------------
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.
Why not use DJGPP ?
-------------------
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/'.
Known/potential Problems in the B20.1 Release
*********************************************
Windows 95 freezing up
======================
While this problem may have been worse under B19, Control-c's in bash
under Win 95 may still be able to lock up the Win 95 kernel, freezing
your machine. This problem can be fixed if you are running the OSR2
version of Win 95 by installing the USB patch available on OSR2 CDs or
on MSDN subscription CDs. More information about OSR2 and the USB patch
is available from `http://www.compuclinic.com/osr2faq/index.html'.
Some programs can't deal with // pathname scheme in arguments
=============================================================
gcc and other tools aren't fully compatible with the current pathname
scheme: it can't grok an argument of -I//d/foo which means it is vital
that when attempting to configure/build UNIX packages, that only normal
paths with single slashes are used.
History
*******
Beta 20.1 Update (Nov 20 1998)
==============================
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.
Changes in specific 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.
Changes in the Cygwin API (cygwin.dll):
---------------------------------------
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.
Release Beta 20 (Oct 30 1998)
=============================
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.
The project has a new name!
---------------------------
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).
Changes in specific tools:
--------------------------
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.
Changes in the Cygwin API (cygwin.dll):
---------------------------------------
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.
Release Beta 19 (Feb 26 1998)
=============================
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.
Changes in specific tools:
--------------------------
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.
Changes in the Cygwin32 API (cygwin.dll):
-----------------------------------------
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.
Release Beta 18 (May 6 1997)
============================
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).
Changes in specific tools:
--------------------------
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.
Changes in the Cygwin32 API (cygwin.dll):
-----------------------------------------
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.
Release Beta 17.1 (Dec 10 1996)
===============================
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.
Release Beta 17 (Dec 7 1996)
============================
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.
Changes in specific tools:
--------------------------
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.
Changes in the Cygwin32 API (cygwin.dll):
-----------------------------------------
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.
Release Beta 16 (Aug 30 1996)
=============================
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.
Release Beta 14 (April 10 1996)
===============================
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.
Release Beta 13 (Feb 9 1996)
============================
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.
Release Beta 12 (Jan 3 1996)
============================
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.
Release Beta 11 (Jan 3 1996)
============================
Something broke on the way to the ftp site.
Release Beta 10 (Dec 5 1995)
============================
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.
Release Beta 9
==============
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.
Release Beta 8
==============
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.
Release Beta 7
==============
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.
Release Beta 6
==============
Can now generate DLLs, tiny demo included. tcl, byacc, fileutils,
diff, make included.
Release Beta 5
==============
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.
Release Beta 4
==============
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.
Release Beta 3
==============
Was so long ago we don't remember.
Who's behind the project?
*************************
I'm Geoffrey Noer (noer@cygnus.com). I've had Cygwin on the brain
since mid-1996 when I became responsible for the project. As Cygwin
maintainer, I produced the Net releases from beta 16 until present, made
the development snapshots, worked with Net contributors to fix bugs,
fixed some myself, etc... Thanks to the success of Cygwin and the
increasing importance of Windows, I now share the responsibility for
Cygwin with Chris Faylor and DJ Delorie under our manager, Eric Bachalo.
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.
DJ Delorie (dj@cygnus.com) has recently joined Cygnus and has been
making himself useful since day one. He did some profiling of Cygwin,
worked on the Dejagnu automated testing framework and ld/dlltool, wrote
a good deal of the Cygwin Users' Guide, and authored the cygcheck
utility.
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 I
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.
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@cityweb.de) has contributed
several useful fixes to the path handling code, console support, and
raw device support.
Philippe Giacinti (giac@dalim.de) contributed the implementation of
dlopen, dlclose, dlsym, dlfork, and dlerror in Cygwin.
Steve Chamberlain (sac@transmeta.com) wrote the original
implementation of Cygwin when he worked for Cygnus. He also produced
all of the releases up to beta 14.
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.
Also many thanks to everyone using the tools for their many
contributions in the form of advice, bug reports, and code fixes. Keep
them coming!
What are the copyrights ?
*************************
The general idea
================
Most of the tools are covered by the GNU General Public License
(GPL), although some are public domain, and others have a Berkeley-style
copyright. To cover the GNU GPL `restrictions', 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 commercial use as part of the
Cygnus GNUPro Toolkit. Customers who purchase the GNUPro Toolkit with
Mission Critical Support for a development team of five or more users
get a commercial version of the Cygwin library. The price for five
users is $7495, which includes the GNUPro Toolkit, Mission Critical
Support for one year, and a commercially licensed version of the Cygwin
library. Please contact info@cygnus.com for more information.
GNU GENERAL PUBLIC LICENSE
==========================
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.