Old 3rd March 2008, 14:09   #81
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I just made the tweak and modified the binary on my website to include the NSIS_UNICODE predefine for the Unicode build. Enjoy.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 16th March 2008, 17:12   #82
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
7zip will not open the installer archive properly. I get rubbish filenames. Not sure if it's something that 7zip would need to fix, though.
Attached Images
File Type: png 7zip_nsis_unicode.png (38.4 KB, 492 views)
Benski is offline   Reply With Quote
Old 16th March 2008, 19:01   #83
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,342
7-zip expects a very specific format from the installer. One of its assumptions is that the string table is saved as ANSI. It's not such a faulty assumption when you add in the no-real-nsis-binary-specification factor.

NSIS FAQ | NSIS Home Page | Donate $
"I hear and I forget. I see and I remember. I do and I understand." -- Confucius
kichik is offline   Reply With Quote
Old 17th March 2008, 11:47   #84
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
So does the installer still work? Is it just that a 3rd party app can't open the Unicode-NSIS generated file? If so, then I don't think we can do much about that. If the installer doesn't work with 7zip compression algorithm, that's something I can look into. But the notion I had was that NSIS used those compression algorithms for its own nefarious purposes, not that it had to adhere to some binary format.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 17th March 2008, 15:52   #85
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
The installer works great. It's just that I often use 7zip's ability to open the installer in order to extract the binaries for crash dump debugging. Not a big deal, but I miss the feature Maybe there's a way for the 7zip author to add special handling for Unicode NSIS.
Benski is offline   Reply With Quote
Old 20th March 2008, 14:52   #86
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
A helpful hint to anyone converting their NSIS scripts to Unicode. Be sure to change your System::Call stuff to use w. instead of t. for string types!
Benski is offline   Reply With Quote
Old 20th March 2008, 15:04   #87
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
but is that the way it should work? The system plugin should probably be changed so that "t"="w" in the unicode build and you can use "a" for forcing ansi strings. Should help keep things portable, but some stuff might break

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 20th March 2008, 16:10   #88
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
Yeah, I agree with that idea. Although 'a' is already taken to be a shortcut for the chosen language
Benski is offline   Reply With Quote
Old 20th March 2008, 17:12   #89
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
"a" is not taken as a param type, only source/destination, but I'm not sure if the parser could handle using "a" for two different things. using @ might be a little weird, maybe "z" for zero terminated or whatever unless someone has a better idea

OT: also, adding support for "p" for pointers might ease a future move to 64 bit

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 2nd April 2008, 11:17   #90
sridhare
Junior Member
 
Join Date: Mar 2008
Posts: 4
Hello jimpark,

Your unicode nsis has been of immense help to me. There seems to be a slight problem with the language selection dialog - the languages that aren't supported by the system also show up and I'm NOT using MUI_LANGDLL_ALLLANGUAGES .

For example , I'm running the installer on Windows XP with English as the OS language (and I haven't installed the files required for displaying CJK languages). On running the installer , Japanese (actually garbled boxes) also appears in the drop down menu .

It works as expected on my system where i have installed the files for Japanese i.e., both English and Japanese are displayed.

It will be great if you can help.
sridhare is offline   Reply With Quote
Old 2nd April 2008, 13:03   #91
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I don't know of a way to enumerate all the supported language scripts on a given user's computer. I can do it per locale or language but that's not sufficient since the user's computer is usually set to one language/locale but may be able to support scripts of other languages. If someone knows how to list all the scripts supported by a given system, I think it's just a matter of calling GetStringScripts() and VerifyScripts().

Anyway, this shouldn't be an issue--everyone should have the East Asian Language support turned on!

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 2nd April 2008, 13:45   #92
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Unfortunately, those two methods don't exist on versions prior to Vista (and there, East Asian Language support is always turned on) - you can get support on XP SP2 and 2003 SP1, but that requires a separate download (and doesn't help with Win2000).

