WinVer in NSIS Unicode 2.42

Hi all,

i use this to check for a Windows 2003 Server in the .oninit Function.

Function CheckIfValidOS



    !Include WinVer.nsh

    

    ${If} ${IsWin2003}

        MessageBox MB_OK YES

    ${Else}

        MessageBox MB_OK NO

    ${Endif}

    

FunctionEnd  

It works with NSIS Unicode 2.38-1 but not with NSIS Unicode 2.42

It also works with the regular NSIS 2.42 (non Unicode)

Regards
Holger

Ok i have looked into it some more, i am building the same script with NSIS 2.42 (Unicode and not)

NSIS 2.42 will recognize XP, Windows 2003 Server and Windows 2008 Server

NSIS 2.42 Unicode will only recognize XP but not 2003 or 2008

Funny enough the WinVer of the 2.42 Unicode Version will recognize a W2K3 Server as Windows XP .....

I have now replaced the 2.42 WinVer with the one from 2.38 and it works for my purposes.

Hrm, I'm not sure why you are getting an error. I just did a few sample tests myself and it works fine. There has been quite a bit of changes in how include files are used from 2.38 to 2.42. Could that be the problem? Can you try writing a very simple NSI script that reproduces the problem? And this may be a dumb question but "how about completely uninstalling 2.38?" Are all the files gone? Are you including the right WinVer.nsh and not a copy?

That's a bit disconcerting. But if you copy the WinVer.nsh from 2.38 it works?

It might work, but the current WinVer is pretty new, 2.38 would be the old one where as you said, 2003 = XP and 2008 = Vista SP1

Unless you need to specify GetVersionExW in the unicode version, I could see no problems with the one from 2.42

@jimpark

this is the script i use

Name WinVerTest

OutFile WinVerTest.exe



Section Test

#

SectionEnd



Function .onInit

    

    !Include WinVer.nsh

    

    ${If} ${IsWin2003}

            MessageBox MB_OK "Win2003"

    ${Else}

        MessageBox MB_OK "NotWin2003" 

    ${Endif}

    

FunctionEnd

WinVer.nsh Version 2.38 IT WORKS
WinVer.nsh Version 2.38 DOES NOT WORK

I have also build on a machine that has never had any NSIS installed on it.

@Anders
At this moment i only need to recognize if the machine ist a 2003 Server and that works fine... the 2003 = XP happens with the 2.42 WinVer.nsh

Well, I just tested it on Win2003 R2 which requires the test

${If} ${IsWin2003R2}

And it worked. Can you do the following to see what you get for the machines where you say it fails?

${WinVerGetMajor} $1

DetailPrint "Major version = $1"

${WinVerGetMinor} $2

DetailPrint "Minor version = $2"

${WinVerGetBuild} $3

DetailPrint "Build number = $3"

See if that returns meaningful info.

sorry, I was talking about XP 64 = 2003 (they have the same version number)

edit: ${IsWin2003R2} is special, it does not check the version number at all, you should only use it if you need to detect R2

Are you sure your server is not really Windows 2003 R2?

OK i get

Major version = 5
Minor version = 1
Build number = 3790


thats on a regular 2003 Server (not R2) i don't have an R2 to test with sadly.

Actually, version 5.1 build 3790 is Windows 2003 R2. 🙂

Are you sure? Doesn't it usually display a R2 on the Login Page ?

${IsWin2003R2} does not work there either 🙁

OK found an R2 Server in my VMWare collection

Good News: ${IsWin2003R2} works
Bad News: IT IS Version 5.1 build 3790 (same as my none R2 server)

So you cannot distinguish a R2 from a non R2 using Version and Build number 🙁

And yes the R2 has "R2" right on the logon screen while the other versions do not.

thats the point of ${IsWin2003R2}, because the version numbers are the same

the system plugin in unicode 2.42 is broken

StrCpy $0 "FooBar"

System::Call '*(&t20 "$0")i.r1'

System::Call '*$1(&t4.r2)'

MessageBox mb_ok $2

System::Free $1

should display "FooB" but only displays "Fo" (&w is also broken) so I'm guessing you end up with wrong offsets in the OSVERSIONINFO struct, so it can't check the product type and so Win2003 is converted to XP (XPx64=5.2 workstation)

You're right Anders. This is a bug. I've got a fix for it but I won't be releasing another build until I get a few more fixes in. But thanks for finding this!

Well, on second thought, the documentation for System does say that the special character '&' should be used to describe BYTES of things. So &tN = N bytes of text. &wN = N bytes of Unicode text. &gN = N bytes of GUID. Should this be changed for the case of &wN and &tN so that it is a count of characters? That's sort of what we assume all the time.

well, you already have &i for bytes, if there is going to be any hope of using the same system calls for both versions, &t and &w must be sizeof(TCHAR) counts

Okay, I will have to change the documentation for the System plugin as well to reflect this change. I think I've got some of the other issues hammered out as well. So expect 2.42.1 soon.

Now that 2.42.1 behaves the same as the ANSI version, and this still remains a problem, we need the main NSIS trunk to get this fixed.

Get what exactly fixed?

I may have spoken too soon. I found a bug in xbarns test script that he sent me so it may not be a bug in NSIS at all.

You can use Source\Tests\WinVer.nsi to test WinVer.

it seemed to detect 2003 fine in my tests, I just thought you were talking about the ansi docs, the bytes vs chars count bit

That's been fixed in 2.42.1. And WinVer.nsi works fine for me as well. So it's really up to xbars to see if it's not a bug in his script.

shame on me, as in another post

*imagine sound of forehead hitting tabletop*

You were completely right Jim, almost everything works except finding the difference between 2003 and 2003 R2 i have tested this on a 2003 Standard and a 2003 R2 X64 server these are the only two i have at hand right now.

All else (i tested Vista and XP) works correctly after your correction(s) to my script.

Thanks.