Archive: New Poll - Read! :)


New Poll - Read! :)
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!


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.


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.


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


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


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) :D


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 :D


sweet!
exactly the response i was looking for.

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

-peace-


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!


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.


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:D) however i bought so many hardcore cds that i couldn`t bring it home :D

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


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 ;)


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.


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-


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


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


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


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.


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.


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.


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.:eek:

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:D


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


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.


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 :D

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:eek:, trace ;)


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!


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


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,


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.


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


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.


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.


all these great ideas. *sweet*


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.


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.


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.


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.


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)


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


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.


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


Archive: New Poll - Read! :)


the project readme. change the extension to .doc before running.


Cool. If you guys need an Website Guy and/or a project writer, I would be glad to help. I can even write .pdf files!!!!!

-Duane


I'm not absolutely clear on the C++ scripting core part?
And is the final language 'set'?


Someone on a different thread (I think) thought that MAKENSIS should be written with a C++ "core" (thought it already was, that was somehow self updating. How he thought that was going to work he didn't ellaborate on. I think this can be safely ignored for now, I would think the same goes for allowing RAR and CAB files to be output. Unless someone want to rewrite MAKENSIS and it's components.


the RAR/CAB thing was used only to explain how the installer could be split up; i didn't mean that the actual split files would be these file types.


Might have misunderstood or misread your post, sorry. What I was really trying to say that any enhancements to the NSIS compiler side of things I would have thought are outside the scope of creating a NSIS GUI, apart from anything else no one I've seen reply to this thread has VC++ experience (unless I've missed someone). However if a VC++ person joins in then I'm sure there would be quite a few bits and pieces that people would like changing/implementing.


i read the nsis gui project. sounds good. and about the file splitting i know that this feature must be implemented in the nsis compiler. just thought that justin will read it and writes some comment. bye, trace :D

liquidmotion: my communication skills increasing... ;)
(i laughed 10min. after i read it... thanx)

we should make some advertising sentence,
(just for fun) like:

...NSIS will never die!:cool:

or

...behold, here comes the NSIS

or

...let the NSIS control your mind:eek:


Have we got a name yet? :confused: :rolleyes: :cool: :D ;) :p


NSIS GUI PROJECT
GUI COALITION
NSIS COALITION
sTARfUCKERS iNC. :)
MORPHEDMEDIA.COM - (SHAMELESS SELF PROMOTION)

ANY OTHER GOOD SUGGESTIONS? AND WHY IS MY CAPS LOCK ON?


and also, i need a simple one line post from each person who is in, and what they want to do. nothing big, just so i know :)


Also I suggest that if anyone is interested helping code the project then they should also detail what languages they have experience in (and obviously have access to) and the version they're running (e.g. Delphi 6 Professional)


Help with the specifications and user interface design. I'll sure I'll be able to spend some time on coding regardless of work, although work obviously dictates how much time.

Delphi 5/6 Enterprise, VB 6 Enterprise (but not keen on using VB for this project, however that depends on others).

Marc


Hey, I wouldn't mind helping if you need any extra help.

I have Vis Studio 6 Enterprise (VC++, VB, etc), Borland C++ 5, Delphi 6 personal. Most of my coding is in c/c++ because most of the code I write has to run on Windows/Solaris/Linux/FreeBSD. I've spent a lot of time with VB, and am semi experienced with Delphi but learning it quick.


With your VC++ experience you sound like a good candidate for updating the look of the NSIS installer/uninstaller. If that would be of interest to you. The idea was to give it a facelift making it look more like the current versions of the Wise/Installshield.


i can code in: ASP, HTML, some JAVASCRIPT, VB, some VC++, learning Delphi, flash & photoshop (not really coding).

tools i have: photoshop 6.01, flash 5, golive 5, delphi 5 ent., delphi 6 ent, vc++ ent., vb ent., basically everything :)

i propose delphi to be our language, since it produces stand alone exes while mainting a RAD interface. if we need to use commercial components, we can all chip in to buy it/them.

once people stop posting their skills and applications, i will write up a list of members.

also, http://www.morphedmedia.com/forums has a forum setup for the gui project.


Updating the look of the installer is fine, but do we really want to proceed that path? In order to get the look truely up to date, it's going to add some overhead to the program. It's going to require fairly significant changes which will need to be done repeatedly (unless of course we get them into the official release)

If we do change the look of the installer to be more like InstallShield/Wise, then you're going to have to add several features to make it work. (some of these I've mentioned in other threads and would like to see in there anyway)

Delphi is a good choice for the development language. Sounds like a lot of people know it already, and it's not really that difficult to learn for the rest. (btw, you can download the personal edition for free so there is no reason not to have it ;) )


Keeping it up to date would be a problem (which is probably why the NSIS DLL isn't based on the latest version, at least I don't think it is) and it will also make it a bit larger. However it does currently look rather old fashioned and personally I wouldn't distribute anything other than freeware with it because of this, users like to see you following the latest trends.

It doesn't have to be a 100% clone of either Wise or Installshield just have their general look. So for exmaple, the sidebar graphic could be optional in which case the size shouldn't be much different to the current version. Adding the XP manifest settings to the resource file only add just over 500 bytes.

Hopefully then it might become the standard release.


I can code in Delphi (I have v5 and v6), Visual Basic (but trying to get rid of it because of the upcoming .NET monopoly) and the HTML/PHP/Java bunch. And I know some C/C++ but not enough to actually create anything.

I've created a sort of framework today, it's code-only, no GUI, it's a base class which is going to contain all script settings.

It's called NG (that directory on my HD must have a name...).
Have we found a suitable OS-license yet? Because I put a '(c) by me until we have a license' inside.


i can code in c/c++, vc++ (win32api just little but i`m learning), HTML(DHTML), JavaScript, Flash5, CorelDraw and Photo-paint.

