Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NSIS 2.0 Final Released

timothy posted more than 10 years ago | from the install-you-must dept.

America Online 36

nandhp writes "The NSIS (Nullsoft Scriptable Install System) project has finally released version 2.0 final. NSIS is a powerful open-source install system for Windows that is based on scripts. It was invented by Nullsoft for the distribution of WinAmp. You can get it here"

cancel ×

36 comments

Sorry! There are no comments related to the filter you selected.

"install scripts" (2, Interesting)

Anonymous Coward | more than 10 years ago | (#8214983)

You mean you don't just drag a folder somewhere and call it done?

Seriously, why don't apps just look at their environment, fix whatever is missing, and not require any install script at all?

Re:"install scripts" (0)

Anonymous Coward | more than 10 years ago | (#8215108)

What's stopping you from creating one?

Re:"install scripts" (5, Insightful)

RzUpAnmsCwrds (262647) | more than 10 years ago | (#8215111)

Many apps do, but they usually provide an installer because it is more convenient. It is a single executable package which installs the application in the proper place (under Program Files if the application is half-ass decent) and adds a shortcut to the Start menu.

Compare this to the folder method. You have to download a compressed archive, extract it, drag it to the proper folder, and create a shortcut (or alias or symbolic link) to the proper executable or executables (if the application has more than one program, such as a game and a level editor) in the proper location.

Executable installers are generally very easy to work with:

- Click on download link
- Click "open"
- App downloads to temporary location (WWW cache)
- When download is complete, installer automtically opens
- Click next a few times, click "I agree", click finish
- App is installed

This works 98% of the time.

Re:"install scripts" (1, Informative)

Anonymous Coward | more than 10 years ago | (#8215205)

Ever used a Mac?

You click the thing you want to download.

A few moments later a window appears with a single icon and maybe a readme. Drag the icon somewhere, double click it and it runs.

All libraries (DLLs), all run-time files, etc, are hidden inside that icon (because it's really a directory with a special flag set that conceals the contents).

Install scripts are left for system files, kernel drivers, non-app stuff.

Or at least, that's how it is supposed to work, a lot of software ported from Windows doesn't quite work that smoothly! :-)

Re:"install scripts" (2, Interesting)

RzUpAnmsCwrds (262647) | more than 10 years ago | (#8216792)

"Install scripts are left for system files, kernel drivers, non-app stuff."

Than why did iTunes have a version whose install script deleted your hard drive in some cases?

"A few moments later a window appears with a single icon and maybe a readme. Drag the icon somewhere, double click it and it runs."

Somewhere? Oh, so you mean that you open your hard drive, find the applications folder, drag the icon in, and make an alias in the Dock.

Thanks, but I'll take the Windows style.

Re:"install scripts" (1, Informative)

Anonymous Coward | more than 10 years ago | (#8217030)

Than why did iTunes have a version whose install script deleted your hard drive in some cases?

You wrote that backwards. What you should have said was, "Buggy install scripts are why we don't use them any more."

Somewhere? Oh, so you mean that you open your hard drive, find the applications folder, drag the icon in, and make an alias in the Dock.

Wow. You really haven't used a Mac. The "applications folder" is an icon in the window sidebar. You already have a window open, obviously, because you're looking at the program you want to install. All you do is drag the program icon to the Applications icon.

If you want to put the program in your dock, do. Point is, it's up to you. There's no annoying installer to put it there for you.

Thanks, but I'll take the Windows style.

Sure, 'cause ignorance is bliss.

Re:"install scripts" (2)

thentil (678858) | more than 10 years ago | (#8216205)

It is a single executable package which installs the application in the proper place (under Program Files if the application is half-ass decent)

No. If the application is "half-ass decent", it allows me to specify where I want it installed in, and *defaults* to Program Files. There are some programs that I do not want installed under the program files directory (fortunately, most 'half-ass decent' programs do allow me to specify where I want it installed). The other thing I would like to see an end to is the spewing of dll's all over the place; they should, unless absolutely necessary, be contained within the application's directory...

Re:"install scripts" (0)

Anonymous Coward | more than 10 years ago | (#8217695)

The other thing I would like to see an end to is the spewing of dll's all over the place; they should, unless absolutely necessary, be contained within the application's directory...

The WHOLE POINT of a DLL is that it can be used by more than one application.

Re:"install scripts" (0)

Anonymous Coward | more than 10 years ago | (#8215117)

Damn, my last 2 mod points expired last night. Otherwise you'd have a +1 Insightful there. Good work!

Re:"install scripts" (2, Funny)

aled (228417) | more than 10 years ago | (#8215404)

I would like about how YOUR apps register their COM objects, DLLs, etc and repair themself, Mr. AC.

Re:"install scripts" (1)

spitefulcrow (713858) | more than 10 years ago | (#8215919)

There's one of the major flaws in the construction of Windows. The entire registry system is horrible and needs to be thrown out.

Re:"install scripts" (1)

aled (228417) | more than 10 years ago | (#8216106)

May be but if you distribute windows apps that use those features you have to live with it. Those installers are your friend here.

Re:"install scripts" (1)

Chacham (981) | more than 10 years ago | (#8216703)

The registry was actually there to fix INI issues. It was a wonderful fix. A central location for most settings was and is a good idea. It does not need to be thrown out. Reworked, yes. Thrown out, absolutely not.

Re:"install scripts" (4, Informative)

Chacham (981) | more than 10 years ago | (#8216750)

Seriously, why don't apps just look at their environment, fix whatever is missing, and not require any install script at all?

There are so many things involved in installation that makes your question one of sheer ignorance. Having worked at a Windows Installation software company, i'll mention a few.

1) DLLs. In order for a DLL to be properly used in a system it must be registered. If it uses OLE, it must be "self-registered". That is, the DLL itself has a subroutine called OLESelf-Register, and it must be called in order to work so the OLE system knows where it is. For a quick example, find ComDlg32.ocx on a system (System or System32 directory) and choose proeprties. On the Version tab, in the list, you will see OLESelfRegister. To selfregister it (it doesn't hurt) go to start run and type regsvr32 ComDlg32.ocx. A dialog box then reports success.

Common DLLs must be marked on the system as to how many program claim to use it. This is so it is deleted only after the very last program stops using it.

Since the DLLs must be placed in the system directory, and the Windows directory is not always known, a system call to get the Windows directory is required.

2) BDE. For those programs using the BDE, the installation process is under an NDA.

3) Uninstall. Creating an uninstall can be painful. An automated system is nice.

4) Installing ODBC. This takes various system calls to be done properly.

5) INI writes. If an INI file is used, the official way to write to it is with as system call. (So NT can divert it to the registry).

6) Temporary files. Creating a temporary files for the installation requires a unique name, and automatic deletion.

There's so much more it's amazing, A very simple project does not need much other than a folder copy (assuming the user can make his own shortcuts). Most programs need some knowledge of Windows, and there is no reason for the programmers to waste their time there.

Also, note, that a great deal of programmers are absolute morons. They having the slightest idea what to do. They can do VB, but when it comes to windows they haven't a clue. For them, an instllation system is a must.

Also, now, with Windows Installer, the installation file must be a specific format. An installation system can make that for you easily.

Re:"install scripts" (0)

Anonymous Coward | more than 10 years ago | (#8217352)

I wouldn't say easily.

My experience with IntallSheild developer at least is that it's several times more difficult.

On the other hand, it wasn't exactly rocket science in the first place.

Re:"install scripts" (1)

jonadab (583620) | more than 10 years ago | (#8223336)

> There are so many things involved in installation that makes your question
> one of sheer ignorance.

This is only true of badly-designed, poorly-implemented software. Good
software is *easy* to install.

> Common DLLs must be marked on the system as to how many program claim to
> use it. This is so it is deleted only after the very last program stops
> using it.

Common DLLs are an example of misguided design. For all of its theoretical
benefits, rampant dynamic linking causes way more trouble than it's worth,
and most "common" DLLs end up being used by exactly one app in almost all
cases; when there *are* multiple apps using it, there is danger of conflicts
(especially under Win9x). It would be far better for all concerned if these
were stored in the same place as the application's primary executable(s); in
many cases it would be even better if the functions that are actually *used*
from the libraries were just linked in statically.

> Since the DLLs must be placed in the system directory

This is almost always a bad idea. It's probably the number one complaint
of powerusers against low-quality Windows software. The problems it can
cause are many and varied.

> Uninstall. Creating an uninstall can be painful.

Yeah, it's painful if your software litters oodles of files all over the
drive. If you've got to clean junk out of multiple different directories,
some of which do not belong just to the application in question, of *course*
the uninstall process will be painful. But this is bad design. There
should only be files in three types of places:

1. The application itself and any needed libraries, controls, whatever,
in the application directory. This includes any "data" that ships
with the application and doesn't change (e.g., images used for toolbar
icons).

2. User-specific configuration information stored on a per-user basis.

3. Other (non-configuration) files that the user has created.

The uninstaller should always remove part 1 completely, ask whether to
remove part 2 (config files) or not, and leave part 3 (documents) alone.
On Windows, these things would typically be in Program Files, Application
Data, and My Documents, respectively. On Unix parts 2 and 3 are in the
user's home directory, and part 1 is in /usr (though it gets split
between /usr/bin and /usr/share typically and maybe /usr/lib too, and
sometimes the prefix may be /usr/local or something else instead of /usr).

> INI writes. If an INI file is used, the official way to write to it is
> with as system call.

There are other, better ways to store configuration information than system
INI writes. The registry is useful for things like setting up associations,
but storing all of the app's config information there is a major mistake,
as it makes it virtually impossible for a user to maintain separate versions
of your app in different directories. (If you don't think users will want
to do this with your app, you're either more naive than you let on or your
app is too simple to need updates to a new version.)

Regular old application-specific configuration files are actually a very
nice, clean solution that works well and has no disadvantages.

Re:"install scripts" (1)

Chacham (981) | more than 10 years ago | (#8225872)

This is only true of badly-designed, poorly-implemented software. Good
software is *easy* to install.


I will repeat this to you now. This statement is sheer ignorance. You obviously haven't an idea as what goes into an installation.

I have woked on thousands of installation scripts. I've responded to tens of thousands of inquiries. I can tell you, that software intallation is complex, and only the simplest of applications should be "easy" to install.

Common DLLs are an example of misguided design. For all of its theoretical
benefits,


Theoretical? OLE is theoretical? Office doesn't get used? Adobe static links? Are you ignorant or just plain stupid? I cannot take this comment seriously.

Common DLLs are used on every OS out there, and are absolutely wonderful.

rampant dynamic linking causes way more trouble than it's worth,

Why? Rampant dynamic linking is what people want. It saves memory, execution time, and file clutter.

and most "common" DLLs end up being used by exactly one app in almost all
cases;


Of course most common DLLs do. Since every DLL is needed by another program. However, if all the programs that use common DLLs would put its own version on the system instead, you'd probably have hundreds more.

when there *are* multiple apps using it, there is danger of conflicts
(especially under Win9x).


And what are these so-called conflicts? The only conflicts i've seen is when people don't dynamically link. There ends up being a name problem, as Windows can only load one DLL given any one name.

> Since the DLLs must be placed in the system directory

This is almost always a bad idea. It's probably the number one complaint
of powerusers against low-quality Windows software. The problems it can
cause are many and varied.


Actually, i believe it is a Windows logo requirement. It was because of the low quality of software that didn't do it. By having all DLLs in one place, there can be no name conflicts, and the correct DLL is always loaded. Plus versioning, and OS versioning, are no longer a problem.

Yeah, it's painful if your software litters oodles of files all over the
drive. If you've got to clean junk out of multiple different directories,
some of which do not belong just to the application in question, of *course*
the uninstall process will be painful. But this is bad design. There
should only be files in three types of places:


And files are the only problem?

What about registry writes? BDE/ODBC entries? Restoring Backups? Needing a reboot during the process (in-use DLLs)? Keeping common DLLs? And i though of that in just a moment. There is much more to be done.

1. The application itself and any needed libraries, controls, whatever,
in the application directory. This includes any "data" that ships
with the application and doesn't change (e.g., images used for toolbar
icons).

2. User-specific configuration information stored on a per-user basis.

3. Other (non-configuration) files that the user has created.

The uninstaller should always remove part 1 completely,


What if the controls come from a runtime environment (VB/VC/MFC)? What if the data is language tranlastion for more than one application (NERO)? What nif the images are user modifiable, and the unijnstall want to give to user a chance to save it?

ask whether to remove part 2 (config files) or not,

Each file infdividually. Uninstallers tend to do that.

and leave part 3 (documents) alone.

Actually, it should ask.

On Windows, these things would typically be in Program Files, Application Data, and My Documents, respectively.

And if the user isn't using NT (Application Data is not always there)? Or the user doesn't want to store it in "My Documents"?

There are other, better ways to store configuration information than system
INI writes.


Not for an INI file. There is a consistent method of doing it, that has been there, and is there, in all versions of Windows.

The registry is useful for things like setting up associations,
but storing all of the app's config information there is a major mistake,
as it makes it virtually impossible for a user to maintain separate versions
of your app in different directories.


Actually, that is the purpose of HKLM and HKLU. The use of INI files before the resgistry was hurting Windows programs a lot. That is exactly why they expanded the registry when going from 3.1 to 95. It ended up being *wonderful*. Cross-computer configurations became extremely easy and multiple users having different setting was now possible.

Your solution only addresses multiple instances by the same user, which is unlikely, yet ignores different setting by the same user, which is very likely.

The appropriate way to address multiple configurations, is with the application having a manger for it.

(If you don't think users will want to do this with your app, you're either more naive than you let on or your app is too simple to need updates to a new version.)

Most users do not do this.

If you want a different version, the registry should have a different parent key for each version. Many applications do this.

Regular old application-specific configuration files are actually a very
nice, clean solution that works well and has no disadvantages.


Sorry, Microsoft specifically said that was a bad idea, and that it doesn't work nicely. This was after trying it for years (Windows 3.x).

Being they actually had to address the real issues, i trust their judgement over your speculation.

===

Even with what you have said. How does the user know where "My Documents" resides? NT and 95 have it in different places. What if it's a dual boot system, and the system drive is not C. What if it's a Japanese NEC and the main drive is A:? How is the programmers supposed to keep up on these things?

What if the application program was a standard instllation, and wanted to switch to a Windows Installer. Anyone who has used an installation program can just recompile with the later version. Anyone who didn't has a lot of work, including reading and starting over from scrap.

Making shortcut icon requires talking to Program Manager (if the app is to work on 3.1 as well). Even creating the shortcut manually, requires installing the file first. What if the user doesn't know C. How should he accomplish these tasks?

Most programmers are rather ignorant when it comes to instllations. It's simply not worth their time to learn how to do it. A simple program that create instlation scripts is wonderful.

Re:"install scripts" (1)

jonadab (583620) | more than 10 years ago | (#8234342)

> > This is only true of badly-designed, poorly-implemented software.
> > Good software is *easy* to install.
>
> I will repeat this to you now. This statement is sheer ignorance.
> You obviously haven't an idea as what goes into an installation.

Repeating it doesn't make it any less wrong. If installing the software
is hard, then the software is badly-written.

> I have woked on thousands of installation scripts. I've responded to
> tens of thousands of inquiries. I can tell you, that software intallation
> is complex, and only the simplest of applications should be "easy" to
> install.

This is bunk. Large, highly-complex software can be easy to install
if it's designed correctly. I've used large, highly-complex software
that's easy to install, because it was well designed.

> Theoretical? OLE is theoretical?
OLE is a mess. There are better ways of accomplishing the same things.

> Office doesn't get used?
What's that got to do with anything?

> Adobe static links?
Please don't appeal to Adobe as an example of good software design.
It makes my whole body cringe.

> Are you ignorant or just plain stupid? I cannot take this comment seriously.
Argumentum ad hominem doesn't strengthen your case.

> Common DLLs are used on every OS out there,
Well, something equivalent is on most of them. I'm not sure how that's
germaine to the question of whether they're a Good Thing, though.

> Why? Rampant dynamic linking is what people want. It saves memory,
> execution time, and file clutter.
It saves memory at the expense of maintainability, and it *greatly*
increases file clutter.

> > and most "common" DLLs end up being used by exactly one app
> Of course most common DLLs do. Since every DLL is needed by another
> program. However, if all the programs that use common DLLs would put
> its own version on the system instead, you'd probably have hundreds more.
So? You'd also have fewer problems.

> > when there *are* multiple apps using it, there is danger of conflicts
> > (especially under Win9x).
> And what are these so-called conflicts?

DLL version conflicts. One app installs an incompatible upgrade to a DLL
and the other app breaks. This used to happen a *lot* on Win95. Microsoft
started a campaign circa 1996 to educate developers about the problem and
about the benefits of installing into the application directory (except
for standard system DLLs), and the situation has improved considerably.

> The only conflicts i've seen is when people don't dynamically link. There
> ends up being a name problem, as Windows can only load one DLL given any
> one name.
This is a confused statement. With static linking Windows doesn't need to
load a DLL at all, so there's no problem.

> > > Since the DLLs must be placed in the system directory
> > This is almost always a bad idea. It's probably the number one complaint
> > of powerusers against low-quality Windows software. The problems it can
> > cause are many and varied.
> Actually, i believe it is a Windows logo requirement. It was because of
> the low quality of software that didn't do it. By having all DLLs in one
> place, there can be no name conflicts, and the correct DLL is always
> loaded. Plus versioning, and OS versioning, are no longer a problem.

No, this is wrong. When the app's installer throws DLLs into the system
directories, it creates version conflicts with any app that uses an
earlier version of the same DLL. It is theoretically possible to avoid
this by changing the filename of the DLL every version, but the library
developers never seem to do that. They usually only change the filename
every *major* version, and keep it the same over several *minor* versions;
minor versions are *supposed* to be backward-compatible with eachother,
but nobody ever does enough regression testing to guarantee this.

> And files are the only problem? What about registry writes?

The registry is overused. Data should be stored in files. The registry
is important for things like associations, but using it for storing data
creates major problems. Among other things, it totally screws up when the
user wants to have multiple versions of the same app installed.

> Needing a reboot during the process (in-use DLLs)?
Needing to reboot during the install process, for any normal application,
is a symptom of massively hugely enormously brain-dammaged design. When
an app wants me to reboot after install before using it, I'm always
suspicious about the quality of the app. Usually I end up replacing it
with a competing product.

> What if the controls come from a runtime environment (VB/VC/MFC)?
Requiring the user to install a runtime environment like that is usually
bad application design, unless the app is intended strictly for in-house
usage.

> What if the data is language tranlastion for more than one application?
You're trying to muddy the waters here. Is it data that's an immutable
part of the application, or isn't it? If it is, it should be deleted when
the app is uninstalled. Otherwise, it shouldn't be in the app directory.
If you aren't sure, then your application design has major problems.

> What if the images are user modifiable, and the unijnstall want to give
> to user a chance to save it?
Data that the user is modifying shouldn't be in the application directory.

> > ask whether to remove part 2 (config files) or not,
> Each file infdividually. Uninstallers tend to do that.

No, heavens, no, not each file individually. Just ask whether or not to
remove the configuration data or not.

> > and leave part 3 (documents) alone.
> Actually, it should ask.
The app uninstaller should not remove documents or other data that the user
has created, since the user can use these data with other applications. (If
the user cannot use these data with other applications, then you're using a
proprietary data format, which is bad application design.)

> > On Windows, these things would typically be in Program Files, Application
> > Data, and My Documents, respectively.
> And if the user isn't using NT (Application Data is not always there)?
> Or the user doesn't want to store it in "My Documents"?

I meant by default, in the most recent version of Windows. Obviously the
user can choose to install the app in F:\apps\foo if the user wants, and
on Win95/98 the Application Data stuff should go in the user's Profile
directory probably.

> > There are other, better ways to store configuration information than
> > system INI writes.
> Not for an INI file.

What I mean is, there are better ways than putting it in a system INI file
at all.

> > The registry is useful for things like setting up associations,
> > but storing all of the app's config information there is a major mistake,
> > as it makes it virtually impossible for a user to maintain separate
> > versions of your app in different directories.
>
> Actually, that is the purpose of HKLM and HKLU.

I assume you mean HKEY-LOCAL-MACHINE and HKEY-CURRENT-USER, but these
keys have nothing to do with this problem. You've obviously never tried
to keep three different versions of Internet Explorer installed so that
you can check your web pages in all three of them in turn. The easiest
way to do it is to shell out money for VMWare or the equivalent.

> The use of INI files before the resgistry was hurting Windows programs
> a lot.
Yeah, but the registry didn't help much...

> multiple users having different setting was now possible.
For a desktop system (which is all Windows is good for), multiple users
having different settings is mostly unimportant. *One* user being able
to use multiple versions of the same app, however, can be very important
on the desktop, and it's virtually impossible if the app stores all its
data in the registry.

> > (If you don't think users will want to do this with your app, you're
> > either more naive than you let on or your app is too simple to need
> > updates to a new version.)
> Most users do not do this.

Most users don't install *any* software that's not already there when they
buy the computer -- what's your point? Applications need to be designed
so that they can handle the demands of (at least) intermediate users.

> Even with what you have said. How does the user know where "My Documents"
> resides? NT and 95 have it in different places. What if it's a dual boot
> system, and the system drive is not C.

I did say there are some things the registry should be used for. This is
one of them. System-level preferences for all applications (such as,
foreground and background colors) are another. I didn't mean that the
registry shouldn't exist at all, only that it shouldn't be used to store
tons and tons of things that could be better stored elsewhere.

> Making shortcut icon requires talking to Program Manager (if the app is
> to work on 3.1 as well).
At this point, programming for Windows 3 is a lost cause. Don't get me
wrong, I'm a big fan of portability, but at this point the only people
still using Windows 3.1 are using it to run legacy software, and they
also know how to use DOS (which is much easier to support than Windows
3.1, due to its much greater simplicity). It makes more sense to support
VMS than Windows 3.1 these days.

Re:"install scripts" (1)

Chacham (981) | more than 10 years ago | (#8234505)

Your comments deny reality, and instead blame Windows. Whether Windows is coded well or not is not the question here. Dealing with the reality of Windows is. As such, an installer is needed.

> Office doesn't get used?
What's that got to do with anything?


It's an excellent example of common DLLs.

> Adobe static links?
Please don't appeal to Adobe as an example of good software design.
It makes my whole body cringe.


It is an extremely common software suite. Common DLLS are used by it, and it is an excellent example.

> Are you ignorant or just plain stupid? I cannot take this comment seriously.
Argumentum ad hominem doesn't strengthen your case.


But it does help convey that i am amazed at your comments.

For a desktop system (which is all Windows is good for), multiple users having different settings is mostly unimportant. *One* user being able to use multiple versions of the same app, however, can be very important on the desktop

That denies the current design of Windows software. Windows is designed to allow for one instance per user. More than that either should be suppoorted by the application, or should be expected not to work well.

Re:"install scripts" (0)

Anonymous Coward | more than 10 years ago | (#8217340)

or i could just...

# emerge whatever_the_hell_i_want

That works too.

Re:"install scripts" (1)

Lord Omlette (124579) | more than 10 years ago | (#8219700)

What Mr. AC is describing is the "XCOPY install" thingee that Microsoft wants your .NET Windows Forms apps to conform to.

Re:"install scripts" (1)

Brandybuck (704397) | more than 10 years ago | (#8222033)

You mean you don't just drag a folder somewhere and call it done?

Hah! Reminds me of a UI epiphany I had a few years ago. I was trying to get a Windows application bundled up ready to go. I was struggling with InstallShield. This was supposed to be the professional version, but I guess I still had to pay extra for the full functionality. So I was planning to just put everything in a zip archive and distribute it like that. Unzip-and-run, in other words. But I was worried, because that was NOT the Windows way.

So I bitched about it to a Mac friend of mine. "What's wrong with that?" he asked. "That's pretty much what we Mac users do." He was right. So I ended up distributing it as a self-extracting zip file. To date I have not had one complaint.

Yeah, SuperPIMPin! (3, Informative)

TheSHAD0W (258774) | more than 10 years ago | (#8215181)

Just FYI, NSIS stands for the product's original name, the "Nullsoft Super-PIMP Install System", before AOL made them change it.

mod down parent. (0)

Anonymous Coward | more than 10 years ago | (#8216215)

Simply untrue. Prove me wrong.

Re:mod down parent. (1)

petard (117521) | more than 10 years ago | (#8216872)

He (or she, I suppose) is right. It was originally the Nullsoft SuperPiMP Install System [sourceforge.net] ... RTFS :-)

Re:mod down parent. (1)

TheSHAD0W (258774) | more than 10 years ago | (#8220390)

Thank you for the hoist, petard. And it's "he".

Ssssshhhhh... (3, Funny)

Doktor Memory (237313) | more than 10 years ago | (#8215192)

Don't just come out and tell people about NSIS! That'll ruin everything!

I like the fact that my competition thinks they have to drop 5-6 figures every year on commercial licenses for InstallShield or InstallerVISE, thank you very much!

Another free/open source installer (4, Informative)

aled (228417) | more than 10 years ago | (#8215423)

I also used Inno setup [jrsoftware.org] with good results. It had some features that NSIS didn't and we switched to it. Very good so far. It is actively being developed.

Details please (3, Insightful)

Hal The Computer (674045) | more than 10 years ago | (#8215932)

Mind being a little more verbose? Some of us probably want to hear what features it had that NSIS didn't.

Re:Details please (2, Informative)

aled (228417) | more than 10 years ago | (#8216117)

It was more scriptable, it has a scripting language based on Pascal. Sorry I don't remember the details.

Re:Details please (0)

Anonymous Coward | more than 10 years ago | (#8216223)

useless karma whore.

Re:Details please (3, Interesting)

Electrum (94638) | more than 10 years ago | (#8217053)

Some of us probably want to hear what features it had that NSIS didn't.

InnoSetup is VERY easy to use. It has a program that writes the config file for you. You can go from installing InnoSetup to having a perfectly working installer in under ten mintes. A disadvantage over NSIS is that the installer size overhead is much greater.

Second Life uses NSIS (5, Informative)

Critter92 (522977) | more than 10 years ago | (#8216546)

Second Life [secondlife.com] has been hapily using NSIS -- featuring Super-PIMP(tm) technology -- for 3 years. We played with just about all of the different installers and settled on NSIS because it generated by far the fastest installs and also created the smallest files. Throw in the fact that it was incredibly easy to use and you had a winner. We haven't switched over to 2.0, though.

Gentoo Portage for Cygwin (1)

axxackall (579006) | more than 10 years ago | (#8217907)

Check Gentoo forums: last summer there was a project letting Gentoo Portage to run on Cygwin. And it worked! Too bad there is no people with resources (time for support and bandwidth for downloads) behind to continue it.

Python scripting for NSIS... (2, Informative)

pschmied (5648) | more than 10 years ago | (#8218864)

And now for something completely different.

It's...

Python scripting for NSIS. [hispeed.ch]

Seriously, there are times when these scripting systems can't do the heavy lifting of a "real" scripting language. I've often thought that Python might be an ideal embedded scripting language for an installer, especially with Mark Hammond's excellent Windows Extensions [python.net] .

Has anyone used this NSIS/Python package? I suppose the only thing stopping me from trying at this point is my own laziness. Alas, this plugin requires that you track your own Python module dependencies.

-Peter

Re:Python scripting for NSIS... (1)

Roman_(ajvvs) (722885) | more than 10 years ago | (#8223671)

So let me get this straight. Just to install a small freeware program which does something maybe slightly entertaining (hopefully greatly entertaining of course), you want the me to install an entire scripting engine along with it, just to get it installed? That doesn't make sense to me.

a quote from their readme.txt:
The packed python22.dll adds less than 400k to the installer executable. One disadvantage stays so far: dependecy have to be tracked manually. If an extension module is used (py or pyd) it must be packed in the installer.

that seems like a fair bit; or am I just misjudging the size of the scripting engine? Using python scripting for python programs [delord.free.fr] , that makes sense, though.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?