Unicode: Replace TargetMinimalOS with?

It has been decided that TargetMinimalOS is not going to be implemented at this time so we need a (new) instruction to toggle the creation of unicode installers.

My suggestion is just:

Unicode < yes (default) | no >

Post your alternative instructions/syntax suggestions and we will vote on the final syntax if required.

Thoughts and comments are also welcome...

Simpler is often better, so Unicode sounds good to me.


Current installer attributes use true/false or on/off. I'd say on/off is most suitable here, because unicode is not a small addition such as AllowRootDirInstall (true/false). Rather, it compiles to a completely different executable.

But should there be only two options? Are there perhaps situations where a third option would be helpful/necessary?

As for the default value, if the nsi wasn't saved as UTF8 (or other unicode formats), I'm thinking it might make sense to auto-switch back to ansi building for backwards compatibility. In such a case, 'unicode on' could still be used to force unicode building.

Originally Posted by MSG View Post

Current installer attributes use true/false or on/off. I'd say on/off is most suitable here, because unicode is not a small addition such as AllowRootDirInstall (true/false). Rather, it compiles to a completely different executable.

IMHO true/false is better than on/off

Originally Posted by MSG View Post

But should there be only two options? Are there perhaps situations where a third option would be helpful/necessary?

No, this is a A vs W API thing, there will never be more options. Unless you mean auto...

Originally Posted by MSG View Post

As for the default value, if the nsi wasn't saved as UTF8 (or other unicode formats), I'm thinking it might make sense to auto-switch back to ansi building for backwards compatibility. In such a case, 'unicode on' could still be used to force unicode building.

I thought you wanted UTF8 files without BOM to be treated as UTF8 and not backwards compatible with older ansi scripts?


I guess the following syntax would be possible:

<true | false | auto (default) >

Where auto uses unicode if the main .nsi has a BOM

Originally Posted by Anders View Post

No, this is a A vs W API thing, there will never be more options. Unless you mean auto...

