Angstrom: Replacement scripting language for NSIS?

Howdy everybody. I'm one of the developers over at Yaga (http://www.yaga.com), another one o' them P2P network dotcom startups. I used NSIS for installation of "Yaga Share", and lemme tell ya, we would never have made it to our current 190k (!) installer without it.

However, I must say I'm not particularly enamored of NSIS's scripting language. Yeah, it gets the job done, but I feel it could be better.

But! It is better to light a single candle than curse the darkness. In my spare time, I've cobbled together a prototype for a replacement language. I called it "Angstrom". Its runtime engine is essentially a lightweight FORTH; the current parser also looks like FORTH, but I would probably hide that before it saw the light of day.

Angstrom currently supports:

• Arbitrarily-named global variables, all-you-can-eat!
• User functions, with named arguments and local variables (also all-you-can-eat), and recursion
• Expanding variables inside strings, like "My name is $foo"
• Built-in flow control with if/else/endif and begin/while/repeat; no more labels, real structured programming!
• A variable can be numeric (3) or a string ("foo"), and they are handled differently
• A couple odds and ends thrown in (addition, subtraction, equals, less-than)
• Separate "compiler" and "executor" modules, to minimize runtime size
• Calling out to C functions for easy embeddability

As a proof-of-concept, it's already pretty usable. F'r instance, it can tell you how to solve Tower Of Hanoi puzzles 🙂

So how big is it? Angstrom currently adds 2290 bytes to my test program. But it's hard to say how much it would change EXEHEAD (the NSIS installer runtime component.) First of all, I can probably squeeze that down a little. Also, keep in mind also that your compiled scripts would probably be smaller with Angstrom (as it's more space-conscious). And there's also a bunch of special-case code in EXEHEAD that I could streamline (like the N different versions of if/else/endif).

So. How interested would you folks be in such a thing? Should I take the plunge and try and integrate it into NSIS? If Nullsoft weren't interested in the diffs, should I bother making my own alternate release?


Cheers,


larry

I'd be interested in it. I know that at least one other developer, Edgewize announced plans to "spin-off" another version of NSIS. What you have in mind sounds great for more than just installers. Windows lacks majorly when it comes to scripting...We can use batch files, perl, or other third party resources, but there are few "lightweight" script languages that use a Win32 interface and are powerful enough to be useful. I've been learning Euphoria http://www.rapideuphoria.com , which is a cross-platform language (Linux, Win32, DOS) that has a nice library for building Win32 apps, but an open-source script engine, built on NSIS, would really be cool.

-=Gonzotek=-

I've been working on a replacement script syntax for NSIS, basically more of the same token-parsing but with a consistant syntax. I have to say that a full-fledged scriptable langage sounds incredible. Assuming there are still ways to perform basic NSIS functions (like extracting a file 😉, I can't see why anyone wouldn't be interested in this!

My only worry is that it is perhaps too indepth for some projects - for example, a simple self-extracting archive that opens a readme afterwards. So perhaps replacing the original parser with Angstrom is a little premature. But for larger projects I can only imagine some of the benefits a true language would bring.

I have long been interested in opening a "community-NSIS" site, possibly on SourceForge, where anyone can suggest modifications or improvements. Since I am not likely to go through with this for some time yet, I think you should simply create an independant release (with source code) and tell us where to find it.

Justin has been incredibly hard to reach for any sort of comment - he never replies to emails or forum posts. You probably won't get much encouragement from him :\

Now, that would be nice. Both Edgewize and ExoticMandables have a great idea. But, here are a few thing I want to know:

ExoticMandables: First, the program you are developing, How would you integrate it into NSIS? If it includes an EXE, then how would it work? Second, How is the compression??

Edgewize: Do you know if sourceforge has CGI or PHP access. That way, you can manage people's ideas and own compiled versions. Maybe, Nullsoft/AOL will host it (like the NSI compiler) and that way there is a forum just for NSIS.

You both have some good ideas, and hope it works out.

Duane Jeffers

Edgewise: My goal is to make the Angstrom-added EXEHEAD roughly the same size as the current one, and to make the scripting language about as simple to use as the current one. Since most people don't like postfix (which is FORTH's natural state), I'll have to add parenthesis to make things explicit. If I'm not feeling lazy, the result would be:

if (MessageBox("$message" "$title" $MB_YESNO) == $IDYES)

If I am feeling lazy, I'll just leave operators as functions:

if (Equals(MessageBox("$message" "$title" $MB_YESNO), $IDYES))

So I don't think this would be "too indepth for some projects". My hope is that it would be as easy to use as NSIS currently is for such projects.

DuaneJeffers: I'd integrate it into NSIS by removing NSIS's current scripting language, and plugging in mine instead. The result would work just the same as NSIS currently does (same compression, same EXEs), just with a different scripting language.

