Archive: Determining OS version
Determining OS version
Hi,
I know about NSIS-OS, but after I searched the
forum about this subject again, I saw the message
about IfOSVersion command. Has it made it into the
scripting language? I have v1.98 (downloaded
a few weeks ago), and it doesn't appear to be there...
IfOSVersion didn't make it to any version of NSIS. Use an external DLL to do the job. Here is one:
http://www.clantpa.co.uk/nsis/x18sysinfoV0.0.zip
here, this is what i use..
work VERY well
ReadRegStr $8 HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion" ProductName
StrCmp "Microsoft Windows XP" $8 lbl_xp
StrCmp "Microsoft Windows Nt" $8 lbl_nt
StrCmp "Microsoft Windows 2000" $8 lbl_2k
ReadRegStr $8 HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion" ProductName
StrCmp "Microsoft Windows ME" $8 lbl_me
StrCmp "Microsoft Windows 98" $8 lbl_98
StrCmp "Microsoft Windows 95" $8 lbl_win95
then just
lbl_xp:
goto lbl_end
lbl_nt:
goto lbl_end
etc.
Re: Determining Win version
Any idea why the aforementioned never made
it into an [not THE, of course :-] official
release? It seems like a very useful feature
for an installer such as NSIS.
Because it could be done using a script. There are lots of stuff that never made it into the installer because they can be done in the script. InstallSheild, for example, have a lot of things in the installer, and a lot less in its script and look at its overhead, 2 meag bytes!
Because it could be done using a script. [...]
Exactly, there are lots of things that can be done via
scripts, but it may serve the users, and thus the cause/project
better if they were implemented as a sort of "sugar" to things
that can be done otherwise. I realize that there's always a
judgment call to that effect; however, determining the version
of Windows in use is one of the paramount features of an installer, IMHO.
InstallSheild, for example, have a lot of things in the installer, and a lot less in its script and look at its overhead, 2 meag bytes!
InstallShield, for one, costs too much money :))). Furthermore,
NSIS's script capability is superior, but that doesn't mean
that sugar is not an option! See what I mean here?
While functionalities X, Y and Z are possible via
15 lines of code, there's nothing conceptually
(or in other ways) wrong with providing sugar
for functionality XYZ, if that's a very commonly
used one.
Opposition to this, again, IMHO, is largely religious,
and leads to forking at best, and people abandoning
a great project at worst. Just, again, My Humble Opinion.
To continue my point, if the size of the
installer's kernel is a problem, it is
certainly possible to split it into
"bare functionality" and "full functionality".
Furthermore, a possibility of easier plugins
for new functionality may be a good consideration
(I'm willing to participate in it, if that's considered
a viable option).
Too much sugar ruins your teeth :D
Plugins are easier then ever with Sunjammer's simplified plugin calls. Try it.
Too much sugar ruins your teeth
Yeah, I know, syntactic sugar causes cancer
of the semicolon... But still...
Plugins are easier then ever with Sunjammer's simplified plugin calls. Try it.
Tried Sunjammer's site, couldn't find it. Perhaps
its too late (read: early) in the day, but, on the other
hand, perhaps you'd provide a link?
I am a consultant, recently having done work
for people who are not as savvy as I am. Shortcuts
in the very language of NSIS would be helpful.
I understand the Unix mentality, but then again,
nothing in Unix mentality goes against a shell
that would provide often-used sugar,
to pull a drawn-out-meaning-not-much
metaphor.
Sunjammer's plugin stuff is already in NSIS 2 (the unoffical version). Have a look at the NSIS 2 thread.
Have you looked at Sunjammer's site enough to find this:
http://www.clantpa.co.uk/nsis/x18sysinfoV0.1.zip
?
My plugin changes are part of NSIS already, no need to look on my site. Instead read the section in the makensis.htm named Plugin DLLs which explains how I made plugins easier to use.
[Sorry if you have trouble finding stuff, the site needs an overhaul, as already stated I will get time for this soon!!]
Hey, let me check out NSIS 2 before I
offload bile on this forum... :)
Incidentally, nothing lead me to go for
the NSIS 2 before; is there a fork? Is
there a reason for that?
I checked out X*info; I myself am using
nsisos (posted here at some point by
Robert Rainwalker. It works fine;
although my personal peeve was that it's
not a part of NSIS script itself, being
such a commonly used thing.
It is a branch. Have a look at the version history here.
Ok; cool; my bad somewhat; any reason
though (apologies if this has been
rehashed many times over :-)) for this
branching? Should I continue to think of
the NSIS 2 as the ONE TRUE VERSION?
Just look at the version history and you will see the reason(s). Most of this forum users use NSIS 2, but it is not official yet. Officiality is up to Justin :D
grisha37, Justin (official developer of NSIS) declared he was going to be away from NSIS for a while, since then mainly KiCHiK and Rainwater, but a few others too, have been continuing to develop NSIS.