Outdated: this has been released.
Application: Unicode NSIS
Category: Development
Description: Unicode NSIS is the Nullsoft Scriptable Installer System with unicode support packaged as a portable app. NSIS is the language used to write all of the launchers at PortableApps.com. Unicode NSIS contains the capabilities to deal with unicode utf-16LE.
Unicode NSIS Portable 2.46 & PortableApps.com InstallerU now have an official release !
(Unicode)NSIS Portable
PortableApps.com Installer
Unicode NSIS Portable 2.46 Development test 5 Online [960KB download / 8.88MB installed]
(MD5: 2162b7e0354b347321d4d12077cf9582)
PortableApps.com InstallerU 1.0.3 Development Test 3 [1.38MB download / 5.63MB installed]
(MD5: 58f1fedee25bf9b8f44b541ea3f0f889)
PortableApps.com AppCompactorU 1.1 Development test 1 [0.8MB download / 0.8MB installed] 2010/04/19
(MD5: c80bce11d2cb0e19bad688f832f8b790)
Release Notes for Unicode NSIS Portable 2.46:
Development Test 5 (2010-05-25):
- features added:
Updated the Registry.nsh to include 'nsExec::ExecToStack reg.exe'
Development Test 4 (2010-05-24):
- features added:
Updated the Registry plug-in
Updated launcher to PAL HG-tip 2010-05-24 - bug fix:
This should fix the registry restore issues on Wine - Note:
To make full use of the new Registry plug-in you'll need to update PAL with the latest HG-tip
Development Test 3 (2010-05-15):
- features added:
Updated Unicode NSIS to 2.46 (Binaries are identical with 2.46 rc 2)
Updated launcher to PAL HG-tip 2010-05-15 - bug fix:
This should fix the launcher bug for vista / Windows 7
And I included my fix for TrimWhite.nsh
Development Test 2 (2010-04-20):
- features added:
Updated Unicode NSIS to 2.46 rc2 & PAL beta 4
No more moving about of nsisconf.nsh, linking directly to the data\settings folder
Development Test 1 (2010-04-16):
- features added:
Updated Unicode NSIS to 2.46 rc1
Release Notes for Unicode NSIS Portable 2.45.1:
Development Test 7 (2010-04-16):
- features added:
Used latest PAL 2.0 beta 3
Include the new update of the registry plug-in what should fix an issue with XPsp2
Development Test 6 (2010-03-27):
- features added:
Used latest PAL 2.0 beta 2, pulled of Development repository 2010-03-27
Added PortableApps.comLauncherCustom.nsh, to check if ansi NSIS Portable or a local makensisw.exe is running. - Notes:
NSIS Portable (ansi) is not checking if Unicode NSIS Portable or even makensisw.exe is running.
And due to the both NSIS packages using the same executable names, if run at the same time, each launcher will be waiting for them to both be ended !
So then the NSIS registry key won't get cleaned up on exit
Development Test 5 (2010-03-07):
Development Test 4 (2010-02-04):
- features added:
Done away with all the alternative macros
Most standard used plugins are now included
Fully compatible, no need any more to modify your scripts from Ansi to unicode[edit:almost fully...]
Development Test 3 (2009-12-25):
Development Test 2 (2009-12-19):
Development Test 1 (2009-12-13): Initial release
Release Notes for PortableApps.comInstallerU 1.0.3:
Development Test 3 (2010-03-28):
- features added:
converted the language files with the proper code-pages
converted the 'InstallerWizard.nsi' to utf-16 to deal with the '®' not showing
included the recompiled executable which shows the '®'
Development Test 2 (2010-02-27):
- bugs fixed: The install paths are working. I updated all files in the 'nsis\include' folder, what fixed it.
Development Test 1 (2010-02-26): Initial release
- features:
Converted all languages to UTF-16 LE, but there could be some mistakes as I couldn't verify them all ! - known bugs:
The install path within the actual compiled installer is messed up!
NSISunz can not deal with wide-chars in the file path.(probably isn't a big issue thought)
The Unicode NSIS plug-ins List: (beta means: I recompiled and tested them)
TextFunc.nsh (beta: TextFunc_2010_07_01.zip) RealProgress (beta: RealProgress.zip)Original source nsisunz (beta: NSISunzU.zip)Original source NsisUnzU can't handle foreign characters within the extraction/ZIP-file path ! Registry (beta: RegistryU.zip)Original source this includes the new _RestoreKey function ! EnumINI (beta: EnumINI.7z) Original source is included NewTextReplace (beta: NewTextReplace)Original source EmbeddedLists (solved: EmbeddedLists.zip) newadvsplash (solved: newadvsplashu.zip)Note: Play sound doesn't work, for now ! inetc (solved: inetc-unicode.zip ) ExecDos (solved: execdosunicode.zip) FindProcDLL (solved: FindProcDLL Unicode bin.zip) md5dll (solved: Md5dll.zip) MoreInfo (solved: MoreInfo.1.0.1.2.zip)translated into C by KJD (PerditionC) DialogsEx (solved: DialogEx for Unicode) UAC (solved: UAC plug-in)
A few important notes ! (Read the Unicode NSIS manual for more info)
- The Unicode NSIS compiler reads all included scripts as utf-8, if it can't find a utf-16 bom. Overall this won't give major problems as most scripts just use latin characters, but specific symbols could get wrongly converted !
- For the same reason it is strongly recommended to convert the EULA's to utf-16LE! Like that it will be more obvious if this EULA accidentally gets included into an ansi installer !
- This does NOT count for the run-time commands.
'Read/WriteINIStr' depending on the existence of a utf-16le BOM, it will read/write as utf-16 or ANSI
'FileRead' will read as ANSI
'FileWrite' will write as ANSI
'FileReadUTF16LE' will read as utf-16
'FileWriteUTF16LE' will write as utf-16
${registry::StrToHex/HexToStr} are behaving differently then the ansi commands, probably I should include additional *UTF16LE commands soon, for compatibility ! - For any 'system::call' commands you should just remove the A, the plug-in should call the right API (A / W):
System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${NAME}") i .r1 ?e' System::Call 'kernel32::CreateMutex(i 0, i 0, t "${NAME}") i .r1 ?e' - To keep your script compatible, when experiencing additional behavior differences between the two NSIS packages, use:
!ifdef NSIS_UNICODE ;Unicode NSIS script (in utf-8) !else ;NSIS script (in ansi) !endif
BTW: BOM (Byte Order Mark), the first few bytes of a file to identify the files encoding. UTF-16LE = FF, FE or as word FEFF
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
Please rename this to Unicode NSIS Portable and change all references of NSIS Unicode to Unicode NSIS (or for short versions, NSIS -> NSISu) as that's what it is.
What are those alternative instructions you mention? What are they there for? And I presume they should be in a <pre> block.
I think one of the things I'm most concerned about in upgrading our applications from NSIS to NSISu is the registry thing; we need to be able to convert REGEDIT4 files to the newer format; this should just be convert ANSI to UTF-8 and change REGEDIT4 to RegistryEditor v5.00 or whatever it is on the first line, but I imagine we'll need to do it (preferably in the installer I think - with the Unicode plugin or can NSISu do it itself?). We can't just make users lose their settings or worse also have their application not run properly the first time after upgrade for all registry-using applications.
Edit: also, the one thing we must all remember for forwards-compatibility is
!ifdef NSIS_UNICODE(seems to me it'd also be useful to have something like this in the header (it'd be more useful in NSIS and NSISu themselves but it's not there, so ah well))Then you could just have
System::Call 'Kernel32::SetEnvironmentVariable${UNICODE_AW}(t, t) i("USERPROFILE", "$SETTINGSDIRECTORY\UserProfile").n',System::Call 'kernel32::CreateMutex${UNICODE_AW}(i 0, i 0, t "$NAME") i .r1 ?e'etc. (I think I'll implement it in the launcher for simplicity of upgrade, it's also then only one minor change per active line rather than an !ifdef around each such line of System::Calliness.)Also useful at times is that the 1024 character string limit is 8096 with NSISu.
Edit: actually it seems it's fine to just drop off the A or W on almost all functions (the ones that don't have A or W start with a lowercase character) and it'll resolve it to the correct one (we'll need to test it though).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
but for the launcher I need some time, cause my internet connection is that bad. It already took me 2 times of failer and waiting ages to get this 1.9 MB uploaded.
Should I delete the link till it's fixed ?
Registry.nsh, Registry.dll, TextReplace.nsh & FindProcDLL.dll are missing in Unicode NSIS.
Myself I couldn't find any additional plugins for this on internet !
ReadEnvStr $APPLANGUAGE "PortableApps.com????" I just didn't get to work properly.
So I made some alternative scripts what do the same trick.
I think upgrading is a long way head, as a lot of Unicode NSIS plugins aren't available. But at least maybe this is a small start. My experience with this edition is that it uses mainly utf-16LE, so as well for the registry files.
There again, since you are worried about registry files, the way it is setup at the moment, the following line didn't have to be modified:
I just tested it and the launcher does it already ! I compiled the script with execwait NSIS.exe deleted and just added a messagebox, launched it and when the launcher finished the file is saved/converted to Registry Editor v5.00 utf-16LE format.
[edit: converted from REGEDIT4 ANSI format to Registry Editor v5.00 utf-16LE format, I just copied the registry file from NSIS Portable over to Unicode NSIS Portable settings directory !]
Formerly Gringoloco
Windows XP Pro sp3 x32
Good, I'm glad about the regsitry stuff.
What's not working with ReadEnvStr? Are you running it from inside the PortableApps.com Platform? PortableApps.comLang* are only set from inside the Platform (they'll be not set and thus an empty string in NSIS when run outside the Platform or some other special thing set up by the end user to do the same thing).
We'll see if Jim Park comments on the things you say are missing... I'll see if I can find an email address if he doesn't (I think he will notice it though, I guess he's got a Google Alert on as how he spotted the last thread discussing it).
Don't bother taking down the link in the meantime, it's just a name, the functionality won't be changing.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
It is done really crud for now, epecially the registry::movekey instruction.
Cause I do not have any knowledge about coding dll's, I have just made some NSIS script what saves the key to a temp. file, then uses some kind of ReplaceInFile script, writes back the key to the registry and deletes the temp files.
So definitly I need some input to find more proper ways of doing this !
I have tested and test the ReadEnvStr over and over again. it does work (I think to remember) for getting the drive letter. For now, I made ${ReadEnvStr}, which reads the ini and language files from the PortableApps.com folder, which does the same trick.
All these issues I like to get developed in a better way, through this tread.
Ps.: Another failure with uploading ! I have to go to an internet cafe to do this.
[Edit:
By standard, (Unicode)NSIS has it's own basic registry instructions which I used, but they are just not sufficient enough. The problem I had with coding a registry::move script was, that there is only an instruction to read a value and search values and keys(EnumRegKey/Value). So the script had to got through all the separated values and subkeys to be able to move them all. It seems a simple code, but I gave up half way down and found the above mentioned solution]
Formerly Gringoloco
Windows XP Pro sp3 x32
A few of the plugins we use have been recompiled for NSIS Unicode. Most have not. We should start a topic with the full list and start working through them. I'd like to switch over the PA.c Installer, Backup Utility and AppCompactor to Unicode and then do the launchers for each app as we do new releases (which would require NSIS Portable switching to NSIS Unicode as well). For the launchers that do the registry, we'll need a solid way of switching from old to new registry files standardized as a simple function call we can include. I think this is a good beginning to the conversation and process.
Sometimes, the impossible can become possible, if you're awesome!
Yes, a list should be made. I've noticed that most plugin writers have been pretty good about making a Unicode version when asked.
Yes, it's mostly fine to remove the A or the W. It will resolve it fine. The only ones that currently have problems -- and we are looking into possible solutions -- are those that are kernel functions but mimic stdlib functions like strlen. These functions have non-A, non-W functions which are the same as the A functions -- I believe Microsoft did this for backward compatibility. Those are the only functions I've seen that have this issue.
The only other gotcha to look for are memory allocations and pointer manipulations with strings. Remember Unicode in Windows is UTF-16LE, i.e. 16-bits. So you should make use of the ${NSIS_CHAR_SIZE} macro which is 1 for ANSI and 2 for Unicode.
We just have to make more use of Reg.exe (+parameters).
We can copy a key from any source to any target by:
And then delete the key !
Have to test more, it seems to get 'stuck' when a target key already exists !
Downside is, that I expect these commands to not work on WIndows 98. But is really anybody still using that ???
Ps.: Internet cafe was closed (sunday evening)
Formerly Gringoloco
Windows XP Pro sp3 x32
nsexec can not be used in anything we release. Two different major software firewall products have issues with it. It's better to avoid using reg.exe if at all possible as some PCs will have rights that disallow access to it. If unavoidable, the ExecDOS plugin can get around it.
Sometimes, the impossible can become possible, if you're awesome!
But isn't every Portable App (which uses the registry) of this site currently using nsexec & reg.exe to restore the key before launching the app ?
RestoreTheKey: IfFileExists "$WINDIR\system32\reg.exe" "" RestoreTheKey9x nsExec::ExecToStack `"$WINDIR\system32\reg.exe" import "$SETTINGSDIRECTORY\${APPNAME}.reg"`Formerly Gringoloco
Windows XP Pro sp3 x32
How about simply using the windows API using the System plugin? For example: RegistryCopyTree() might be useful. It might be best to just write your own helper macros that use the Win32 API directly. That way you'll have one less plugin to worry about.
That's a good point, Jim. Actually, it would make sense if we did a full set of macros that handle the same things as the registry plugin but use the Windows API. We can put it together and release it under BSD (unlike our usual GPL for our stuff) like we do for our other NSIS add-ons and post it to NSIS so that others can use it as well.
Sometimes, the impossible can become possible, if you're awesome!
I'd be interested in playing around with that. We would need a list of what functions are needed first. Windows registry API is a PITA... however this method would make cooking in unicode support easier I think.
Do you have any ideas for the ${registry::CopyKey}, ${registry::MoveKey} & ${registry::SaveKey}?
I am modifying the following script by AxelMock, REG_MultiSZ.nsh !
To read / write individual values, slowly I am getting it work with all value types !
Hopefully in the end we could use it to copy/move whole trees ???
Formerly Gringoloco
Windows XP Pro sp3 x32
I know about all that stuff. I looked through the original source back when I was developing something similar for AutoIt. It's going to be a PITA in NSIS I think.
I'd like to see a list of what's needed / wanted for PApps before committing any time to this. For example, I doubt anyone uses the registry search functions in the registry plugin. And there a built-in registry functions that can be used for individual keys and such. So... what is really needed here? Just the copy / move / recursive stuff?
${registry::MoveKey} and ${registry::SaveKey} are the most important !
As John mentioned, we shouldn't use any 'nsExec::ExecToStack' or 'reg.exe'!
About ${registry::MoveKey}:
JimPark advised:
But the information I found on internet says RegCopyTree only works for Vista and newer ???
For now I got it working by using 'SHCopyKey'. (see dev. test 2 registry.nsh source)
Till now, it does the job just as well as the original version of the Registry plugin. Both of them don't seem to copy values containing unicode data !
But I consider this a problem ! Anything compiled with Unicode NSIS should be able to deal with unicode registry keys/values !
About ${registry::SaveKey}:
Uses 'nsExec::ExecToStack reg.exe export' for now !
I just didn't have time to find another solution for this.
JimPark send us a link for a ExecDos unicode plugin, which I tried and works. But still John rather doesn't have us using reg.exe anyway.
Probably using 'system::call RegSaveKey' could do the job ? But as I said I didn't get around playing with it jet !
At the moment I made a script to read / write individual values. Not that they are needed by the standard PA launchers, but because I am learning to use the 'system::call reg***key' stuff and have the hope that I can combine the read & write functions to construct a proper way of copying whole registry trees ?!?!
I'll include the ${registry::Read} & ${registry::Write} soon, in the next dev.test. As I still have to thoroughly test & cleanup the script.
Formerly Gringoloco
Windows XP Pro sp3 x32
Sounds like you don't need my help for anything! You've got it covered. I don't think there a built-in function to export keys to file. You'll have to read the keys and write the correct format I think. I'll look into the source of the old registry plugin to see how he did it.
Use SHCopyKeyA (Ansi) or SHCopyKeyW (Unicode). The Ansi version of NSIS will call the Ansi function if not specifically told to do otherwise. The Unicode version of NSIS *should* call the Unicode version of the function.
but it didn't change behavior !
Googling on the web I crossed some forums stating it doesn't work for unicoded values due to a Microsoft bug.
Anyway, as I got a bit more experience now, I will give it another go !
Formerly Gringoloco
Windows XP Pro sp3 x32
Interesting. You might have to do it manually then. According to Microsoft, the Reg functions will automatically convert between Ansi and Unicode for you. This is from RegGetValue:
I've written AutoIt recursive reg functions, it's not too hard. I'll have to refresh myself a little on NSIS and System calls. And it will definitely be a bit harder without the abstractions provided by an interpreted language like AutoIt. NSIS, unfortunately, does not really provide the required information in their readreg / writereg functions (like returning the value type and allowing you to specify a value type when writing).
I just took a look at the REG_MultiSZ.nsh script. This makes a lot of calls to the system. And not only that, it uses integer operations to work on pointers to internal buffers. In order to make this work with Unicode strings, we need to realize that all the IntOp calls that are trying to move a pointer forward or backward by a character needs to be do so by TWO bytes for Unicode and ONE byte for ANSI. To accomodate this, Unicode NSIS and ANSI NSIS built by me, have an NSIS_CHAR_SIZE macro which is 1 for ANSI and 2 for Unicode. Also, when allocating strings, always use StrAlloc because it will do the right thing for the string length.
So basically, make sure the pointer arithmetic is correct and you'll get it to work pretty well. That's pretty much the trickest part of the whole conversion.
Got the hang of it a bit!
Made my own script to copy keys, instead of using SHCopyKey !
The above info, I got to take in account for next update, but the way I got it done for now seems to work pretty well.
Thanx for your interest !
[EDIT :
For now all the script just assumes it will be compiled in Unicode NSNS,
The Read / Write macros, are made to use the IntOp * 2 for the text value types. I'm probably going to need the Read/Write for the SaveKey & RestoreKey macros, will have a go on this soon !
The CopyKey doesn't deal with this, it just reads the value-data into the buffer, then writes the buffer into the value in the target path !
I will have a look if and how I would implement NSIS_CHAR_SIZE, cause I'm not sure if this Registry.nsh is any use in th ANSI version of NSIS !
I have to have a look into what StrAlloc can do ( not much time these days, Christmas!)
Merry Christmas to you as well !]
Formerly Gringoloco
Windows XP Pro sp3 x32
I included a link in the main topic.
So far it looks like it will solve our main problem !
Formerly Gringoloco
Windows XP Pro sp3 x32
I have changed and added a lot to the registry.nsh script.
But really the 'system::call' stuff is all new to me, so it takes me time to get the hang of it all !
Formerly Gringoloco
Windows XP Pro sp3 x32
I found FindProc was one of those functions that was really useful so FindProc is built-in to Unicode NSIS. (Open the User Manual and search for "FindProc".) This works just like the FindProc plugin by Sunil Kamath. This has been there since day one.
The ExecDos plugin also has a Unicode variant: http://forums.winamp.com/showthread.php?threadid=181442
If there are bugs, you can emit concerns at the forum above and he can help you.
a lot Jim !
Formerly Gringoloco
Windows XP Pro sp3 x32
Ya know, another option might just be to recompile a unicode version of the Registry plugin... it might be easier than trying to reinvent the wheel in native NSIS.
I'm just a newbie on computers and programing, and for now c or c++ are just a step to far for me. (that's what the plugins are written in, I believe)
I tried getting in contact to the author of the registry plugin about this, but no luck so far.
But if you could do this yourself, recompiling would be the ideal solution !
Formerly Gringoloco
Windows XP Pro sp3 x32
I'll be out of two until after Christmas, but I'll have my laptop with me. If I get a chance to check it out I will, otherwise I'll get to it early next week.
copy or move values containing unicode data.
I just tested the newest version (v3.6) of the registry plugin, and it doesn't.
Maybe cause it's being used in ANSI NSIS, but I consider this to be a bug. It has the potential to mess up the local registry this way !
As well I tried SHCopyKey again and added a 'W' after all the registry instructions, without any luck !
Both of the tests left the registry values full of question marks instead of the unicode text, after copying/moving the keys !
Formerly Gringoloco
Windows XP Pro sp3 x32
Since I'm not an über c0der like you guys, I'll turn cheerleader and say, "Good work guys! Keep it up!"
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
Could people PLEASE test:
${Registry::MoveKey} or
${Registry::CopyKey}
In Vista, Windows 7 and 64 bit operating systems ???
There is a 'test.reg' in 'Source\AdditionalFiles', which consists all possible value types and unicode characters !
This because it's a whole new script, making lots of system calls !
Ps.: Windows 98, 2000 and Millennium edition tests are also welcome.
Formerly Gringoloco
Windows XP Pro sp3 x32
IT IS TO SLOW!
I've written a NSIS code, which saves a key just like the Registry Editor v5.00 format ! It reads every separate value through system::call and writes it to a file.
For the 7ZipPoratble.reg it takes about 2.2 seconds to save.
For REGEDIT4 this file contains 13KB,
but converted to Registry Editor v5.00 it's 26KB (2.2seconds!!!)
The main problem is that, except for REG_SZ, all value types are saved as hexadecimal, example:
The script needs a lot of time to make this format.
My idea is to use a new format(and new extention), just for portable apps, which saves these values in a faster way, for example:
This good potentially be much faster, and I do not see a problem with this, since REG_SZ values basacilly keep the same format !
Ps.: I do not understand why .reg files have a double backslash in REG_SZ folder paths, they aren't written this way to the registry?
Let me know if anybody has a problem with this ?
Formerly Gringoloco
Windows XP Pro sp3 x32
I believe the double backslash is because the first one is the escaping character to tell the system the second slash should be taken as a literal slash.
Read under "Listing 2":
http://www.geekgirls.com/windows_registry03.htm
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
The backslash is the escape character. I think you can have \r and \n but I've never tried it; so also you'd use \" to escape " in a value name. So, you must escape the \ as \\ (it's standard programming practice).
I say that you should just use a plugin - NSIS code is inherently slow and we'd really be better off with straight C for the whole launcher (but we're using NSIS, at the moment at least).
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
or somebody else, who has knowledge about writing NSIS plugins.
I've tried contacting the developer of the registry plugin, but no reply !
For now I'm probably better off to leave it as it is. Executing reg.exe through the ExecDos plugin.
Any other instructions, like CopyKey/MoveKey, I consider being fast enough .
About writing a plugin, I'd like to learn, and had a look at the source of the registry plugin. The SaveKey part basically does the same as my NSIS script, just has to be modified to write wide chars. RestoreKey has to be rewritten, cause it just executes regedit.exe .
But I can't even get to recompile registry.dll . I'm using DevC++, but get a "[link error] undefined reference to 'WinMain@16'". Probably this has something to do with it being a .dll ?[edit: got it to recompile, but modifying the code myself will probably take me months !]
Formerly Gringoloco
Windows XP Pro sp3 x32
Apps run but no splash. full plugin. Help me, thks alots
as an example, to modify your ANSI based script!
the splash plugins uses a slightly different command, and myself I just got it to work with .bmp files !
Formerly Gringoloco
Windows XP Pro sp3 x32
i don't work with .bmp files. I tested
UnicodeNSISPortable: ok
but
Notepad++Portable: bad
huhu.....
But as you can see in the source folder of UnicodeNSISPortable, it does use a .bmp file !
Just convert your .jpg to .bmp ! You can even just convert it using Paint.
Formerly Gringoloco
Windows XP Pro sp3 x32
But better late then never.
I believe the plugins mentioned on the top are the missing ones still needed by PA.c.
Not sure what the 'EmbeddedLists plugins' are ???
Anyway, I gave up on the idea to script this in NSIS, it's just to slow.
Therefor I've been learning some C, and it all doesn't seem that hard.
Had some experience on the newtextreplace plugin for ansi NSIS, and even got one function working of the registry plugin for unicode NSIS.
It's a (small) start !
Formerly Gringoloco
Windows XP Pro sp3 x32
I just noticed that the ini doesn't have the line to disable the splash screen. If I add that line, the splash still shows up. It seem that the launcher doesn't have the ability to disable the splash.
Hopefully you get the last few plugins figured out, this will be perfect when PortableApps moves to unicode for its launchers.
My first plugin compiled for Unicode NSIS, published !
I'm quite far with doing the registry one. I got all the functions working (& tested) which we use in standard launchers. Just want to do some more testing for the other functions, but will send a link soon!
NewTextReplace doesn't make use of the 'TCHAR' stuff, cause that way it would break functionality for standard files. So I just made 2 separated sets of 'pop-' & 'pushstring'.
The registry plugin will be recompiled with making use of the 'TCHAR' stuff.
I will try to get in contact with JimPark this weekend, for additional advise about recompiling.
[edit: EnumIni recompiled, done some extensive testing so it should be fine]
Formerly Gringoloco
Windows XP Pro sp3 x32
Don't get confused / hung up on char vs wchar_t vs TCHAR. TCHAR is a compile time only macro that uses either char or wchar_t based on whether the source is compiled with unicode support. Once compiled, TCHAR doesn't exist anymore.
I did a lot of investigation about all of it!
This is what you mean I believe:
If I implement this TCHAR becomes, wchar_T. Otherwise it becomes char.
Like that the scripts could be compiled for either Unicode NSIS & Ansi NSIS !
The way I did the EnumINI plug-in, I used the TCHAR. The same way jimpark uses it. And the other stuff like _T("***") & sizeof(TCHAR).
Just I had a problem implementing this for NewTextReplace, as it destroyed functionality for doing the replace in ANSI & UTF-8 files. So instead I used WideCharToMultiByte() and reversed it just to use CreateFileW(). This is the only way I got NewTextReplace working for now. And it does the job as it should ! (At least in my testing it did)
Maybe, after I have more experience I can get it done using the TCHAR stuff.
[edit: Have a look at the source, if you got time]
Formerly Gringoloco
Windows XP Pro sp3 x32
That's cool. It wasn't clear from your other comment you had it all straight. I'm not familiar with the source, but I could see where there could be issues reading and writing data to/from the file. You're correct, you need to use the proper versions of functions based on the file encoding.
However, and I'm just speculating here at the moment, ReadFile just reads binary data. It doesn't matter if the file is opened with CreateFileA or CreateFileW. It would be up to you how to interpret the data and how to write it back. So technically, you could open all files with CreateFileW then branch to ANSI/UTF-8/Unicode parsing/writing functions. I'm blabbering...
Carry on!
Will update the package later, no time anymore today!
The bug for ${Registry::WriteExtra} only counts for use with REG_MULTI_SZ values.
As this isn't important for portable apps and I expect for the installer. Anyway probably there will be some additional moddifications to be made.
Ps.: As I tried to contact the specific plun-in developers, one has replied finally !
He will do the MD5dll plug-in this weekend !
[edit: Bug is fixed!]
Formerly Gringoloco
Windows XP Pro sp3 x32
By Takhir.
The launcher plugins are complete!
Also I done FindProcDll, so if you change the name of NewTextReplace.nsh to ReplaceInfileWithTextReplace.nsh , the launcher scripts should be compatible for ansi & unicode
Formerly Gringoloco
Windows XP Pro sp3 x32
Updated....
Formerly Gringoloco
Windows XP Pro sp3 x32
I'm a bit confused here, it looks like some mod. has altered some of the list of plugins needed.
But I thought moreinfo (& md5dll) are needed for the installer, as I can see in the 'PortableApps.comInstaller' folder.
And the time plugin (which has just dissapeared some how) should be needed for the 'PortableApps.comUpdater'???
Anyway, md5dll plugin is added. Really seeing an end to this, now.
Nsisunz, is almost done!
Just 'moreinfo' is written in Delphi, so I won't be burning my hands on that one.
[Edit: Nsisunz added, just has a problem that 'zlib' isn't written for unicode, so it won't be possible to unzip files with odd characters in the name/path. But same seems to be for 'untgz' plugin which uses 'zlib' aswell ]
Formerly Gringoloco
Windows XP Pro sp3 x32
Setting DisableSplashScreen=true does nothing.
This is because, the launcher is the same script as of NSIS Portable. Which doesn't have this option as well.
I'm not developing the launcher, I just want to get all the plugins working properly !
Formerly Gringoloco
Windows XP Pro sp3 x32
NSIS doesn't have a splash screen. That thing that comes up is the NSIS menu that you then pick what you want to do (read docs, check out examples, compile something).
Sometimes, the impossible can become possible, if you're awesome!
Yes, but I added the splash, for last dev tests. As an example for people how to use the advsplash plugin.
Anyway, we are in need of some one having a look at MoreInfo plugin.
I believe it written in delphi. Any ideas ???
And yes I did try to contact the developer of the plugin, a while ago.
Formerly Gringoloco
Windows XP Pro sp3 x32
I was actually talking about the Dev Test splash screen. The ini options in UnicodeNSISPortable.ini don't do anything.
I was looking at the code for the launcher and there is a section in there to disable the splash screen, but it doesn't work properly. Maybe you could take a look at it and see if you can fix it. Either that or remove the splash screen since it is just a dev test anyways.
Just use the NSISPortable.exe launcher instead, and rename it to UnicodeNSISPortable.exe
or comment out the following: (just as in the original launcher)
;InitPluginsDir ;File /oname=$PLUGINSDIR\splash.jpg "${NAME}.jpg" ;newadvsplash::show /NOUNLOAD 1500 0 0 -1 /L $PLUGINSDIR\splash.jpgand recompile it.... (you do have to rename it first thought)
I'm really not intending to develop the launcher it self. But I should include the the dev.test splash as it's not an official release !
Formerly Gringoloco
Windows XP Pro sp3 x32
I understand what you're saying, and maybe it's because I like all my apps to be the same, but if it does become an official app (which it likely will since John wants to move towards unicode) either there needs to be a way to disable the splash or it needs to be removed.
I understand that the splash in the case is important to let people know that it is a dev test, but most people who download apps from the beta forum know what dev tests are and that they may contain bugs. These people probably don't need a splash to remind them of that each time they launch the app.
Sorry for being long winded, I just think it would be worthwhile to fix the launcher. Maybe a fix would be rather than commenting out the necessary code, set the default for DisableSplashScreen = true.
This way it would be disabled by default, but end users could enable the splash screen if they wanted to. The splash screen functionality would still be there, but could be toggled on and off just like all the other apps.
For the dev test DisableSplashScreen = true, but for the official release DisableSplashScreen = false.
I guess I just see no reason for the functionality to be completely removed.
Yes, it's fine to drop off the A and W for most functions. The only ones that are trouble are those API where the function without the A or W actually resolves to a function. For example, lstrlen is such a function. The Unicode version is lstrlenW. The only functions like these are Windows API that are named just like the C standard library functions which aren't many. So as you said, if you see a function that is not camel-cased i.e. all lowercased, make sure to add the W for Unicode.
[Edit] I hadn't realized that I remarked on this before. There may be some changes coming which may even make this even more automatic. Sorry about the sudden case of amnesia and the repeated post. I'm glad to see this project making progress. Please let me know when it's all done and rolled out!
I know you know this, but I'll restate it in this thread so we can make sure people realise it; it's (almost) only the C-style functions that may have a sans-A version as the ANSI function - viz, if it is lower case, check it up on MSDN.
In the PortableApps.com Launcher I've been dropping A in every instance of a System::Call (and successfully). The probability that you'll use a sans-A function in any of our coding is very low indeed.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I posted the PortableApps.com Installer for unicode.
No modifications have been made to the actual script!
I done some small testing for the languages and online installers which is working as expected.
Just I could find the problem with the path, which the installer assumes you like to install your portable app.[Edit:I think I fixed it, see main topic for details]
Formerly Gringoloco
Windows XP Pro sp3 x32
In your DT4 notes you've said "Fully compatible, no need any more to modify your scripts from Ansi to unicode". How does this work? Automatic execution of a2u on a copy or something, or something else?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
a2u isn't needed in the first place. It's possible to compile any script with an ansi code-page. Unicode NSIS will look for a BOM, if it finds it, assumes the file is UTF-16, if it doesn't it assumes the file is UTF-8, which converts the same as an ansi file, as scripts are done in latin letters
And, for now there shouldn't be no more need to implement any:
I'm trying to keep it that way
As well for the .reg files. The registry plugin uses regedit.exe to restore the .reg files(it has always used regedit.exe). So the .reg files are backwards- and forwards compatible(on my XP anyway), between the RegistryEditor v5.00 and the REGEDIT4 formats !
[edit: cleared up the a2u part]
Formerly Gringoloco
Windows XP Pro sp3 x32
Another remark....
For the PortableApps.com InstallerU, it didn't seem to be flawless...
In 'PortableApps.comInstaller.nsi', the '®' in:
Didn't get through right, so I had to convert this script to UTF-16 LE.
As well, some how I had to use all .nsh files from Unicode NSIS in the 'nsis\include' folder. Which are in UTF-16. And it fixed the issue with finding the portableapps path within the compiled installer!
Last issue, trying to recompile PAL I got some problems, but I have to wait till you do away with SimpleSC plugin, before I can be sure what's wrong !
Formerly Gringoloco
Windows XP Pro sp3 x32
I just committed changes in PAL which should make it work better with NSISu; services are disabled, and plug-ins are separated into Plugins\A and Plugins\U depending on whether NSIS_UNICODE is defined or not. If you update your checkout of the repository you might even find it works (you'll get three warnings due to services being disabled).
I just tested it and found a problem with my use of !searchparse to get the version from appinfo.ini...
For want of a better way to fix it (any ideas?) I put in
/noerrorsand fall back to 1.0.0.0.Still can't compile though, but I'll get to that. Shouldn't your language files be UTF-16LE? I'm getting lots of warnings like this:
The reason it's failing to compile though is that it's just getting things wrong. I have a
!ifmacrondef ${Segment}_${Hook}, and the compiler is evaluating both sides of the expression, both before and after the!else. And so it decides the macro Core_.onInit doesn't exist (!?), and yet it continues on and tries (and fails) to insert the macro. It's wacky. I'm giving up on it now before I get further confusedIt's possible that the fact I'm using Wine has some bearing on the issue. If Unicode NSIS doesn't work properly in Wine it's evil and will cause me no end of trouble.
(Wait, something just occurred to me; all the files I've created since running gVim in Ubuntu will be ff=unix rather than ff=dos and thus LF rather than CR LF; I'll try making them all dos and see if that does anything.)
Edit: getting somewhere. !searchreplace is going crazy, utterly ruining a string whether the file is latin1 or UTF-16LE (with BOM). Can't do anything until !searchreplace is fixed (and also it'd be good if !searchparse had worked in appinfo.ini, an ANSI file).
Jim Park: could you please help fix !searchreplace?
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
!searchreplace will be working if you remove the newlines out if the ini file ! No-matter it is ansi or utf-16, I think this problem is due to it being version 2.45 (but not sure anymore)
I will do testing for today, but I had the same errors on the segments, I had a feeling it was due to some plugins.
I will let you know!
About the languages, I can convert them and send them to you, but their is just no way I can check if japanese and chinese are done properly !
Formerly Gringoloco
Windows XP Pro sp3 x32
Your 'warnings' about the languages, they aren't really warnings. Unicode NSIS just tells you for every file if it did find a BOM, and on what way it will open the file. I even believe it internally converts it if it doesn't find a BOM, but just from utf-8 to utf-16. But anyway, here is an example folder with the PortableApps.comLauncher languages converted UTF-16, for when you want to implement them. Just they should be over looked by some Japanese/Chinese person !
And I've included an appinfo.ini file what works (for me anyway)
http://www.mediafire.com/?dfngdyiywyo
I'm also getting the error: 'macro named "Core_.onInit" not found!' For for both compilers !
That's new, didn't have that in Alpha 4
But, for Unicode NSIS compiling, I need to use 'UAC v0.0.11d' instead of 'UAC v0.2.2b'. Otherwise it fails before the 'Core_.onInit' error:
This last error is just really odd, are you using the UAC plugin for 'RefreshShellIcons.nsh' ???
I'm afraid I can't really help you for the script, cause for me it's just too complicated to follow the code.
Ps.: How do I download the files from the 'Mercurial repositories'. I ended up copy/pasting, but had to delete all the line-number by hand! (never want to do that again)
Formerly Gringoloco
Windows XP Pro sp3 x32
The problem with those weird characters is that !searchreplace is broken; it's nothing to do with the UAC plug-in
!searchparsegets something from a file. This isn't working with an ANSI file appinfo.ini; I suspect it's just not coping with multi-byte characters properly.!searchreplacedoes find/replace in a string. I tried taking it down to the simplest form replacing a in bc with d (clearly no matches) and it ends up with a badly broken string. Multi-byte character problems again, I suspect.As for updating the hg repo,
hg pulland thenhg up.I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
As per our discussion I created an FTP account for you and sent you the details. I also downloaded, uploaded and updated the links for your two main packages on this page, UNP and PAIU, so now they're direct links to downloads on gringoloco.portableapps.chrismorgan.info. Hope you can manage to upload other things there with your connection.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Not sure if someone already mentioned this, or if this is an otherwise known bug, but when using the unicode build of the installer, if there is an EULA.txt in the source folder, some things don't look correct when it is displayed to the user during the install process:
“Revo Uninstaller” -> �Revo Uninstaller�
USER’S -> USER�S
If EULA.txt is Ansi, I don't think it will show up right. So be sure it is set for Unicode. You can do this in Notepad++ Portable, for example.
Sometimes, the impossible can become possible, if you're awesome!
Forgot to mention: I did do that. Same results with ANSI and UTF-8.
EDIT: lol. I selected the wrong option, oops. I did "Encode in UTF-8" instead of "Convert to UTF-8."
EmbeddedLists plug-in is re-compiled for Unicode NSIS
I tested it with all the example files, no issues !
Note: The original, so also this, version apparently has a bug what will be fixed any time soon by AfroUK.
http://forums.winamp.com/showthread.php?t=311949
Formerly Gringoloco
Windows XP Pro sp3 x32
Nice! That's awesome news. I'll get working on incorporating it.
Once bug... Disabling sort by columns in options doesn't work. The columns are always click-sortable if you have sort enabled by one of the columns. This bug is present in the original Ansi version as well. Any idea where the author accepts bugs?
Sometimes, the impossible can become possible, if you're awesome!
There doesn't seem to be a dedicated forum topic for this specific plugin !
Probably it's best to comment to the same (recent) forum topic I linked to just above.
Formerly Gringoloco
Windows XP Pro sp3 x32
Is it possible to delay the time out longer in the paf installer for this, I missed my firewall warning asking me to allow the download which caused the first install to abort, after I allowed the second attempt at install worked without a hitch? Just a thought
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
It's in the plug-in used by the PortableApps.com Installer. It can't handle things like that at all.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I found that adding /TIMEOUT=20000 to the inetc call in my installer gave users enough time to respond to firewall prompts.
There is a 2.46 Unicode NSIS RC1 that's been released for testing. It looks pretty good and it might stand as is for 2.46 but I wanted to make sure PortableApps works fine with the release first. Can someone take a quick look to make sure it's okay?
http://code.google.com/p/unsis/downloads/list
I'll give it a workout with some launchers and installers within a few hours.
Do you know offhand if this fixes the !searchparse issue that Chris Morgan was having?
Sometimes, the impossible can become possible, if you're awesome!
Details of the !searchparse issue: reading from files with blank lines (such as our appinfo.ini files) failed. There was also an issue with !searchreplace being completely broken due I believe to a multibyte-offset problem. I don't have time to test these today but if no-one's reported about it I'll try to check them tomorrow or Saturday.
I managed to work around using !searchreplace completely fairly easily, and replaced !searchparse by the Generator, using ReadINIStr and then passing it with /D. So neither of these issues affect us any more with the Launcher. (But they'd still be good fixed.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I just remembered another problem I've found with Unicode NSIS Portable. It's to do with how its components find itself.
The strange thing with this issue is that it only affects it when running from my Command Prompt Portable installation. (I tried removing the relevant doskey macros, no change. I haven't dug as deeply as I could though.) Running it from PAP it works, running it from cmd works, but running it from cmd via PAP with my startup script it's hopelessly broken... (I've never had any such issues with NSIS Portable). And I did try completely removing NSISu and starting fresh.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Update with the new registry plug-in.
Personally I'm experiencing a problem with a secondary portable instance of Unicode NSIS Portable, which leaves HKCU\Software\NSIS behind.
Please let me know if you experience the same !
Formerly Gringoloco
Windows XP Pro sp3 x32
Why exactly is NSISu using an online installer?
No particular reason, besides it's easier for me to upload and initially I done it to test the downloading & extracting of the unicode installer !
Formerly Gringoloco
Windows XP Pro sp3 x32
So when it's officially released, it'll be included with the installer?
Yes, I would think so !
Any change in confirming the HKCU\Software\NSIS registry being left behind on a secondary portable instance ?
Formerly Gringoloco
Windows XP Pro sp3 x32
Nope, sorry. =\
I will look into the problem with !searchreplace. I'm looking at the code and I think I know where the bug is. I'll make sure this issue is resolved before 2.46 is released.
If you see anything else, please submit an issue or e-mail me.
Thanks for this Jim. We're not using it anymore, but I'm sure someone is somewhere.
Also, do you have any sense of an ETA on this now? We're gonna be switching over our launchers, installers, utilities, updater, etc to Unicode NSIS this week and I was wondering which version we should be targeting. I'm tempted to use the RC for now, honestly, if we have no issues with it.
Sometimes, the impossible can become possible, if you're awesome!
Well, I just released RC2 thinking you guys might still need it. It's been pretty quiet as far as bug reports go so I'll wait for you guys to do some cursory testing before I do a 2.46 release. If no changes are needed, 2.46 RC2 might just be renamed to the final release. But I would suggest that RC2 be used instead of RC1.
Pages