You can use EnumSystemLocales with LCID_INSTALLED to check which locales are "ready for use" (if you know specifically which one to check for, you can just use IsValidLocale), or you could check the possible languages groups with IsValidLanguageGroup and LGRPID_INSTALLED.

However, all of this requires that you have a mapping between the languages and the locales (or language group) - I can't remember if that information is currently available to NSIS.
Pidgeot is offline   Reply With Quote
Old 2nd April 2008, 15:51   #93
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I don't think it is available hence my initial thought to use GetStringScripts(). Which makes me think that may be the use of the native language to display the language name may not be a good idea. Or maybe I should combine them together so that there's a legible English version of the name in the drop down menu along with it in the native script.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 2nd April 2008, 19:28   #94
sfidanza
Junior Member
 
Join Date: Dec 2007
Posts: 4
Couldn't it be a missing font issue, rather than an unsupported language?
sfidanza is offline   Reply With Quote
Old 2nd April 2008, 20:08   #95
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Technically, on NT-based OSes, it's ONLY a matter of a missing font (and to some degree, the version of Unicode they support), but that's why LCID_/LGRPID_INSTALLED should be used (instead of _SUPPORTED). Using that flag makes the operating system report if it has everything it needs to display a string based on a given locale.

The problem is, checking against a specific font name is less than optimal, since their names may be localized (the japanese fonts MS Gothic and MS Mincho do that, to give examples), and Windows might know of a font you don't. That's why you need to check on the locale or language group, if you're going to filter on it - but to the best of my knowledge, no WinAPI function exists to detect locale, language group, or script for a given string (except those Jim already mentioned, which are only built into Vista and require a separate download for XP and 2003, therefore not really being usable here).
Pidgeot is offline   Reply With Quote
Old 10th April 2008, 22:35   #96
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
Latest 7-zip alpha build supports opening Unicode NSIS installers

http://sourceforge.net/forum/forum.p...forum_id=45797
Benski is offline   Reply With Quote
Old 23rd April 2008, 09:29   #97
sridhare
Junior Member
 
Join Date: Mar 2008
Posts: 4
Our unicode-nsis installer calls a java program using nsExec and all the output from the java program gets directed into the scrolling text box. If we choose English for the installation language, everything in the text box looks fine , but when an exception stack trace is printed, a part of the stack trace gets cut off. If we choose Japanese for the installation language, weird characters are displayed in place of forward slashes. What could be the reason?

I've hacked the RealProgress plugin source to get it working with the unicode-nsis. Could it be the reason for this behaviour? (seems unlikely though). I'm attaching a snapshot.
Look at the second line in the image. It is actually supposed to be C:/PROGRA~1/Java/.. so on. But all "/" are replaced with some weird character. Similarly, both the stack traces are only partially displayed.
Any help will be greatly appreciated. Thanks in advance.
Attached Images
File Type: png untitled4.png (13.6 KB, 434 views)
sridhare is offline   Reply With Quote
Old 23rd April 2008, 10:02   #98
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
I can't say why it cuts off part of it, but the reason \ is replaced by the ¥ sign is for historical reasons: Japan (and Korea) put their currency symbol in their code page back in the pre-Unicode days. When Unicode was introduced, it was believed that people were too used to seeing the currency symbol as the path separator, so they kept it that way. (There's no real "right" answer to that problem, so you can't really blame them, even if it does seem a bit foolish these days)

As a result, all Japanese fonts (MS Gothic, etc.) show a Yen sign where the backslash is supposed to be, just like Korean fonts (GulimChe, etc.) show a Won sign (â‚©).
Pidgeot is offline   Reply With Quote
Old 26th April 2008, 12:38   #99
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
sridhare, when an exception is thrown and the stack trace is printed by your Java app, there are potential problems with buffered IO that is probably causing the cutoff of the text output. I don't know how much control over the IO you have with the Java program but you might want it to be unbuffered when outputting or at least flush the IO when it exits. The other issue is that I think NSIS will also buffer the input as well so it will display everything if it thinks the IO has been closed or is flushed.