Yeah, something like an auto mode. Your true/false/auto suggestion seems to cover it all.
(Although there's no such thing as a semi-true boolean, so on/off/auto makes more sense to me than true/false/auto.)

Originally Posted by Anders View Post

I thought you wanted UTF8 files without BOM to be treated as UTF8 and not backwards compatible with older ansi scripts?

I was thinking about ansi scripts. UTF8 without BOM should definitely be compiled as unicode by default.

SetEncoding < ansi (default) | unicode >

I don't know if it handles/allows existing ansi plug-ins so they'll work in unicode, if there isn't maybe ansi should be default backward compatibility.

From chat:
- NSIS Unicode will be NSIS v3.0. This has some consequences for backwards compatibility and defaults.
- Distinguishing between ansi and UTF8 without BOM will probably not be coded any time soon. Again, consequences for defaults.

My opinion at this point:
If we can't easily recognize whether an nsi file saved as UTF-8 without BOM is intended for a unicode or an ansi installer, it seems we have two options: Either we default to ANSI for ascii/UTF8noBOM files and unicode for anything else, or we default to unicode across the whole line.

If that's the choice, given that this is for NSIS v3.0, I vote for making it unicode. I think the number of people coding for unicode installers will (eventually) be higher than the number of newbies recompiling ancient nsi scripts meant for NSIS 2. And anyone making new installers with NSIS 3 should know what the difference is and should simply supply the proper attribute Unicode Off in the script.

Originally Posted by Anders View Post

IMHO true/false is better than on/off

better yes, but inconsistent with previous syntax

Originally Posted by redxii View Post

SetEncoding < ansi (default) | unicode >

The SetXYZ pattern should only be used by flags that can be changed at runtime. I'm also not sure if "Encoding" is specific enough...

I think this is good: <true | false | auto (default) >

The SetXYZ pattern should only be used by flags that can be changed at runtime

I think SetEncoding sounds better than Unicode <true|false|...> .

Originally Posted by Anders View Post

The SetXYZ pattern should only be used by flags that can be changed at runtime.`

That's not how it's been done in the past, though: http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.4

Originally Posted by MSG View Post

That's not how it's been done in the past, though: http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.4

That is true, but those instructions are really old and we cannot change them now...

How about UnicodeInstall.

Stu

Originally Posted by Afrow UK View Post

How about UnicodeInstall.

Will this not be confusing? What about the uninstaller?

I don't think it would be confusing. Aren't BrandingText, AutoCloseWindow, etc, also shared with the uninstaller? They're still called Installer attributes. In fact, it doesn't mention an uninstaller' even in the intro of chapter 4.8.1. http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.1

I don't see much reason to not use Unicode these days 🙂

Even good old Windows 2000 did support the Unicode Win32 API functions. But, as Windows 2000 isn't maintained anymore (and thus won't get any security fixes), using it nowadays is a severe security problem! Not to speak about even older Windows versions! Consequently we can assume 99.9% of all users are on Windows XP or newer these days. The remaining 0.1% is Windows 2000 maybe. So, if we really need a switch to disable "Unicode support", it should probably be called ForceWin9xCompatibility <true|false(default)> or something like that. And the manual should highly discourage its use (like "Use this only, if you really need Win9x compatibility!"). Or are there any other sane reasons, except Win9x compatibility, why anybody may want to disable Unicode support nowadays?

BTW: I don't know which compiler you use to create the NSIS stubs, but if you use MSVC2010, the binaries won't even run on Windows 2000. They certainly won't run on Win9x, which makes any compatibility options for Win9x pointless then. If you stick with MSVC2008, then Windows 2000 is still supported, but that one certainly doesn't need the No-Unicode workaround. I have no idea what the last MSVC was that still supported Win9x. But unless you plan to stick with that old MSVC forever, Win9x compatibility switches become pointless...

(The next MSVC won't even support Windows XP anymore 😢)

i agree with lord moulder and i think it's clear that a platform should only use the kind of software that was made to support it. that software can likely be installed already and in any other can use a nsis version that supports it. there's no need to support all of the platforms (like i haven't heard of nsis working on dec alpha)

Originally Posted by LoRd_MuldeR View Post

BTW: I don't know which compiler you use to create the NSIS stubs, but if you use MSVC2010, the binaries won't even run on Windows 2000. They certainly won't run on Win9x, which makes any compatibility options for Win9x pointless then. If you stick with MSVC2008, then Windows 2000 is still supported, but that one certainly doesn't need the No-Unicode workaround. I have no idea what the last MSVC was that still supported Win9x. But unless you plan to stick with that old MSVC forever, Win9x compatibility switches become pointless...

We support VC6+, MinGW and cross compiling on POSIX and VC6 is our preferred compiler but this thread has nothing to do with which compiler is used for the stubs, we simply need to figure out what the syntax in the .nsi should look like. (We will provide stubs and plugins for ansi and unicode)

Well, I think this is an important point that should be considered here. The one and only reason to add an option to disable Unicode support (once Unicode is supported in an official NSIS release) would be backward-compatibility to older OS' that didn't provide the required Unicode API. This would be the Windows 9x series then, I guess. But adding backward-compatibility options for an "old" OS to NSIS is completely pointless, if the compiler (the one used for the stubs) doesn't generate code compatibility with that "old" OS anyway. Consequently by dropping support for the Windows 9x platform, we could kill two birds with one stone: There would be no need for adding the "Unicode" compatibility option anymore and we wouldn't have to stick with an outdated compiler (e.g. VC 6) for the stubs.

And again: While support for Windows 9x is completely meaningless these days, even the need for Windows 2000 support is questionable. But if we decide that Windows 2000 should still be supported (which I think we should do!), then not Unicode support is the problem (Windows 2000 does support it just fine), but the lack of an up-to-date compiler that still supports this platform is the biggest problem...

Originally Posted by LoRd_MuldeR View Post

...and we wouldn't have to stick with an outdated compiler (e.g. VC 6) for the stubs.

The stubs (and most of the plugins) are written in plain C and don't use the CRT so what do you hope to gain by updating the compiler? (Not even VS11 has full C99 support) Not only do you gain nothing, MS are actually dropping support for some of the switches we use to generate smaller files (/OPT:NOWIN98, filealign etc)


I don't think we are ready to drop the ansi support just yet, this means we will need a keyword to toggle unicode. If you think ansi support is pointless, just save your files as UTF16LE and pretend that the other mode does not exist...

How much actively developed software distributed with NSIS even still support Win9x/NT4? What good is it that the installer still supports Win9x/NT4 when the market share is virtually nil along with the amount of active software that still support those platforms.

I guess that's a better idea. Drop ANSI/Win9x/NT4, go Unicode only. If you are still making software for Win9x/NT4 you can stick with the latest 2.x.

I would say, there should be NSIS 3.0 that supports only Windows XP+, fully Unicode.
And I agree with above posts. Drop ANSI/Win9x/NT4 support. Leave it in NSIS 2.4x line.
But, if this is not possible, making ANSI and Unicode in one package is not bad idea... but I think it need much more work.

Originally Posted by Pawel View Post

But, if this is not possible, making ANSI and Unicode in one package is not bad idea... but I think it need much more work.

The code in SVN already produces ansi and unicode stubs and plugins when you build, there is no extra work that needs to be done...

Unicode true | false | auto (default)

that's what i'd prefer to see as it seems to best cover what would appear in compiles attempted be if from those who have remained using the official release or moved over to the unicode release.

i know there's all this talk about ansi being pointless, but i still think it has it's place for things like specific internal installers or even uber simple ones or those that must rely on older plug-ins for specific features to work. yes i know someone is going to bring up the paths issue but it's no more different than what was the case in the years before the unicode fork appeared and things generally worked ok then anyway (am sure i'll be pointed at something if that is wrong).

yes i know that unicode is the way and i'm not disagreeing with that at all but it still seems reasonable to support things as can and if people are willing to work on it then it's their time that they're spending on it so what does it really matter?

and really, all i want to see is a consistent official release without some of the hacks and fragmentation which has been caused by the unicode fork.

-daz

Originally Posted by Pawel View Post

I would say, there should be NSIS 3.0 that supports only Windows XP+, fully Unicode.
And I agree with above posts. Drop ANSI/Win9x/NT4 support. Leave it in NSIS 2.4x line.
But, if this is not possible, making ANSI and Unicode in one package is not bad idea... but I think it need much more work.

+1

I'd drop ANSI in 3.0 as well, as I'd drop support for operating systems < XP.
Win 2000 doesn't get any security related update anymore and for those people, who still depend on these systems, you still provide 2.4x related updates for some time. I guess all agree, that the whole Win9x line isn't worth to be mentioned anymore..

Unicode is the future, ANSI simply the past, but I'd may agree with an ANSI/Unicode hybrid package, because it will take some time, until the majority of the NSIS plugins are available as Unicode version unless you find another way to make those plugins available in Unicode NSIS.

Wow, Koopa, you just wrote it so clearly and nice 😁
I hope Anders and other NSIS magicians will make NSIS alive soon. This is my favourite
software.

Btw, Anders, if you need any help I am ready (not necessarily with programming, but help system, graphics is what I can do).

Originally Posted by Koopa View Post

+1

I'd drop ANSI in 3.0 as well, as I'd drop support for operating systems < XP.
Win 2000 doesn't get any security related update anymore and for those people, who still depend on these systems, you still provide 2.4x related updates for some time. I guess all agree, that the whole Win9x line isn't worth to be mentioned anymore..

Unicode is the future, ANSI simply the past, but I'd may agree with an ANSI/Unicode hybrid package, because it will take some time, until the majority of the NSIS plugins are available as Unicode version unless you find another way to make those plugins available in Unicode NSIS.

There is not much reason to drop NSIS support for Windows 2000 yet. If your software doesn't run on Windows 2000, it's MUCH better to have your installer exit cleanly with a "Sorry, this software doesn't run on Windows 2000" than having it crash/fail with a "Not a valid Win32 executable!" And yes, some people are still using Windows 2000. Also keep in mind that Unicode is supported on Windows 2000 just fine. It's Windows 9x (and maybe NT 4.0) that didn't support Unicode! So, in my opinion, we should drop ANSI support in NSIS 3.0 along with any Windows 9x support, but keep the Windows 2000 support for now. If there was a reason to drop Windows 2000, then this would be compiler incompatibility. But Anders said that they currently prefer VC6, so this doesn't seem to be an issue ^^

Somebody is working on a x64 fork, this means we would need a setting to control that as well. I'm not sure if it is a good idea but I'll throw it out there anyway; a general "target" property.

Target <x86|amd64|ansi|unicode> [...]

so

Target ansi = Similar to 2.46
Target unicode == Target x86 unicode
Target amd64 == Target unicode amd64 

("Target amd64 ansi" is not a valid combination, x64 will always be unicode)

Possible problems:
*"Unicode auto" mode would probably not be supported because I don't know how the syntax for that would look
*.nsi files would be harder to parse (Not for makensis but for external things like batch files etc)

Afrow's UnicodeInstall attribute comes to mind again. UnicodeInstall and x64Install? Using the latter would then automatically mean unicodeinstall is enabled. This would also prevent the use of an illegal x64/ansi combination.

win2k and version number

Definitely release a new version, and soon. So many people think this project is dead weight. A lot of other installer projects popping up, a new version like a 3.0, etc would bolster this project in a major way and would really help to sway developers looking to get away from the typical garbage. I almost didn't go NSIS when I saw 2009 as the last revision. Now, I've very glad to be here.

As far as unicode, yes yes yes. But, support win2k, perhaps in a separate branch, whatever. Most Microsoft developers are .NET now and .NET 2.0 runs on win2k. That is actually a REALLY big deal. I have several customers who are running my code on some ancient win2k servers which are virtual machines. So, I'm still building against the 2.0sp1 framework all day long. Which is a major shame because I've never touched LINQ yet, but, I love what I'm seeing. The final straw for me will be the Parallel MultiCore featureset in 4.5. Now, with 8 core AMD's, I cannot handle the limited multicore support in .net 2.0, so I'm ready for a jump, and a version jump in NSIS would be awesome to go along with my jump from .Net 2...

Unicode is going to also bring on a bunch of newb's because unicode demand is really strong now, almost everything I do now is unicode only.

I say if you can make it run on win2k, great, if not, make the min winxp, and setup a branch for win2k and earlier. Then the community of people writing for 98, ME, etc can provide the support to handle bug fixes, etc, on the 98/me possibly win2k branch.

Sorry for the long winded post, writing a lot of ASM today all NASM, 64bit, dreading it, only know 32bit, anyway, thanks,