Cygwin: remove support for Vista entirely

Fix up a few comments while at it

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

winsup/cygwin/cygheap.h

@@ -222,7 +222,7 @@ class fcwd_access_t {
     LONG           FSCharacteristics;	/* Taken from FileFsDeviceInformation */
     WCHAR          Buffer[MAX_PATH] __attribute ((aligned (8)));
   };
-  /* This is the layout used in Windows 7 and Vista. */
+  /* This is the layout used in Windows 7. */
   struct FAST_CWD_7 {
     UNICODE_STRING Path;		/* Path's Buffer member always refers
 					   to the following Buffer array. */

winsup/cygwin/fhandler_pipe.cc

@@ -1179,7 +1179,7 @@ cache_err:
   if (wincap.has_query_process_handle_info ())
     return get_query_hdl_per_process (name, ntfn); /* Since Win8 */
   else
-    return get_query_hdl_per_system (name, ntfn); /* Vista or Win7 */
+    return get_query_hdl_per_system (name, ntfn); /* Win7 */
 }
 
 /* This function is faster than get_query_hdl_per_system(), however,

winsup/cygwin/fhandler_socket_inet.cc

@@ -2180,7 +2180,7 @@ fhandler_socket_inet::getsockopt (int level, int optname, const void *optval,
 
   if (onebyte)
     {
-      /* Regression in Vista and later: instead of a 4 byte BOOL value, a
+      /* Regression in 6.0 kernel and later: instead of a 4 byte BOOL value, a
 	 1 byte BOOLEAN value is returned, in contrast to older systems and
 	 the documentation.  Since an int type is expected by the calling
 	 application, we convert the result here. */

winsup/cygwin/net.cc

@@ -1488,12 +1488,12 @@ get_adapters_addresses (PIP_ADAPTER_ADDRESSES *pa_ret, ULONG family)
   if (wincap.has_gaa_largeaddress_bug ()
       && (uintptr_t) &param >= (uintptr_t) 0x80000000L)
     {
-      /* In Windows Vista and Windows 7 under WOW64, GetAdaptersAddresses fails
-	 if it's running in a thread with a stack located in the large address
-	 area.  So, if we're running in a pthread with such a stack, we call
-	 GetAdaptersAddresses in a child thread with an OS-allocated stack.
-	 The OS allocates stacks bottom up, so chances are good that the new
-	 stack will be located in the lower address area. */
+      /* In Windows 7 under WOW64, GetAdaptersAddresses fails if it's running
+	 in a thread with a stack located in the large address area.  If we're
+	 running in a pthread with such a stack, we call GetAdaptersAddresses
+	 in a child thread with an OS-allocated stack.  The OS allocates stacks
+	 bottom up, so chances are good that the new stack will be located in
+	 the lower address area. */
       HANDLE thr = CreateThread (NULL, 0, call_gaa, &param, 0, NULL);
       SetThreadName (GetThreadId (thr), "__call_gaa");
       if (!thr)

winsup/cygwin/sec_auth.cc

@@ -1617,8 +1617,6 @@ s4uauth (bool logon, PCWSTR domain, PCWSTR user, NTSTATUS &ret_status)
     }
   else
     {
-      /* Per MSDN MsV1_0S4ULogon is not implemented on Vista, but surprisingly
-	 it works. */
       MSV1_0_S4U_LOGON *s4u_logon;
       USHORT user_len, domain_len;
 
@@ -1671,9 +1669,9 @@ out:
 
   if (token && logon)
     {
-      /* Convert to primary token.  Strictly speaking this is only
-	 required on Vista/2008.  CreateProcessAsUser also takes
-	 impersonation tokens since Windows 7. */
+      /* Convert to primary token.  CreateProcessAsUser takes impersonation
+	 tokens since Windows 7 but MSDN still claims a primary token is
+	 required.  Better safe than sorry. */
       HANDLE tmp_token;
 
       if (DuplicateTokenEx (token, MAXIMUM_ALLOWED, &sec_none,

winsup/cygwin/syscalls.cc

@@ -3627,8 +3627,8 @@ seteuid32 (uid_t uid)
 		}
 	      /* If s4uauth fails with status code STATUS_INVALID_PARAMETER,
 		 we're running on a system not implementing MsV1_0S4ULogon
-		 (Windows 7 WOW64, Vista?).  Fall back to create_token in
-		 this single case only. */
+		 (Windows 7 WOW64).  Fall back to create_token in this single
+		 case only. */
 	      debug_printf ("s4uauth failed, try create_token.");
 	      if (!(new_token = create_token (usersid, groups)))
 		{

winsup/cygwin/wincap.cc

@@ -18,37 +18,6 @@ details. */
    in the same session.  I'm only writing this longish comment because I'm
    puzzled that this has never been noticed before... */
 
-wincaps wincap_vista __attribute__((section (".cygwin_dll_common"), shared)) = {
-  def_guard_pages:1,
-  mmap_storage_high:0x070000000000LL,
-  {
-    is_server:false,
-    needs_query_information:true,
-    has_gaa_largeaddress_bug:true,
-    has_precise_system_time:false,
-    has_microsoft_accounts:false,
-    has_broken_prefetchvm:false,
-    has_new_pebteb_region:false,
-    has_broken_whoami:true,
-    has_unprivileged_createsymlink:false,
-    has_precise_interrupt_time:false,
-    has_posix_unlink_semantics:false,
-    has_posix_unlink_semantics_with_ignore_readonly:false,
-    has_case_sensitive_dirs:false,
-    has_posix_rename_semantics:false,
-    no_msv1_0_s4u_logon_in_wow64:true,
-    has_con_24bit_colors:false,
-    has_con_broken_csi3j:false,
-    has_con_broken_il_dl:false,
-    has_con_esc_rep:false,
-    has_extended_mem_api:false,
-    has_tcp_fastopen:false,
-    has_linux_tcp_keepalive_sockopts:false,
-    has_tcp_maxrtms:false,
-    has_query_process_handle_info:false,
-  },
-};
-
 wincaps wincap_7 __attribute__((section (".cygwin_dll_common"), shared)) = {
   def_guard_pages:1,
   mmap_storage_high:0x070000000000LL,
@@ -382,9 +351,6 @@ wincapc::init ()
       case 6:
 	switch (version.dwMinorVersion)
 	  {
-	    case 0:
-	      caps = &wincap_vista;
-	      break;
 	    case 1:
 	      caps = &wincap_7;
 	      break;