New Poll - Read! :)

[liquidmotion]

after some debate, a question arose: what is the best installer scripting language? most likely it is NSIS, but i thought i would poll everyone to see what they think.

when the results are in, mkeeley and i will probably try to get a group of coders together to write the "ultimate gui" for the chosen scripting language.

think hard, and reply soon!

[n_ick2000]

I have to say NSIS. I choose this because I really haven't tried anything else, but I think NSIS is the best one out there.

[locnar42]

The other installer's I've used include InstallShield (v5, 6, & 2000), Ghost Installer (1.6), the VB setup project, and of course NSIS.

Every version of InstallShield is a beast. It does everything you want, everything you could ever want, and everything you don't want it to do. That's also the reason the last project I converted from InstallShield to NSIS went from a 5.8 MB file where you had to reboot at least once, older versions of Windows twice, down to a 1.7 MB file with no reboot typically required. One saving grace is the fact that it's the standard which everybody is accustomed to.

Ghost Installer is ok and they have a newer version out now which probably has some nice enhancements. It's a pretty barebones installer, and no source code so you are somewhat limited in what you can do.

The VB setup project is a dog. It sucks in everyway except to package something written in VB. At least they give you the source code to modify, but it's a PIA to do anything with it.

I think I've settled on NSIS for quite a while. It's small, easy to program, source is available, and out of the box does nearly everything I need it to (especially after I wrote the dialog plugin)

Hrmm, probably more than you wanted for a response, but thought I'd give you my take on what I've used.

[dbareis]

While I'm using NSIS I think the current scripting language is too cryptic with not enough generic commands (to many specific variations) For example to set text why not just have one command and specify the text "type" being set as a parameter.
The format of the documentation also does not make finding the right comamnd easy.

I like Ghosts XML and will have another look at that.

I noticed some posts a while back on alternative scripting language (for NSIS) which sounded interesting but at this stage I want to stick with mainsteream NSIS rather than a variation.

My 2 cents worth,
Dennis

[DuaneJeffers]

I like NSIS. Where else can you get feedback to the developer and you can create your own. Now, I think back to a post for a multiplatform NSIS. Why couldn't you guys create a C++ based NSIS scripting core. That way, whenever the downloader updates his/her version of NSIS, then all the program could do is read the C++ source and use that core in conjuntion with a NSIS DLL. But the downloader needs to install the source to use the full core. That way, when a new version is solidified, then you can do a full update.

Just an idea though.
-Duane

[Koen van de Sande]

Creating 'the' NSIS gui is hard, because there are 2 different GUI's required:
1) The scripting GUI. Allows easy editing of scripts. Much like what Slate Blue does right now.
2) The 'commercial' GUI which can do what WISE and InstallShield do: completely hide scripting from the user if he wants to, but allow it with the 1) editor.
I've used WISE instalmaker/builder/something (very confusing names). It offers better (!) compression than NSIS (on maximum), but the base package size is 150 KB, while NSIS' is only 36 KB
I was going to say: WISE supports patch-making, but we have VPatch for that (a GUI for VPatch will be released today)

[trace]

i`ve tryed InstallShied. It`s total shit. I didn`t understand anything from that program some wizard apears there with things like: "create normal installer" or "divide installer into few files" (hope that comming guis (versions of nsis) would be able to make an installer divided into more than 1 file (for floppy disks) like old norton commander you put disk1 -> installing... "pip!!!" please insert disk2... atc.) however i think NSIS is the greatest installer ever. it`s small, easy, FREE, atc. i`m very glad that something like nsis exists, i don`t even imagine the world without it. bye

[liquidmotion]

exactly the response i was looking for.

now i just need to gather some developers for the project. let the application process begin!

-peace-

[mkeeley]

Unfortunately there's a bit more to it than just getting some programmers together.

