Old 10th July 2008, 02:41   #121
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
You can, when you know the codepage. You can't tell programmatically right now. Some languages use two scripts and have two different language files. The NLF files can be read and the codepage gotten but not the NSH files. It would require that we add something in the NSH files to store the codepage. Maybe a special comment?

Also, no the console is not Unicode by default but outputs to the console through the stdlib will convert them to ANSI before displaying them on the console. Hence, you really want to use the makensisw.exe to see the Unicode characters.

All new scripts for the Unicode only NSIS should be UTF-16LE but we can make makensis.exe read ANSI scripts and 1. convert them to Unicode using the system codepage or 2. provide a parameter that provides the codepage to use to convert to Unicode.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 11th July 2008, 00:25   #122
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
But there are also scripts that contain strings with different code pages. This is impossible to convert to Unicode.
Joost Verburg is offline   Reply With Quote
Old 11th July 2008, 00:46   #123
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Yes. I was looking at some just today. They cannot be automatically converted.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 11th July 2008, 12:42   #124
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
There is nothing that can't be done. It's complicated, I'll give you that. But at the very minimum, we could have two string tables - ANSI and Unicode. Those strings that can't be translated could be saved in the ANSI table.

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 11th July 2008, 15:54   #125
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Okay, we are talking about the automation of the conversion of a script into Unicode. There isn't a language that ANSI supports that Unicode cannot which I know you know but someone can misread your statement and think that.

The complication comes in when a script has multiple ANSI codepage strings. The strings themselves do not tell you what codepage they are encoded in. But it may be possible if the script always explicitly uses the $LANGUAGE variable that we can deduce the codepage for conversion in makensis itself. If someone just encodes a string in their native codepage and never says in the script what language it is in, then you really can't do anything except assume things like that it's the system default codepage which can be wrong.

Where as the Unicode to ANSI conversion can be done if the ANSI codepage that supports the language exists, because the script is inherently implied in the Unicode codepoint. So it's much safer to store the scripts as Unicode and then convert them to ANSI if desired and possible.

So just to be clear:

Unicode can encode a superset of the scripts that are supported by ANSI codepages. Each codepoint implies a script. Therefore, for any shared subset of scripts, a Unicode string can be converted to the ANSI codepage encoding.

An ANSI codepage string does not imply any codepage / script. So unless hints are given, we cannot automatically convert to Unicode.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 11th July 2008, 17:58   #126
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
Of course. And so the very minimum we can do is have two tables and have the ANSI table act as it does now. This way, you could still build these old scripts.

Most language files already provide codepage identifiers and some string paths can give you a good enough hint on the codepage for the ANSI string. But as a first very basic solution, two tables is enough.

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 11th July 2008, 19:54   #127
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Can you clarify what you mean by two tables? Do you mean that the installer executable will have two tables? Then yes, I think that was the proposal -- two exeheads that accesses two different string tables.

So we have this path:

ANSI script generates:
1. best guess at Unicode string tables.
2. ANSI string tables.