BTW, I have not been able to work on the updates to the Unicode NSIS for a while. I will be very busy until probably sometime in June. My apologies.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 29th April 2008, 08:58   #100
sridhare
Junior Member
 
Join Date: Mar 2008
Posts: 4
Thanks for all the response. This java exception stack trace cut off never happened when we were using (non-Unicode) NSIS. Are you saying that the buffering issue could arise in the Unicode NSIS ?
sridhare is offline   Reply With Quote
Old 29th April 2008, 13:48   #101
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
No, there isn't anything different about how NSIS handles the IO buffers with Unicode. When an exception happens, does the output look like junk? I don't know how it is in Java but in C++, the exception strings need to be ASCII and I wonder if something similar is happening in Java.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 26th May 2008, 07:53   #102
sridhare
Junior Member
 
Join Date: Mar 2008
Posts: 4
Quote:
Originally posted by jimpark
No, there isn't anything different about how NSIS handles the IO buffers with Unicode. When an exception happens, does the output look like junk? I don't know how it is in Java but in C++, the exception strings need to be ASCII and I wonder if something similar is happening in Java.
No, the output doesn't look like junk, but it gets displayed incompletely - This is the actual exception message that used to get displayed fine in the log window when I was using the official NSIS :

code:

INFO: Not started: http://localhost:80/identity
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.Socket.connect(Socket.java:516)
at sun.net.NetworkClient.doConnect(NetworkClient.java:152)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:365)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:477)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:214)
at sun.net.www.http.HttpClient.New(HttpClient.java:287)
at sun.net.www.http.HttpClient.New(HttpClient.java:299)
at sun.net.http://www.protocol.http.HttpURLConn...tNewHttpClient(HttpURLConnection.java:795)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:747)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:672)
at com.pramati.bfly.install.InstallOperations.getStatus(InstallOperations.java:335)
at com.pramati.bfly.install.InstallOperations.dasStatus(InstallOperations.java:190)
at com.pramati.bfly.install.BaseInitializer.start(BaseInitializer.java:301)
at com.pramati.bfly.install.offline.StandaloneInstaller.start(StandaloneInstaller.java:488)
at com.pramati.bfly.install.offline.StandaloneInstaller.start(StandaloneInstaller.java:475)
at com.pramati.izpack.DekohProcessPanel.invokeInstaller(DekohProcessPanel.java:479)
at com.pramati.izpack.DekohProcessPanel.installDekoh(DekohProcessPanel.java:346)
at com.pramati.izpack.DekohProcessPanel.access$300(DekohProcessPanel.java:43)
at com.pramati.izpack.DekohProcessPanel$2.run(DekohProcessPanel.java:262)



Now, after switching to the Unicode NSIS, the same exception stack trace started appearing as follows!

code:

INFO: Not started: http://localhost:80/identity
java.net.ConnectException: Connection refused: connect
nnection.java:747)



Also, when this cut-off happens, it also swallows some other messages printed to the window after this stack trace. Having the full exception stack traces is very critical for debugging, it'd be great if you can be of help.
sridhare is offline   Reply With Quote
Old 9th June 2008, 15:22   #103
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Just released Unicode NSIS 2.37 which merges in the changes from the trunk into the Unicode build. You can find it at the usual place: www.scratchpaper.com.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 9th June 2008, 17:18   #104
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
sridhare, try the new version to see if it fixes your issue. If not, I do have another idea that might fix it. So let me know.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 10th June 2008, 18:18   #105
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
sridhare, I found the bug and I've finally fixed it. Sorry it took so long. I didn't have any time to work on the Unicode NSIS until recently. I just released new binaries and fixed source at the usual place. http://www.scratchpaper.com The version is 2.37.1. Everyone should get this new one instead.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 23rd June 2008, 14:27   #106
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Just released 2.37.2 which has an initial Vietnamese support thanks to Clytie Siddall of the OpenOffice translation team.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 4th July 2008, 16:49   #107
pabs
Senior Member
 