You need to work out a functional spec, what features do you want to include? Is it going to be completely wizard/gui based with no ability to script or a mixture of the two. The latter being a much more complex proposition mainly due to the fact that NSIS scripting language isn't "structured" e.g. variable number of arguments, lines can span multi lines, lines can include code and comments, which therefore makes it difficult to parse with total success. Something like Ghost score well in that department as the script definition if stored in XML making it easy to parse (although apart from that it doesn't look very impressive).

You need to decide what language it's going to be written in, that might be down to which language the majority of the volunteers can code in. Also agree coding standards that everyone must stick to, it's no fun reading through code written in n different styles. I suppose at that time agree what sort of licensing it is going to have, freeware, open source...

When you've got the easy bits out of the way you need to work out how you're going to break the project up in order for multiple people to work on it. It's not enough just to think that you can simply share out the different screens, as in order to be able to do that everyone needs to know how they will hook together, file layouts, internal data structures... Project managing a team of programmers isn't easy even if each is working on a different program within a suite of programs, I know I do it, it's quite a few times more difficult when they're all working on the same program, even more so when working remotely.

So that's you taken care of for next week!

[Koen van de Sande]

Teamwork is hard. My specs: Can do Delphi and Visual Basic. But I am being to dislike VB more and more, because I see how powerful Delphi is.
Deciding what to do is the next big proplem, like mkeeley says, you need to decide what the program should do.

[trace]

yes it`ll be hard to organize a program developing on internet... but you give nothing for a try so go on it! i know c/c++, but only dos stuff. so i cannot help you with developing (for now). i`m learning win32api i`ve got a very good book so i hope i`ll be a good coder. i want to learn MFC also. but i can help you with features i have a lots of ideas how to make program better and easy to use...
keep in work you`re doing very good job

Koen van de Sande: are you listening to hardcore? (thunderdome atc...) i love that music... i was in belgium last week (i had worldchampionship artistic gymnastics in ghent 64place) however i bought so many hardcore cds that i couldn`t bring it home

Hardcore will never die!!! (slate blue also)

[Koen van de Sande]

trace: No I don't listen to hardcore.
And I was in Belgium too last week. Sat/Sun I was in Brugge, and Monday I was in Gent. Maybe we even saw each other

[mkeeley]

One thing you need to keep in mind when deciding on its functionality is that if you try and incorporate everyones wish lists it will probably turn out to be such a large project it may never actually be completed. You should probably go for what the average user requires, with the capability of expanding the features at a later date.

[liquidmotion]

so much to say, here goes:

to everyone: i can code in VB, and i'm learning delphi. i could also take care of our website, hosting, etc.

mkeeley: very good points; the project would be decided by the developers, and what they feel their skills are. if the group wanted a wizard and scripting support, yes the task would be harder. that is why the group would consist of good coders. if the majority wants a wizard only, then this would be much more simple and able to be completed in a much shorter time frame. of course, all of these things will be discussed and decided when the actual group of coders is formed. - we will try to incorporate the functions that are most requested. maybe we could add some sort of plugin engine that would allow more advanced users to add their own functions.

koen van de sande: you sound like a good coder, and i've seen some of your work. you will be a good addition to the team.

trace: you still might be able to help in script parsing if that is the route we choose. if not, you could help with ideas and support.

i really think we should give this a try, would be a good learning experience for everyone involved, especially me, if we decide to use Delphi instead of VB. nothing like pressure to help you learn a new language

let me know your thoughts, feelings, etc, and hopefully we can get this project underway!

-dan green-

[liquidmotion]

trace: i hope slate blue never dies too =) (almost 1600 downloads this week!)

[mkeeley]

Just to let you know I wasn't trying to put you off, just pointing out what may have been obvious.

[mkeeley]

What I was thinking was that if it was completely gui/wizard based then save everything out as XML that would make parsing much easier than having to parse NSIS script

[liquidmotion]

i know you weren't putting me down

if it was put into XML, how would we pass it to the compiler? convert it into a reg. script, in a temp file, pass the temp file to the compiler, then delete the temp file? works for me. thx XML idea does sound more appealing.

[mkeeley]

