Old 17th December 2007, 06:15   #41
prz
Junior Member
 
Join Date: Apr 2006
Posts: 13
Talking

Yes, C++ isn't the perfect language to make small change for a person doesn't know it.
Anyway I'll try to do it (is this the right time to study even the C++ ?).

These are the plugins that I use in my installer:
- GetVersion (to kown the Windows and IE versions and the OS architecture)
- GetSize (to know the size of the data folder)
- HwInfo (to know the processor name)
- nsProcess (to kill a process before uninstalling)

Bye
prz is offline   Reply With Quote
Old 17th December 2007, 06:42   #42
CodeSquid
Member
 
Join Date: Dec 2001
Posts: 89
Quote:
Yes, C++ isn't the perfect language to make small change for a person doesn't know it.
No language is.
CodeSquid is offline   Reply With Quote
Old 17th December 2007, 08:27   #43
prz
Junior Member
 
Join Date: Apr 2006
Posts: 13
Quote:
Originally posted by CodeSquid
No language is.
You're right, but C++ isn't the easier one.
prz is offline   Reply With Quote
Old 17th December 2007, 08:37   #44
prz
Junior Member
 
Join Date: Apr 2006
Posts: 13
Quote:
Originally posted by jimpark
Well, it will be a bit difficult not knowing C++ if you want to convert other plugins. But you could try downloading the source from the NSIS branch, then download the source from my site. And you could compare the source files for a smaller plugin like LangDLL and see what the differences are.

