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 `:\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 where 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 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/ where 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 . 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_'. 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 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 [n1;n2r and setting the console title using xterm escape sequence: ]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 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 < 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 /include rather that /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. Copyright (C) 19yy 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. , 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.