Archive: Thanks!!!


Thanks!!!
Many thanks for adding in some of the features I had suggested. I've spent a bit here reworking my scripts now so that they can be properly templated using !define and also getting rid of those horrifying incremental loops since intop has been included. The funny thing was that after our October 1st deadline, I was just looking through the source today to start thinking about how to implement those features and then noticed you'd already taken care of it. Thank you very much!

I did noticed a couple of things, though.

For example, !define SYMBOL 0x12345678 is seemingly being converted to a string. Here's what I mean.

!define CREATORID 0x77487265

WriteRegDword HKEY_CURRENT_USER "Software\U.S. Robotics\Pilot Desktop\Application$2" "Creator" ${CREATORID}

(This will write out a 0 since it's thinking it's a string)

!define CREATORID 2001236581

WriteRegDword HKEY_CURRENT_USER "Software\U.S. Robotics\Pilot Desktop\Application$2" "Creator" ${CREATORID}

This works and correctly writes out the string.

So just something to think about maybe fixing, perhaps like this:

!define CREATORID 0x77487265 - actual hex valued var
!define CREATORID "0x77487265" - string 0x77487265


Also, having a flag to tell an installer to check for a previous installation and ask you to uninstall it before continuing would be nice. I currently have to check in all my scripts and prompt like that, I think it would be a useful addition.

Thanks again.


Fixed this in 1.53, http://firehose.net/free/nsis/

Basically since the string->integer conversion has moved into the exe header, I had to reimplement base 8/16 conversion in the header. It added a little bit of size, but some of the other optimizations I made on 1.53 keep it a cozy 36k.

Love,

Justin


Doh!
When you run the uninstaller executable, the "Next" button on the far right now disappears to a blank button. :(

For 1.53, naturally...


Re: Doh!

Originally posted by Pomflain
When you run the uninstaller executable, the "Next" button on the far right now disappears to a blank button. :(

For 1.53, naturally...
Wow, I am so bad. It'll be fixed in 1.54, up on firehose.net in about 2 hours, or on nullsoft.com in about 23. :)


[edit: both sites are updated. I love Tom. ]
-Justin

Alright. Hey Justin, what do you have planned for NSIS 2.0????:P
-Duane


Haven't really thought about it ... not really sure if nsis 2.0 should exist...

I mean, from the exehead side, there are many directions you could go, but all of them are just different.. do you go:
- smaller but less functionality?
- larger and more functionality? is this necessary?
- dynamic exeheads that are generated on the fly? is this necessary?

Or do we focus on something like using bz2, but compressing the entire datablock as one (this is necessary to really make bz2 outperform zlib in most cases). The problems with doing that are:
- bz2 has more runtime memory requirements
- bz2 would make us have to decompress all the data, do we do that
to a temp file or something? it'd make the installer slower....
- bz2 decompressors may be larger than gzip, but that's probably not much of an issue...

Finally, there is the issue of the compiler end. Basically the existing scripting language has evolved into its current state. Which makes it kind of gross and nasty. But it works, and I kinda like it. Would all the work of making some new fancy parser that is more C like be worthwhile? What good does that do?

I don't know. I think I'd like to focus on taking NSIS 1.x as far as it can go -- i.e. as flexible and small and efficient as possible. Thinking about experimenting with bz2 more, but not sure if it is worth the tradeoffs.

I'd like to cut down the existing exehead from 36k to 32k. Just for cluster size effect. Heh.

-Justin


I like the compression idea - but there should be some way you can choose which compression method to use. For normal use, ZLib should do the trick, but if you're making software for download, saving 100 KB by having a slower installer is worthwhile (for me anyway).
I like the NSIS language as it is - and with the new integer type & comparison, you can do almost everything a normal language can - in essence.
Another 'highly requested' option in this forum was the "Enter text" option. I feel this should be an extra program, which allows entering text in a few text boxes or making a selection with radio buttons - and that program returning INI files. I can make this in Delphi, but not in C++.


Another slight problem?
No problems, figured it out.