Old 22nd December 2008, 05:55   #201
CritterNYC
Junior Member
 
Join Date: May 2006
Location: Astoria, NY
Posts: 9
Quote:
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:
http://www.innosetup.com/files/is/license.txt

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.
CritterNYC is offline   Reply With Quote
Old 22nd December 2008, 08:13   #202
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
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? )

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 3rd January 2009, 17:11   #203
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 3rd January 2009, 21:23   #204
ehsanakhgari
Guest
 
Posts: n/a
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?
  Reply With Quote
Old 4th January 2009, 12:12   #205
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th January 2009, 14:29   #206
KrisAster
Junior Member
 
Join Date: Aug 2005
Posts: 38
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.
KrisAster is offline   Reply With Quote
Old 6th January 2009, 15:03   #207
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 8th January 2009, 13:24   #208
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 8th January 2009, 13:41   #209
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
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.

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

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 8th January 2009, 17:20   #211
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Well, you might be surprised to find that adding the function did not grow System.dll by a single byte. The code section grows in some increments and it just fits nicely into the space available. And if you really want to fuss over bytes, if you compare my version of the ANSI System.dll, it's actually 512 bytes smaller. And the Unicode version is the same size as the official one.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 13:24   #212
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Auto conversion of text encodings:

Here's basically what the Unicode NSIS does as far as auto-encoding/decoding of text types.
  • If the file has no BOM in the beginning, it assumes it's an ANSI text file. (It will probably use the system codepage to convert it internally to UTF-16LE -- but I'm not sure about this. It may just strip out anything beyond ASCII and replace them with '?').
  • If the file starts with a 16 bit encoding of the BOM (the usual kind 0xFEFF), it will treat the file as a UTF-16 file and correct it for endianness, internally storing everything as UTF-16LE.
  • If the file starts with an 8 bit encoding of the BOM (0xEF 0xBB 0xBF), then it treats the file as a UTF-8 file and not an ANSI file. So those who desire to store their scripts in UTF-8, it's fine as long as it starts with a UTF-8 BOM. I understand that it's not usual for UTF-8 files to have a BOM, but since in the Windows world ANSI/ASCII files are more prevalent than UTF-8, this is what I chose. If people want UTF-8 to be the default, I'm open to that. Just let me know what you opinion is. Incidentally, notepad.exe, when saving files as UTF-8 will add a BOM to the start of the file for you.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 14:42   #213
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
The way I would prefer codepage detection to work is like this:

BOM Present: Use the corresponding encoding/codepage.
No BOM present: Check to see if the file can be fully parsed as UTF-8 (that is, no invalid byte sequences exist). If this succeeds, then it is very safe to assume that the file is indeed UTF-8. If it fails, fall back to ANSI/system codepage. Although we could, at least in theory, try to figure out UTF-16/UTF-32 without a BOM, due to the nature of the files, I suggest not doing so (since they are exceedingly rare, unlike BOM-less UTF-8).

To use this information efficiently, MakeNSISW should be able to perform this check (not only the actual MakeNSIS command-line compiler), and the command-line compiler should have a parameter to tell it the codepage in advance (or, at the very least, a parameter that tells it to skip the "valid UTF-8" check if no BOM is present). The parameter would probably be a good idea anyway, as it would more easily allow for a "Always assume UTF-8 if encoding unknown" option in MakeNSISW.
Pidgeot is offline   Reply With Quote
Old 9th January 2009, 14:50   #214
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Well, there is no BOM for ANSI. There never has been and never will be. Basically, what we can do is make Unicode NSIS never work with ANSI with the exception of ASCII only scripts. If there is no BOM, assume UTF-8. If there is a BOM, assume UTF-16. This is the only other option in my mind.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 18:25   #215
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
Older unix tools might not support BOM for UTF-8, but that's not our problem

