2. NSIS Discussion
  3. Disappointed by NSIS

Archive: Disappointed by NSIS


Diaa
15th March 2005 13:25 UTC

Disappointed by NSIS
Two or three months ago, I needed to make an installer for my application, after a quick search I chose NSIS because I found that it's widely used.
back then, I've never made any installers, so NSIS was my first experience with installers.
I downloaded and installed NSIS, and I began learning from the samples provided with it.
at the beginning I was thrilled, but soon I got far disappointed.
what I noticed was that every time I needed to add something, I had to do it myself(manually):
//- I needed to add a custom page, so I made it myself.
- I needed to add shared dll, I had to do it myself(I know the function is found in the help, but that's not the only thing I needed)
- I had to write the registry keys myself using an API which is very similar to the bare Win32 API.
- I had to add an entry to Add/Remove programs myself(through the registry too).
- I had to check for windows version myself.

that's not the only thing, but in addition to a hard and ugly script.
hard:
- no standard control-flow constructs like( if, while). only the bad goto and labels(which reminded me of assembly).
- what's the stack for(Push, Pop)?!!! are we back to assembly in the
ugly: well, look at it, can you tell whether a statement is a built-in command, a function or a macro!! and it's not beautiful coz It doesn't look like any language I know.

What made me really switch to another installer(we'll come to that later) was Current/All user support, I thought it should be integrated into NSIS or something, but no, it isn't.
ok, I was ready to do it manually, but what I found that I have to write 2 paths for each statement which depends on Current/All User(which will be a pain to write and maintain).
if it had a good script, I could have done something like that:
var hive;
if (user_chose_current_user)
hive = HKCU;
else
hive = HKLM;

// later, any statement depending on Current/All User could use 'hive' variable.
WriteRegKey(hive, "key");

I switched to InnoSetup, first thing I found is that there's a separation between settings and code, i.e. there are some settings which are understood by the installer engine, and if you want to add custom actions, you could use Delphi.
I liked that very much, and I made the same installer with only half the number of lines.

so, bottom line is: NSIS is as hard as C/C++ plus a bad library.

I'm wondering if I'm wrong with something, please tell me.
I thought it was much better.

Davion
15th March 2005 13:57 UTC

The Difference between NSIS and other installers is the fact that you have to do everything yourself, but this grants you that the Installer does only what you want.

I've worked with InstallShield, InnoSetup and some others before, after over 5 Months I didn't have any results - with NSIS I had an Instller after less then 3 Weeks and there were only a few updates since the last Year

Yes NSIS requires some Work to understand and to get a nice installer, but it's worth the time

Greetz Dave

Joel
15th March 2005 14:12 UTC

Hi Diaa!

First... the idea of making all your self is one of the goals of NSIS...
You know why installers like Inno are popular? Because their Tool IDE (AKA ISTool)... I, as former Inno user, was one of the few that actually "write" the hole script...
MSI installers... well...they are modern and cool... the fact that you need its runtime (1.00 ~MB) and good IDE script makers (which most of them aren't free)
Wise... one of the oldest but coolest installers that uses the old "point n click"...
InstallShield... do you have to download 500 ~MB to get a decent installer?
NSIS... free, opensource, good library, good examples, good plugins ;), good forum members :p ... I'll say...yes...you have to type everything..... even if you use a good IDE like HM NSIS edit :)

Takhir
15th March 2005 17:36 UTC

I see 2 types of NSIS consumers:
1. End users and my boss - they are interested in global product features - maximum functionality (all C can do), total compatibility, (more or less) modern look, Linux package builder, minimum additional package size and zero cost. IMHO this is 8/10 points, multivolume installation and max 4 GB file/volume size (instead of current 2 GB) can give last 2 points to NSIS :)
2. Script writers point of view, I can give 6/10. Pluses - very flexible, source code available, NOT uses Delphi. Minuses - bad manuals (2/10, may be 3 with some samples now), ugly script lang (IntOp :) ). When I use Modern UI it looks like old style dialogs still presents (hidden) in the package (or in code) and increase it's size. Parameters, definitions, compile and runtimes (partly because of bad manuals) - all looks messed, I not feel any concept of product development.
Finally IMHO NSIS is a very good quality product but a bad managed project.

kichik
15th March 2005 19:39 UTC

For future reference:

And a bit more to the point, I like NSIS the way it is now. Easy for simple installers, highly customizable, fast, small and powerful. I really like how it allows to create applications like the following:

http://www.xtremej.com/rcpbuilder.php
http://nsis.sourceforge.net/archive/...php?pageid=493
http://www.smorgasbordet.com/pellesc/

There's always better, but I won't say where we are now is bad.

fredtheman
16th March 2005 08:37 UTC

Re: Disappointed by NSIS

Originally posted by Diaa
I switched to InnoSetup, first thing I found is that there's a separation between settings and code, i.e. there are some settings which are understood by the installer engine, and if you want to add custom actions, you could use Delphi.
Does InnoSetup require your having Delphi to write scripts, or does it come with some basic scripting language, forcing you to use Delphi only for advanced tasks? If the former, then this comparison with NSIS doesn't hold.