Unicode script generates:
1. Unicode string tables (of course).
2. ANSI string tables. (Multiple languages in the Unicode script will not work if they are meant to be shown together. Not a big surprise because ANSI NSIS can't do this either.)

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 11th July 2008, 21:55   #128
kichik
M.I.A.
[NSIS Dev, Mod]
 
kichik's Avatar
 
Join Date: Oct 2001
Location: Israel
Posts: 11,343
I do mean two string tables in the installer executable. But there's no need for two different exeheads/stubs for the job. The ANSI table could simply be empty for installers generated from Unicode scripts.

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 13th July 2008, 21:37   #129
Joost Verburg
NSIS MUI Dev
 
Join Date: Nov 2001
Posts: 3,717
And all variables will also be in ANSI when an ANSI script is compiled? Otherwise it won't be backwards compatible anyway.
Joost Verburg is offline   Reply With Quote
Old 15th July 2008, 02:10   #130
vcoder
Junior Member
 
Join Date: Jun 2008
Posts: 7
NSIS 2.38

NSIS 2.38 released.
What about Unicode version of NSIS 2.38?
vcoder is offline   Reply With Quote
Old 15th July 2008, 18:47   #131
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
vcoder, I'm on vacation right now. So I won't be on it for a few weeks. But I'm sure you can survive in the interim.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 15th July 2008, 23:44   #132
vcoder
Junior Member
 
Join Date: Jun 2008
Posts: 7
Quote:
Originally posted by jimpark
vcoder, I'm on vacation right now. So I won't be on it for a few weeks. But I'm sure you can survive in the interim.
Thank you for your response.

Have a good vacation!
vcoder is offline   Reply With Quote
Old 16th July 2008, 06:03   #133
vcoder
Junior Member
 
Join Date: Jun 2008
Posts: 7
Bug in FileWrite?

This script work well on ANSI version of NSIS and failed on Unicode version:

PHP Code:
OutFile "GetVersion.exe"

!define File "Resources.dll"

RequestExecutionLevel user

Function .onInit
    GetDllVersion 
"${File}$R0 $R1
    IntOp $R2 $R0 
0x00010000
    IntOp $R3 $R0 
0x0000FFFF
    IntOp $R4 $R1 
0x00010000
    IntOp $R5 $R1 
0x0000FFFF
    StrCpy $R1 
"$R2.$R3.$R4.$R5"

    
FileOpen $"$EXEDIR\Version.txt" w
    FileWrite 
$'!define Version "$R1"$\n'
    
FileClose $0
;    MessageBox MB_OK "$R1"
    
Abort
FunctionEnd

Section
SectionEnd 
Result file:
ANSI: !define Version "3.4.0.96"
Unicode: !def
vcoder is offline   Reply With Quote
Old 16th July 2008, 17:53   #134
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I'll look into it when I get back from vacation.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 21st July 2008, 21:12   #135
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I am back from vacation today.

Just released Unicode NSIS 2.38. Fixed vcoder's FileWrite bug as well. And modified the Unicode Mongolian translation to use some characters that do not exist in the ANSI Cyrillic codepage as per request by the OpenOffice project.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 22nd July 2008, 15:50   #136
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Just modified the System plugin so that the 't' type specifier acts like a TCHAR*, that is, it will be an ANSI string in the ANSI version of NSIS, but will act as a wide-char string (Unicode string) in the Unicode NSIS.

I introduced an 'm' type specifier to specify an ANSI string. Why 'm'? Well, I can't do 'a' or 's'. So 'm' stands for multi-byte string which ANSI strings can be (although, usually not). Also 'm' looks like an upside down 'w' which stands for wide-char string.

This means that the conversion from your ANSI NSI script to the Unicode one will be mostly straightforward file conversion unless you were naughty and used the ANSI Windows API specifically, such as MessageBoxA. Some Windows API like GetProcAddress only take ANSI strings, so you should still look at your System calls carefully.

The new version is dubbed 2.38.1. You know where to get it.

I've also added an FAQ page (http://www.scratchpaper.com/unicodensisfaq). If there are any missing topics you'd like to see or there's some erroneous info, please e-mail me.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 22nd July 2008, 19:00   #137
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,590
there was already a feature request for this (http://sourceforge.net/tracker/index...49&atid=373088) would be great if you could submit a patch so the system plugin stays in sync

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 22nd July 2008, 19:32   #138
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I didn't know there was already a feature request. The feature request mentions 'z' as the potential type specifier. I did consider that but favored 'm'. Can we settle with 'm'?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 22nd July 2008, 19:52   #139
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
BTW, I can't add the modified source to the feature request. I can only submit comments. (Permissions issue?) Or do I have to submit a new patch request?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 23rd July 2008, 05:27   #140
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 4,590
yeah, go with 'm', and you would have to submit it as a patch, not sure why its not possible to attach files

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 18th August 2008, 22:50   #141
vcoder
Junior Member
 
Join Date: Jun 2008
Posts: 7
Wink 2.39

We a waiting for Unicode version of NSIS 2.39...
vcoder is offline   Reply With Quote
Old 19th August 2008, 00:04   #142
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
I'll probably work on it this weekend.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 21st August 2008, 14:04   #143
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
This code work well on ANSI version of NSIS 2.38 and failed on Unicode 2.38.1 version:

!define HAVE_UPX
!ifdef HAVE_UPX
!packhdr tmpexe.tmp "UPX --best -f -q -v --ultra-brute --all-methods --all-filters --compress-icons=0 tmpexe.tmp"
!endif
Ta2i4 is offline   Reply With Quote
Old 22nd August 2008, 10:45   #144
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Have you tried packhdr just on its own to see whether it works on Unicode NSIS generated installers?

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 27th August 2008, 13:38   #145
xbarns
Senior Member
 
xbarns's Avatar
 
Join Date: Aug 2007
Location: Frankfurt, Germany
Posts: 185
I tried using a2u.exe on a Windows 2003 Server (SP1, Standard English) it gives me an error: "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."

It works fine on XP Pro. (SP2, German).
xbarns is offline   Reply With Quote
Old 27th August 2008, 14:42   #146
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
You most likely need a newer verison of the C++ redistributables installed: http://www.microsoft.com/downloads/d...DisplayLang=en

(If that doesn't work, try the 2008 one)
Pidgeot is offline   Reply With Quote
Old 27th August 2008, 21:31   #147
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Well, if it is because of the redistributable, then it's a silly mistake on my part. I tried rebuilding the project. Can you try downloading a2u.zip and trying the executable inside it again?

As for the Unicode NSIS update, I don't think it's happening this week. I've got way too much other work to do. Hopefully, next week some time.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 28th August 2008, 06:56   #148
xbarns
Senior Member
 
xbarns's Avatar
 
Join Date: Aug 2007
Location: Frankfurt, Germany
Posts: 185
It works now,thanks a lot!
xbarns is offline   Reply With Quote
Old 29th August 2008, 13:18   #149
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
Quote:
Have you tried packhdr just on its own to see whether it works on Unicode NSIS generated installers?
This code I found in ansi-NSIS help file. I converted my ansi script file to unicode by a2u.exe and tried to compile it by unicode-NSIS. Result is error when part of code with UPX is processing.
Ta2i4 is offline   Reply With Quote
Old 29th August 2008, 13:48   #150
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Okay, so can you try calling UPX itself to see if it works on Unicode NSIS installers? What does the errors say? I just don't have a lot of time to work on Unicode NSIS these days, so you're going to have to help me find the problem a bit.

- Jim

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 30th August 2008, 01:35   #151
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
I found this error on WinXP SP3. But in Vista SP1 the same error.

This is report:
Error name: APPCRASH
Application name: makensis.exe
Version: 0.0.0.0
Time stamp of application: 4885ef1f
File with error: makensis.exe
Version: 0.0.0.0
Time stamp of file: 4885ef1f
Code of exception: c0000005
Stack of exception: 00006c6b
OS version: 6.0.6001.2.1.0.768.2
Language: 1049
Advanced info1: 8a1e
Advanced info2: 9e3d13911997afb9af7c20e45db763b3
Advanced info3: 3aba
Advanced info4: 1beeb7f8f0c5e3f3f9c6c0f5ff97433e
Ta2i4 is offline   Reply With Quote
Old 30th August 2008, 01:41   #152
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
1. In script: CRCCheck off
2. Generating installer with name 'example.exe' without code with UPX.
3. Command line: upx -9 example.exe
4. Installer is working! Files is copying to folders. But the error when uninstall.exe creating.
Ta2i4 is offline   Reply With Quote
Old 30th August 2008, 05:06   #153
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Is there a plugin you are using to get this UPX capability? Or are you calling the UPX tool straight as part of your script? I only support the default plugins that come with NSIS. If you are using a third-party plugin, you will need to contact them for help or convert the third-party plugin to interface with the Unicode NSIS using Unicode strings. It seems like either a plugin that has not been converted for Unicode support or an UPX issue. Either way, I don't think I can help you in this case. I apologize.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 30th August 2008, 16:51   #154
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
I calling the UPX tool straight as part of script.

See in file NSIS.chm:
"NSIS Users Manual" -> "Chapter 5: Compile Time Commands" -> "5.1 Compiler Utility Commands" -> "5.1.10 !packhdr"

Sorry, there is new code now. I will try the new code and will write the result here.
Ta2i4 is offline   Reply With Quote
Old 31st August 2008, 14:26   #155
Ta2i4
Junior Member
 
Join Date: Sep 2006
Location: Russia, Birobidzhan
Posts: 13
Same result.

Script file contents:
code:

;...<code before>...
page licensepage
;...<pages>...

!packhdr ....

Section First
;Some data
SectionEnd
;...<code after>...



Output in makensis:
code:
;...<code before>...

!packhdr

Section First


Its all! Why?
Application error at this place.
Ta2i4 is offline   Reply With Quote
Old 4th September 2008, 22:54   #156
jamescookmd
Junior Member
 
Join Date: Nov 2006
Posts: 12
I'm an engineer on Second Life (www.secondlife.com). We've been using NSIS for years and love it.

Recently we've noticed that installers built with NSIS 2.39 (and earlier) fail to launch on east Asian systems when the path to the installer has a non-roman character in it. For example, if a Korean user has a Windows username with Korean characters in it (í•œêµ_ì–´), and the installer is on the desktop, it fails to launch with the error:

NSIS Error: Error launching installer

I've noticed that I don't get this error if I build the installer using NSIS Unicode.

Is this a known issue with the mainline NSIS? Do I have to switch to NSIS Unicode if I want my Asian users to be able to run the installer off their desktops?

Thanks,

James Cook
james@lindenlab.com
jamescookmd is offline   Reply With Quote
Old 5th September 2008, 03:43   #157
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
If the user had used MBCS (ANSI codepage) for their path names, it might have worked. But usually when Windows creates the User's documents and settings directory using the user name, that user name is going to be Unicode, not ANSI codepage, even if the operating system codepage is Korean in this case. So that's why ANSI NSIS has trouble with it. However, Unicode NSIS has no problems at all.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th September 2008, 07:38   #158
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Not entirely true, Jim. In NTFS, all path names are Unicode (actually, this also applies to LFNs in FAT), so Windows will convert to ANSI when applications call the relevant *A-APIs.

However, the ANSI codepage used is dependant on the setting selected for non-Unicode applications in Regional and Language settings in the Control Panel. If you've selected a codepage that doesn't contain the required characters, it'll fail to make a proper conversion because the unmapped characters are converted to a ?, which in turn means the path won't be found.

Now, although I kind of doubt James posted the actual text in question, it would appear to contain 2 characters that aren't Korean (at least they appear as good old "I don't know what this character looks like" to me). That might indicate characters outside of CP949, the Korean codepage.

(There's also an underscore, but that's in the 0-127 area, where they've only changed \ to ₩ - just like CP932, Japanese, has ¥ at that position.)
Pidgeot is offline   Reply With Quote
Old 5th September 2008, 10:42   #159
jimpark
Senior Member
 
Join Date: Sep 2007
Posts: 204
Ah, thanks for the clarification Pidgeot. So the user name issue then must be that people like to have their user names in their native language which naturally causes Unicode characters to be included into the desktop path which is something like c:\documents and settings\<user name>\desktop or on Vista c:\Users\<user name>\desktop.

Now what if the system codepage is not Korean but the person still wanted to have a Korean user name? How does the system convert that to codepage for NSIS to manipulate and back to Unicode? I think that's also a legitimate issue.

So perhaps recently, there was a change in NSIS which required that it needed to know where itself was not just where the user wanted to install the program.

Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.
jimpark is offline   Reply With Quote
Old 5th September 2008, 11:19   #160
Pidgeot
Senior Member
 
Pidgeot's Avatar
 
Join Date: Jan 2002
Location: Denmark
Posts: 136
Just to elaborate how it all works with an example:

If the system codepage is not Korean, and you use ANSI functions to fetch a path containing Korean characters, you'll get a question mark in place of each non-convertable character.

Having your username in your native language is usually not an issue, because you'll usually have the same language set for non-Unicode applications, and when you aren't using that language in path names, it's usually English anyway, which can be expressed in all code pages.

To give an example, the issue can pop up if I (being a Danish user) wanted to run a Japanese non-Unicode program. Running it with the non-Unicode language set to Danish would result in mojibake for text, so I'll need to set it to Japanese to run that program.

(There's a tool by Microsoft, called AppLocale, which can set this for a single application - and because changing the global setting requires a reboot, that's a good thing - but that's a different story.)

If my username then included a Danish letter, such as Ã…, any non-Unicode application attempting to get the username would read that character as a question mark, because Ã… does not exist in the Japanese codepage. The folder "Ã…l" (Eel) would thus become "?l" - but because the folder is called "Ã…l" and not "?l", it can't access the folder.

You might argue that it could try to guess - after all, ? is a wildcard - however, there are issues with that:

1) If there are multiple matches (let's say we also have a folder named "Øl", meaning beer), you don't know which one you're supposed to get. Acting differently in the case of "only one match" is not consistent behavior, so that's not that good of an idea.
2) Strictly speaking, NTFS does allow a file to be called "?l" - the only character not really allowed is NUL, much like in Linux. Win32 adds several characters to the "disallowed" set due to backwards compatibility
Pidgeot 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