* dcrt0.cc (get_cygwin_startup_info): Fix comment.

* wincap.cc (wincapc::init): Always reset needs_count_in_si_lpres2 to
	false on non 64-bit systems.

winsup/cygwin/ChangeLog

@@ -1,3 +1,9 @@
+2006-12-05  Corinna Vinschen  <corinna@vinschen.de>
+
+	* dcrt0.cc (get_cygwin_startup_info): Fix comment.
+	* wincap.cc (wincapc::init): Always reset needs_count_in_si_lpres2 to
+	false on non 64-bit systems.
+
 2006-12-05  Corinna Vinschen  <corinna@vinschen.de>
 
 	* dcrt0.cc (get_cygwin_startup_info): Change zeros to DWORD array.

winsup/cygwin/dcrt0.cc

@@ -607,9 +607,10 @@ get_cygwin_startup_info ()
      This seems to be a bug in Vista's WOW64, which apparently copies the
      lpReserved2 datastructure not using the cbReserved2 size information,
      but using the information given in the first DWORD within lpReserved2
-     instead.  Funny enough, 32 bit Vista doesn't care if zero[0] is 0 or a
-     non-0 count value, while older versions of Windows might crash if
-     zero[0] is set to a non-zero value, as observed at least on XP 64.
+     instead.  32 bit Windows and former WOW64 don't care if zero[0] is 0
+     or a sensible non-0 count value.  However, it's not clear if a non-0
+     count doesn't result in trying to evaluate the content, so we do this
+     really only for Vista 64 for now.
 
      exec/spawn as well as fork write an appropriate value into zero[0] now,
      depending on the wincap.needs_count_in_si_lpres2 flag.  The value is

winsup/cygwin/wincap.cc

@@ -927,6 +927,8 @@ wincapc::init ()
   BOOL is_wow64_proc = FALSE;
   if (IsWow64Process (GetCurrentProcess (), &is_wow64_proc))
     wow64 = is_wow64_proc;
+  else
+    ((wincaps *)this->caps)->needs_count_in_si_lpres2 = false;
 
   __small_sprintf (osnam, "%s-%d.%d", os, version.dwMajorVersion,
 		   version.dwMinorVersion);