Archive: Unicode: Replace TargetMinimalOS with?
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.
Simpler is often better, so Unicode sounds good to me.
http://nsis.sourceforge.net/Docs/Chapter4.html#4.8
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 MSGIMHO true/false is better than on/off
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.
Originally posted by MSGNo, this is a A vs W API thing, there will never be more options. Unless you mean auto...
But should there be only two options? Are there perhaps situations where a third option would be helpful/necessary?
Originally posted by MSGI thought you wanted UTF8 files without BOM to be treated as UTF8 and not backwards compatible with older ansi scripts?
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.
<true | false | auto (default) >Where auto uses unicode if the main .nsi has a BOM
Originally posted by AndersYeah, something like an auto mode. Your true/false/auto suggestion seems to cover it all.
No, this is a A vs W API thing, there will never be more options. Unless you mean auto...
Originally posted by AndersI was thinking about ansi scripts. UTF8 without BOM should definitely be compiled as unicode by default.
I thought you wanted UTF8 files without BOM to be treated as UTF8 and not backwards compatible with older ansi scripts?
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 Andersbetter yes, but inconsistent with previous syntax
IMHO true/false is better than on/off
Originally posted by redxiiThe SetXYZ pattern should only be used by flags that can be changed at runtime. I'm also not sure if "Encoding" is specific enough...
SetEncoding < ansi (default) | unicode >
I think this is good: <true | false | auto (default) >
The SetXYZ pattern should only be used by flags that can be changed at runtimeI think SetEncoding sounds better than Unicode <true|false|...> .
Originally posted by AndersThat's not how it's been done in the past, though: http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.4
The SetXYZ pattern should only be used by flags that can be changed at runtime.`
Originally posted by MSGThat is true, but those instructions are really old and we cannot change them now...
That's not how it's been done in the past, though: http://nsis.sourceforge.net/Docs/Chapter4.html#4.8.2.4
How about UnicodeInstall.
Stu
Originally posted by Afrow UKWill this not be confusing? What about the uninstaller?
How about UnicodeInstall.
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 :cry:)
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_MuldeRWe 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)
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...
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_MuldeRThe 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)
...and we wouldn't have to stick with an outdated compiler (e.g. VC 6) for the stubs.
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 PawelThe code in SVN already produces ansi and unicode stubs and plugins when you build, there is no extra work that needs to be done...
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.
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.
Originally posted by Pawel+1
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.
Wow, Koopa, you just wrote it so clearly and nice :D
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 KoopaThere 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 ^^
+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.
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> [...]
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)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,
Originally posted by Damian KohlfeldThe exehead stubs are already using TCHAR and the minimum target is NT4 or 2000, the hold up is the compiler, not the code running on the end-users system...
As far as unicode, yes yes yes. But, support win2k, perhaps in a separate branch, whatever.
I like your original suggestion "Unicode yes/no".
Unicode support wouldn't hurt for software that requires an NT OS, though I have to admit I haven't felt a great need for the feature. From my perspective, built-in timestamp+code sign for installer/uninstaller would be handier. I do it with conditionals and a batch file presently...
Please don't break compatibility with Windows 9X.
If you already have the code there, there is no technical reason.
It'd require me to keep two versions of NSIS. Older software still needs patches/support, and honestly, any decent developer should make their software run on the widest range of Windows versions compatible with their economics. Don't force my users to upgrade for an installer's sake of all things. Even new software, if it doesn't *need* a recent OS feature, why *choose to fail*?
For those talking about "even Win2K doesn't work in VS2010", Google EncodePointer Win2K and see for yourself how trivial the fix is.
I'd encourage you to ignore those with an upgrade fetish.
Lastly, Damien, for .NET... My Mono 2.10.8 install, it doesn't seem to have an EncodePointer dependency so probably runs on Windows 2000. Mono for Windows works quite well and lacks the conflicts of interest that cause .NET's minimum OS to keep going up and up. You can fit the necessary runtime for a WinForms application in about 4MB compressed, and won't even need admin access as the executables are relocatable and do not use registry entries.
Originally posted by JamesB7We will break 9x compatibility...for makensis.exe (because this thread really is about the compiler). It will be Win2000+ probably.
Please don't break compatibility with Windows 9X.
Oh ok, my bad, I'd thought you were discussing the resulting executables. :)
On the compiler side, yeah, seems unlikely anyone is still *developing* from a 9X machine.
btw, would be interesting to get some insights on the usage stats. do you run any sort of analytics software on the nsis website?
Originally posted by YathoshoStats of what? The admins have access to Piwik. There are public download and commit stats on SF...
btw, would be interesting to get some insights on the usage stats. do you run any sort of analytics software on the nsis website?