A small note on Windows 8 GetVersion() depreciation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A small note on Windows 8 GetVersion() depreciation

Jakob Bohm-7
While I have not specifically checked the Windows 8 SDK, my extensive
experience with the version detection APIs in Windows tells me the
following:

1. GetVersion() is the only version-detection API available on older
   platform versions.  Later platform versions added variants of
   GetVersionEx(), with each newer variant being available on less
   platforms.

2. The order of the bit fields returned by GetVersion() has
   historically confused many developers, therefore Microsoft has long
   told people to avoid it if they don't know what they are doing.
    At one point, even the editor of the GetVersion() documentation
   got confused!

3. Starting a few years ago, Microsoft began a trend of using the
   compiler "__declspec(deprecate)" mechanism to scare developers
   away from functions that are not really deprecated, just not
   recommended for some other reason.  Those deprecations can
   usually be ignored safely by those with good reason to use those
   more portable APIs.

So, if this is just another "political" compiler warning, there is
little reason to head it.

Otherwise, the GetVersionEx() function can be used as a replacement,
but only by dropping support for Windows NT 3.10 and maybe Win32s
(NT 3.50 and all the Win9x and WinCE variants include the basic
form of GetVersionEx()).

P.S.

If there is still code in there to support 16 bit Windows 3.x, then
that API includes only GetVersion(), and with a different
specification than its 32/64 bit namesake.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: A small note on Windows 8 GetVersion() depreciation

Dongsheng Song
[1] GetVersionEx may be altered or unavailable for releases after
Windows 8.1. Instead, use the Version Helper APIs.

I thinks use 'Version Information Functions'[2] is the better choice.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ff468915%28v=vs.85%29.aspx

--
Dongsheng

On Thu, Jan 9, 2014 at 3:11 AM, Jakob Bohm <[hidden email]> wrote:

> While I have not specifically checked the Windows 8 SDK, my extensive
> experience with the version detection APIs in Windows tells me the
> following:
>
> 1. GetVersion() is the only version-detection API available on older
>   platform versions.  Later platform versions added variants of
>   GetVersionEx(), with each newer variant being available on less
>   platforms.
>
> 2. The order of the bit fields returned by GetVersion() has
>   historically confused many developers, therefore Microsoft has long
>   told people to avoid it if they don't know what they are doing.
>    At one point, even the editor of the GetVersion() documentation
>   got confused!
>
> 3. Starting a few years ago, Microsoft began a trend of using the
>   compiler "__declspec(deprecate)" mechanism to scare developers
>   away from functions that are not really deprecated, just not
>   recommended for some other reason.  Those deprecations can
>   usually be ignored safely by those with good reason to use those
>   more portable APIs.
>
> So, if this is just another "political" compiler warning, there is
> little reason to head it.
>
> Otherwise, the GetVersionEx() function can be used as a replacement,
> but only by dropping support for Windows NT 3.10 and maybe Win32s
> (NT 3.50 and all the Win9x and WinCE variants include the basic
> form of GetVersionEx()).
>
> P.S.
>
> If there is still code in there to support 16 bit Windows 3.x, then
> that API includes only GetVersion(), and with a different
> specification than its 32/64 bit namesake.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
> Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: A small note on Windows 8 GetVersion() depreciation