What I thought was you write out all the setup info from the gui/wizards to XML, obviously read that back in to repopulate everything when you open a project, then when you build generate the NSIS script from the XML.

[Koen van de Sande]

I think the XML file format is worth investigating - however, we should first look how VB/Delphi/C++ work with XML files. Haven't used them before. On the other hand, I did work a lot with INI files, which are more limited than XML files, but much easier to parse.
I believe there is a XML parser inside Delphi 6, I'll have a look.

[trace]

please can somebody explain me what is XML i thought it`s something like HTML, but from your talk about it i don`t think so.

liquidmotion: you`re right. this will be a good experience for all i`ve learned so many new english words last week...
i can help with the homepage too. i know: HTML, JavaScript, Flash5. So if you need to make some animations, JavaScripts(whole page fade in/out effect atc.), or i can make some pictures also. in CorelDRAW, CorelPhoto-paint. so in this things you can count on with me

[prodangle]

XML is just basically a markup language for holding whatever data one wants. It is used on the web to hold database info, and XSL (extensible style sheets) are used to put the info out of the XML, slam it within pages, and send it to browsers as HTML. XML can be used to hold just about any info. It's also used for WMP7 and WA3 skins.

Have a look at http://www.w3.org/XML/1999/XML-in-10-points

[mkeeley]

As far as Delphi support for XML goes only Delphi 6 enterprise comes with it built in. However there's 3rd party stuff out there both free and commercial. Two free examples:

http://www.destructor.de/xmlparser/

Also at Project Jedi

http://www.delphi-jedi.org/

Haven't tried them so don't know how good they are.

[trace]

hi everyone... i was bored the whole day to day, so i`ve colected some pictures of me and my computer atc. so if there is anybody who wants to see such a things you can download it... hai

trace_fotos.zip

prodangle: thanx... now i know what it is (i think), but i don`t understand what role does it take in the nsis gui app? if it is too long to explain let it be, i`ll take a look on it later.

free your mind, trace

[mkeeley]

The idea is that because XML is structured it's easier to work with than a line of NSIS script. A simple example is that rather than having to chop up

BGGradient 0000FF 000000 FFFFFF

the XML file would have a "field" for each parameter.

So the idea is when you setup your project with the GUI/Wizards all those settings are written away to an XML file, when you re-open the project you use read the XML to get all those settings back. When you build your project you generate the script from the XML.

Hope that sort of makes sense!

[trace]

oh! now i understand... yay that`s great. thanx.
let the xml control your mind bye bye, trace

[liquidmotion]

sounds good. if we are going to be using delphi, which seems to be the consensus, it looks like i will be limited to management/web development/ideas.

i am looking into XML, as far as parsing is concerned. i really think this is the best way to go about doing scripts for the gui.

if you want, i can setup a new forum @ (http://www.morphedmedia.com/forums) dedicated to the new gui. let me know what you want me to do.

thanks a bunch Milton,

[mkeeley]

Apart from standard configuration such as app name, splash screen, folders... I think the following would be a good thing to aim for:

Installation
1. Full, standard and minimum installs
2. Find current version location from registry, ini file or by performing a file search
3. Option to create install log file
4. Ask user before overwriting option
5. Backup current files before overwriting option
6. Register file associations
7. Register DLL's/AciveX's
8. Create shortcuts
9. Reboot windows on exit option

Unistallation
1. Specify additional files and registry entries to be deleted during the uninstall.

Things To Run

If those features were implented it should cover 99% of installs, or thereabouts!
1. Specify things to run at startup, before installation, after installation, before uninstall, after uninstall and at shutdown.
With the option to ask the user if they want to, for example, Do you want to view the read me? Also if it should simply execute or execute and wait for completion.

[mkeeley]

Missed one (at least), write values to registry/ini files during install.

[Koen van de Sande]

All these options aren't going to fit onto one page - so we need to split it into multiple pages. Idea:

1) Program name, installer title, InstallDir and InstallDirRegKey, BackgroundGradient, etc, all the things not found in sections (possibly spanning 2 pages, with one being advanced).
2) Dialog-er page, you can select whether you want a license page. There should be other dialog-related settings here.
3) The Section page - specify all sections install types.
4) Putting in the files (possibly combined with section page?)
5) Compiler options (use UPX, SetCompress, etc) and a huge fat compile button.
6) Script Editor (perhaps).