pabs's Avatar
 
Join Date: Mar 2005
Posts: 186
Whats the status of this Unicode branch? Ready to be merged into trunk?

I ask because Debian would like to use it for our win32-loader program used to boot the Debian installer on Windows machines:

http://bugs.debian.org/489218

bye,
pabs
pabs is offline   Reply With Quote
Old 4th July 2008, 17:47   #108
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
Because a Unicode build will break backwards compatibility with existing scripts, it will probably be a NSIS 3.0 release.

However, Win9x support is still not avaialble. It is possible to add support for these platforms (even with the internal installer data being in Unicode) by converting the data back to ANSI for the user interface.

The other option would be to completely drop support for Win9x in NSIS 3.x.
Joost Verburg is offline   Reply With Quote
Old 4th July 2008, 18:56   #109
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I would love to see the code get merged into the trunk as well, as I've mentioned many times already.

As for Win9x support, it is not on my list of priorities. I personally don't have a need for it since all the software we are shipping require Win2k+ anyway. I think most developers have similar requirements nowadays.

The "unofficial" status of the Unicode NSIS branch hasn't stopped high profile projects like Winamp, OpenOffice, Flickr, Filezilla, etc. from using it. And in the near future Mozilla's products like Firefox and Thunderbird will use it as well (Unicode NSIS is already incorporated into their build environment since MozillaBuild 1.2). It just goes to show that there is definitely a need for an Open Source Unicode Installer.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 4th July 2008, 18:59   #110
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
And I'll mention this point again as well. My codebase generates both the Unicode version and the ANSI version that DOES run on Win9x. So I really don't see what you can lose from adopting the codebase as-is and then working forward from there to make the Unicode version Win9x compliant via unicows.dll or some other method as mentioned by Joost.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 4th July 2008, 22:42   #111
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
I don't think it's a good idea to have an ANSI and a Unicode version at the same time. Many scripts will not be compatible with both versions, so this will cause a lot of confusion. And there is also the issue of plug-in compatibility.

Regarding Win9x, we cannot use Unicows or something like that because this file does not exist on all systems. The only option for real Win9x support would be to create ANSI dialogs and convert the intenal Unicode data to ANSI based on the current code page. In this case, scripts, examples, plug-ins etc. will all use Unicode internally and there will be no compatibility issues.

Personally I think it's OK to drop Win9x support in NSIS 3.0 (with NSIS 2.x still being available for Win9x users) and move to Unicode scripts. But I don't know whether other developers agree with this.

I'd definately like to have Unicode support in the official version.
Joost Verburg is offline   Reply With Quote
Old 4th July 2008, 23:50   #112
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I see three potential options other than the one I have which is two versions of NSIS, meaning two sets of plugins (but one codebase) and two sets of scripts, which I concede can be unwieldy.

1. One makensis.exe that can generate both an ANSI or a Unicode installer. This means that there will still need to be two sets of plugins and exeheads, but potentially just one set of scripts. If we go this route, I'd suggest that all scripts are Unicode. If we start with ANSI codepage scripts, mixed scripts in a single file becomes very difficult if not impossible to support. (Imagine a single string with mixed scripts.) And we would alienate Unicode-only languages.

2. We generate one exehead but with the ability to on-the-fly convert the internally stored Unicode strings to the ANSI codepage strings to call the ANSI Windows APIs on Win9x machines. This requires that we have a small but portable implementation of wide string to multi-byte string conversion function. Maybe we can leverage some code in the Wine project to do this. But it does mean making the exehead and therefore the final installer to be bigger. The plugins would also need to do this conversion as well since they would likely get the Unicode strings on the stack. So this method requires more complexity in the exehead and the plugins.

