* 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.
This commit is contained in:
Corinna Vinschen 2006-12-05 13:16:24 +00:00
parent 301cd37dda
commit a83c59fbc3
3 changed files with 12 additions and 3 deletions

View File

@ -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.

View File

@ -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

View File

@ -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);