bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/5] Handle Windows CE and rewrite NT version handling.


From: Bruno Haible
Subject: Re: [PATCH 4/5] Handle Windows CE and rewrite NT version handling.
Date: Fri, 2 Oct 2009 02:24:51 +0200
User-agent: KMail/1.9.9

Hi Paolo,

> This further patch improves detection of Windows CE and of the processor
> kinds (ARM, SH, etc.) supported by Windows CE as well as older versions
> of Windows.  I also made it return i686 for WoW64 (Win32-on-Win64).

Thanks. This is welcome.

> At the same time, Windows 95/98/ME never supported anything but 32-bit
> x86, so its section can be simplified.

There is no need to "simplify" here. The goal of this uname() function is
to support all kinds of machines, even those to which we don't have
access to. Therefore adding to the list is ok, but removing is pointless.

> +     default: /* 3.5, 4.0, versions not yet known */
> +               sprintf (buf->release, "Windows NT %s %u.%u",
> +                        is_server ? "Server" : "Workstation",
> +                (unsigned int) version.dwMajorVersion,
> +                (unsigned int) version.dwMinorVersion);

I object against outputting "Windows NT" for the versions not yet known
(Windows 7, 8, who knows?). Returning "Windows" is suboptimal, but
acceptable. Returning "Windows NT" will be confusing for end users.

> +      switch ((version.dwMajorVersion << 8)
> +           | version.dwMinorVersion)

An idiom like this may save a couple of instructions at the expense of
readability of the code. When I look at the MS documentation of
OSVERSIONINFOEX, I see values 5, 6 mentioned, but I don't see 0x502,
0x601 etc. Consequence: This idiom makes the code harder to maintain.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]