Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
America Online Operating Systems Software Windows

NSIS 2.0 Final Released 36

Posted by timothy from the install-you-must dept.
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"
This discussion has been archived. No new comments can be posted.

NSIS 2.0 Final Released More

NSIS 2.0 Final Released

Comments Filter:

  • "install scripts" (Score:2, Interesting)

    by Anonymous Coward
    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" (Score:5, Insightful)

      by RzUpAnmsCwrds ( 262647 ) on Saturday February 07, 2004 @07:23PM (#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" (Score:1, Informative)

        by Anonymous Coward
        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 do
        • "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" (Score:1, Informative)

            by Anonymous Coward
            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 lookin
      • 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 i
    • I would like about how YOUR apps register their COM objects, DLLs, etc and repair themself, Mr. AC.
      • There's one of the major flaws in the construction of Windows. The entire registry system is horrible and needs to be thrown out.
        • May be but if you distribute windows apps that use those features you have to live with it. Those installers are your friend here.
        • 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" (Score:5, Informative)

      by Chacham ( 981 ) * on Sunday February 08, 2004 @01:19AM (#8216750) Homepage Journal
      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.
      • > 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 t
        • 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
          • > > 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
            • 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 exce
    • What Mr. AC is describing is the "XCOPY install" thingee that Microsoft wants your .NET Windows Forms apps to conform to.
    • 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 w

  • Yeah, SuperPIMPin! (Score:4, Informative)

    by TheSHAD0W ( 258774 ) on Saturday February 07, 2004 @07:32PM (#8215181) Homepage
    Just FYI, NSIS stands for the product's original name, the "Nullsoft Super-PIMP Install System", before AOL made them change it.

  • Ssssshhhhh... (Score:4, Funny)

    by Doktor Memory ( 237313 ) on Saturday February 07, 2004 @07:34PM (#8215192) Journal
    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 (Score:5, Informative)

    by aled ( 228417 ) on Saturday February 07, 2004 @08:16PM (#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.

  • Second Life uses NSIS (Score:5, Informative)

    by Critter92 ( 522977 ) on Sunday February 08, 2004 @12:18AM (#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.
  • 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... (Score:3, Informative)

    by pschmied ( 5648 ) on Sunday February 08, 2004 @12:03PM (#8218864) Homepage
    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
    • 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 mus

Slashdot Top Deals

Do you suffer painful illumination? -- Isaac Newton, "Optics"

Close