i am not able to test it on win08 but i found this document, here?
What do you think about adding better detections to this header file which is distributed by default in nsis installation?
Or should i add the more complex detection to my own header file, to keep the official one slim, clean and simple?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The kernel is the same as Vista SP1 (And I'm guessing the major usermode dlls like kernel32 and user32 aswell) So, maybe 6.0.6001 should just be known as Win2008, WinVer.nsh does not detect other service packs does it?
If you need something for display purposes, you can call GetVersionEx yourself no?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After looking at this some more, I still feel 6.0.6001 should be known as Win2008 (and nothing else). VistaSP1 is AFAIK the first time in windows history (Win98SE did it as well, but its not a service pack) that the build number changed in a service pack.
Just like XP x64 and Win2003 share the same version/build numbers, VistaSP1 and Win2008 now share version numbers because the kernels are the same. I'm guessing its going to be like this in the future as well (Consumer version comes out, a couple of months later, the server comes out, sharing the same kernel with whatever the SP level the consumer version is at) If this is the case, IMHO, it does not make sense to test for OS names, installers should be testing for major/minor versions and service pack level, then IF it should only run on NT Servers for example, check if it is a server or not (Or the other way around, check for server OS first, then version numbers) I'm guessing most installers don't care if they are on a server or not, all they care about is that whatever they are installing runs (meaning, kernel32 and friends are atleast at version X.Y)
Or you could look at all the stuff I just said and turn it around and say: Anything pre NT6 needs the old way of checking OS type and then service pack, but with NT6+ we can just check the server bit and the build number and be able to support IsWin"XXXX"SP"Y" and just hope they keep changing the build number with future SP's
So...we just don't know if the build number will change with VistaSP2/Win2008SP1, so changing the way we use the WinVer stuff should probably not be done at this point.
-----
I did come up with a new version of WinVer, it checks for NT Server OS and build numbers. It also has support for GETTING the service pack level, but not with if tests like IsWin"XXXX"SP"Y" (Except for IsWinVistaSP1)
It has support for Win98SE,Win2000Srv,WinXP64,WinVistaSP1 and Win2008 (Not including the other stuff it already supported) It uses two variables and the large block of code that calls GetVersionEx is only used once now.
It does however break compatibility with older WinVer (IsWin98 is FALSE on Win98SE, IsWin95 != IsWinNT4) People really should be using AtLeast and/or AtMost instead of testing for one version directly (Unless you have a time machine) So, by default it works like the old code (Except for the new xxxSrv tests) To get build number tests, you must define WINVER_USEBUILDNUMBERS
The version info format is now:
Platform (bool)NT \
/Major /Minor /Build (bool)NT Server |
| | | ||
0MMMMMMMMMMMMMMMmmmmmmmmmmmmmmmmBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBSP
(Platform type is not used during version compare. Major version is really treated as two bytes, but it does not deal with sign exstension when we get up to windows 127+ ;)
I'm not sure if the NTServer bit should come before the build number, if it was, it would go:
WinNT4 < Win95/98 < WinNT4Srv instead of WinNT4 < WinNT4Srv < Win95/98 like it is now.
I also added support for getting the actual version numbers with GetWinVerMajor,GetWinVerMinor and GetWinVerBuild macros (for now, to read the service pack version, just check $__WINVERSP, but should probably be a macro so $__WINVERSP can be extended (OSVersionInfoEx.wSuiteMask and/or minor service pack version))
In addition to all that stuff, I also added code for detecting MediaCenter, Tabled Support and Starter Edition, but its not related to the version code and could be added to the old WinVer without change
Oh, almost forgot the link, http://pastebin.ca/1048713 (Only did limited testing on XP. Script includes a little test app)
I'm sure this needs more work, but I'm just throwing stuff out there so at least we keep this thread going
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I disagree. The OS version is much more than just the kernel. There are also the different pre-installed applications that come with different OS versions. XP, for example, doesn't have the same Active Directory tools that come with 2003.
I like patch #1835866 approach for service packs. It seems clearer in a sense that some people might get confused by the time line of service packs. NT SP6 came after 2000 was released. So is SP6 newer or older than 2000 SP0? Letting the user play with the service packs separately seems better.
But I do like the idea of initializing everything on the beginning and then just comparing. Maybe it'd be best if we assign a number for each OS, ordered by their "newnewss" (95, 98, ME, NT, 2000, XP, 2003, Vista, 2008). That should be easy to compare and might be cleaner to create.
I also want to add the tablet and media center bits when the interface is settled.
I'm attaching your patch here so it won't get lost on pastebin.
File Added: Anders-WinVer.nsh
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=584402
Originator: NO
When you run winver.exe on 2008 does it say Version 6.0 or something else?
Logged In: YES
user_id=1200683
Originator: YES
i am not able to test it on win08 but i found this document, here?
What do you think about adding better detections to this header file which is distributed by default in nsis installation?
Or should i add the more complex detection to my own header file, to keep the official one slim, clean and simple?
Logged In: YES
user_id=1200683
Originator: YES
forgot the link, sorry ;)
http://www.codeguru.com/cpp/w-p/system/systeminformation/article.php/c8973/
Logged In: YES
user_id=584402
Originator: NO
That article is what I also saw and according to it you can't differentiate between 2008 and Vista SP1 with the current GetVersion method.
I'd like WinVer.nsh to detect at least the version. If it means calling GetVersionEx, so be it.
Logged In: YES
user_id=872912
Originator: NO
The kernel is the same as Vista SP1 (And I'm guessing the major usermode dlls like kernel32 and user32 aswell) So, maybe 6.0.6001 should just be known as Win2008, WinVer.nsh does not detect other service packs does it?
If you need something for display purposes, you can call GetVersionEx yourself no?
Logged In: YES
user_id=584402
Originator: NO
But 6.0.6001 is Vista's version as well. We have no choice but to move on to GetVersionEx and friends. You want to take care of that Anders?
Logged In: YES
user_id=872912
Originator: NO
I came up with something, but I don't have a server OS to test with (Only did limited testing on xp with the compatibility tab)
http://pastebin.ca/1014249
I added tests for 2000Srv and XP64 aswell as 2008
The new version constants are in the following format: 0xMmmS, where M=major, m=minor and S is 1 on server on 0 on workstation platforms
Logged In: YES
user_id=872912
Originator: NO
After looking at this some more, I still feel 6.0.6001 should be known as Win2008 (and nothing else). VistaSP1 is AFAIK the first time in windows history (Win98SE did it as well, but its not a service pack) that the build number changed in a service pack.
Just like XP x64 and Win2003 share the same version/build numbers, VistaSP1 and Win2008 now share version numbers because the kernels are the same. I'm guessing its going to be like this in the future as well (Consumer version comes out, a couple of months later, the server comes out, sharing the same kernel with whatever the SP level the consumer version is at) If this is the case, IMHO, it does not make sense to test for OS names, installers should be testing for major/minor versions and service pack level, then IF it should only run on NT Servers for example, check if it is a server or not (Or the other way around, check for server OS first, then version numbers) I'm guessing most installers don't care if they are on a server or not, all they care about is that whatever they are installing runs (meaning, kernel32 and friends are atleast at version X.Y)
Or you could look at all the stuff I just said and turn it around and say: Anything pre NT6 needs the old way of checking OS type and then service pack, but with NT6+ we can just check the server bit and the build number and be able to support IsWin"XXXX"SP"Y" and just hope they keep changing the build number with future SP's
So...we just don't know if the build number will change with VistaSP2/Win2008SP1, so changing the way we use the WinVer stuff should probably not be done at this point.
-----
I did come up with a new version of WinVer, it checks for NT Server OS and build numbers. It also has support for GETTING the service pack level, but not with if tests like IsWin"XXXX"SP"Y" (Except for IsWinVistaSP1)
It has support for Win98SE,Win2000Srv,WinXP64,WinVistaSP1 and Win2008 (Not including the other stuff it already supported) It uses two variables and the large block of code that calls GetVersionEx is only used once now.
It does however break compatibility with older WinVer (IsWin98 is FALSE on Win98SE, IsWin95 != IsWinNT4) People really should be using AtLeast and/or AtMost instead of testing for one version directly (Unless you have a time machine) So, by default it works like the old code (Except for the new xxxSrv tests) To get build number tests, you must define WINVER_USEBUILDNUMBERS
The version info format is now:
Platform (bool)NT \
/Major /Minor /Build (bool)NT Server |
| | | ||
0MMMMMMMMMMMMMMMmmmmmmmmmmmmmmmmBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBSP
(Platform type is not used during version compare. Major version is really treated as two bytes, but it does not deal with sign exstension when we get up to windows 127+ ;)
I'm not sure if the NTServer bit should come before the build number, if it was, it would go:
WinNT4 < Win95/98 < WinNT4Srv instead of WinNT4 < WinNT4Srv < Win95/98 like it is now.
I also added support for getting the actual version numbers with GetWinVerMajor,GetWinVerMinor and GetWinVerBuild macros (for now, to read the service pack version, just check $__WINVERSP, but should probably be a macro so $__WINVERSP can be extended (OSVersionInfoEx.wSuiteMask and/or minor service pack version))
In addition to all that stuff, I also added code for detecting MediaCenter, Tabled Support and Starter Edition, but its not related to the version code and could be added to the old WinVer without change
Oh, almost forgot the link, http://pastebin.ca/1048713 (Only did limited testing on XP. Script includes a little test app)
I'm sure this needs more work, but I'm just throwing stuff out there so at least we keep this thread going
Logged In: YES
user_id=584402
Originator: NO
I disagree. The OS version is much more than just the kernel. There are also the different pre-installed applications that come with different OS versions. XP, for example, doesn't have the same Active Directory tools that come with 2003.
I like patch #1835866 approach for service packs. It seems clearer in a sense that some people might get confused by the time line of service packs. NT SP6 came after 2000 was released. So is SP6 newer or older than 2000 SP0? Letting the user play with the service packs separately seems better.
But I do like the idea of initializing everything on the beginning and then just comparing. Maybe it'd be best if we assign a number for each OS, ordered by their "newnewss" (95, 98, ME, NT, 2000, XP, 2003, Vista, 2008). That should be easy to compare and might be cleaner to create.
I also want to add the tablet and media center bits when the interface is settled.
I'm attaching your patch here so it won't get lost on pastebin.
File Added: Anders-WinVer.nsh
New WinVer based on Anders' patch is now waiting in SVN. It will be present in the next version - 2.42.