Gonzotek: I wouldn't suggest using an Angstrom-based NSIS for general-purpose scripting. I expect my result would still be tailored to the domain of installation/uninstallation. For general-purpose scripting under Windows, I suggest Python. It has wonderful integration with Windows, and is plenty powerful, yet it's a joy to program in.

One more thought. The way Angstrom works internally, it is easy to add new symbols at runtime. I'm thinking I could add an extension DLL interface to NSIS, which would let me move some little-used functionality (Netscape plugins, ActiveX registration) into their own DLLs. The extension DLLs would be stored like regular installed files; the installer would decompress them into a temporary directory and load them. For people who don't use these features, they wouldn't include the DLLs, and adding Angstrom would likely result in a smaller installer. (Well, unless they rebuilt NSIS to disable those features.)

Cheers,


larry

Python! I forgot all about that lil' serpent 🙂.

I'll have to make an effort to learn Python; I read somewhere that a group of highschool students were polled as to what languages were easiest to pick up and Python was near the top (BASIC being #1).

I like the idea of using .dll's for little used functions. That would also give developers a lot of flexibility in making NSIS customized for their needs.

Good luck!

Edgewize: I'd be willing to give a site some loving if you ever do set up a community site. I haven't written an PHP scripts or anything, but I can work with them, and most anything with "straight-up" html.

-=Gonzotek=-

Gonzotek-
I have been working on php and CGI, if you need help, email me duanejeffers1@earthlink.net.

ExoticMandibles-
Ok, but what if I wanted to use NSIS functions for certain things and then your language for other??? What you could do is in the source, add a function that when checked would disable the NSIS source and when enabled would disable yours. If you cannot do that, then with the dll, have an ability to disable your or nsis scripting elements.

Thanks,
Duane Jeffers

Originally posted by DuaneJeffers
Ok, but what if I wanted to use NSIS functions for certain things and then your language for other??? What you could do is in the source, add a function that when checked would disable the NSIS source and when enabled would disable yours.

I don't think you've quite got what I'm proposing. I'm proposing replacing the existing NSIS scripting language with Angstrom, but preserving all the existing functionality.

So, for instance, right now you'd call:

RegDLL "$OUTDIR/foo.dll"

to self-register a DLL called foo.dll. If you used my theoretical Angstrom-enhanced version, it'd probably look more like:

SelfRegister("$OUTDIR/foo.dll")

You could still do everything that NSIS does now, it'd just look slightly different. Of course, the whole point is to add new functionality at the same time, and I'd be doing that too.

So: you wouldn't be able to choose between NSIS scripting and Angstrom scripting in the same installer. But my expectation is that you wouldn't want to 🙂

Oooooooh, ok. I get it. Wow, that would be awesome, but the only thing is learning a new "language" 🙂 . It took me a while to learn NSIS, but I will learn it while still using NSIS. Maybe not. But that sounds much easier.

One suggestion though: Make the help file more comprehensive and more informative. You might even want to create a Zip2Exe program like NSIS so that others would use the comprensive language but not have to learn it (But I would learn it).

DJ

That really sounds like a nice idea. I am all for it. However I would still try to bother Justin until he agrees on merging Angstrom with the official NSIS (although that will be hard :-).

I don't like the idea of having many unofficial spin offs which all incorporate some good ideas, but are not that, well, official and central like NSIS.

But the reason why Justin included the Source with NSIS is so that other people can have their own versions of NSIS. You don't need Justin's approval for redistributing any version of NSIS. See the licence.

DJ

I know that *can* do that according to the license. I am just saying that no so many people will be using it *if* you fork, which would be a sad thing as it is a good change which should come mostly for free concerning the EXEHEAD size.

If it did more than NSIS I'd definately go to the trouble of learning it - seems like Justin hasn't got a huge amount of time to work on NSIS now, maybe NSIS scripting has kinda reached it's limits and it's needing to be ripped out and replaced with something new to allow it to proceed a lot further, were just looking for someone with the time and skill to do that 🙂. It not being an official release would not put me off at all, as long as plenty of folks are happy with it Id have no problem at all using it. Go for it man

Ok, So if it has a Lazy-type script and a Hard work-type script engines, then why not make it open source. If you release this as a developer and NOT through the company you work for, then I among lots of people would LOVE it. To learn about how this scripting language gets it's power would be awesome. But I have a few questions, so please don't think I'm stupid newbie-programmer. 1) Will it have a name in the installer or will it be blank like the yaga share installer? 2) Could you put in an option to replace the name (if there is one) or have a name instead of having a blank spot? 3) Will there be MORE code like an option to have different checkboxes in each section like expressed in this tread http://forums.winamp.com/showthread.php?threadid=52420 ? 4) Can the installer have an option to create web-based databases or something that can instantly e-mail the user AND add them to a Database? 5) How much will it be like NSIS??

There are my questions,
DJ

...

Would you consider using Microsoft's Setup API library? Its pretty powerful when it comes to placing files where they should go and registering them. To get the desired behavior in NSIS requires some really ugly scripting and is shady code at best.

