Re: Update 'uname' emulation on MS-Windows

2016-07-24 Thread Andy Wingo
On Sun 24 Jul 2016 16:32, Eli Zaretskii  writes:

>> Does the uname MinGW patch introduce a regression in any case that we
>> care about?
>
> No.  On the contrary: where before Guile would only report correct OS
> version up to and including XP, it now reports correct values also for
> Vista, Windows 7, and Windows 8.  Versions beyond that require the
> manifest, and otherwise will be reported as 8.0.
>
> Also, the modern CPU types are now supported, including 64-bit ones,
> which were not reported at all before.
>
>> Is it a user-visible change?  If so an update to NEWS might be
>> needed.
>
> From my POV, this is a bugfix: APIs that were reporting inaccurate
> values now report more accurate ones.

Thanks for the info, and the patches of course :)

Andy



Re: Update 'uname' emulation on MS-Windows

2016-07-24 Thread Eli Zaretskii
> From: Andy Wingo 
> Cc: andrewjmore...@gmail.com,  guile-devel@gnu.org
> Date: Sat, 23 Jul 2016 23:03:46 +0200
> 
> >> > Does the Mingw toolchain supply a suitable manifest automatically ?
> >> 
> >> No.  The manifest should be provided with Guile.
> >
> > Of course, singe Guile is mainly a library, any application that is
> > linked against libguile also needs such a manifest.
> 
> Does the uname MinGW patch introduce a regression in any case that we
> care about?

No.  On the contrary: where before Guile would only report correct OS
version up to and including XP, it now reports correct values also for
Vista, Windows 7, and Windows 8.  Versions beyond that require the
manifest, and otherwise will be reported as 8.0.

Also, the modern CPU types are now supported, including 64-bit ones,
which were not reported at all before.

> Is it a user-visible change?  If so an update to NEWS might be
> needed.

>From my POV, this is a bugfix: APIs that were reporting inaccurate
values now report more accurate ones.



Re: Update 'uname' emulation on MS-Windows

2016-07-23 Thread Andy Wingo
On Sun 17 Jul 2016 14:04, Eli Zaretskii  writes:

>> Date: Sun, 17 Jul 2016 05:37:24 +0300
>> From: Eli Zaretskii 
>> Cc: guile-devel@gnu.org
>> 
>> > Does the Mingw toolchain supply a suitable manifest automatically ?
>> 
>> No.  The manifest should be provided with Guile.
>
> Of course, singe Guile is mainly a library, any application that is
> linked against libguile also needs such a manifest.

Does the uname MinGW patch introduce a regression in any case that we
care about?  Is it a user-visible change?  If so an update to NEWS might
be needed.

Andy



Re: Update 'uname' emulation on MS-Windows

2016-07-17 Thread Eli Zaretskii
> Date: Sun, 17 Jul 2016 05:37:24 +0300
> From: Eli Zaretskii 
> Cc: guile-devel@gnu.org
> 
> > Does the Mingw toolchain supply a suitable manifest automatically ?
> 
> No.  The manifest should be provided with Guile.

Of course, singe Guile is mainly a library, any application that is
linked against libguile also needs such a manifest.



Re: Update 'uname' emulation on MS-Windows

2016-07-16 Thread Eli Zaretskii
> From: Andy Moreton 
> Date: Sat, 16 Jul 2016 22:40:38 +0100
> 
> On Sat 16 Jul 2016, Eli Zaretskii wrote:
> 
> > The processors and OS versions of the emulated 'uname' need an update;
> > the patch below does that:
> 
> This uses GetVersionEx, which does not tell the truth on versions after
> Windows 8 unless the application contains a manifest (see online
> documentation for GetVersionEx at MSDN for details).

Right.

> Does the Mingw toolchain supply a suitable manifest automatically ?

No.  The manifest should be provided with Guile.



Re: Update 'uname' emulation on MS-Windows

2016-07-16 Thread Andy Moreton
On Sat 16 Jul 2016, Eli Zaretskii wrote:

> The processors and OS versions of the emulated 'uname' need an update;
> the patch below does that:

This uses GetVersionEx, which does not tell the truth on versions after
Windows 8 unless the application contains a manifest (see online
documentation for GetVersionEx at MSDN for details).

Does the Mingw toolchain supply a suitable manifest automatically ?

AndyM






Re: Update 'uname' emulation on MS-Windows

2016-07-16 Thread Eli Zaretskii
> From: Andy Wingo 
> Cc: guile-devel@gnu.org
> Date: Sat, 16 Jul 2016 10:58:39 +0200
> 
> On Sat 16 Jul 2016 09:27, Eli Zaretskii  writes:
> 
> > 2016-07-16  Eli Zaretskii  
> >
> > * libguile/posix-w32.c (uname): Update to modern processors (ia64
> > and x86_64) and OS versions (Vista to Windows 10).  Delete
> > trailing whitespace.
> 
> Applied, thanks.

Thanks.