These different pages could be implemented with Page Controls, but coding will get messy, because all controls are on one form. Using multiple forms might be better, by doing MDI which is always maximezed (you can have a tabbar, but the content is on different pages). Maybe we should just start designing a few of these pages in VB or Delphi? I'd like to use VirtualTreeView for the Section/File pages, because of it's flexibility.

Back to XML: The Delphi 6 TXMLDocument can parse XML files (read anyway). However, I would first suggest designing the classes which contain data at runtime, and worry about loading/saving later on.

[Koen van de Sande]

The URL for VirtualTreeView is: http://www.lischke-online.de and http://groups.yahoo.com/group/VirtualTreeview (with the latest version 2.6.5)
It's a bit hard to use at first, but very powerful.

[liquidmotion]

all these great ideas. *sweet*

[mkeeley]

Agree, page control isn't a good idea, for a start only one person can really work on the thing. Don't like the idea of MDI.

Personally I think a tree view down the left, list view in report mode on the right that shows files for the project. All options pages as modal dialogs. I've attached a simple mock-up to give you a better idea of what I mean.

Think things like set compression should be at a file level not project. Also think all file related bits should be in one dialog, that's how I've done it in my wizard (so I would think that), don't see the point making them go to different locations to pick the file and then setup it shortcut.

Not sure why you want to use a virtual tree view when you're only going to be using it for perhaps a dozen items, if it's just going to be used for section navigation.

[mkeeley]

Oh, if you meant that get all the screens going and then think about how to save and load, then if I were coding I definately wouldn't do that. I think you have to know how this is going to work, even if it's not coded, to be able to know how things should be stored internally.

[Koen van de Sande]

I wanted to do those screens as to define what we want the interface to do. When coding you have to start differently. It's just that our views on the interface are very different (I think).
The treeview on the left is nice, I have it myself in TibEd. Then on the right, like you have your grid, you have all the options. Doing it inside a seperate form isn't very handy - you have to click, close, etc. It's much handier when it 'seamlesly' integrates. Perhaps that was the whole idea of Frames in Delphi? Mmm perhaps Frames might be the way to go. Everyone gets their own frame (every page/item in the tree).
But we have to make some sort of TNSISProject base class first, with child members, etc. Perhaps I should make the VPatch GUI opensource, it has something similar.

[mkeeley]

Frames don't work in the way you may be thinking. Nothing to do with multi-pages, they're a container, bit like a super panel, that you add you're controls to, the frame can then be used a bit like a composite component. But if you're thinking do that and then, say, add them to the pages of a notebook then you'll have problems linking them up to the toolbar and menu.

Having a dialog requires no more typing from the end user than if the form was "integrated", for example either way when you're adding a file you'll still want OK and Cancel options.

One program I've written in the past uses multiple forms shown in a form container. So my main form has the section side panel on the left and the frame container on the right in which you you create an instance of the forms in.

[trace]

oh delphi is nothing for me so i`ll be just the listener for this round. however if trying to explain how the interface shall be, make some picture of it. it`ll be more understable for all of us (i think) more people can write their feelings from it... bye (sorry my english)

[liquidmotion]

kinda sounds like the old slate blue: all on one form, seamlessly integrated.

[mkeeley]

Never saw the old version of Slate Blue, but the main differnece is probably that it's completley gui/wizard based, you never normally see the script. When you want to amend a project it loads everything back up and you amend it visually.

[rainwater]

You should check out ISTool. Its a script editor for Inno Setup. Its one of the best script editors I have ever seen (even though Inno Setup is a little bloated).

Rob