tools i have: Adobe Photoshop 6.0, Visual Studio 6.0 ENT, CorelDRAW 9.0, Flash 5.0, atc... ;)

i coded in Turbo Pascal 7.0 few years ago but i don`t know anything from it now ;)


time for a poll. answer this in the order in which the questions are posted please:

1) Which language should the GUI be written in?
2) What kind of GUI should it be (ultimate,wizard,etc)?
3) what do you want to do in the project?
4) a name for the project/group.

my vote:

1) delphi
2) ultimate
3) www,manage,coder
4) <beer>happiness</beer>

thanks,


1) Delphi
2) 'ultimate', completely hiding script implementation except in the script editor window. Perhaps a wizard too later, but interface first.
3) code interface/internal classes
4) NG :D


a) delphi (all of you code in delphi)
b) ultimate (what is ultimate?) wizard will be good (later)
c) ideas, maybe help with www... what is needed...
d) lost world, project nsis, uncle-fuckers;), ???


i think the project will probably require 2-5 coders, 2 www people, and then people who can contribute good ideas.

sound ok? let's move the discussion to morphedmedia.com/forums :)


Based on the NG 0.0.1 code I wrote some more. Still nothing GUI-like though :rolleyes: but it can now store all text strings for the install. Will upload something again tomorrow.

I have to register again for the MorphedMedia forums... Mmm can't we have our discussions here? Probably not...


ok i will register on the morphedmedia forum... by the way it`ll be good to add to the gui a multi-language support ;-)


It sounds like you are trying to create Inno Setup. Its a installshield look-alike written in Delphi. Of course it has much more overhead than NSIS. I don't think there is a need to try to rewrite NSIS. Why not change the current source if you want a different looking GUI.


we aren't updating the gui for nsis; it is in dos. we are making a windows gui.

or did you mean something different altogether?


I'm mistaken. I thought you were planning on updating the installer itself.

Why not use Java/Swing. That way you wouldnt have to spend so much effort creating GUI components.


We shouldn't really call it a GUI, but more like an user-friendly frontend.
And Delphi has many GUI components, when looking at components it's better than VB, and far better than C++ (in my opinion). And I don't know very much Java yet... have to learn it next year though.


does java run on any computer as a standalone exe?

anyway, we will need to decide if it is a gui or a frontend.


Java will run on any computer which has a virtual machine installed. This includes most computers because of web browsers. Of course, MS has taken Java support out of WinXP by default, so you would required additional components. There are a few compilers which will compile Java to EXE, but they are not the norm.

Although I like Java, I really wouldn't recommend it for this project. The biggest strength of Java is cross platform. Since NSIS only runs on Windows anyway, I doubt many people running Linux/Solaris/BSD/etc are going to be using the front end.

Java does not have as many components to build from, but you can find a large amount of code for it. A lot of ideas can be pulled from Jscript, but you don't have the lot of ActiveX controls and such that are available for Delphi, VB, VC++. (just about any ActiveX control can be used by any of the three. Java can't use them unless you use a scrap all that Java stands for)


Re: New Poll - Read! :)

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.
What is the best? NSIS lokks a little bit like assembler (of course with some powerfull memnoics.
IMHO something like simplified javascript, small, tiny... running precompiled on a stack based bytecode engine and allowing simple branches and loops like if, for, goto (possibly try and catch too) and functions! write once install_font(filename) and use everywhere.
Having an intelligent linker would allow tons of libraries (instead NSIS functions, macros, Sections..) with a suitable hardcoded set of operations for filenamehandling, copiing, versioning...

WSH and VB5CCE would be all to use (if it could be found on all systems)

Using a known language with a common syntax (javascript,c,c#,php...) allows to use any editor so a gui setupgenerator would be overkill.

A setuptoolkit better should integrate in automated processing (make...) or Version Control (cvs...) and might add additional features like resource (f.e. product-versionstring)of all included binaries.

Think hard
(BTW: have changed NSIS to look like inno-setup, if anyone cares)

Hello friends,

i am new at NSIS, but i have used a lot of installer-systems and i think is the best one is NSIS, because it is OpenSource!

My question: What is the status of your NSIS-GUI ?, because i would like to join a OpenSource NSIS-GUI project.


Sorry for my bad english!