BTW, other than the GetVersion plugin, what other plugins do you use?
I converted GetVersion and works well only under ANSI version (like the original one). Can be the problem in the definition of _UNICODE (I don't find it)?

Thanks
prz is offline   Reply With Quote
Old 17th December 2007, 11:42   #45
prz
Junior Member
 
Join Date: Apr 2006
Posts: 13
Quote:
Originally posted by prz
I converted GetVersion and works well only under ANSI version (like the original one). Can be the problem in the definition of _UNICODE (I don't find it)?

Thanks
I added the _UNICODE string to the pre-processor strings, but the output of the plugin is the same of the ANSI version.
something else to make a unicode version of the plugin?

Bye
prz is offline   Reply With Quote
Old 30th December 2007, 02:12   #46
sfidanza
Junior Member
 
Join Date: Dec 2007
Posts: 4
Thanks for the great work on Unicode NSIS, and for hosting it. I just used it for an english/french/czech installer (and I should be adding more languages soon). It still needs to be more thoroughly tested but it seems to have worked fine.

A note though: I didn't convert the install script itself to UTF16-LE (I did at first but NIS Edit wouldn't display it correctly). It worked anyway. It was completely ANSI, but ANSI is not a subset of UTF16 so I'm (happily) surprised.

I consider Unicode as the way to go: displaying multiple or Unicode-only languages is more and more needed, and I'm really glad that NSIS is moving to complete Unicode support.
sfidanza is offline   Reply With Quote
Old 30th December 2007, 11:17   #47
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Thank you for the kind words of encouragement. I've never used NIS Edit but I take your word for it that it doesn't understand UTF16. If you didn't convert the script to Unicode, perhaps the ANSI one was run and it created an ANSI installer? One thing you could do is check that the ANSI one works first, then convert it to Unicode using notepad or a2u.exe and then create the installer again using the Unicode version. If it worked for the ANSI it will most likely just work for the converted Unicode version (barring the use of 3rd party plugins that have not been converted to support Unicode.)

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 30th December 2007, 12:42   #48
sfidanza
Junior Member
 
Join Date: Dec 2007
Posts: 4
Actually, the ANSI script was compiled with classic NSIS until now. It works correctly. But I wondered if making a unicode installer was possible, and found out about Unicode NSIS.
I don't use any 3rd party plugin, only language files, which I converted to UTF16-LE. And I updated the link to the compiler in NIS Edit to Unicode NSIS. The only issue was that NIS Edit displays only the BOM of a unicode script.

Classic NSIS wouldn't compile even the ANSI script (using unicode language files), but Unicode NSIS produces a working installer.

However, I just compiled the Unicode script on Unicode NSIS, and did a byte-to-byte comparison of the 2 "unicode" .exe installer: they are indeed not exactly the same.
I couldn't spot any difference by running them though, even with czech texts (usually requiring CP1250 while I use CP1252 myself). I'll have to test with russian or chinese.

Anyway, I'll use the unicode script from now on to be on the safe side.
I described everything here in case it is of some help to you. I'll be happy to make some more tests or give some more details if you wish.
sfidanza is offline   Reply With Quote
Old 30th December 2007, 16:36   #49
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
What about making a Unicode version that supports both Windows 95/98/Me as well as Windows 2000/XP/Vista? I think it should be possible to have scripts and internal NSIS strings in Unicode but convert the user interface strings to ANSI for 95/98/Me.

Because there is no simple one-to-one conversion of ANSI NSIS scripts to Unicode (multiple codepages can be used in a single file for e.g. LangStrings), we can just call it NSIS 3.0 and require scripts to be in Unicode.
Joost Verburg is offline   Reply With Quote
Old 30th December 2007, 22:00   #50
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Actually the problem is during the loading the exe and dynamic link time. By using Unicode-based Win32 calls, the program fails to even run. Not sure how to solve that except by distributing unicows.dll with the installer on Win9x. But seriously, I think we should just drop Win9x support soon. Looking at browser OS stats at http://www.w3schools.com/browsers/browsers_os.asp, only 1% of the web users use Win98. And the demographic for users of products that ship with NSIS installers are probably netizens. Every year that passes by, the need to support Win98 and therefore both ANSI and Unicode will dwindle. We will eventually only need Unicode.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 31st December 2007, 14:35   #51
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Merged in 2.34 changes into the Unicode version of NSIS. Go to the usual place: http://www.scratchpaper.com for the binaries and source.

Added Pashtu support. Thank you Zabeeh khan.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 1st January 2008, 11:09   #52
CodeSquid
Member
 
Join Date: Dec 2001
Posts: 89
I've tried to compile your patch on Linux but it utterly failed.

Can you please update your patch so that it compiles on Linux?
If you don't have Linux, you can download it from http://www.ubuntu.com/
CodeSquid is offline   Reply With Quote
Old 1st January 2008, 12:10   #53
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
Quote:
Originally posted by jimpark
Actually the problem is during the loading the exe and dynamic link time. By using Unicode-based Win32 calls, the program fails to even run.
It's possible to call these APIs on run-time depending on the Windows version. A framework for this method is already included in the NSIS source and is used for various functions that are not available in all Windows versions.
Joost Verburg is offline   Reply With Quote
Old 1st January 2008, 13:18   #54
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
CodeSquid, it's not that I don't have Linux. I did this project because of a need for a Unicode installer on Windows for the project I'm working on. I'm giving the source back to the community as-is. I'm only updating the code so that my code base doesn't go out of sync with the latest changes. And I'm offering it to the public and especially the NSIS developer community so they can potentially use it to create an official Unicode version of NSIS. And while there isn't such, the developers who need a Unicode solution for their installer will have something that works right now. I could just update it internally and never let anyone else use it or see it but that would not be following the spirit of open source. I don't have the time or resources to make sure the source builds on Linux, Mac and whatever else NSIS usually can build on. So if it's important to someone that the Unicode source builds on Linux or on the Mac, I hope that someone steps up to the plate and makes it work for those OSes.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 1st January 2008, 14:02   #55
CodeSquid
Member
 
Join Date: Dec 2001
Posts: 89
I'd very much like this in the official NSIS code. Unfortunately I don't have the time to work on this either.
CodeSquid is offline   Reply With Quote
Old 1st January 2008, 17:04   #56
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
I think it will require quite some effort to have combine a non-Unicode/Unicode version in the same source. This would also cause a lot of trouble with plug-ins. Having a major new release (NSIS 3.0) with only Unicode support and Unicode script files would probably be a better solution.

If only Windows 2000 and later need to be supported, the current Unicode version is mostly complete (expect for some issues like Linux compilation). Windows 95/98/Me cannot be supported forever. Microsoft has dropped support for all these versions some time ago, so there are also no more security fixes. The C++ runtime of Visual Studio 2008 doesn't even support them anymore.

So maybe this would be the time to remove legacy stuff and introduce some breaking changes.
Joost Verburg is offline   Reply With Quote
Old 14th January 2008, 01:23   #57
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
I'd like to suggest support for UTF-8 scripts, with and without BOM. I exclusively do UTF-8 without a BOM, as I feel it hurts more than it helps: it only serves as identification (even though in almost all cases, you'd do just fine by assuming UTF-8, and using ANSI as a fallback), and excluding it allows for a neater handling by non-Unicode programs.

