Remove references to older Cygwin releases from documentation

Signed-off-by: Corinna Vinschen <corinna@vinschen.de>

winsup/doc/cygserver.xml

@@ -27,11 +27,6 @@
   passwords in <command>set(e)uid</command> does not require running
   Cygserver.  For details, see <xref linkend="ntsec-setuid-overview"></xref>.
   </para></listitem>
-  <listitem><para>This functionality is no longer used since Cygwin 1.7.6,
-  but the interface is still available:  Control slave tty/pty handle dispersal
-  from tty owner to other processes without compromising the owner processes'
-  security.  Starting with Cygwin 1.7.6 another safe mechanism to share tty/pty
-  handles is used.</para></listitem>
 </itemizedlist>
 
 </sect2>

winsup/doc/cygwinenv.xml

@@ -119,8 +119,8 @@ system call will immediately fail.</para>
 <title>Obsolete options</title>
 
 <para>
-Certain CYGWIN options available in past releases have been removed in
+Certain CYGWIN options available in past releases have been removed over
-Cygwin 1.7 for one reason or another.  These obsolete options are listed
+time for one reason or another.  These obsolete options are listed
 below.</para>
 
 <itemizedlist mark="bullet">
@@ -225,8 +225,8 @@ Windows programs.</para>
 <listitem>
 <para><envar>(no)upcaseenv</envar> - This option could be used to convert
 all environment variables to uppercase.  This was the default behavior in
-releases prior to Cygwin 1.7.  Since keeping the case of environment
+older releases of Cygwin.  Since keeping the case of environment variables
-variables intact is POSIXly correct, Cygwin now does not change the case
+intact is POSIXly correct, Cygwin now does not change the case
 of environment variables, except for a restricted set to maintain minimal
 backward compatibility.  The current list of always uppercased variables is:
 </para>

winsup/doc/faq-api.xml

@@ -278,8 +278,9 @@ shared library.  First of all, since October 1998 every Cygwin DLL has
 been named <literal>cygwin1.dll</literal> and has a 1 in the release name.
 Additionally, there are DLL major and minor numbers that correspond to
 the name of the release, and a release number. In other words,
-cygwin-1.7.1-2 is <literal>cygwin1.dll</literal>, major version 7, minor
+cygwin-2.4.1-1 is <literal>cygwin1.dll</literal>, major version 2, minor
-version 1, release 2.
+version 4, release 1.  -1 is a subrelease number required by the distro
+versioning scheme.  It's not actually part of the Cygwin DLL version number.
 </para>
 <para>The <literal>cygwin1.dll</literal> major version number gets incremented
 only when a change is made that makes existing software incompatible. For

winsup/doc/faq-setup.xml

@@ -709,9 +709,9 @@ easy way to do it. Full instructions for constructing a portable Cygwin
 on CD by hand can be found on the mailing list at
 <ulink url="https://www.cygwin.com/ml/cygwin/2003-07/msg01117.html"/>
 (Thanks to fergus at bonhard dot uklinux dot net for these instructions.)
-Please note that these instructions are rather old and are referring to the
+Please note that these instructions are very old and are referring to the
 somewhat different setup of a Cygwin 1.5.x release.  As soon as somebody set
-this up for Cygwin 1.7, we might add this information here.
+this up for recent Cygwin releases, we might add this information here.
 </para>
 </answer></qandaentry>
 
@@ -719,9 +719,8 @@ this up for Cygwin 1.7, we might add this information here.
 <question><para>How do I save, restore, delete, or modify the Cygwin information stored in the registry?</para></question>
 <answer>
 
-<para>Since Cygwin 1.7, there's nothing important in the registry anymore,
+<para>Cygwin doesn't store anything important in the registry anymore for
-except for the installation directory information stored there for the sake
+quite some time.  There's no reason to save, restore or delete it.
-of setup-x86{_64}.exe.  There's nothing left to manipulate anymore.
 </para></answer></qandaentry>
 </qandadiv>
 

winsup/doc/faq-using.xml

@@ -772,9 +772,8 @@ of this is perl's configuration script, which wants
 tell the difference between files with just different case, so the
 configuration fails.
 </para>
