GetVersion plugin

Hey,

Can you update the plugin for windows Server 2008 versions and (maybe) future windows 7 ?

thanks,
OJi.

Hi Stuart,

any plans of making this work with the unicode version of NSIS?

I tried and only get nice little "boxes" and some numbers back 🙂

regards
xBarns

Originally posted by xbarns
Hi Stuart,

any plans of making this work with the unicode version of NSIS?

I tried and only get nice little "boxes" and some numbers back 🙂

regards
xBarns

I did build a Unicode GetVersion.dll to be used with Jim Park's excellent port. I encountered a problem however: generated installers seem to be running in XP-compatibility mode. As a result, GetVersion will report Windows XP SP2 on a Vista machine. I'll try to contact Jim to figure out how to fix it.

Mark

You need to use RequestExecutionLevel to avoid Vista's compatibility hacks. If it doesn't work, there might be a problem with the embedded manifest. Maybe it was converted to UTF-16 as well though it should stay UTF-8.

Originally posted by kichik
You need to use RequestExecutionLevel to avoid Vista's compatibility hacks. If it doesn't work, there might be a problem with the embedded manifest. Maybe it was converted to UTF-16 as well though it should stay UTF-8.

The manifest is all right. For some reason the generated installer ran in Windows XP compatiblity mode. And not for me, but for "all users": right-click icon, properties, compatibility, settings for all users. Ticking that one off, and GetVersion.dll returns Vista again.

I rebuild GetVersion.dll and Processes.dll for Unicode. Now I can roll out our installer with Unicode language strings 🙂

What about Vista x64 and Windows7?

How about adding support for detecting Vista 64-bit and Windows 7?

you already have a header with 64 bit stuff.

7 is not out yet so we can't be 100% sure what the version number is, probably 6.1.XXXX

Service Pack is localized 🙁 -- improvement suggestion

Hi

Could you please introduce a function to return the value from wServicePackMajor and/or wServicePackMinor to complement the existing WindowsServicePack which uses szCSDVersion? It's just that the string in szCSDVersion is localized and therefore harder to parse (you have to look for the number assuming that instead of "Service Pack" you can get something else).

Thanks for the great plugin

Best regards,
Miguel

I'm afraid I do not have the tools available to build this plugin at this time (nor can I install them because I am on Vista here).

Stu

There is a new version of WinVer.nsh that does detect Windows 7. I have the latest build, RC-1 on my laptop. I am willing to test GetVersion on it, as I need to have routines in my installers that detect Windows 7.

Thanks

where do i get exdll.h and other dependencies so i can build my own copy so i can try to add win7 items?

download the source @ http://sourceforge.net/project/showf...ckage_id=15374

or browse the code directly:


and

GetVersion update for Windows 8 and 2008R2

Hello

I currently use GetVersion to successfully control the scripts behaviour dependent on the Windows version and architecture.

I see that WinVer.nsh is updated to include the ability to detect Windows 7 and Windows Server 2008 R2 - but since I already use GetVersion I'd prefer to continue using it rather than to switch to WinVer.nsh.

Will GetVersion be similarly updated to detect and report Windows 7 and Windows Server 2008 R2 and if so does anyone have any idea when - or is GetVersion no longer being updated?

Thanks

Tim

TJK, you could, for the while being, identify Windows 7 by checking both WindowsServerName and WindowsVersion.
The WindowsVersion would report 6.1 for Windows7/Windows Server 2008 R2.
The WindowsServerName would be blank for Windows 7 & filled in for Windows Server 2008 R2.

I have included the modifications for Windows 7/Windows Server 2008 R2 and compiled it with Visual C++ 2008 Express, which resulted in the DLL being 21kB! Here is the dll & modified source: http://www.mediafire.com/?sharekey=9...4e75f6e8ebb871

I haven't tested it for Vista & Windows 7 yet.
A friend of mine got the following error when he used my dll in Win7 x64 🙁 "Could not load: C:\Users\ludwig\AppData\Local\Temp\nszCDEE.tmp\GetVersion.dll"
I guess it has to do with .NetFX.

