mgillespie
20th November 2003 23:51 UTC

Congrats and a whinge.
First off, congratulations on getting B4 out the door. It's working well here.

Now the whinge.

Do the developers consider the impact of the language changes? In particular ModernUI. We have big problems here keeping script and NSIS versions in sync. I am forever being called across the office to look at NSIS compile problems, and it's always due to mismatched script and NSIS files.

Today I checked our stock script against 2.0B4, and low an behold, it no longer compiled (previously using 3 week old CVS). It's all modern UI errors, and most of the problems were down to renamed #defines, that changed their name for no obvious reason.

I know the product is still beta, and things are subject to change, but please be gentle... I know have 4 versions of NSIS floating around, all versions since 2.0b3, all of which only work with the matching NSIS files.

rainwater
21st November 2003 00:40 UTC

Yes, this is becoming a big problem as NSIS gets more popular. I recently had to switch to another installer package due mainly to this reason.

sdbarker
21st November 2003 06:38 UTC

I sort of agree.

Yes, this is a problem, and very inconvenient.

However...

This is BETA SOFTWARE! You should expect that things are going to change between a CVS pull and a released build. If you have that much of a problem keeping things updated, then stick to ONE build, be it released, or a nightly, or a random cvs pull, or a beta; just stick to something.

-Scott

Joost Verburg
21st November 2003 16:14 UTC

During the NSIS 2 development a lot of things changed and new features were added.

With every release, the Modern UI has become more easier and more stable because of new NSIS features and improvements of the Modern UI code itself. NSIS ifself has also been improved and not everything was backwards compatible with previous development versions.

Remember it was beta software, if we would have chosen not to change anything since the first beta release, we would never have come so far. We could also have chosen not to release the beta versions, but then it would have been impossible to create NSIS 2, because feedback and help from the community is very important. If you would have used only the pre-released, you would only have had to update this script a few times (Beta 3 was released in March). When using CVS version, you can expect that things change.

The next release will probably be a release candidate and the main changes will be related to compressions methods (LZMA compression support).

You can except that there won't be any major changes in the script langauge. The release candidate will be ready soon and then there will only be some bugfixes before the final release.

After the final release, there won't be any major language changes and scripts should be backwards compatible.

Rob: If you had sent me message I could have updated your script in one minute :) There will be a final version soon, I hope you will switch back to NSIS. Then you won't have an installer that is 200 KB larger than the ZIP file and you can keep it multilingual.

mgillespie
21st November 2003 17:21 UTC

We have no intentions of moving from NSIS, it's too good! We use Installshield for a main install still (as it involves installing drivers, and lots of other stuff, but patches, service packs etc, which were previously done using InstallShield are now all converted to NSIS. Developers now spend minutes making the installs, compared to hours (sometimes days, if Installshield was playing silly buggers).

When my boss mentioned about the script incompatabilities, I did point out that it's beta software, and also pointed out how much time NSIS is saving us, and he was happy.

NSIS in our company is still at it's proving stage amonst fellow developers, and when it fails to compile, it does not give a good impressions.

I have tried to limit the amount of versions, but due to various small niggles with the random CVS versions we used, I have to update a couple of times. The version we now have, we have no issues with, but is a CVS cut from a few weeks ago, and I know that if we want to move to release, there will be more script changes required, so I will try to hold off until 2.0 Final.

Joel
21st November 2003 17:32 UTC

Or do like me: keep one version or release untill "The One". :)

mgillespie
21st November 2003 17:41 UTC

We did try sticking to one cut. The problem was 2.0b3 was missing some functionality we needed (1st script rev), so had to opt for a CVS version (2nd script rev), which had some problems with the extraction progress (from CDROM, extracting a 80Mb install looked like it hung), so progressed to a 2nd CVS cut (3rd script rev), which we are now using, and just tried 2.0b4 (4th script rev).

As it is, I think we have been unlucky, in timing and randon CVS pulls. we have 3 script versions in curculation, 4, if we move to 2.0b4 (unlikely unless something pops up that's been fixes in the lasr few weeks).

I originally started this thread, just to highlight these problems to the developers, knowing full well that the comment about beta sw would be thrown back!!! :-) but it did have to be mentioned.

I also understant that most of these changes have been required to make MUI better. But there are still some #defines macros that have changed their name for no obvious reason, making unnecessary problems, keeping version compatabilities.


How about a alias.nsh to help maintain compatability?

#define OLDVAR NEWVAR

Joost Verburg
21st November 2003 19:05 UTC

Keeping everything backwards compatible was not possible without limiting new features.

Adding an alias file would only maintain compatibility for a few things. When users have to update the script anyway, it's better not to keep these old names.

kichik
22nd November 2003 21:55 UTC

If you're not going to upgrade for a while you should at least comment the following piece of code in Ui.c, DialogProc, WM_COMMAND:

else
{
  // Forward WM_COMMANDs to inner dialogs, can be custom ones
  SendMessage(m_curwnd, uMsg, wParam, lParam);
}

kichik
22nd November 2003 22:34 UTC

Scratch that, it's only NSISdl. Unless you're using NSISdl you should ignore this because removing that piece of code will not allow users to press enter to on buttons in inner dialogs.

OK... Turns out this is a bug with NSISdl. If you want to use NSISdl replace:

if (lpWndProcOld)
  SetWindowLong(parent,GWL_WNDPROC,(long)lpWndProcOld);
if (dlg) DestroyWindow(dlg);

if (dlg) DestroyWindow(dlg);
if (lpWndProcOld)
  SetWindowLong(parent,GWL_WNDPROC,(long)lpWndProcOld);

n0On3
23rd November 2003 01:08 UTC

I was annoyed for those changes, but I try not to be anymore ;) NSIS is progressing very much and I am interested in having the script language as simple as possible.

So, I keep an eye on changes, and download CVS as less as I can.


btw, congratulations for v2.0b4! :D :D