-<para>To help with this problem, Cygwin supports case sensitivity
+<para>To help with this problem, Cygwin supports case sensitivity.  For a
-starting with Cygwin 1.7.0.  For a detailed description how to use that
+detailed description how to use that feature see the Cygwin User's Guide at
-feature see the Cygwin User's Guilde at
 <ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>.
 </para>
 
@@ -793,8 +792,7 @@ interesting.  E.g., the perl distribution has a file called
 letters 'aux' in it will hang.
 </para>
 <para>At least that's what happens when using native Windows tools.  Cygwin
-1.7.0 and later can deal with these filenames just fine.  Again, see the
+can deal with these filenames just fine.  Again, see the User's Guide at
-User's Guide at
 <ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>
 for a detailed description of what's possible with filenames and what is not.
 </para>
@@ -950,14 +948,13 @@ two packages:</para>
 <question><para>Why don't some of my old symlinks work anymore?</para></question>
 <answer>
 
-<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
+<para>Cygwin supports multiple character sets.  Symlinks created with Cygwin
-Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
+are using the UTF-16 character set, which is portable across all character
-portable across all character sets.  Old symlinks were written using your
+sets.  Old symlinks were written using your current Windows codepage, which
-current Windows codepage, which is not portable across all character sets.
+is not portable across all character sets.  If the target of the symlink
-If the target of the symlink doesn't resolve anymore, it's very likely that
+doesn't resolve anymore, it's very likely that the symlink points to a target
-the symlink points to a target filename using native, non-ASCII characters,
+filename using native, non-ASCII characters, and you're now using another
-and you're now using another character set than way back when you created
+character set than way back when you created the symlink.</para>
-the symlink.</para>
 
 <para>Solution: Delete the symlink and create it again under you new Cygwin.
 The new symlink will be correctly point to the target no matter what character
@@ -1054,7 +1051,7 @@ usually all set and you can start the sshd service via
 </answer></qandaentry>
 
 <qandaentry id="faq.using.ssh-pubkey-stops-working">
-<question><para>Why does public key authentication with ssh fail after updating to Cygwin 1.7.34?</para></question>
+<question><para>Why does public key authentication with ssh fail after updating to Cygwin 1.7.34 or later?</para></question>
 <answer>
 
 <para>

winsup/doc/highlights.xml

@@ -74,10 +74,10 @@ a POSIX-compliant one.  The implementation details are safely hidden in the
 Cygwin DLL.  UNC pathnames (starting with two slashes) are supported for
 network paths.</para>
 
-<para>Since version 1.7.0, the layout of this POSIX view of the Windows file
+<para>The layout of this POSIX view of the Windows file system space is
-system space is stored in the <filename>/etc/fstab</filename> file.  Actually,
+stored in the <filename>/etc/fstab</filename> file.  Actually, there is a
-there is a system-wide <filename>/etc/fstab</filename> file as well as a
+system-wide <filename>/etc/fstab</filename> file as well as a user-specific
-user-specific fstab file <filename>/etc/fstab.d/${USER}</filename>.</para>
+fstab file <filename>/etc/fstab.d/${USER}</filename>.</para>
 
 <para>At startup the DLL has to find out where it can find the
 <filename>/etc/fstab</filename> file.  The mechanism used for this is simple.
@@ -130,23 +130,22 @@ 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>Cygwin 1.7 and later supports Extended Attributes (EAs) via the
+<para>Cygwin supports Extended Attributes (EAs) via the linux-specific function
-linux-specific function calls <function>getxattr</function>,
+calls <function>getxattr</function>, <function>setxattr</function>,
-<function>setxattr</function>, <function>listxattr</function>, and
+<function>listxattr</function>, and <function>removexattr</function>.  All EAs
-<function>removexattr</function>.  All EAs on Samba or NTFS are treated as
+on Samba or NTFS are treated as user EAs, so, if the name of an EA is "foo"
-user EAs, so, if the name of an EA is "foo" from the Windows perspective,
+from the Windows perspective, it's transformed into "user.foo" within Cygwin.
-it's transformed into "user.foo" within Cygwin.  This allows Linux-compatible
+This allows Linux-compatible EA operations and keeps tools like
-EA operations and keeps tools like <command>attr</command>, or
+<command>attr</command>, or <command>setfattr</command> happy.
-<command>setfattr</command> happy.
 </para>
 