Regards
Chris

I have updated the plugin.

Stu

Thanks

still missing locale dependent SP version functions

Stu please also add functions to get from wServicePackMajor and wServicePackMinor instead of the localized WindowsServicePack using szCSDVersion

I've added those functions (I'm attaching them). I'm just not sharing the binary DLL 'cause it gets huge (100+KB) when I compile it here.

Best regards,
Miguel

Thanks, done.

Stu

Feature wish/idea

First of all thanks for the very great plugin 😉

When you display the architecture you return just 32 or 64, but not the processor architecture like AMD64, IA64, EM64T, x64. But sometimes it would be important to know things exactly (e.g. if you want to auto install Net Framework 2.0 the installers of MS are depending on the architecture as the installer is different for IA64 and x64).

I totally understand, that in most cases the result 32 or 64 is enough, but why not making an additional function GetVersion::WindowsProcessorArchitecture which shows the processor architectiure string.

Hey Stu,

thank for this plugin. I've updated the download version information and the changelog on the download page.

Kind regards

Rainer

Unfortunately this plugin lacks of detecting the real windows version if the installer is started under compatibility settings.

In this case "GetVersionEx" returns the values of the OS selected in the compatibility settings, not the real installed OS!

See the MSDN:
Link: http://msdn.microsoft.com/en-us/libr...51(VS.85).aspx

"If compatibility mode is in effect, the GetVersionEx function reports the operating system as it identifies itself, which may not be the operating system that is installed. For example, if compatibility mode is in effect, GetVersionEx reports the operating system that is selected for application compatibility."

And this is a fight you will ALWAYS lose, you could check the version of system dll's etc, but in the end, if the OS wanted to, it could lie about those also, that's the whole point of forcing a compatibility setting

Originally posted by Anders
And this is a fight you will ALWAYS lose

No! Microsoft itself give the advice to find out the version by checking the OS properties and the version number of i.e. kernel DLL. This is a very save way to find out the real OS.
And I'm sure this possibility will never be disabled since it will be always necessary to get the real OS version, since Win2000, XP, Vista and Seven hape parts with annoying different behaviour which is handled differently.

The article postet at Monday, February 26, 2007 is very interesting and points out reliable possibilities:

Strange results for getVersion

Hi there,

I tried to use this promising plugin for my installer project, but when I do so, I'm getting some strange results from the functions. See attached file.

I seems that the result string of GetVersion::WindowsType is translated into chinese or some other "cryptic" language thing.

Installer is run in English. But I use unicode version of NSIS to be able to install in Japanese.
All other strings I use are displayed correctly.

My system setup:
Windows XP Professional SP3, German

Any ideas?

Thanks,
Jo

The plug-in is not Unicode. It needs rebuilding (among mods). I haven't got the time to do it at the moment.

Stu

you could try http://nsis.sourceforge.net/CallAnsiPlugin_plug-in (Does not work on every plugin, but you can always give it a shot)

Finally got around to building a Unicode version along with some other changes. Uploaded v1.2.

Stu

When I tried using version 1.2 of the GetVersion (ANSI) plugin on my Windows 7 Professional 64-bit system GetVersion::WindowsType reported "Business" instead of "Professional"

It does that for me too. I am using the correct constant values defined in winnt.h so it must be right.

Stu

I think the plugin should be returning "Professional" when it is run on a Windows 7 Professional system.

I found this on MSDN:

The following table indicates the product types that were introduced in 6.1.0.0, and what they will map to if GetProductInfo is called with version 6.0.0.0 on a 6.1.0.0 system.

New for 6.1.0.0            Value returned with 6.0.0.0

PRODUCT_PROFESSIONAL       PRODUCT_BUSINESS

PRODUCT_PROFESSIONAL_N     PRODUCT_BUSINESS_N

PRODUCT_STARTER_N          PRODUCT_STARTER

See http://msdn.microsoft.com/en-us/libr...58(VS.85).aspx