If the file is BOM-less and contains invalid UTF-8, I think it should be read as ANSI and internally converted to Unicode for the actual installer. Such behavior would help reduce the effort needed to migrate installers to Unicode, as it should allow most existing scripts to continue compiling with no changes (as long as they don't use any plugins not supplied with NSIS).

I do realize there's a potential problem when a file in a different codepage is included from the script. This could be solved in various ways, such as using a stack to keep track of codepage information. Whenever inclusion starts, the current info is pushed onto the stack. When inclusion stops, pop it back.

Although there is a risk of incorrectly interpreting an ANSI script as UTF-8, it is extremely slim, due to the fact that it requires some very specific byte patterns as the only non-ASCII text in the entire script.
Pidgeot is offline   Reply With Quote
Old 15th January 2008, 12:08   #58
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
The real crux of the problem is the conversion from ANSI to Unicode. What codepage should you use? Hopefully, the script has that information. But even if it does, it may mean you have to parse a significant portion of the scripts to figure out which code page the text is in which means writing a lot of code that is not there currently. Or I guess you could default to using the system codepage but that may not be the intent of the developer. If someone develops a Chinese installer and gives it to someone who uses an English codepage on their machine, the same installer would produce junk characters on its messages.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 15th January 2008, 13:05   #59
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Quote:
Originally posted by jimpark
Or I guess you could default to using the system codepage but that may not be the intent of the developer.
I'm not sure you understood me correctly, but my idea is to use the system codepage to convert it at compile-time; allowing us to minimize issues. It would likely be best to issue a warning about ANSI scripts being deprecated when it has to do this, so the developer knows to use UTF-8 or UTF-16 instead of relying on the system codepage.

Quote:
If someone develops a Chinese installer and gives it to someone who uses an English codepage on their machine, the same installer would produce junk characters on its messages.
As long as they only get the compiled installer, no problem, as it would have been handled by then. If they distribute the actual ANSI script, without realizing this change had happened, then yes, they'd have a problem, but this should not happen very frequently - even less if we issue that warning - and the fix is simple; that particular script just needs to be converted into a Unicode format.

For installers creating a dynamic script, nothing prevents us from using UTF-8 as a default output codepage for file writing to minimize issues; as long as they are able to change it from the script (for when they need a specific codepage). Yes, that one would require a change, but you'd be affecting fewer scripts, thus easing migration.
Pidgeot is offline   Reply With Quote
Old 15th January 2008, 17:34   #60
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Yes, I do understand you. I am talking about the developers sharing scripts with different codepages set on their machines. The problem you are trying to fix... which is converting their ANSI scripts to Unicode is trivial. Open it up in notepad.exe and save as Unicode. Or use the a2u.exe program I provided. All the proposed changes you are talking about only saves the little tiny headache of converting your script once to Unicode. The real problem is that people write scripts that are shared like libraries, like the language files. They all still need to be converted to Unicode, whether UTF-8 or UTF-16 before they are shareable with others. There's no way around that. We can do some intelligent guessing as the NSIS program parses the ANSI scripts but it may not always be correct.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 15th January 2008, 19:28   #61
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
I don't think there is any possibility to convert existing scripts automatically.

There is no way identify the codepage of a script file, the bytes just have a different character representation depending on the users codepage. Script files can even contain multiple codepages (for example, if language strings are combined in a single file).

On run-time, texts that are sent to the dialogs can come from any source on the system, complete outside the installer itself. Again, no automatic conversion is possible. Things become even more complicated when external DLLs (including NSIS plug-ins) are called that return ANSI strings.

Taking this all into account, I think the only realistic thing is to release a new major version that will be Unicode-only.
Joost Verburg is offline   Reply With Quote
Old 15th January 2008, 19:50   #62
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Of course not, and you're right - those scripts would need to be converted. But we're not going to get around such an issue no matter what we do; and I don't see it as a good idea to cause extra hassle for everyone writing non-English single-language installers, compared to causing a little more work for those that would actually benefit greatly from converting it to Unicode - at least not for the first official Unicode release.

Also, are the amount of "non-native-codepage"-dependent scripts really that big? I'm under the impression that many people stick to the bundled stuff, which would already be Unicode, or have already switched to the Unicode build.

EDIT: Good point, Joost - I hadn't considered external calls. Alright, never mind the ANSI then.
Pidgeot is offline   Reply With Quote
Old 17th January 2008, 10:05   #63
onad
Senior Member
 
onad's Avatar
 
Join Date: Dec 2004
Location: Turkey
Posts: 447
Lightbulb

IMHO two article developers or NSIS script creators should read (I mean really READ...)

http://www.microsoft.com/globaldev/h..._announce.mspx

http://www.joelonsoftware.com/articles/Unicode.html

Note that this message is NOT to insult, it's purpose is to help getting Unicode support in a decent smooth upgrade path to NSIS. Lots of people have lots of good ideas but somehow we have to create it...that will mean some fierce pro/cons discussions. But take for example Jim Park's initiative, it is *great*, he got things rolling for Unicode for him because he has a need and just created his own build!

It is also not that I personally still would support for Win9x/ME, but a lot of third pary software uses NSIS e.g. the Firefox installer on Win32, they are affected if there is an "Only" unicode build" with no backwards compatibility layer.

For those who do not know: "kichik" knows possibly the best what path to choose, and if he doesn't he still does after all he does a major amount of the NSIS development.

But I also see the points by Joost, Unicode only major release to avoid confusing people which NSIS to use, and after all still 2.x can be used for non Unicode releases.

And for the plugins, most of them come with source, should we already ask the plugin creaters nicely to make them Unicode compatible if needed and not done so already?

...so now MY first step will be, make the plugins I've created unicode compatible, even if not used yet...

"Just do it"
onad is offline   Reply With Quote
Old 17th January 2008, 16:13   #64
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
Windows 95/98/Me support would require NSIS itself and all plug-ins to provide both an ANSI and a Unicode user interface. If external APIs are used to modify the interface, scripts would also have to check whether ANSI or Unicode is used and do the required conversions.

All scripts need to updated anyway if NSIS uses Unicode internally, even if the user interface is still ANSI. The fact that an ANSI interface is still available would only improve backwards compatibility a little.

Because this is all very complicated, I'm afraid we don't have the manpower to implement it within a reasonable time.

Almost all new applications that are developed (e.g. Firefox 3) don't support 95/98/Me anymore. If legacy Windows versions still need to be supported for an installer, NSIS 2 can be used.
Joost Verburg is offline   Reply With Quote
Old 17th January 2008, 16:30   #65
sfidanza
Junior Member
 
Join Date: Dec 2007
Posts: 4
As an interested outsider here, I can say I would largely prefer having an officially maintained Unicode NSIS (NSIS3), with an unofficial ANSI legacy version (for example if new features would be backported to NSIS2). That is to say, of course, if a choice has to be made, since limited resources always push to make choices.
sfidanza is offline   Reply With Quote
Old 17th January 2008, 16:33   #66
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
I think both NSIS 2 (ANSI) and NSIS 3 (Unicode) can remain official versions. However, we won't really have enough resources to backport features.
Joost Verburg is offline   Reply With Quote
Old 17th January 2008, 20:47   #67
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
If we use TCHAR style macros in the C/C++ source, we can use one set of source files to generate both the ANSI and Unicode binaries. I know some people don't like the use of TCHARs but that's the choice I made because of the convenience of having one common set of source files for both binaries. So I know I can make changes to the source that will be reflected in both the ANSI and the Unicode versions. This should help in keeping NSIS ANSI and NSIS Unicode features in sync.

The other problem is the script files -- it's painful keeping two sets of script files as kichik pointed out. But I think most of the behavior enhancing script files are plain ASCII files which can easily be converted to Unicode and back to ANSI.

The language files, however, I think we need to keep separate because the two sets will have to be different. For one, the number of Unicode language files will be bigger than the ANSI. In fact, it already is in my build. And two, the Unicode script files can have the language name itself in its vernacular because the Unicode binaries can show them all at the same time.

Consider the multi-language installer demo picture on my website. It's a very powerful argument for being able to generate Unicode installers. I know of one case where a software targeted to the Chinese audience had two installers -- one in Traditional Chinese and the other Simplified Chinese. And they were able to use the NSIS Unicode multi-language installer to show the instructions / license agreement in both Traditional and Simplified at the same time. That's over a billion people that can benefit from that sort of flexibility. India also has a huge set of scripts for its languages. With China and India together, you've got almost half of the world's population!

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 17th January 2008, 21:54   #68
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
A mixed ANSI/Unicode (ANSI on 95/98/Me and Unicode on NT/2000/XP/2003/Vista) stub is almost impossible as I pointed out, so building ANSI-only and Unicode-only stubs from the same source may indeed be a good option!

If the compiler would automatically convert Unicode scripts to ANSI (using multiple codepages in a script if necessary, just like the situation is right now), language files and example scripts not using special features would be compatible with both versions (solving the issue kichik pointed out). A simple define (!ifdef UNICODE ...) can allow more advanced scripts (such as the Modern UI) to support both stubs. A script command (independent of the script encoding) can then be used to select what stubs should be used.

We would need two folders for the plug-ins, because the ANSI stubs can only use ANSI plug-ins and the Unicode stubs can only use Unicode plug-ins. All standard NSIS plug-ins can of course support both (using the TCHAR thing).

You'll have to ask kichik about his opinion. Maybe you can work on implementing Unicode in a different branch of the official NSIS SVN repository.
Joost Verburg is offline   Reply With Quote
Old 12th February 2008, 07:50   #69
high1
Junior Member
 
Join Date: Apr 2007
Posts: 12
What about FileOpen function in Unicode version? If a file does not exist, does it create an ANSI or Unicode file? There should be a way of creating an Unicode file, and maybe there is, but I didn't find it. Sorry if my question is out of place here, but I did try general forum and got no replies.
high1 is offline   Reply With Quote
Old 12th February 2008, 10:29   #70
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Use FileOpen and use FileWriteUTF16LE. If you want to write a BOM at the beginning of the file, you should be able to using FileWriteWord file_handle "65279" which is U+FEFF

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 13th February 2008, 12:23   #71
high1
Junior Member
 
Join Date: Apr 2007
Posts: 12
Did that and it works perfect, thanks. However, if I try same approach with header I'm tinkering with to make it work with Unicode version of NSIS, I get garbage in file. I'm no expert in NSIS, but I have tried to find the cause of it, and I think that usage of FileJoin from TextFunc.nsh is causing the garbage in final file, since header uses that function to join two files. Files are utf16le, and here is a part of the function :


define ${_TEXTFUNC_UN}FileJoin `!insertmacro ${_TEXTFUNC_UN}FileJoinCall`
...
FileOpen $3 $4 a
IfErrors error
FileSeek $3 -1 END
FileRead $3 $5
StrCmp $5 '$\r' +3
StrCmp $5 '$\n' +2
FileWrite $3 '$\r$\n'
FileOpen $0 $1 r
IfErrors error
FileRead $0 $5
IfErrors +3
FileWrite $3 $5
goto -3
FileClose $0
FileClose $3

...

Maybe the bold part is causing problems? Should there be FileWriteUTF16LE and FileReadUTF16LE calls? Or maybe not, beacuse of the define? I tried to place UTF functions, but this function produces no file then. Any thoughts, Jim?
high1 is offline   Reply With Quote
Old 13th February 2008, 13:07   #72
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
If you want this function to work for Unicode files, I think you'll have to create a Unicode version. Copy the macro and as you suspected, you need to convert the FileRead and FileWrite calls to the UTF16LE versions. You might have to open the files as binary as well.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 13th February 2008, 22:31   #73
high1
Junior Member
 
Join Date: Apr 2007
Posts: 12
Got it working. Thanks for all the help and sorry for bugging you. The function does not work with Unicode files - had to change calls, that was obviuos. But this script with UTF produces errors, and I am not sure why - so I had to do this:
(changes are bolded).

FileOpen $3 $4 a
;IfErrors error
FileSeek $3 -1 END
FileRead $3 $5
StrCmp $5 '$\r' +3
StrCmp $5 '$\n' +2
FileWrite $3 '$\r$\n'
FileOpen $0 $1 r
;IfErrors error
ClearErrors
FileReadUTF16LE $0 $5
IfErrors +3
FileWriteUTF16LE $3 $5
goto -3
FileClose $0
FileClose $3

The header in question is Advanced Uninstall Log, and I'm going to send changes to RedWine. I also had to change Serbian.nlf as UTF16LE is a pile of rubbish.
This
Ďđčőâŕňŕě óńëîâĺ äîăîâîđŕ î ďđŕâó ęîđčřžĺśŕ
should be, in fact, this
Прихватам услове договора о праву коришћења
but I guess it's all Greek to you.
Anyway, thanks, Jim - it sure is great to have a Unicode installer which produces Unicode log, and I can install in Unicode named folder, and uninstall files automatically.
Going to send you correct Serbian.nlf.
high1 is offline   Reply With Quote
Old 13th February 2008, 23:12   #74
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I appreciate that. Looking forward to getting those files. It's good to know that the Unicode version of NSIS is actively being used.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 18th February 2008, 20:59   #75
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
NSIS Unicode has been updated to 2.35. Please go to the usual spot to download the binaries and the modified source: http://www.scratchpaper.com.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 19th February 2008, 13:09   #76
high1
Junior Member
 
Join Date: Apr 2007
Posts: 12
Is there any particular reason why there are no registry entries at HKLM -> Software -> NSIS for VersionMajor and VersionMinor? ANSI release writes current release values there. Is there another way to get version of NSIS with which the script was compiled?
Regards.
high1 is offline   Reply With Quote
Old 19th February 2008, 14:29   #77
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
It's because I've been building without specifying revision number and build number. I'm surprised you're the only one who brought this up. Thank you. The files have been updated on my site. Now NSIS Unicode will put the version info under Software/NSIS/Unicode.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 19th February 2008, 17:49   #78
high1
Junior Member
 
Join Date: Apr 2007
Posts: 12
Thanks. I was using this to read the version of NSIS I've used for buliding the installer so noticed it was missing...
high1 is offline   Reply With Quote
Old 2nd March 2008, 23:39   #79
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,558
Is there a way to detect if the compiler is unicode, meaning, is there a defined symbol like __NSIS_UNICODE__ in the unicode build? If not, you should add it so that 3rd party header files for stuff can support both ansi and unicode in one file

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 3rd March 2008, 13:17   #80
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
That's not a bad idea. I will add it to the next version.

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