-<para><function>chroot</function> is supported since Cygwin 1.1.3.
+<para><function>chroot</function> is supported.  Kind of.  Chroot is not a
-However, chroot is not a concept known by Windows.  This implies some serious
+concept known by Windows.  This implies some serious restrictions.  First of
-restrictions.  First of all, the <function>chroot</function> call isn't a
+all, the <function>chroot</function> call isn't a privileged call.  Any user
-privileged call.  Any user may call it.  Second, the chroot environment
+may call it.  Second, the chroot environment isn't safe against native windows
-isn't safe against native windows processes.  Given that, chroot in Cygwin
+processes.  Given that, chroot in Cygwin is only a hack which pretends security
-is only a hack which pretends security where there is none.  For that reason
+where there is none.  For that reason the usage of chroot is discouraged.
-the usage of chroot is discouraged.
+Don't use it unless you really, really know what you're doing.
 </para>
 </sect2>
 
@@ -347,14 +346,11 @@ completely transparent to the application.  Cygwin's implementation also
 supports the getpeereid BSD extension.  However, Cygwin does not yet support
 descriptor passing.</para>
 
-<para>IPv6 is supported beginning with Cygwin release 1.7.0.  This
+<para>IPv6 is supported.  This support is dependent, however, on the
-support is dependent, however, on the availability of the Windows IPv6
+availability of the Windows IPv6 stack.  The IPv6 stack was "experimental",
-stack.  The IPv6 stack was "experimental", i.e. not feature complete in
+i.e. not feature complete in Windows 2003 and earlier.  Full IPv6 support
-Windows 2003 and earlier.  Full IPv6 support became available starting
+became only available starting with Windows Vista and Windows Server 2008.
-with Windows Vista and Windows Server 2008.  Cygwin does not depend on
+</para>
-the underlying OS for the (newly implemented) <function>getaddrinfo</function>
-and <function>getnameinfo</function> functions.  Cygwin 1.7.0 adds
-replacement functions which implement the full functionality for IPv4.</para>
 
 </sect2>
 

winsup/doc/new-features.xml

@@ -9,25 +9,25 @@
 <itemizedlist mark="bullet">
 
 <listitem><para>
-- Full set of POSIX.1e ACL API functions now implemented.
+Full set of POSIX.1e ACL API functions now implemented.
-  New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry,
+New APIs: acl_add_perm, acl_calc_mask, acl_clear_perms, acl_copy_entry,
-  acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file,
+acl_copy_ext, acl_copy_int, acl_create_entry, acl_delete_def_file,
-  acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text,
+acl_delete_entry, acl_delete_perm, acl_dup, acl_free, acl_from_text,
-  acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, acl_get_qualifier,
+acl_get_entry, acl_get_fd, acl_get_file, acl_get_permset, acl_get_qualifier,
-  acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset,
+acl_get_tag_type, acl_init, acl_set_fd, acl_set_file, acl_set_permset,
-  acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid.
+acl_set_qualifier, acl_set_tag_type, acl_size, acl_to_text, acl_valid.
 </para></listitem>
 
 <listitem><para>
-- Most libacl extensions now implemented, too:
+Most libacl extensions now implemented, too:
-  New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
+New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
-  acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
+acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
-  acl_from_mode, acl_get_perm, acl_to_any_text.
+acl_from_mode, acl_get_perm, acl_to_any_text.
 </para></listitem>
 
 <listitem><para>
-- Including &lt;sys/acl.h&gt; now *only* includes the POSIX ACL API.  To include
+Including &lt;sys/acl.h&gt; now *only* includes the POSIX ACL API.  To include
-  the old Solaris API, include &lt;cygwin/acl.h&gt;.
+the old Solaris API, include &lt;cygwin/acl.h&gt;.
 </para></listitem>
 
 <listitem><para>

winsup/doc/overview.xml

@@ -113,7 +113,7 @@ have seen continuous development.
 </para>
 
 <para>
-The biggest major improvement in this development is the 1.7 release in
+The biggest major improvement in this development was the 1.7 release in
 2009, which dropped Windows 95/98/Me support in favor of using Windows
 NT features more extensively.  It adds a lot of new features like
 case-sensitive filenames, NFS interoperability, IPv6 support and much
@@ -121,7 +121,7 @@ more.</para>
 
 <para>The latest big improvement is the 64 bit Cygwin DLL which
 allows to run natively on AMD64 Windows machines.  The first release
