This is the mail archive of the
cygwin-cvs@cygwin.com
mailing list for the Cygwin project.
[newlib-cygwin] Remove references to older Cygwin releases from documentation
- From: Corinna Vinschen <corinna at sourceware dot org>
- To: cygwin-cvs at sourceware dot org
- Date: 18 Mar 2016 21:52:15 -0000
- Subject: [newlib-cygwin] Remove references to older Cygwin releases from documentation
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=83029bb69e2ccb47ab5546551210b59c4d483198
commit 83029bb69e2ccb47ab5546551210b59c4d483198
Author: Corinna Vinschen <corinna@vinschen.de>
Date: Fri Mar 18 22:52:04 2016 +0100
Remove references to older Cygwin releases from documentation
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Diff:
---
winsup/doc/cygserver.xml | 5 -----
winsup/doc/cygwinenv.xml | 8 ++++----
winsup/doc/faq-api.xml | 5 +++--
winsup/doc/faq-setup.xml | 9 ++++----
winsup/doc/faq-using.xml | 25 ++++++++++-------------
winsup/doc/highlights.xml | 50 +++++++++++++++++++++------------------------
winsup/doc/new-features.xml | 26 +++++++++++------------
winsup/doc/overview.xml | 4 ++--
winsup/doc/pathnames.xml | 15 +++++++-------
winsup/doc/setup-env.xml | 5 ++---
winsup/doc/setup-locale.xml | 42 +++++++++++--------------------------
winsup/doc/setup-maxmem.xml | 34 +++++++-----------------------
winsup/doc/specialnames.xml | 36 ++++++++++++++------------------
winsup/doc/textbinary.xml | 2 +-
winsup/doc/utils.xml | 7 +++----
15 files changed, 107 insertions(+), 166 deletions(-)
diff --git a/winsup/doc/cygserver.xml b/winsup/doc/cygserver.xml
index 2367a60..6849048 100644
--- a/winsup/doc/cygserver.xml
+++ b/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>
diff --git a/winsup/doc/cygwinenv.xml b/winsup/doc/cygwinenv.xml
index 0b0e5ac..5fadaee 100644
--- a/winsup/doc/cygwinenv.xml
+++ b/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
-Cygwin 1.7 for one reason or another. These obsolete options are listed
+Certain CYGWIN options available in past releases have been removed over
+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
-variables intact is POSIXly correct, Cygwin now does not change the case
+older releases of Cygwin. Since keeping the case of environment variables
+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>
diff --git a/winsup/doc/faq-api.xml b/winsup/doc/faq-api.xml
index d2aa029..b52ad22 100644
--- a/winsup/doc/faq-api.xml
+++ b/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
-version 1, release 2.
+cygwin-2.4.1-1 is <literal>cygwin1.dll</literal>, major version 2, minor
+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
diff --git a/winsup/doc/faq-setup.xml b/winsup/doc/faq-setup.xml
index 2a4c507..89ec00d 100644
--- a/winsup/doc/faq-setup.xml
+++ b/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,
-except for the installation directory information stored there for the sake
-of setup-x86{_64}.exe. There's nothing left to manipulate anymore.
+<para>Cygwin doesn't store anything important in the registry anymore for
+quite some time. There's no reason to save, restore or delete it.
</para></answer></qandaentry>
</qandadiv>
diff --git a/winsup/doc/faq-using.xml b/winsup/doc/faq-using.xml
index 66e133b..76f9058 100644
--- a/winsup/doc/faq-using.xml
+++ b/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
-starting with Cygwin 1.7.0. For a detailed description how to use that
-feature see the Cygwin User's Guilde at
+<para>To help with this problem, Cygwin supports case sensitivity. For a
+detailed description how to use that feature see the Cygwin User's Guide 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
-User's Guide at
+can deal with these filenames just fine. Again, see the 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.
-Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
-portable across all character sets. Old symlinks were written using your
-current Windows codepage, which is not portable across all character sets.
-If the target of the symlink doesn't resolve anymore, it's very likely that
-the symlink points to a target filename using native, non-ASCII characters,
-and you're now using another character set than way back when you created
-the symlink.</para>
+<para>Cygwin supports multiple character sets. Symlinks created with Cygwin
+are using the UTF-16 character set, which is portable across all character
+sets. Old symlinks were written using your current Windows codepage, which
+is not portable across all character sets. If the target of the symlink
+doesn't resolve anymore, it's very likely that the symlink points to a target
+filename using native, non-ASCII characters, and you're now using another
+character set than way back when you created 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>
diff --git a/winsup/doc/highlights.xml b/winsup/doc/highlights.xml
index 01080ee..65407ab 100644
--- a/winsup/doc/highlights.xml
+++ b/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
-system space is stored in the <filename>/etc/fstab</filename> file. Actually,
-there is a system-wide <filename>/etc/fstab</filename> file as well as a
-user-specific fstab file <filename>/etc/fstab.d/${USER}</filename>.</para>
+<para>The layout of this POSIX view of the Windows file system space is
+stored in the <filename>/etc/fstab</filename> file. Actually, there is a
+system-wide <filename>/etc/fstab</filename> file as well as a user-specific
+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
-linux-specific function calls <function>getxattr</function>,
-<function>setxattr</function>, <function>listxattr</function>, and
-<function>removexattr</function>. All EAs on Samba or NTFS are treated as
-user EAs, so, if the name of an EA is "foo" from the Windows perspective,
-it's transformed into "user.foo" within Cygwin. This allows Linux-compatible
-EA operations and keeps tools like <command>attr</command>, or
-<command>setfattr</command> happy.
+<para>Cygwin supports Extended Attributes (EAs) via the linux-specific function
+calls <function>getxattr</function>, <function>setxattr</function>,
+<function>listxattr</function>, and <function>removexattr</function>. All EAs
+on Samba or NTFS are treated as user EAs, so, if the name of an EA is "foo"
+from the Windows perspective, it's transformed into "user.foo" within Cygwin.
+This allows Linux-compatible EA operations and keeps tools like
+<command>attr</command>, or <command>setfattr</command> happy.
</para>
-<para><function>chroot</function> is supported since Cygwin 1.1.3.
-However, chroot is not a concept known by Windows. This implies some serious
-restrictions. First of all, the <function>chroot</function> call isn't a
-privileged call. Any user may call it. Second, the chroot environment
-isn't safe against native windows processes. Given that, chroot in Cygwin
-is only a hack which pretends security where there is none. For that reason
-the usage of chroot is discouraged.
+<para><function>chroot</function> is supported. Kind of. Chroot is not a
+concept known by Windows. This implies some serious restrictions. First of
+all, the <function>chroot</function> call isn't a privileged call. Any user
+may call it. Second, the chroot environment isn't safe against native windows
+processes. Given that, chroot in Cygwin is only a hack which pretends security
+where there is none. For that reason 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
-support is dependent, however, on the availability of the Windows IPv6
-stack. The IPv6 stack was "experimental", i.e. not feature complete in
-Windows 2003 and earlier. Full IPv6 support became available starting
-with Windows Vista and Windows Server 2008. Cygwin does not depend on
-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>
+<para>IPv6 is supported. This support is dependent, however, on the
+availability of the Windows IPv6 stack. The IPv6 stack was "experimental",
+i.e. not feature complete in Windows 2003 and earlier. Full IPv6 support
+became only available starting with Windows Vista and Windows Server 2008.
+</para>
</sect2>
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index c440782..7a54851 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -9,25 +9,25 @@
<itemizedlist mark="bullet">
<listitem><para>
-- Full set of POSIX.1e ACL API functions now implemented.
- 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_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_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.
+Full set of POSIX.1e ACL API functions now implemented.
+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_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_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.
</para></listitem>
<listitem><para>
-- Most libacl extensions now implemented, too:
- New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
- acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
- acl_from_mode, acl_get_perm, acl_to_any_text.
+Most libacl extensions now implemented, too:
+New APIs: acl_check, acl_cmp, acl_entries, acl_equiv_mode, acl_error,
+acl_extended_fd, acl_extended_file, acl_extended_file_nofollow,
+acl_from_mode, acl_get_perm, acl_to_any_text.
</para></listitem>
<listitem><para>
-- Including <sys/acl.h> now *only* includes the POSIX ACL API. To include
- the old Solaris API, include <cygwin/acl.h>.
+Including <sys/acl.h> now *only* includes the POSIX ACL API. To include
+the old Solaris API, include <cygwin/acl.h>.
</para></listitem>
<listitem><para>
diff --git a/winsup/doc/overview.xml b/winsup/doc/overview.xml
index e10b3b7..1086c01 100644
--- a/winsup/doc/overview.xml
+++ b/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>
diff --git a/winsup/doc/pathnames.xml b/winsup/doc/pathnames.xml
index d628089..3c0bdc1 100644
--- a/winsup/doc/pathnames.xml
+++ b/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
-the filename of the target file, to better support internationalization.
-Symlinks created by older Cygwin releases can be read just fine. However,
-you could run into problems with them if you're now using another character
-set than the one you used when creating these symlinks
-(see <xref linkend="setup-locale-problems"></xref>). Please note that this
-new UTF-16 style of symlinks is not compatible with older Cygwin release,
-which can't read the target filename correctly.</para></note>
+<note><para>Cygwin symbolic links are using UTF-16 to encode the filename of
+the target file, to better support internationalization. Symlinks created by
+old Cygwin releases can be read just fine. However, you could run into
+problems with them if you're now using another character set than the one you
+used when creating these symlinks
+(see <xref linkend="setup-locale-problems"></xref>).
+</para></note>
</listitem>
<listitem>
diff --git a/winsup/doc/setup-env.xml b/winsup/doc/setup-env.xml
index ca5acc9..c2674a7 100644
--- a/winsup/doc/setup-env.xml
+++ b/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
-them are honored and have a meaning. For a more detailed description see
-<xref linkend="setup-locale"></xref>.
+<envar>LC_xxx</envar> environment variables. For a more detailed description
+see <xref linkend="setup-locale"></xref>.
</para>
<para>
diff --git a/winsup/doc/setup-locale.xml b/winsup/doc/setup-locale.xml
index de0532f..ebde7a2 100644
--- a/winsup/doc/setup-locale.xml
+++ b/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
-to the ASCII character set on the application level. If you want to stick
-to the "C" locale and only change to another charset, you can define this
-by setting one of the locale environment variables to "C.charset". For
-instance</para>
+"C" or "POSIX" locale. This locale defaults to the ASCII character set
+on the application level. If you want to stick to the "C" locale and only
+change to another charset, you can define this by setting one of the locale
+environment variables to "C.charset". For 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
-fetch locale-dependent information from Windows. If the language and
-territory are not known to Windows, the <function>setlocale</function>
-function fails.</para>
+The language and territory are used to fetch locale-dependent information
+from Windows. If the language and territory are not known to Windows, the
+<function>setlocale</function> 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,
-the default character set is determined by the default Windows ANSI codepage
-for this language and territory. Cygwin uses a character set which is the
-typical Unix-equivalent to the Windows ANSI codepage. For instance:</para>
+set a character set, so what will Cygwin use now? The default character set
+is determined by the default Windows ANSI codepage for this language and
+territory. Cygwin uses a character set which is the typical Unix-equivalent
+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,
diff --git a/winsup/doc/setup-maxmem.xml b/winsup/doc/setup-maxmem.xml
index 1f5ee31..d5e5b99 100644
--- a/winsup/doc/setup-maxmem.xml
+++ b/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
-field contains 0, which is the default, the application heap defaults to
-a size of 384 Megabyte. If the field is set to any other value between 4 and
-2048, Cygwin tries to reserve as much Megabytes for the application heap.
-The field used for this is the "LoaderFlags" field in the NT-specific
-PE header structure (<literal>(IMAGE_NT_HEADER)->OptionalHeader.LoaderFlags</literal>).</para>
+to keep the initial size of the application heap. If the field contains 0,
+which is the default, the application heap defaults to a size of 384 Megabyte
+on 32 bit Cygwin, 512 Megabyte on 64 bit Cygwin. If the field is set to any
+other value between 4 and 2048, Cygwin tries to reserve as much Megabytes
+for the application heap. The field used for this is the "LoaderFlags" field
+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>
diff --git a/winsup/doc/specialnames.xml b/winsup/doc/specialnames.xml
index 543a4f1..d67d484 100644
--- a/winsup/doc/specialnames.xml
+++ b/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
-under Cygwin since release 1.7.0. There are a few rules which
-apply to Windows filenames. Most notably, DOS device names like
-<filename>AUX</filename>, <filename>COM1</filename>,
+<para>Filenames invalid under Win32 are not necessarily invalid under Cygwin.
+There are a few rules which apply to Windows filenames. Most notably, DOS
+device names like <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
-with Cygwin 1.7.6, Cygwin recognizes these filesystems and works around
-this problem by applying the same rule as for the other forbidden characters.
-Leading spaces and trailing dots and spaces will be converted to UNICODE
-characters in the private use area. This behaviour can be switched on
-explicitely for a filesystem or a directory tree by using the mount option
+"No such file or directory" when trying to create such files. Cygwin
+recognizes these filesystems and works around this problem by applying
+the same rule as for the other forbidden characters. Leading spaces and
+trailing dots and spaces will be converted to UNICODE characters in the
+private use area. This behaviour can be switched on explicitely for a
+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
-command <command>ls /dev/</command> although commands such as
-<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
+internally. 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/cons1 /dev/cons0 upwards. Console device names are pseudo device
-... names, only accessible from processes within this very console
- session. This is due to a restriction in Windows.
+/dev/cons0 Console sessions are numbered from /dev/cons0 upwards.
+/dev/cons1 Console device names are pseudo device names, only accessible
+... from processes within this very console session. This is due
+ to a restriction in Windows.
/dev/tty The current controlling tty of a session.
diff --git a/winsup/doc/textbinary.xml b/winsup/doc/textbinary.xml
index 112042f..dbc540a 100644
--- a/winsup/doc/textbinary.xml
+++ b/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
diff --git a/winsup/doc/utils.xml b/winsup/doc/utils.xml
index 501d248..a904c34 100644
--- a/winsup/doc/utils.xml
+++ b/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
- Cygwin 1.7.9: 30 mount points). Also, although you can mount to
- pathnames that do not start with "/", there is no way to make use of
- such mount points.</para>
+ <para>Limitations: there is a hard-coded limit of 64 mount points.
+ Also, although you can mount to pathnames that do not start with "/",
+ there is no way to make use of 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