If you really want UTF-8 without BOM, maybe makensis could check the first line for a comment like #NSIS: encoding=UTF-8

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 9th January 2009, 18:31   #216
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Well, my guess is, if they don't like putting 3 bytes in front of their file, they will like having to put "#NSIS: encoding=UTF-8" even less.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 18:35   #217
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
but the header is just ascii text that any editor can write, you don't need any special support

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 9th January 2009, 19:18   #218
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I think a lot of these guys are scripting their NSI files and so it's not a big deal to emit three bytes at the front. If they are writing their scripts via a text editor, they may be able to simply save as UTF-8 and it may embed the BOM for them (e.g. notepad.exe does). Or they may have a way to type hex codes: EF BB BF (decimal: 239 187 191). For example in vim, I just do this command:

code:

:dig b: 239 o: 187 m: 191



And then I hit 'i' to insert text and type their ctrl-k b: ctrl-k o: ctrl-k m:. And there I have it.

Or paste this guy: 

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 19:28   #219
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Long post ahead...

Quote:
Originally posted by jimpark
Well, there is no BOM for ANSI. There never has been and never will be.
Well, no, but there doesn't need to be. I've yet to encounter an ANSI file (with characters > 128) that could be mistaken for a BOM-less UTF-8 file, because the odds of an ANSI file not containing any invalid UTF-8 character sequences are astronomically low, due to the way UTF-8 works on a byte level: not only do all bytes > 128 have to be placed together, but all bytes in the range 128-192 must be after a valid lead byte (194-244), and there has to be a very specific amount of high bytes following - it can be expressed as a very simple state machine that checks each byte (worst case executions-wise is that the file is UTF-8, so we end up running through the entire file, but even so, that process shouldn't take more than a second).

That's why I prefer not having to choose between "allow ANSI, but require UTF-8 BOM" or "disallow ANSI, always assume UTF-8", instead getting the best of both worlds by checking for UTF-8 validity if there is room for doubt: it generates the highest possible amount of backward compatibility, while still allowing people to save their UTF-8 the same way they've always been doing (That doesn't mean we can't issues a warning or something if they use an ANSI file, but that's still a hell of a lot better than temporarily breaking all existing scripts by forcing a conversion). Yes, it requires a bit of extra work to read the file into memory and checking it before starting the compilation, but I think the value in that feature would be pretty great compared to the time it takes to develop it. (Of course, that's easy for me to say, since I'm not likely to be the one programming it. )

Quote:
Basically, what we can do is make Unicode NSIS never work with ANSI with the exception of ASCII only scripts.
I'd certainly prefer this to not supporting BOM-less UTF-8 (partially because I no longer use Notepad for editing scripts, but gVim, and having to remember to add the BOM will be a pain - particularly since not getting these useless BOMs is one of the reasons I switched), but see above.

Quote:
If there is no BOM, assume UTF-8. If there is a BOM, assume UTF-16.
I assume you mean "If there is a UTF-16 BOM".

Quote:
This is the only other option in my mind.
Quote:
Originally posted by Anders
Older unix tools might not support BOM for UTF-8, but that's not our problem
Except NSIS can do cross-compilation on *NIX systems and, to the best of my knowledge, most *NIX editors don't place a BOM unless explicitly told to (the only advantage is for identification, and most Unicode-aware tools try UTF-8 anyway, so no real benefit is observed).

Forcing people to do this also means forcing them to change their usual editing routines beyond just having to select a different encoding - they need to know "does my editor add a BOM" (and how they can add it if it doesn't), and I think that could potentially put some people off from going with Unicode NSIS.

Quote:
If you really want UTF-8 without BOM, maybe makensis could check the first line for a comment like #NSIS: encoding=UTF-8
It's not really logical to have to force a Unicode-aware application to use Unicode like this. You don't have to use files with signatures for Notepad to recognize UTF-8, to give an example.

This sort of thing could be more useful if extended to allow specifying non-Unicode code pages, such as sjis or big5, in which case Unicode NSIS would convert from that particular codepage, since that would allow Unicode NSIS compilation of an ANSI script on a random system - but I'm not convinced this is a relevant feature for very many people.

Quote:
Originally posted by jimpark
For example in vim, I just do this command: <snip>
Just a comment on this: check out :h bomb.

Quote:
Or paste this guy: 
If you use the same codepage as Jim, that is.
Pidgeot is offline   Reply With Quote
Old 9th January 2009, 19:52   #220
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Quote:
Just a comment on this: check out :h bomb.
Wow. I did not know that. Very cool. Vim rocks. Now, is there a universal font that is available in Vim that can work on a lot of different scripts? For example, I'd love to see Arial Unicode work for me but I can't seem to choose that font for my guifontwide setting. Is there a font like that out there that I can download and have it work for Vim or somehow get Arial Unicode to work?

Quote:
If you use the same codepage as Jim, that is.
True but everyone should have Latin-1 as their codepage! What else could we possibly need?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th January 2009, 20:29   #221
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Quote:
Originally posted by jimpark
Wow. I did not know that. Very cool. Vim rocks. Now, is there a universal font that is available in Vim that can work on a lot of different scripts? For example, I'd love to see Arial Unicode work for me but I can't seem to choose that font for my guifontwide setting. Is there a font like that out there that I can download and have it work for Vim or somehow get Arial Unicode to work?
The help file states that all GUI versions of Vim, with the sole exception of the GTK2 version (you might be able to compile a GTK2 version for yourself and use that, but even there), only allows monospaced fonts. Personally, since my editing is pretty much restricted to Danish, English and Japanese, I use MS Gothic: it contains all the characters I need (although not all of the non-CJK characters are particularly pretty). A Chinese font like SimHei would probably give better Kanji/Hanzi support, though, since the Chinese use a much larger set of characters (I haven't tested this, though...)

We're getting pretty off-topic, though, so let's try to get back to NSIS...
Pidgeot is offline   Reply With Quote
Old 9th January 2009, 22:29   #222
ehsanakhgari
Guest
 
Posts: n/a
Problem with non-Unicode InstallerOptions INI files

Another problem which we are facing in order to use Unicode NSIS in Mozilla is about InstallOptions INI files. We use WriteINIStr, which seems to write the INI file as ANSI and convert to a Windows codepage on the fly.

Is there any way to write Unicode INI files from within the Unicode NSIS, or any other similar effects? Without this, our custom installer pages will not benefit from being Unicode...

Thanks!
Ehsan
  Reply With Quote
Old 9th January 2009, 23:32   #223
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
Your best bet is to move to nsDialogs

IIRC, NT will write unicode ini files if the .ini already has a UTF-16LE BOM

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 9th January 2009, 23:38   #224
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
http://blogs.msdn.com/michkap/archiv...15/754992.aspx

..so I guess you can use the nsis FileOpen/FileWriteByte commands to write the unicode BOM before you use the ini functions

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 10th January 2009, 01:21   #225
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Well, it actually wouldn't be too hard to support WriteINIStrUTF16LE. And after thinking about Pidgeot's idea, and taking a moment to write the ValidateUTF8 function myself, I think it's probably best to not require a UTF-8 BOM. I'm starting to see a potential for 2.42.2 already.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 10th January 2009, 01:43   #226
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I wonder if I shouldn't just make the INI files it generates as UTF-16LE instead of creating a new function. I think Windows supports INI files as UTF-16LE with no problems.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 10th January 2009, 02:32   #227
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I dug a little deeper about WriteINIStr and this is what I found.

WriteINIStr uses WritePrivateProfileString() in kernel32.lib. If you look at the documentation for this function it states: "If the file was created using Unicode characters, the function writes Unicode characters to the file. Otherwise, the function writes ANSI characters."

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 10th January 2009, 03:56   #228
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
did I not already say this?

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 10th January 2009, 09:54   #229
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
You may have. This thread is long and my memory is short. Ah, I see your post now. I just missed it.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 13th January 2009, 03:34   #230
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I've semi-secretly released a prototype to 2.42.2 which can read UTF-8 NSI files. It does not require a UTF-8 BOM. If it finds a BOM in the beginning of the file, it uses the BOM as a cue to how to read the file. If it does not find a BOM, it checks the file to see if it looks like a valid UTF-8 file. If it's valid UTF-8, the file is read as UTF-8 and internally converted to UTF-16LE so that it can call the Win32 API. If it does not have a BOM and it does not validate as UTF-8, then it is opened as ANSI. But if this latter thing happens, anything that is > 0x7f probably gets converted to question marks.

http://www.scratchpaper.com/nsis-2.4...code-setup.exe

So basically this version of NSIS officially supports:
UTF-8
UTF-16LE

It may work with UTF-16BE with the BOM (I'm relying on Microsoft on this one). But it does not work with UTF-32 of any endian flavor. Not sure there's a big demand for it anyway.

Let me know if you run into any problems. If it looks solid, I will release it to the general public some time next week or so.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 14th January 2009, 01:25   #231
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
Now that it can use UTF-8, wouldn't it be best to use that everywhere instead of having ANSI and Unicode versions of almost every file? If so, please be sure to strip the BOM character from the beginning of each UTF-8 file.

${NSIS_CHAR_SIZE} sounds like a bad idea, nsis shouldn't assume any specific size for characters - each character in UTF-8 can be multiple bytes long and same for UTF-16, that can have characters that are more than two bytes long. Only UCS-2 and UTF-32 have constant-sized characters.

bye,
pabs
pabs is offline   Reply With Quote
Old 14th January 2009, 02:47   #232
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
you are missing the point with NSIS_CHAR_SIZE, some windows api structures have hardcoded buffer sizes (GetVersionEx etc.)

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 14th January 2009, 02:50   #233
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Pabs, NSIS_CHAR_SIZE is the internal char size representation. You absolutely need it. Unicode NSIS does NOT internally store things as UTF-8. It can read UTF-8 files but internally it works with strings as UTF-16LE which is the native Windows encoding of Unicode.

Also UTF-8 is not a superset of ANSI. UTF-8 is a superset of ASCII but as soon as you hit codepages, UTF-8 and ANSI are foreign to each other. So anything with localizations cannot be shared. But a lot of the NSH files and samples CAN be reduced. You still have to read the code very carefully to see if they are strictly the same. If it uses the System plugin, for example, the strings you allocate needs to be adjusted for Unicode vs. ANSI. Unicode should be double the width. They must call the appropriate API -- the wide versions vs. ANSI. They must use the right messages -- sometimes there are two messages with the same #macro but different values for ANSI and Unicode because one message ID returns ANSI string values while the other returns UTF-16LE values. Using things like System::StrAlloc, ${NSIS_CHAR_SIZE}, and ${NSIS_UNICODE} can help you write code that will port easily between the ANSI and Unicode NSIS but it will require quite a bit of care to make sure it is done right.

Here's an example where it's not so simple to share the same code for both Unicode and ANSI NSIS.

http://forums.winamp.com/showthread....hreadid=300271

Albeit, if you do the basic stuff only in your installer, you probably won't see these kinds of problems and keeping your installer just UTF-8 may be quite doable. (If you don't have any localized strings in the NSI script and rely solely on the Language Files distributed by NSIS, then even non-Latin installer may be able to go this route.)

If you really want to give it a try, please feel free. One thing I've noted is that the further you stray from the trunk, the harder it is to merge the changes for each release.

BTW, I definitely appreciate any help I can get. So I do value your input (and enthusiasm).

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 15th January 2009, 03:22   #234
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
OK, fair enough on the size thing.

Are there any changes that can be merged now? Perhaps the conversion of the plugins/makensisw/etc to TCHAR instead of char?

Is there a need to duplicate the .nsh, .nlf etc files? This creates a maintenance headache IMO.

For example, the Unicode/ANSI versions of COPYING and nsisconf.nsh are identical after conversion to UTF-8. Same for the following directories containing Unicode & ANSI versions: Contrib/zip2exe/ Contrib/InstallOptions/ Contrib/Splash/ Contrib/Banner/ Contrib/AdvSplash/ Contrib/BgImage/ Contrib/VPatch/ Contrib/Modern UI/ Contrib/MultiUser/ Contrib/UserInfo/ Contrib/StartMenu/ Contrib/nsDialogs/ Contrib/Modern UI 2/.

I think it would be best to have one version of them (encoded in UTF-8 for compatibility with legacy text editors and Unix tools).

The differences due to System::Call or structure/string sizes can be wrapped in !if ${NSIS_UNICODE} or similar.

makensis can be made to convert .nlf & .nsh strings to ANSI/UTF-16LE at runtime.

Not sure how to deal with the Contrib/UIs/ differences, presumably you could set the class to RichEdit20, use a define of some sort or makensis could set the class at installer creation time.

I think the differences in due to registry key names and stuff are gratuitous and not necessary.

bye,
pabs
pabs is offline   Reply With Quote
Old 15th January 2009, 03:35   #235
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I agree with you Pabs. I'd like to see that done as well. When they are the same, we should keep them the same. Only fork them if they need to be different like the Language Files.

One thing about the !if ${NSIS_UNICODE} checks are that I'm afraid it might unnecessarily make the scripts harder to read. I know I hate it when I see a lot of #ifdef's in the C/C++ code. Also, the !if ${NSIS_UNICODE} checks may bloat the resulting installer with extra code as well. I'm not sure I like that.

As for the NSIS source code, I'd still like to be able to generate both the Unicode and ANSI builds of NSIS until everyone decides that ANSI is dead. Then we can do what the guys at PortableApps are thinking [1] -- eventually, wrap up a final build of ANSI NSIS for those writing installers for legacy systems and continue on with Unicode only.

[1] http://portableapps.com/node/17291

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 19th January 2009, 11:36   #236
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
I was under the impression that !if was an installer-build-time statement like #ifdef in C, if it isn't, I mean whatever is available for installer-build-time statement conditionals.

bye,
pabs
pabs is offline   Reply With Quote
Old 21st January 2009, 22:52   #237
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
Looking at the documentation, !if and !ifdef are exactly what is needed; they are conditional compilation, the ignored bits don't end up in the executable.

There aren't that many differences between the Unicode and ANSI examples and include files in the Unicode NSIS for you to be worried about making them harder to read.

bye,
pabs
pabs is offline   Reply With Quote
Old 22nd January 2009, 13:22   #238
30er
Junior Member
 
Join Date: Jan 2009
Location: Austria - Vienna
Posts: 4
UAC + Unicodebuilt

Hi

its my first post here

Anders + jimpark

you did both a great job

BUUUUUUUUUUUUUT

i use Anders UAC plugin together with your unicode nsis

with the ANSI build everything works

but in unicode mode...
during install for all users:
${UAC.RunElevatedAndProcessMessages}
only opens an adminpassworddialog at first run of the setup

if u start the setup again for all users u wont see that dialog anymore



next problem is:
if i call the uninstaller from the unicodebuild this line makes troubles:
${UAC.U.Elevate.AdminOnly} "${UNINSTALLER_NAME}"

error pops up:
unable to elevate, error 05536


hope u can help me

ty


Software:
OS: XP Pro
NSIS: 2.42.1 ANSI + UNICODE (jimpark)
UAC: v0.0.10a - 20081004 (Anders)
30er is offline   Reply With Quote
Old 22nd January 2009, 20:34   #239
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
"if u start the setup again for all users u wont see that dialog anymore" does not make any sense, the UAC plugin does not save any state, so it should work the same every time. Can you explain what you mean by "for all users"?

Could you post a minimal example script with these problems?

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 23rd January 2009, 07:54   #240
30er
Junior Member
 
Join Date: Jan 2009
Location: Austria - Vienna
Posts: 4
Quote:
Originally posted by Anders
"if u start the setup again for all users u wont see that dialog anymore" does not make any sense, the UAC plugin does not save any state, so it should work the same every time. Can you explain what you mean by "for all users"?

Could you post a minimal example script with these problems?

I took your UAC RealWorld example script
there u show a dialog where u can choose between single user and ALL USER installation

All user means -> NEED ADMIN RIGHTS

if a normal user choose that
the admin PWD dialog pops up

if i try this with ANSI build everything works
I can start the setup as often as i want and i get allways this ADMINPWD dialog

if i try the same script build with the UNICODE NSIS
the dialog will only be showen at first start

UAC::IsAdmin returns $0 >=1
if i run it as normal user!

thats the strange thing for the installation

maybe you can contact me in skype
ing30er

than i can show u my script
30er 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