Old 5th September 2008, 23:27   #161
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
Thanks for the details, guys. I agree the issue is people with paths to the installer like C:\Documents and Settings\<username-with-extended-chars>\Desktop. I presume this means I'm not doing anything wrong with my plain-old-NSIS installer?

I wish there was a workaround for plain-NSIS because we've got it installed on a plethora of developer and build machines.

Could it be because we're using CRC check?

Can you guys think of a workaround other than switching to NSIS Unicode?

James

(I attached our installer script below in case you're curious.)
Attached Files
File Type: zip secondlife-setup.zip (41.3 KB, 447 views)
jamescookmd is offline   Reply With Quote
Old 6th September 2008, 11:47   #162
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
I made a very small installer to test, and I get the same result with CRCCheck On and CRCCheck Off - so that's not it.

Now, this is just my opinion, but I would probably go Unicode now. It's not something you can really avoid, since the Unicode branch will eventually be moved into the main build, so not doing it now would only postpone the migration.

The alternative would probably be an addition to a readme or FAQ or whatever, with a guide on how to change to the appropriate codepage, or suggesting the workaround to place it in a path only containing ASCII.

I'd like to stress again: The problem is not with paths that contain characters <= U+007F, since those are unchanged in all Windows codepages (except the issue with \, but that one is handled gracefully). The problem is with characters that are >= U+0080, and are not representable in the user's codepage.
Pidgeot is offline   Reply With Quote
Old 6th September 2008, 14:22   #163
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
Thanks guys. I really appreciate the help. I think we'll switch the NSIS Unicode for the time being.

Enjoy the coffee, Jim! :-)

James
jamescookmd is offline   Reply With Quote
Old 9th September 2008, 21:38   #164
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
I'm having another problem...

An installer built with NSIS Unicode 2.38.1 does not show the "unpacking data: ##%" dialog during load. The same installer built with NSIS 2.39 does show the dialog.

My installer is 21 MB compressed with LZMA, so the unpack takes a noticeable amount of time. Is there a way to get that dialog back, or put up some other sort of progress display?

Thanks,

James
jamescookmd is offline   Reply With Quote
Old 9th September 2008, 23:35   #165
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Does that happen with any compression setting? I'm imagining that it does. And also, does it print anything at all like "unpacking data:?" or is there no analogous printed line at all?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 10th September 2008, 00:01   #166
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
Jim,

Should I run the installer from the command line to look for output? I get no window open of any kind during unpack. The first window I get is language select (from our .onInit() function).

I've only tried it with SetCompressor /solid lzma

Tomorrow in the office I'll try it with other compression settings. Any particular ones to try?

James

(I attached the shell of our installer -- all the %%FOO%% sections are automatically populated with our lists of files.)
Attached Files
File Type: nsi installer_template.nsi (30.6 KB, 492 views)
jamescookmd is offline   Reply With Quote
Old 10th September 2008, 00:40   #167
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
It doesn't look like installers print anything to the console -- running from the command line shows nothing.

Also, I have the same problem (no "unpacking" dialog) with:
SetCompressor zlib
SetCompressor /solid zlib
SetCompressor /solid bzip2

Hope that helps.

James
jamescookmd is offline   Reply With Quote
Old 10th September 2008, 11:53   #168
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
A workaround could be to add all files in the right order in the solid archive (using ReserveFile). Then there will be no need to extract a lot of data at startup.
Joost Verburg is offline   Reply With Quote
Old 17th September 2008, 21:13   #169
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
Thanks for the suggestion, Joost. I ended up reordering my .nsi script so all the functions are at the start of the file, followed by all the files. We used to have the .onInit function at the end of the .nsi file, which I think was the cause of the slow unpack. This seems to eliminate the startup delay that caused the "unpacking data" dialog to appear and solves my problem.

I didn't see this documented anywhere -- does NSIS interleave the packed file data and the function definitions? If so, it seems important to put all your user-written functions before the first big list of files. Should that go in the docs somewhere?

Jim, just so you know, NSIS Unicode definitely doesn't show the "unpacking data" dialog, though, even on slow unpacks.