The library (setupapi.dll) is 334 KB (342,288 bytes)

The library is also fully documented at http://msdn.microsoft.com/library/de...iport_73fp.asp

I would be willing to help write/design the NSIS implementation.

Here are some of the features:
- Support for transactional file operation queues (which ties in nicely with NSIS's "Section" concept). These queues (when committed) provide feedback on status of the entire operation (not just the file currently being copied). The operations all take place atomically. If there is an error, the installation can easily be rolled back.

- Automatic registration of com files (even after reboot). This is tough to implement in the current version of NSIS.

- Almost all the functions are passed flags which lends itself to support scripting.

Why in the HELL WOULD YOU WANT MICROSOFT!?!?!?!?!?!?!

The NSIS installer is completely different. Though it is programmed for Win32, Justin made it his own self WITHOUT Microsoft's help. Besides, Microsoft would possibly ask for more than usual information and then contact you to see what you are doing with the item you downloaded. Even if you do nothing with the item, the still contact you. Heck, I even got some invites to a developer conference just because I downloaded the Media Player Encoder.

Now stop giving advice to the people who already have it, and just start another thread just for the program you are programming

-DJ

KennyKen:
While the Windows Setup API is perhaps the wave of the future in Windows installer development, it simply doesn't have enough of an installed base right now for NSIS to be able to rely on it. And adding a 334K DLL to NSIS, when the NSIS runtime is less than 40K, would be an unpopular move with most NSIS developers.

Plus, I'm really only proposing replacing the scripting language. I'm going to have my hands full just doing that; I don't want to get sidelined with lots of other changes.


DuaneJeffers:
First off: Calm down, son. I will point out that if you're interested at all in NSIS, you must be using a Microsoft operating system, and likely you've got other Microsoft products as well. The Windows Setup API is a good idea, even if it's ten years late, and I look forward to the day when I can rely on it being present on users' machihnes.

On to your other questions.

Regarding the lack of the Nullsoft Installation System message in the Yaga Share installer:
Ah, you caught that. 🙂 Yeah, it always annoys me when other companies enforce their own branding on my product. How many products exist out there where the first thing a user sees when running the installer is something about "InstallShield"? Ewww.

You bring up a good point, in that I'm probably not the only person that annoys. I could probably make it settable from within the script, so you could change it to your own text, or make it blank, or whatnot.

As for adding multiple checkbox bitmaps, or a back-end registration database, or how similar will it be to the existing NSIS:
Like I said to KennyKen above, I don't want to add tons of new features to NSIS. I'll have enough to do just replacing the scripting language / runtime execution environment. My goal is to make NSIS+Angstrom able to do
everything NSIS currently can do, and maybe a little more, and make it much easier to extend with new functions.

Finally, all the work I've done on Angstrom so far has been on my own time, and I don't expect that to change. My plan has always been to release it under the same license as NSIS itself, allowing everyone to use/copy/modify it freely.

larry

Well my thought for the back-end registaration was that you could create a separate .exe (like the splash.exe) and the develeper would then add it to the function or something like that. You just put it in the installation package and that is it. The multiple checkboxes seemed like a cool idea, but it doesn't have to be implemented.

Sorry for being mad, I was just P/o-ed at my free website host for not allowing PHP.

-DJ

whats happenin?

ExoticMandibles: Whats happening... Have you anything I could look at... Have you completed the code...

I'm really interrested in getting another language.. I would like to be able to compare a version number i retrieve from the reqistry with another one. So i think the installer needs a new scripting language... Angstrom would be great.

Maybe you could even get it into the "official" NSIS. That would be great even if people has to rewrite their installer scripts...

🙄

It would be worth it to get a more structured language.

Yea, I was wondering if you had completed it. I just thought of your language last night and I hope this works well.

-DJ

I haven't been working on it, due to vacation/visiting family/flu. It's been quite a thrilling month 🙂

However, I do have good news: I have a bunch of modifications to NSIS that I plan to submit to Nullsoft, and/or just plain release to y'all. The big change is an extension DLL that lets you extend NSIS without touching its (hairy) guts. However, I also have a method for changing what I call the "branding text" (that "Nullsoft Install 1.44" thingy, aka the thing Duane desparately wants to be able to change).

I'm hoping to release it soon, but for now my projects have taken priority. But I haven't forgotten about y'all.


larry

Why don't you release it as just a plain release. Justin hardly takes suggestions, and when he does, it is when he is going to release a new version. I just got a site for sourceforge.net and I'm looking for *binary* releases to put on the site (once I learn to upload it via their uploading scheme)(The site is the NSIS Project House for all projects pertaining to NSIS. I will offer the source for NSIS projects using their CVS uploading, but I will have to regulate it. I am hoping Justin will approve of it, so that it is another place for developers to host their projects.

-Duane

For what it's worth, for those of you who still follow this thread: I just released my branch of the NSIS source code, NSIS(lch). You can read about it at the top level of the NSIS Discussion topic.


larry