3. Drop ANSI support in NSIS 3.0 entirely. We have one version of everything going forward, but we lose the Win9x support. But as Joost mentioned, NSIS 2.0 can cover that small and rapidly shrinking market. (The Win9x crowd is ~0.2% of the web surfing public according to w3school: http://www.w3schools.com/browsers/browsers_os.asp)

I think the logical choice is 3. But it isn't my decision.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th July 2008, 00:58   #113
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
Quote:
Originally posted by jimpark

2. ...This requires that we have a small but portable implementation of wide string to multi-byte string conversion function. Maybe we can leverage some code in the Wine project to do this
Win9x has support for a limited set of Wide API's out of the box, including WideCharToMultiByte IIRC


Quote:
Originally posted by jimpark

3. ...according to w3school
That is a dev specific site, yes, the % of people using 9x is small, but not THAT small


I prefer option 1 myself, old scripts would stay in whatever ansi codepage they have always been in, unicode scripts would need a way to specify that they are unicode, with either a BOM or a nsis instruction at the top

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 5th July 2008, 16:46   #114
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
You might be right about the percentage of people using 9x being too small but I would still argue that around 1% is right. Is there a different number you are aware of?

I wouldn't mind getting option 1, either. We might be able to do it by inserting both the Unicode and ANSI exehead into every installer (option controlled, of course). It also means two copies of every plugin as well. So your installer overhead would be 2x what is now if you wanted a "Universal installer."

Unfortunately, this change is not something I can do. Time constraints are a problem for one. But more importantly, it would fork the code too much and I wouldn't be able to maintain the code to be in sync with the main build. It could easily end up being an abandoned fork.

But we are all eager to see the main NSIS developers start work on an official Unicode version. Is there any work going underway for this support currently? If not, is there any tentative plans for Unicode support in the near future?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th July 2008, 22:27   #115
Benski
Ben Allison
Former Winamp Developer
 
Benski's Avatar
 
Join Date: Jan 2005
Location: Brooklyn, NY
Posts: 1,047
Personally, I see no reason to continue win9x development. I know that kichik and other NSIS developers disagree, but the userbase has dropped off dramatically. Based on winamp.com web stats, Winamp's win98/ME userbase went from 3% in 2006 to less than 1% by January 2007 which triggered us to drop support for the platform entirely.
Benski is offline   Reply With Quote
Old 6th July 2008, 13:12   #116
sealite
Registered User
 
sealite's Avatar
 
Join Date: Aug 2002
Location: Bucharest / Romania
Posts: 54
Send a message via ICQ to sealite Send a message via Yahoo to sealite
I agree that developers should drop 9x support. It's like the idea of having 16bit/32bit software build few years before

Keeping the compatibility would require too much effort, effort that could be used other things.

And if you don't trust you can make a survey, just don't forget to put the questions right
sealite is offline   Reply With Quote
Old 10th July 2008, 00:01   #117
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
If we want to continue Win9x support, the best option would be to have all scripts and plug-ins in Unicode but add support to the exehead to create ANSI dialogs on Win9x.

If this is not possible, the scripts should move to Unicode anyway but there will be two sets of plug-ins and exeheads.

However, it may indeed be better to drop Win9x support for NSIS 3.0.
Joost Verburg is offline   Reply With Quote
Old 10th July 2008, 00:10   #118
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
the script should stay like they are, BOM for unicode files and no BOM means ansi, otherwise tricks played with !system that you include again will have to be unicode aswell, and the console is not unicode by default

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 10th July 2008, 00:21   #119
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
But then you also need two sets of langauge files etc., which will all be way to complicated.
Joost Verburg is offline   Reply With Quote
Old 10th July 2008, 02:13   #120
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,475
Quote:
Originally posted by Joost Verburg
But then you also need two sets of langauge files etc., which will all be way to complicated.
You can't convert the lang file on the fly from ansi to unicode when you know the codepage ?

IntOp $PostCount $PostCount + 1
Anders 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