-available in a 64 bit version is 1.7.19.</para>
+available in a 64 bit version was 1.7.19.</para>
 
 </sect1>
 

winsup/doc/pathnames.xml

@@ -391,14 +391,13 @@ followed by the path to which the link points.  They are marked with the
 DOS SYSTEM attribute so that only files with that attribute have to be
 read to determine whether or not the file is a symbolic link.</para>
 
-<note><para>Starting with Cygwin 1.7, symbolic links are using UTF-16 to encode
+<note><para>Cygwin symbolic links are using UTF-16 to encode the filename of
-the filename of the target file, to better support internationalization.
+the target file, to better support internationalization.  Symlinks created by
-Symlinks created by older Cygwin releases can be read just fine.  However,
+old Cygwin releases can be read just fine.  However, you could run into
-you could run into problems with them if you're now using another character
+problems with them if you're now using another character set than the one you
-set than the one you used when creating these symlinks
+used when creating these symlinks
-(see <xref linkend="setup-locale-problems"></xref>).  Please note that this
+(see <xref linkend="setup-locale-problems"></xref>).
-new UTF-16 style of symlinks is not compatible with older Cygwin release,
+</para></note>
-which can't read the target filename correctly.</para></note>
 </listitem>
 
 <listitem>

winsup/doc/setup-env.xml

@@ -30,9 +30,8 @@ This is, of course, just an example.  For the recognized settings of the
 
 <para>
 Locale support is controlled by the <envar>LANG</envar> and
-<envar>LC_xxx</envar> environment variables.  Since Cygwin 1.7.2, all of
+<envar>LC_xxx</envar> environment variables.  For a more detailed description
-them are honored and have a meaning.  For a more detailed description see
+see <xref linkend="setup-locale"></xref>.
-<xref linkend="setup-locale"></xref>.
 </para>
 
 <para>

winsup/doc/setup-locale.xml

@@ -60,11 +60,10 @@ provided by the gettext package under Cygwin.</para>
 
 <para>
 At application startup, the application's locale is set to the default
-"C" or "POSIX" locale.  Under Cygwin 1.7.2 and later, this locale defaults
+"C" or "POSIX" locale.  This locale defaults to the ASCII character set
-to the ASCII character set on the application level.  If you want to stick
+on the application level.  If you want to stick to the "C" locale and only
-to the "C" locale and only change to another charset, you can define this
+change to another charset, you can define this by setting one of the locale
-by setting one of the locale environment variables to "C.charset".  For
+environment variables to "C.charset".  For instance</para>
-instance</para>
 
 <screen>
   "C.ISO-8859-1"
@@ -117,10 +116,9 @@ interoperability with applications running in the default "C.UTF-8" locale.
 </para>
 
 <para>
-Starting with Cygwin 1.7.2, the language and territory are used to
+The language and territory are used to fetch locale-dependent information
-fetch locale-dependent information from Windows.  If the language and
+from Windows.  If the language and territory are not known to Windows, the
-territory are not known to Windows, the <function>setlocale</function>
+<function>setlocale</function> function fails.</para>
-function fails.</para>
 
 <para>The following modifiers are recognized.  Any other modifier is simply
 ignored for now.</para>
@@ -181,10 +179,10 @@ Assume that you've set one of the aforementioned environment variables to some
 valid POSIX locale value, other than "C" and "POSIX".  Assume further that
 you're living in Japan.  You might want to use the language code "ja" and the
 territory "JP", thus setting, say, <envar>LANG</envar> to "ja_JP".  You didn't
-set a character set, so what will Cygwin use now?  Starting with Cygwin 1.7.2,
+set a character set, so what will Cygwin use now?  The default character set
-the default character set is determined by the default Windows ANSI codepage
+is determined by the default Windows ANSI codepage for this language and
-for this language and territory.  Cygwin uses a character set which is the
+territory.  Cygwin uses a character set which is the typical Unix-equivalent
-typical Unix-equivalent to the Windows ANSI codepage.  For instance:</para>
+to the Windows ANSI codepage.  For instance:</para>
 
 <screen>
   "en_US"		ISO-8859-1
@@ -307,25 +305,9 @@ environment, if it's different from the UTF-8 charset.</para>
 consist of valid ASCII characters, and only of uppercase letters, digits, and
 the underscore for maximum portability.</para></note>
 