Thanks again, guys. James
jamescookmd is offline   Reply With Quote
Old 15th October 2008, 01:12   #170
vcoder
Junior Member
 
Join Date: Jun 2008
Posts: 7
2.40?

Are you going to update NSIS' Unicode version up to 2.40?
There are some important (for me) improvements and bug fixes.

Thank you.
vcoder is offline   Reply With Quote
Old 15th October 2008, 02:09   #171
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I'm currently at the busiest time of the year for development. We have what we need right now as far as an installer is concerned so I'm not going to be able to update this any time soon. I'm hoping if the NSIS guys are really going to support Unicode, they pick it up soon.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 27th October 2008, 23:21   #172
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
kichik, whats the status of this Unicode support? Needs reviewing? Needs something fixed? Debian folks are wanting this too.

bye,
pabs
pabs is offline   Reply With Quote
Old 7th November 2008, 05:09   #173
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
I've been looking at the code changes just now.

First thing that got me was all the ANSI/Unicode dirs all over the place with the files in UTF-16. I didn't think that is a good idea, so I converted all the Unicode directories into UTF-8 and looked at the differences between them.

Based on that, here are some suggestions:

Don't duplicate stuff that doesn't have non-ANSI characters in it.

Where the only change between Unicode and ANSI is to re-encode the © (Copyright) symbol, just replace it with the word "Copyright", since that is as legally valid as "©".

Where differing parameters to System::Call are needed, add an !ifdef UNICODE or something.

Some more comments:

Don't add/remove whitespace where it isn't needed.

Menu/images/Unicode/create_header.py isn't needed, Scripts/release.py does that stuff.

Please don't include proprietary formats like Paint.NET in nsis, standardised PNG, BMP or ICO are best.

For the languages, store everything in UTF-8 in the source code and convert to ANSI at makensis time if the user sets a specific code page (and error out if all the characters are not available in that CP). On Linux the iconv function can help and for people running makensis on Win9x the unicows library could be useful:

http://libunicows.sourceforge.net/

Switching to gettext style translations and the PO file format for translations might be useful too, dunno how well Windows supports it though.

Use ISO 639-1 codes for language type instead of English words for the languages.

For the Contrib/UIs, add ifdefs, compile them twice and install them into Unicode and ANSI directories. Alternatively makensis could detect a "RichEdit20" class and replace it with "RichEdit20A" or "RichEdit20W" as appropriate.

Examples/Unicode/bigtest.nsi doesn't need to use the ¢ character.

Examples/Unicode/makensis.nsi doesn't need ANSI/Unicode in the registry/etc does it? Just make one version of makensis that does both ANSI and Unicode depending on a command-line switch or a script command. Same for a lot of other stuff.

Will make some of these changes myself, look at the rest of the changes and add more comments.

bye,
pabs

Last edited by pabs; 7th November 2008 at 05:26.
pabs is offline   Reply With Quote
Old 7th November 2008, 05:19   #174
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
I just filed issue 2230926 related to NSIS 2.40 (and earlier) installers throwing an error on startup if the path to the installer contains wide characters.

https://sourceforge.net/tracker/inde...49&atid=373085

NSIS Unicode doesn't seem to have this problem. I wonder if the parts of the Unicode patch that fix this issue could be ported over separately, or as an initial step.

James
james@lindenlab.com
jamescookmd is offline   Reply With Quote
Old 4th December 2008, 01:27   #175
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
Hello, I was using ANSI version of NSIS until I faced the issue with unicode user name. Then I found unicode nsis and it solve the issue.

I just read though this entire thread, and now a bit confused. Looks like I was supposed to convert scripts to unicode?

I did not converted my scripts to unicode, they are still ANSI. But installer now works fine with UNICODE user names, so, definitely, I compiled unicode version.

Why I was able to compile ANSI scripts? Isnt it should be mandatory converted to UNICODE?