Still, I agree with you that NSIS is a bit rough when you've never built an installer before, especially because the language is assembly-like. I assume Justin found it more efficient to write it like this instead of something more modern like Basic or Python. Maybe someone knowledgeable should come up with a "10mn guide to NSIS" introducing a 10,000-foot view of what NSIS does, and how it does it.

Fred.

noleander
16th March 2005 14:46 UTC

I'm a newcomer to NSIS, and I too was very confused at first, but once I finally got the hang of it, I'm satisfied.

In order to help future newcomers, I just wrote a small overview of NSIS and submitted it for inclusion into the official NSIS documentation suite:

http://sourceforge.net/tracker/index...49&atid=373087


This overview is just a draft document, but at least it is a starting point.

Afrow UK
16th March 2005 16:04 UTC

Well, Diaa I'm sorry you feel that way, but considering I really do not remember you asking any questions on here ever, we can't really do anything for you if you hide from us!

-Stu

Yathosho
16th March 2005 21:08 UTC

Originally posted by Takhir
NOT uses Delphi
good point :D:up:

Diaa
21st March 2005 03:37 UTC

To use conditional structures use the LogigLib
Could you provide a link please, I couldn't find anything about it in NSIS archive.

All you need to add a shared DLL is one line, using the InstallLib macro
I didn't know about this, it's not written in the documentation.

NOT uses Delphi
I don't like Delphi either, but at least, it's a mature language with a formal syntax!.


well, I can see you got me wrong, I'm not complaining about the absence of a GUI editor, wizards, and so, I don't even like them(I wrote the InnoSetup script myself although there's ISTool, which could create the whole script out of some mouse clicks).
I'm a hardcore developer, I use C++, COM and inline assembly, I'm complaining that the code that's written in NSIS is low-level.
there should be some built-in libraries which does the things common to Installers, for example creating folders, adding keys to the registry.
In InnoSetup, all you have to do is list the registry keys that your program uses, you don't write code, that's what I'm talking about.
take a look at how it happens in InnoSetup:
the words contained between {# and } are preprocessor defines.


[Registry]
Root: HKCU; Subkey: Software\{#CompanyName}; Flags: uninsdeletekeyifempty
Root: HKCU; Subkey: Software\{#CompanyName}\{#AppNameDev}; Flags: uninsdeletekey


another thing which justifies my argument is that I wrote an installer for my application using both IS and NSIS, the size of the script for IS is half that of NSIS.
do you think this is good? of course not, more code means more bugs, harder to maintain...

being customizable doesn't justify being low-level, hard and ugly.

finally, I hope you are convinced(at least by some of the points I meant), this is all about making NSIS better.

fredtheman
21st March 2005 09:33 UTC

Could you provide a link please, I couldn't find anything about it in NSIS archive.
http://www.google.com/search?q=site%...e.net+LogicLib

I don't like Delphi either, but at least, it's a mature language with a formal syntax!.
I don't have the skills to write compilers, but I assume there's a trade-off between ease-of-use for the developer, and size of the resulting EXE. NSIS was written from the start to minimize foot-print, so I assume that's why Justin chose to use that assembly-like syntax.

well, I can see you got me wrong
Take it from me, this is not a good way to get people to help you. Change that to "I seem to haven't explained myself correctly", or something like that. It usually works better :-)

there should be some built-in libraries which does the things common to Installers, for example creating folders, adding keys to the registry.
As I said above, NSIS generates very compact installers. If that hasn't been done before (I doubt it, but it's possible), someone should write two identical installers, and compare the size of the EXEs as built by Inno and NSIS. It's likely that NSIS will come out ahead.

In InnoSetup, all you have to do is list the registry keys that your program uses, you don't write code, that's what I'm talking about.
I guess no one found it hard enough to work with the Registry with NSIS to justify writing a plug-in. Or no one had the time yet to do this, but it might get done later.

Honestly, I don't find it hard to use the native instructions. Besides, you can always write a wrapper/function if you'd like something yet smaller:


StrCpy $1 "POOOOOOOOOOOP"
WriteRegStr HKLM SOFTWARE\NSISCrap\BigNSISTest "Install_Dir" "$INSTDIR"


another thing which justifies my argument is that I wrote an installer for my application using both IS and NSIS, the size of the script for IS is half that of NSIS.
Again, it depends on what your priorities are. For all those users still connected by modem, bandwidth matters, so NSIS users are willing to use a scripting language that is not as easy to use as a return for smaller EXE.

Now, if you are able to come up with a higher-level scripting language that can still achieve foot-print as small as NSIS, I'm sure there's a demand for it. You might even get rich :-)

Cheers
Fred.

Afrow UK
21st March 2005 13:12 UTC

Please tell me what instructions that you need? NSIS has ReadRegStr, WriteRegStr.
You can create folders using CreateDirectory, or recursively with SetOutPath.

The idea of NSIS is that it is very very flexible. If you want a 'list' of attributes for your installer, then fine, but that is VERY limited in terms of customisation.

If I read correctly, you thought that NSIS has no built in features like registry and creating folders. Obviously you need to spend a few more minutes scrolling through the documentation. There's tonnes of instructions, and even more extra functions for use in the Archive.

In NSIS, you can do everything and anything, but again if you don't look or ask for what you need you won't get very far. Please just look a bit harder before blatantly complaining.

-Stu

Fork me on GitHub