> I will do what I can to apply patches that aren't in
> git-format-patch format, but I note that using git-format-patch
> makes it more likely that they go upstream.

Noted.  (The reason I didn't use git-format-patch is that the diffs
were generated relative to 2.0.12 in its source tree, so I didn't have
a commit to use in the first place.)

AFAIK, I have write access to the Guile repository, so if it's more
convenient, once I have the approval, I can apply the patch and push
it myself.




Re: Update 'uname' emulation on MS-Windows

2016-07-16 Thread Andy Wingo
On Sat 16 Jul 2016 09:27, Eli Zaretskii  writes:

> 2016-07-16  Eli Zaretskii  
>
>   * libguile/posix-w32.c (uname): Update to modern processors (ia64
>   and x86_64) and OS versions (Vista to Windows 10).  Delete
>   trailing whitespace.

Applied, thanks.  I will do what I can to apply patches that aren't in
git-format-patch format, but I note that using git-format-patch makes it
more likely that they go upstream.  Cheers :)

Andy



Update 'uname' emulation on MS-Windows

2016-07-16 Thread Eli Zaretskii
The processors and OS versions of the emulated 'uname' need an update;
the patch below does that:

2016-07-16  Eli Zaretskii  

* libguile/posix-w32.c (uname): Update to modern processors (ia64
and x86_64) and OS versions (Vista to Windows 10).  Delete
trailing whitespace.

--- libguile/posix-w32.c~1  2016-07-15 19:18:26.83575 +0300
+++ libguile/posix-w32.c2016-07-16 10:22:08.27325 +0300
@@ -64,13 +64,26 @@ uname (struct utsname *uts)
 strcpy (uts->sysname, "Windows NT3x"); /* NT3x */
   else if (osver.dwMajorVersion == 5 && osver.dwMinorVersion < 1)
 strcpy (uts->sysname, "Windows 2000"); /* 2k */
-  else if (osver.dwMajorVersion >= 5)
+  else if (osver.dwMajorVersion < 6)
 strcpy (uts->sysname, "Windows XP");   /* XP */
+  else if (osver.dwMajorVersion == 6)
+   {
+ if (osver.dwMinorVersion < 1)
+   strcpy (uts->sysname, "Windows Vista");   /* Vista */
+ else if (osver.dwMinorVersion < 2)
+   strcpy (uts->sysname, "Windows 7"); /* Windows 7 */
+ else if (osver.dwMinorVersion < 3)
+   strcpy (uts->sysname, "Windows 8"); /* Windows 8 */
+ else if (osver.dwMinorVersion < 4)
+   strcpy (uts->sysname, "Windows 8.1"); /* Windows 8.1 */
+   }
+  else if (osver.dwMajorVersion >= 10)
+strcpy (uts->sysname, "Windows 10 or later"); /* Windows 10 and later 
*/
   os = WinNT;
   break;
 
 case VER_PLATFORM_WIN32_WINDOWS: /* Win95, Win98 or WinME */
-  if ((osver.dwMajorVersion > 4) || 
+  if ((osver.dwMajorVersion > 4) ||
   ((osver.dwMajorVersion == 4) && (osver.dwMinorVersion > 0)))
 {
  if (osver.dwMinorVersion >= 90)
@@ -91,11 +104,11 @@ uname (struct utsname *uts)
   break;
 }
 
-  sprintf (uts->version, "%ld.%02ld", 
+  sprintf (uts->version, "%ld.%02ld",
osver.dwMajorVersion, osver.dwMinorVersion);
 
   if (osver.szCSDVersion[0] != '\0' &&
-  (strlen (osver.szCSDVersion) + strlen (uts->version) + 1) < 
+  (strlen (osver.szCSDVersion) + strlen (uts->version) + 1) <
   sizeof (uts->version))
 {
   strcat (uts->version, " ");
@@ -115,10 +128,13 @@ uname (struct utsname *uts)
 case PROCESSOR_ARCHITECTURE_MIPS:
   strcpy (uts->machine, "mips");
   break;
+case PROCESSOR_ARCHITECTURE_IA64:
+  strcpy (uts->machine, "ia64");
+  break;
 case PROCESSOR_ARCHITECTURE_INTEL:
-  /* 
+  /*
* dwProcessorType is only valid in Win95 and Win98 and WinME
-   * wProcessorLevel is only valid in WinNT 
+   * wProcessorLevel is only valid in WinNT
*/
   switch (os)
 {
@@ -142,13 +158,16 @@ uname (struct utsname *uts)
 default:
   strcpy (uts->machine, "unknown");
   break;
-  }
+}
+  break;
+case PROCESSOR_ARCHITECTURE_AMD64:
+  strcpy (uts->machine, "x86_64");
   break;
 default:
   strcpy (uts->machine, "unknown");
   break;
   }
-  
+
   sLength = sizeof (uts->nodename) - 1;
   GetComputerName (uts->nodename, );
   return 0;