I did nothing else but reinstalled NSIS and recompiled it under unicode NSIS. Looks like everything is fine.
What I am missing?
GoHa is offline   Reply With Quote
Old 4th December 2008, 13:38   #176
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
What it does is try to convert the ANSI script to Unicode using the system's codepage. That's probably okay if you are the only developer and you never change your system codepage to something else but technically this is incorrect. In order to make your NSIS script portable, you should convert your script to UTF-16 (using notepad.exe, for instance). If you don't, you might find that later down the line, users report that your installer produces junk text and you might not remember why. It's simple to do, so just load it up with notepad and save as Unicode and save yourself future grief.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 4th December 2008, 19:01   #177
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
Thanks. One more question, if you please.
We are planning to do some localization.
Question regarding existing language files: I've noticed, that with unicoed nsis you ship non-unicode language files. Correct?

How non-unicode language files survive with unicode installer? What shell I do about it? We server like 9 languages, like Gernam, French, Spanish, Simplified Chinesse, Traditional Chiness, Korean, Dutch, Italian, Japanese, Portuguese.
GoHa is offline   Reply With Quote
Old 4th December 2008, 19:18   #178
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
No, the language files that come with Unicode NSIS are indeed Unicode. I'm not sure why you think that wasn't the case, unless you've been looking at the "regular" NSIS files.
Pidgeot is offline   Reply With Quote
Old 4th December 2008, 19:55   #179
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
In unicode NSIS installation files in ".\nsis\Contrib\Language files" are not unicode. See attahcment.

/edit: attachment deleted. I was looking into the wrong NSIS installation folder.

Last edited by GoHa; 4th December 2008 at 20:35.
GoHa is offline   Reply With Quote
Old 4th December 2008, 20:21   #180
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Those aren't the Unicode NSIS files. I've looked at the exact same files here (2.38.1-Unicode), and they are Unicode here.

Note that, by default, Unicode NSIS installs itself into Program Files\NSIS\Unicode - it does not overwrite the ANSI NSIS files (but the context menu is changed to point to the Unicode NSIS instead). The path you give suggest you're looking at the ANSI NSIS files.
Pidgeot is offline   Reply With Quote
Old 4th December 2008, 20:33   #181
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
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.
GoHa is offline   Reply With Quote
Old 5th December 2008, 01:00   #182
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
Is that possible to declare and use (as a plugin feed) ANSI string within UNICODE version of plugin?
GoHa is offline   Reply With Quote
Old 5th December 2008, 01:10   #183
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Not really.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th December 2008, 01:13   #184
GoHa
Junior Member
 
Join Date: Dec 2003
Posts: 20
Send a message via ICQ to GoHa
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.
GoHa is offline   Reply With Quote
Old 5th December 2008, 01:21   #185
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th December 2008, 06:14   #186
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
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
jamescookmd is offline   Reply With Quote
Old 5th December 2008, 10:25   #187
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th December 2008, 15:34   #188
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,559
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

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 5th December 2008, 21:06   #189
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th December 2008, 22:06   #190
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,559
http://cvs.jrsoftware.org/view/issrc/

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 6th December 2008, 00:04   #191
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
So they did open it up. But Pascal? They should have kept it closed. Just kidding. Still, no support for Unicode. :/

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 6th December 2008, 01:35   #192
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,559
Open it up? It has been open source for years

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 6th December 2008, 02:16   #193
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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...

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 7th December 2008, 19:57   #194
ehsanakhgari
Guest
 
Posts: n/a
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
  Reply With Quote
Old 8th December 2008, 10:24   #195
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.)

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 8th December 2008, 10:51   #196
ehsanakhgari
Guest
 
Posts: n/a
Yes, the text files are all encoded in UTF-16LE. Do you have any ideas on what else could be wrong?
  Reply With Quote
Old 8th December 2008, 22:11   #197
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th December 2008, 14:00   #198
ehsanakhgari
Guest
 
Posts: n/a
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?
  Reply With Quote
Old 9th December 2008, 20:22   #199
ehsanakhgari
Guest
 
Posts: n/a
Cool

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!
  Reply With Quote
Old 10th December 2008, 02:58   #200
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I'm glad things worked out. Thank you for the encouragement.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Reply
Go Back   Winamp & SHOUTcast Forums > Developer Center > NSIS Discussion

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump