overview2.sgml

cygwin, 著名的在win32下模拟unix操作系统的东东

<sect1 id="ov-ex-unix"><title>Expectations for UNIX Programmers</title>

<para>Developers coming from a UNIX background will find a set of utilities
they are already comfortable using, including a working UNIX shell.  The
compiler tools are the standard GNU compilers most people will have previously
used under UNIX, only ported to the Windows host.  Programmers wishing to port
UNIX software to Windows NT or 9x will find that the Cygwin library provides
an easy way to port many UNIX packages, with only minimal source code
changes.</para>
</sect1>

<sect1 id="ov-ex-win"><title>Expectations for Windows Programmers</title>
<para>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.</para>
</sect1>

<sect2 id="ov-hi-intro"><title>Introduction</title> <para>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.</para>

<para>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.</para>

<para>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 Win32 platform.  In many cases, an
environment variable can be set to override the default behavior and force
standards compliance.</para>
</sect2>

<sect2 id="ov-hi-win9xnt"><title>Supporting both Windows NT and 9x</title>
<para>While Windows 95 and Windows 98 are similar enough to each other that we
can safely ignore the distinction when implementing Cygwin, Windows NT is an
extremely different operating system.  For this reason, whenever the DLL is
loaded, the library checks which operating system is active so that it can act
accordingly.</para>

<para>In some cases, the Win32 API is only different for
historical reasons.  In this situation, the same basic functionality is
available under Windows 9x and NT but the method used to gain this
functionality differs.  A trivial example: in our implementation of
uname, the library examines the sysinfo.dwProcessorType structure
member to figure out the processor type under Windows 9x.  This field
is not supported in NT, which has its own operating system-specific
structure member called sysinfo.wProcessorLevel.</para>

<para>Other differences between NT and 9x are much more fundamental in
nature.  The best example is that only NT provides a security model.</para>
</sect2>

<sect2 id="ov-hi-perm"><title>Permissions and Security</title>
<para>Windows NT includes a sophisticated security model based on Access
Control Lists (ACLs).  Cygwin maps Win32 file ownership and permissions to the
more standard, older UNIX model by default.  Cygwin version 1.1 introduces
support for ACLs according to the system calls used on newer versions of
Solaris. This ability is used when the `ntsec' feature is switched on which
is described in another chapter.
The chmod call maps UNIX-style permissions
back to the Win32 equivalents.  Because many programs expect to be able to find
the /etc/passwd and /etc/group files, we provide utilities that can be used to
construct them from the user and group information provided by the operating
system.</para>

<para>Under Windows NT, the administrator is permitted to chown files.  There
is no mechanism to support the setuid concept or API call since Cygwin version
1.1.2.  With version 1.1.3 Cygwin introduces a mechanism for setting real
and effective UIDs under Windows NT/W2K. This is described in the ntsec
section.</para>

<para>Under Windows 9x, the situation is considerably different.  Since a
security model is not provided, Cygwin fakes file ownership by making all
files look like they are owned by a default user and group id.  As under NT,
file permissions can still be determined by examining their read/write/execute
status.  Rather than return an unimplemented error, under Windows 9x, the
chown call succeeds immediately without actually performing any action
whatsoever.  This is appropriate since essentially all users jointly own the
files when no concept of file ownership exists.</para>

<para>It is important that we discuss the implications of our "kernel" using
shared memory areas to store information about Cygwin processes.  Because
these areas are not yet protected in any way, in principle a malicious user
could modify them to cause unexpected behavior in Cygwin processes.  While
this is not a new problem under Windows 9x (because of the lack of operating
system security), it does constitute a security hole under Windows NT.
This is because one user could affect the Cygwin programs run by
another user by changing the shared memory information in ways that
they could not in a more typical WinNT program.  For this reason, it
is not appropriate to use Cygwin in high-security applications.  In
practice, this will not be a major problem for most uses of the
library.</para>
</sect2>

<sect2 id="ov-hi-files"><title>File Access</title> <para>Cygwin supports
both Win32- and POSIX-style paths, using either forward or back slashes as the
directory delimiter.  Paths coming into the DLL are translated from Win32 to
POSIX as needed.  As a result, the library believes that the file system is a
POSIX-compliant one, translating paths back to Win32 paths whenever it calls a
Win32 API function.  UNC pathnames (starting with two slashes) are
supported.</para>

<para>The layout of this POSIX view of the Windows file system space is stored
in the Windows registry.  While the slash ('/') directory points to the system
partition by default, this is easy to change with the Cygwin mount utility.
In addition to selecting the slash partition, it allows mounting arbitrary
Win32 paths into the POSIX file system space.  Many people use the utility to
mount each drive letter under the slash partition (e.g. C:\ to /c, D:\ to /d,
etc...).</para>

<para>The library exports several Cygwin-specific functions that can be used
by external programs to convert a path or path list from Win32 to POSIX or vice
versa.  Shell scripts and Makefiles cannot call these functions directly.
Instead, they can do the same path translations by executing the cygpath
utility program that we provide with Cygwin.</para>

<para>Win32 file systems are case preserving but case insensitive.  Cygwin
does not currently support case distinction because, in practice, few UNIX
programs actually rely on it.  While we could mangle file names to support case
distinction, this would add unnecessary overhead to the library and make it
more difficult for non-Cygwin applications to access those files.</para>

<para>Symbolic links are emulated by files containing a magic cookie followed
by the path to which the link points.  They are marked with the System
attribute so that only files with that attribute have to be read to determine
whether or not the file is a symbolic link.  Hard links are fully supported
under Windows NT on NTFS file systems.  On a FAT file system, the call falls
back to simply copying the file, a strategy that works in many cases.</para>

<para>The inode number for a file is calculated by hashing its full Win32 path.
The inode number generated by the stat call always matches the one returned in
d_ino of the dirent structure.  It is worth noting that the number produced by
this method is not guaranteed to be unique.  However, we have not found this to
be a significant problem because of the low probability of generating a
duplicate inode number.</para>

<para>Chroot is supported since release 1.1.3. Note that chroot isn't
supported native by Windows. This implies some restrictions. First of all,
the chroot call isn't a privileged call. Each user may call it. Second, the
chroot environment isn't safe against native windows processes. If you
want to support a chroot environment as, for example, by allowing an
anonymous ftp with restricted access, you'll have to care that only
native Cygwin applications are accessible inside of the chroot environment.
Since that applications are only using the Cygwin POSIX API to access the
file system their access can be restricted as it is intended. This includes
not only POSIX paths but Win32 paths (containing drive letter and/or
backslashes) and CIFS paths (//server/share or \\server\share) as well.</para>