Unicode

Oops. Please disregard my last question, you were absolutely right, files are unicode. I was looking into the wrong NSIS installation folder. Sorry for the confusion.

Is that possible to declare and use (as a plugin feed) ANSI string within UNICODE version of plugin?

Not really.

Lazy to rewrite plugins...
Do you know any encryption plugin that will work with unicode?
Like sha1 or md5?
stuck in this.. During the installation i have to verify downloaded package. Was easy under ANSI version.

NSIS installers already do CRC checks on themselves as I understand it. If that's not good enough, you will have to port some plugin over to work with Unicode. It's not too hard. Look at how the standard plugins were ported.

Jim,

How hard do you think it would be for me to write a Unicode-path-to-installer patch for ANSI NSIS? If I wrote it, do you think the mainline NSIS would accept it?

The inability of ANSI NSIS installers to run from the Desktop and Download folders of Windows users with Unicode account names is a major blocker for us. We use your Unicode version from www.scratchpaper.com, but it would be nice to stay up to date with the recent ANSI NSIS versions.

I'm way too new to the NSIS code to attempt to update the Unicode NSIS version to the latest ANSI codebase. But I might be able to hard-code all the file open commands to use the FunctionW() versions and convert the path to the installer to WCHAR.

What do you think?

James
james@lindenlab.com

James,

I was no expert when I started. I never heard of NSIS nor cared about installers until out of necessity I had to. I just downloaded the source and dove right in.

The problem of trying to make NSIS partially Unicode might be even harder than making NSIS completely Unicode. For example, you'll need to be able to specify Unicode strings in the ANSI script files. From a UI standpoint, there are a million ways to get the path strings from the user and all those paths need to be covered as well. So supporting two methods of data entry support might be a very daunting task.

And even if you were able to shoehorn it -- I don't know how easy it would be to keep it up-to-date. And it probably won't be accepted by the mainline NSIS.

There are two bright sides, though. One, I'm starting to get freed up from my current project so I might be able to spare some time in the coming weeks to update the Unicode NSIS. And two, the main NSIS project needs to adopt some strategy of supporting Unicode soon or it will really lose relevancy -- the only thing saving NSIS is that there is no other open source option. But that can change. Some big project out of necessity can create one that supports Unicode and that would be the end of NSIS. If that happens, I'm not going to keep up Unicode NSIS. I'll just adopt the new open source installer.

- Jim

There are other open source installers, Inno Setup etc.

It would also be possible to create a plugin that can call ansi nsis plugins from the unicode build

Inno Setup I believe is free but not open source. They may have changed that recently.

Also, I don't think they support Unicode either.

I guess a plugin that calls ansi plugins might be doable, but it would not work in the general case. How do you convert to ANSI? Do you assume that the system default codepage is the right one? That would be wrong on many machines. And it won't help you if you went to the Unicode NSIS because you need Unicode in the first place.

Really, if you need Unicode and you need a particular plugin, you really should create a Unicode version of the plugin. It's not that hard.

So they did open it up. But Pascal? They should have kept it closed. 🙂 Just kidding. Still, no support for Unicode. :/

Open it up? It has been open source for years

Yes, it seems like you are correct, Anders. They have been open source for years. I misremembered reading somewhere that Inno Setup is free but not open source. Maybe I was just remembering that there was no easy way to build the source. You needed to purchase Delphi development tools from Borland. Is there any free development tools that can build Inno Setup, currently? Not that I care to learn Delphi or Object Pascal at the moment...

Using Unicode NSIS in Firefox

Hi all,

I'm trying to convert Firefox's installer from NSIS to Unicode NSIS. I'm facing a problem which I don't know how to solve.

When I build Firefox installer using Unicode NSIS, it appears that some of the images/strings/formattings don't make it into the final installer. For example, the header and watermark which the Firefox installer uses do not appear on the screen; the welcome page strings don't show up, and formattings such as bold header for MUI pages are lost.

I'm not really sure what causes the problems. The same source files can be successfully built using NSIS 2.22 (which Mozilla uses by default). I'm trying the Unicode NSIS version 2.33, but I have tried this with the latest version as well, without any luck.

Any help is very much appreciated!

Thanks!
Ehsan

Are all the files you are using now UTF-16LE? The NSI files as well as all the readme text files you are using should be UTF-16LE. Make sure that's the case. (You can use a2u.exe or notepad.exe to make the conversion.)

Yes, the text files are all encoded in UTF-16LE. Do you have any ideas on what else could be wrong?

Are you generating these text files using a script of some kind? I remembering looking at some of the Mozilla build stuff and it seems heavily scripted. Any possibility that some of these files are generated files? I've noticed that while Python and to some extent Perl does internally support Unicode strings, printing them out to a file needs to be done correctly or they get converted to ANSI inadvertently.

Some of these text files are generated by a script, and some others are simply copied using cp. All those files are in UTF-8 encoding. For ANIS NSIS, we would use iconv to convert them to the correct code page, but with Unicode NSIS, I have used iconv to convert them to UTF-16LE. I prepend the UTF-16LE BOM bytes to the files manually using a very simple Perl script:

my $line;
print "\xFF\xFE"; # UTF-16LE BOM mark
while( $line = <STDIN> ) {
print "$line";
}

I have opened all these files in Notepad++ and they all shown properly with the correct encoding.

I assume I don't have to run the BMP files through iconv, right?

Would you say that iconv's output might be different to that of your a2u program? Does a2u support UTF-8 as the input format?

Nevermind, I found out the problem. In our nsi files, we were !defining MUI_INSERT, which, in newer versions of NSIS, caused the MUI_INSERT macro not to expand to anything useful. Removing that !define did the trick!

By the way, did I mention that Unicode NSIS is *awesome*? Keep up the good work, Jim!

I'm glad things worked out. Thank you for the encouragement.

Originally posted by jimpark
Yes, it seems like you are correct, Anders. They have been open source for years. I misremembered reading somewhere that Inno Setup is free but not open source.

This is partially right. Inno Setup is free (as in money) and the source is available, but they are using a license that is not approved by OSI (opensource.org). Inno Setup uses its own unique license:


The sticking point is point 3: "All redistributions in binary form must retain all occurrences of the above copyright notice and web site addresses that are currently in place (for example, in the About boxes)."

This requirement doesn't appear to be compatible with the GPL and doesn't appear to exist in other OSI-approved open source licenses.

I'm not sure if the actual installer itself has a about box, but the version info has a innosetup link in one of the extra items, no big deal IMHO (how far off topic are we now? 🙂 )

I just wanted to inform everyone that I'm actively working on the Unicode port of 2.42. I've got most of it done and working but I'm having a bit of trouble with the System plugin samples. More code got turned into assembly code since 2.38 and I had brush up on my assembly code skills. So expect a release sometime next week.

Also, if anyone wants to help debug my System plugin woes, please drop me an e-mail and I can provide you with the latest code and binaries.

We'll be using Unicode NSIS 2.33 in Mozilla-based software installers. What would we gain if we update Unicode NSIS to a newer version?

From what I can see (and others may feel free to chime in), they've made the writing of the install script easier. For example, when you include an NSH file, you no longer need to declare all the macros you will you use. When using a plugin, you no longer have to remember to put /NOUNLOAD. When writing the uninstall section and using macros, you don't have to remember to put "un" in front of everything. While this probably won't help you if you already have a working NSI script, for someone creating a new one, I can see how it can be a real benefit.

Pardon me for sounding like a broken record here, but um... Is there any plan for this Unicode branch to be incorporated into the trunk?

Due to the sheer popularity of this thread (#1 in replies and views), it seems that I'm not the only one who is a user of this branch. And, it also seems as though I'm not the only one a bit frustrated by the delay in the Unicode branch receiving the latest features added to NSIS.

Some of the reasons first proffered for this not being added to the trunk when first released were due to the question of its stability, but inasmuch as nearly every major open source project is ALREADY using it (Winamp (the host of this site), Mozilla, Firezilla, Open Office), I think the question of its stability has been answered.

NSIS Unicode works, and it works well. I'd like to voice my request again to have regular builds of this from the NSIS site.

Hello folks. Unicode NSIS 2.42 is now out. Get your copy at http://www.scratchpaper.com. If you find bugs, please let me know.

Well, it's been two days and now Unicode NSIS 2.42.1 is out. My sincere thanks to everyone who reported bugs and worked with me to get the fixes done! Go get the latest from http://www.scratchpaper.com.

Differences in 2.42.1

I took the libery to add a few more features to this albeit short release.

Added the ${NSIS_CHAR_SIZE} macro which will be 1 in ANSI and 2 in Unicode. (This only exist in my versions of NSIS, but it would be nice to get into the trunk as well.) This allows the installer developer to write code that uses IntOp to manipulate string pointers to do it the same way for both Unicode and ANSI scripts.

I've also added System::StrAlloc which allocates strings of N characters not bytes. This means that System::StrAlloc 1024 in ANSI will be 1024 bytes but in Unicode it will be 2048 bytes.

Related to the above, I've made changes to the System plugin such that for &tN and &wN, it refers to N characters not bytes. And I've made documentation changes in System.html to that affect.

I've also changed the names of the shell commands to reflect which version of NSIS you will be compiling against. So instead of getting the generic "Compile NSIS Script" in the context menu when you right click on an NSI file, now you get "Compile Unicode NSIS Script" or "Compile ANSI NSIS Script" or both if you have both installed. You may have noticed that Unicode makensisw.exe is smart enough to try to convert an ANSI NSI file to Unicode and compile it anyway. So if you are sure that your ANSI script needs no modifications, but just a file conversion to Unicode, then this is a nice feature. But it can also be a source of confusion so by making the shell commands more descriptive, you'll know what you are getting.

Enjoy.

I would suggest putting a SystemStrAlloc macro somewhere so that the ansi version can continue to call Alloc and save a couple of bytes in size