-<para>Symbolic links, too, may pose a problem when switching charsets on
-the fly.  A symbolic link contains the filename of the target file the
-symlink points to.  When a symlink had been created with older versions
-of Cygwin, the current ANSI or OEM character set had been used to store
-the target filename, dependent on the old <envar>CYGWIN</envar>
-environment variable setting <envar>codepage</envar> (see <xref
-linkend="cygwinenv-removed-options"></xref>.  If the target filename
-contains non-ASCII characters and you use another character set than
-your default ANSI/OEM charset, the target filename of the symlink is now
-potentially an invalid character sequence in the new character set.
-This behaviour is not different from the behaviour in other Operating
-Systems.  So, if you suddenly can't access a symlink anymore which
-worked all these years before, maybe it's because you switched to
-another character set.  This doesn't occur with symlinks created with
-Cygwin 1.7 or later.  </para>
-
 <para>Another problem you might encounter is that older versions of
 Windows did not install all charsets by default.  If you are running
-Windows XP or older, you can open the "Regional and Language Options"
+Windows XP or 2003, you can open the "Regional and Language Options"
 portion of the Control Panel, select the "Advanced" tab, and select
 entries from the "Code page conversion tables" list.  The following
 entries are useful to cygwin: 932/SJIS, 936/GBK, 949/EUC-KR, 950/Big5,

winsup/doc/setup-maxmem.xml

@@ -9,12 +9,13 @@ Cygwin's heap is extensible.  However, it does start out at a fixed size
 and attempts to extend it may run into memory which has been previously
 allocated by Windows.  In some cases, this problem can be solved by
 changing a field in the file header which is utilized by Cygwin since
-version 1.7.10 to keep the initial size of the application heap.  If the
+to keep the initial size of the application heap.  If the field contains 0,
-field contains 0, which is the default, the application heap defaults to
+which is the default, the application heap defaults to a size of 384 Megabyte
-a size of 384 Megabyte.  If the field is set to any other value between 4 and
+on 32 bit Cygwin, 512 Megabyte on 64 bit Cygwin.  If the field is set to any
-2048, Cygwin tries to reserve as much Megabytes for the application heap.
+other value between 4 and 2048, Cygwin tries to reserve as much Megabytes
-The field used for this is the "LoaderFlags" field in the NT-specific
+for the application heap.  The field used for this is the "LoaderFlags" field
-PE header structure (<literal>(IMAGE_NT_HEADER)->OptionalHeader.LoaderFlags</literal>).</para>
+in the NT-specific PE header structure
+(<literal>(IMAGE_NT_HEADER)->OptionalHeader.LoaderFlags</literal>).</para>
 
 <para>
 This value can be changed for any executable by using a more recent version
@@ -42,25 +43,4 @@ up to 3 GB per process.  See the Microsoft article
 for more information.
 </para>
 
-<note>
-<para>
-Older Cygwin releases only supported a global registry setting to
-change the initial heap size for all Cygwin processes.  This setting is
-not used anymore.  However, if you're running an older Cygwin release
-than 1.7.10, you can add the <literal>DWORD</literal> value
-<literal>heap_chunk_in_mb</literal> and set it to the desired memory limit
-in decimal MB.  You have to stop all Cygwin processes for this setting to
-have any effect.  It is preferred to do this in Cygwin using the
-<command>regtool</command> program included in the Cygwin package.
-(see <xref linkend="regtool"></xref>) This example sets the memory limit
-to 1024 MB for all Cygwin processes (use HKCU instead of HKLM if you
-want to set this only for the current user):
-
-<screen>
-$ regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb 1024
-$ regtool -v list /HKLM/Software/Cygwin
-</screen>
-</para>
-</note>
-
 </sect1>

winsup/doc/specialnames.xml

@@ -50,10 +50,9 @@ to be readable by the $USER user account itself.</para>
 
 <sect2 id="pathnames-dosdevices"><title>Invalid filenames</title>
 
-<para>Filenames invalid under Win32 are not necessarily invalid
+<para>Filenames invalid under Win32 are not necessarily invalid under Cygwin.
-under Cygwin since release 1.7.0.  There are a few rules which
+There are a few rules which apply to Windows filenames.  Most notably, DOS
-apply to Windows filenames.  Most notably, DOS device names like
+device names like <filename>AUX</filename>, <filename>COM1</filename>,
-<filename>AUX</filename>, <filename>COM1</filename>,
 <filename>LPT1</filename> or <filename>PRN</filename> (to name a few)
 cannot be used as filename or extension in a native Win32 application.
 So filenames like <filename>prn.txt</filename> or <filename>foo.aux</filename>
@@ -95,12 +94,12 @@ can create and access files with trailing dots and spaces without problems.
 
 <para>An exception from this rule are some network filesystems (NetApp,
 NWFS) which choke on these filenames.  They return with an error like
-"No such file or directory" when trying to create such files.  Starting
+"No such file or directory" when trying to create such files.  Cygwin
-with Cygwin 1.7.6, Cygwin recognizes these filesystems and works around
+recognizes these filesystems and works around this problem by applying
-this problem by applying the same rule as for the other forbidden characters. 
+the same rule as for the other forbidden characters.  Leading spaces and
-Leading spaces and trailing dots and spaces will be converted to UNICODE
+trailing dots and spaces will be converted to UNICODE characters in the
-characters in the private use area.  This behaviour can be switched on
+private use area.  This behaviour can be switched on explicitely for a
-explicitely for a filesystem or a directory tree by using the mount option
+filesystem or a directory tree by using the mount option
 <literal>dos</literal>.</para>
 
 </sect2>
@@ -227,11 +226,8 @@ semaphores, shared memory, and message queues, so a system without a real
 </para>
 
 <para>Apart from that, Cygwin automatically simulates POSIX devices
-internally.  Up to Cygwin 1.7.11, these devices couldn't be seen with the
+internally.  The <filename>/dev</filename> directory is automagically
-command <command>ls /dev/</command> although commands such as
+populated with existing POSIX devices by Cygwin in a way comparable with a
-<command>ls /dev/tty</command> worked fine.  Starting with Cygwin 1.7.12,
-the <filename>/dev</filename> directory is automagically populated with
-existing POSIX devices by Cygwin in a way comparable with a
 <ulink url="http://en.wikipedia.org/wiki/Udev">udev</ulink> based virtual
 <filename>/dev</filename> directory under Linux.</para>
 
@@ -245,15 +241,13 @@ Cygwin supports the following character devices commonly found on POSIX systems:
 /dev/full
 
 /dev/console	Pseudo device name for the current console window of a session.
-		Up to Cygwin 1.7.9, this was the only name for a console.
-		Different consoles were indistinguishable.
 		Cygwin's /dev/console is not quite comparable with the console
 		device on UNIX machines.
 
-/dev/cons0      Starting with Cygwin 1.7.10, Console sessions are numbered from 
+/dev/cons0      Console sessions are numbered from  /dev/cons0 upwards.
-/dev/cons1	/dev/cons0 upwards.  Console device names are pseudo device
+/dev/cons1	Console device names are pseudo device names, only accessible
-...		names, only accessible from processes within this very console
+...		from processes within this very console session.  This is due
-		session.  This is due to a restriction in Windows.
+		to a restriction in Windows.
 
 /dev/tty	The current controlling tty of a session.
 

winsup/doc/textbinary.xml

@@ -146,7 +146,7 @@ in your project, like this:</para>
   $ gcc my_tiny_app.c /lib/binmode.o -o my_tiny_app
 </screen>
 
-<para>Starting with Cygwin 1.7.7, you can use the even simpler:</para>
+<para>Even simpler:</para>
 
 <screen>
   $ gcc my_tiny_app.c -lbinmode -o my_tiny_app

winsup/doc/utils.xml

@@ -1481,10 +1481,9 @@ D: on /d type fat (binary,user,noumount)
     <refsect2 id="utils-limitations">
       <title>Limitations</title>
 
-      <para>Limitations: there is a hard-coded limit of 64 mount points (up to
+      <para>Limitations: there is a hard-coded limit of 64 mount points.
-        Cygwin 1.7.9: 30 mount points). Also, although you can mount to
+        Also, although you can mount to pathnames that do not start with "/",
-        pathnames that do not start with "/", there is no way to make use of
+	there is no way to make use of such mount points.</para>
-        such mount points.</para>
 
       <para>Normally the POSIX mount point in Cygwin is an existing empty
         directory, as in standard UNIX. If this is the case, or if there is a