Jakob Bohm-7
On 1/9/2014 6:46 AM, Dongsheng Song wrote:
> [1] GetVersionEx may be altered or unavailable for releases after
> Windows 8.1. Instead, use the Version Helper APIs.
>
 > [1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx

Scandalous!  According to that page, Microsoft has essentially sabotaged
one of the first functions called by most language runtimes and also
introduced rules to actively prevent applications from sanely dealing
with OS differences.  For instance, it seems there is no longer any
interface to detect if the OS was made *after* the application code and
may thus differ subtly from whatever the application knows about the
OS-es in existence at the time.

> I thinks use 'Version Information Functions'[2] is the better choice.
>
> [2] http://msdn.microsoft.com/en-us/library/windows/desktop/ff468915%28v=vs.85%29.aspx
>
Well, those functions (or something even more low-level in case
Microsoft sabotages these too), could be a way to work around the
sabotage introduced in Windows NT 6.3 (Marketed as 8.1).


>
> On Thu, Jan 9, 2014 at 3:11 AM, Jakob Bohm <[hidden email]> wrote:
>> While I have not specifically checked the Windows 8 SDK, my extensive
>> experience with the version detection APIs in Windows tells me the
>> following:
>>
>> 1. GetVersion() is the only version-detection API available on older
>>    platform versions.  Later platform versions added variants of
>>    GetVersionEx(), with each newer variant being available on less
>>    platforms.
>>
>> 2. The order of the bit fields returned by GetVersion() has
>>    historically confused many developers, therefore Microsoft has long
>>    told people to avoid it if they don't know what they are doing.
>>     At one point, even the editor of the GetVersion() documentation
>>    got confused!
>>
>> 3. Starting a few years ago, Microsoft began a trend of using the
>>    compiler "__declspec(deprecate)" mechanism to scare developers
>>    away from functions that are not really deprecated, just not
>>    recommended for some other reason.  Those deprecations can
>>    usually be ignored safely by those with good reason to use those
>>    more portable APIs.
>>
>> So, if this is just another "political" compiler warning, there is
>> little reason to head it.
>>
>> Otherwise, the GetVersionEx() function can be used as a replacement,
>> but only by dropping support for Windows NT 3.10 and maybe Win32s
>> (NT 3.50 and all the Win9x and WinCE variants include the basic
>> form of GetVersionEx()).
>>
>> P.S.
>>
>> If there is still code in there to support 16 bit Windows 3.x, then
>> that API includes only GetVersion(), and with a different
>> specification than its 32/64 bit namesake.
>>
>>


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: A small note on Windows 8 GetVersion() depreciation

Watson, Patrick
I'd recommend using VerifyVersionInfo: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx. It's supported from Win2k onward and isn't deprecated as of Win 8.1. I don't remember for sure if it's present in Windows CE and unfortunately I don't have my CE documentation handy at the moment.

I suspect that the previously linked 'Version Information Functions' are not quite as suited to what you want to do since I think you'd need to check the version of a particular file rather than the OS itself.

Should this thread be moved to openssl-dev?

Patrick Watson, CISSP
Software Engineer
Data Security & Electronic Payment Systems
NCR Retail

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jakob Bohm
Sent: Thursday, January 09, 2014 1:21 PM
To: [hidden email]
Subject: Re: A small note on Windows 8 GetVersion() depreciation

On 1/9/2014 6:46 AM, Dongsheng Song wrote:
> [1] GetVersionEx may be altered or unavailable for releases after
> Windows 8.1. Instead, use the Version Helper APIs.
>
 > [1]
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx

Scandalous!  According to that page, Microsoft has essentially sabotaged one of the first functions called by most language runtimes and also introduced rules to actively prevent applications from sanely dealing with OS differences.  For instance, it seems there is no longer any interface to detect if the OS was made *after* the application code and may thus differ subtly from whatever the application knows about the OS-es in existence at the time.

> I thinks use 'Version Information Functions'[2] is the better choice.
>
> [2]
> http://msdn.microsoft.com/en-us/library/windows/desktop/ff468915%28v=v
> s.85%29.aspx
>
Well, those functions (or something even more low-level in case Microsoft sabotages these too), could be a way to work around the sabotage introduced in Windows NT 6.3 (Marketed as 8.1).


>
> On Thu, Jan 9, 2014 at 3:11 AM, Jakob Bohm <[hidden email]> wrote:
>> While I have not specifically checked the Windows 8 SDK, my extensive
>> experience with the version detection APIs in Windows tells me the
>> following:
>>
>> 1. GetVersion() is the only version-detection API available on older
>>    platform versions.  Later platform versions added variants of
>>    GetVersionEx(), with each newer variant being available on less
>>    platforms.
>>
>> 2. The order of the bit fields returned by GetVersion() has
>>    historically confused many developers, therefore Microsoft has long
>>    told people to avoid it if they don't know what they are doing.
>>     At one point, even the editor of the GetVersion() documentation
>>    got confused!
>>
>> 3. Starting a few years ago, Microsoft began a trend of using the
>>    compiler "__declspec(deprecate)" mechanism to scare developers
>>    away from functions that are not really deprecated, just not
>>    recommended for some other reason.  Those deprecations can
>>    usually be ignored safely by those with good reason to use those
>>    more portable APIs.
>>
>> So, if this is just another "political" compiler warning, there is
>> little reason to head it.
>>
>> Otherwise, the GetVersionEx() function can be used as a replacement,
>> but only by dropping support for Windows NT 3.10 and maybe Win32s (NT
>> 3.50 and all the Win9x and WinCE variants include the basic form of
>> GetVersionEx()).
>>
>> P.S.
>>
>> If there is still code in there to support 16 bit Windows 3.x, then
>> that API includes only GetVersion(), and with a different
>> specification than its 32/64 bit namesake.
>>
>>


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded ______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
:��I"Ϯ��r�m���� (���Z+�K�+����1���x ��h���[�z�(���Z+� ��f�y������f���h��)z{,���
Reply | Threaded
Open this post in threaded view
|

Re: A small note on Windows 8 GetVersion() depreciation

Walter H.
On 09.01.2014 19:48, Watson, Patrick wrote:
> I'd recommend using VerifyVersionInfo: http://msdn.microsoft.com/en-us/library/windows/desktop/ms725492(v=vs.85).aspx. It's supported from Win2k onward and isn't deprecated as of Win 8.1. I don't remember for sure if it's present in Windows CE and unfortunately I don't have my CE documentation handy at the moment.
>
>
I guess it must be a combination of GetVersion, GetVersionEx and newer APIs;

http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972%28v=vs.85%29.aspx

Walter


smime.p7s (7K) Download Attachment