Chapter 1. Cygwin Overview
1.5. Expectations for Windows Programmers
Developers coming from a Windows background will find a set of tools capable of writing console or GUI executables that rely on the Microsoft Win32 API. The linker and dlltool utility may be used to write Windows Dynamically Linked Libraries
(DLLs). The resource compiler "windres" is also provided with the native Windows
GNUPro tools. All tools may be used from the Microsoft command line prompt, with full support for normal Windows pathnames.
1.6. Highlights of Cygwin Functionality
1.6.1. Introduction
When a binary linked against the library is executed, the Cygwin DLL is loaded into the application’s text segment. Because we are trying to emulate a UNIX kernel which needs access to all processes running under it, the first Cygwin DLL to run creates shared memory areas that other processes using separate instances of the DLL can access. This is used to keep track of open file descriptors and assist fork and exec, among other purposes. In addition to the shared memory regions, every process also has a per_process structure that contains information such as process id, user id, signal masks, and other similar process-specific information.
The DLL is implemented using the Win32 API, which allows it to run on all Win32 hosts. Because processes run under the standard Win32 subsystem, they can access both the UNIX compatibility calls provided by Cygwin as well as any of the Win32 API calls. This gives the programmer complete flexibility in designing the structure of their program in terms of the APIs used. For example, they could write a Win32-specific
GUI using Win32 API calls on top of a UNIX back-end that uses Cygwin.
Early on in the development process, we made the important design decision that it would not be necessary to strictly adhere to existing UNIX standards like POSIX.1 if it was not possible or if it would significantly diminish the usability of the tools on the
9
