I just came across some info about utf-16 Little-endian format, which is used by Winamp for it's settings files.
I found out that probably my launcher won't support any non latin text in the settings files, cause it would be 16 bit characters !
For now I had the launcher assume there would always be a null byte after each character !
Is there anybody who has more experience with utf-16 settings files ?
What will drive letters be like in other scripts as Latin ???
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
I'm really not sure about this; I've never come across such a file before in making things portable. It's possible that using Unicode NSIS would fix this; we plan on moving to Unicode NSIS some time but at the moment we're not ready to (it requires rewriting System::Call calls from A to W functions and the modification and recompilation of a couple of plugins, not sure of their current status with Unicode support).
At least you can always be sure that the drive letters will always be in the format /[A-Z]:/. It'd really get messy if they supported other scripts for the drive letter...
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
Hi. I'm the one responsible for the Unicode NSIS port. Most of the System calls work pretty well in both ANSI and Unicode if written with "TCHAR" in mind. Can I take a look at the System calls you are worried about? Also, which plugins are missing? Have you tried looking for the Unicode version lately? A lot of people have now released Unicode versions of their plugins for NSIS.
Hi Jim. Thanks for responding. I've been noticing more plugins that have been updated. We're actually debating the switch to NSIS Unicode for the PortableApps.com Installer, NSIS Portable (which we use for all our launchers) and our other tools that are NSIS-based (like the AppCompactor and Backup Utility).
I know we use ExecDOS, FindProcDLL, inetc, md5dll, MoreInfo, nsDialogs, nsisunz, registry and System plugins in our PortableApps.com Installer. In addition, we also use KillProcDLL, newadvsplash and textreplace in some of our other launchers. To that, our updater adds in EnumINI, time and EmbeddedLists plugins.
So, yeah, quite the lists. If they were all available right now and ready today, I think I'd release a test and start the process for basically everything as we're itching to better support Unicode languages.
Feel free to contact me directly (via the developer contact on this site) if I can be of any assistance or if you can offer any direct advice for us.
Sometimes, the impossible can become possible, if you're awesome!
I wasn't aware of you adding setenv in for the updater; why? In the launcher, I finally got tired of the System::Call (and also people always have ".r0" on the end which is pointless, whenever I do it I do ".n" which means that it doesn't bother setting $0 to the return value, 1 I believe) and so I just did a simple macro and define:
!macro SetEnvironmentVariable _VARIABLE_NAME _VARIABLE_CONTENTS System::Call 'Kernel32::SetEnvironmentVariableA(t, t) i("${_VARIABLE_NAME}", "${_VARIABLE_CONTENTS}").n' !macroend !define SetEnvironmentVariable "!insertmacro SetEnvironmentVariable"In my opinion a plugin is just extra dead weight and slowness.
This should also work straight off with SetEnvironmentVariableW instead of SetEnvironmentVariableA. (Is there some !if check you can do to check if you're using Unicode NSIS? Then you could make it support either just with a !warning for the ANSI version when we're all ready with Unicode.)
The only other System call currently used in the upcoming universal launcher so far is
kernel32::CreateMutexA(i 0, i 0, t "$NAME") i .r1 ?e(again, A->W should be fine).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 was looking at the old version. The new one doesn't use it anymore. I changed the post.
Sometimes, the impossible can become possible, if you're awesome!
I've dealt with this in Sandboxie's INI file. Here's what you need:
http://nsis.sourceforge.net/Unicode_FileRead
But the description in your link notes the following.
Anyway, I made (am making) some changes to my script and tested it with settings files containing Cyrillic file names !
All seems to work better now.
Formerly Gringoloco
Windows XP Pro sp3 x32
When he says "multi byte", he means a different form of unicode. Regular Unicode always has 2 bytes per character. There's another encoding called MBCS (multi byte character set) that can have 1 or 2 bytes per character. But since you stated Unicode 16 LE, this function should work for you.
drive letters ?
As well, still I will have to do some additional testing on the m3u8 files, which are said to be unicode as well. (but using 1 byte per character ?)
Do you have experience with the Unicode (make)NSIS edition ?
Formerly Gringoloco
Windows XP Pro sp3 x32
Nope.
Another option though is the NSIS unicode plugin which can convert text files between all unicode types and ansi. So you could convert your file to ansi, do whatever, and convert it back again.
http://nsis.sourceforge.net/Unicode_plug-in
This plugin does work for some things. I do use it in at least one launcher at the moment (can't recall which offhand).
Sometimes, the impossible can become possible, if you're awesome!