Old 9th March 2012, 18:36   #1
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Exclamation 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:
Quote:
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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 9th March 2012, 19:50   #2
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
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.
MSG is offline   Reply With Quote
Old 9th March 2012, 20:06   #3
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
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


Quote:
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...


Quote:
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:
Quote:
<true | false | auto (default) >
Where auto uses unicode if the main .nsi has a BOM

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 9th March 2012, 20:23   #4
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
Quote:
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.)

Quote:
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.
MSG is offline   Reply With Quote
Old 10th March 2012, 05:10   #5
redxii
Senior Member
 
Join Date: Nov 2005
Posts: 115
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.
redxii is offline   Reply With Quote
Old 10th March 2012, 06:57   #6
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
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.
MSG is offline   Reply With Quote
Old 10th March 2012, 11:56   #7
Yathosho
Forum King
 
Yathosho's Avatar
 
Join Date: Jan 2002
Location: AT-DE
Posts: 3,366
Quote:
Originally Posted by Anders View Post
IMHO true/false is better than on/off
better yes, but inconsistent with previous syntax
Yathosho is offline   Reply With Quote
Old 10th March 2012, 18:07   #8
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 10th March 2012, 18:09   #9
Pawel
Moderator
 
Pawel's Avatar
 
Join Date: Aug 2004
Location: Poland
Posts: 525
Send a message via ICQ to Pawel
I think this is good: <true | false | auto (default) >
Pawel is offline   Reply With Quote
Old 10th March 2012, 22:42   #10
demiller9
Senior Member
 
Join Date: Mar 2006
Location: Dallas
Posts: 462
Quote:
The SetXYZ pattern should only be used by flags that can be changed at runtime
I think SetEncoding sounds better than Unicode <true|false|...> .
demiller9 is offline   Reply With Quote
Old 11th March 2012, 07:35   #11
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
Quote:
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
MSG is offline   Reply With Quote
Old 11th March 2012, 16:34   #12
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 11th March 2012, 17:52   #13
Afrow UK
Moderator
 
Afrow UK's Avatar
 
Join Date: Nov 2002
Location: Surrey, England
Posts: 8,434
How about UnicodeInstall.

Stu
Afrow UK is offline   Reply With Quote
Old 11th March 2012, 18:55   #14
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
Originally Posted by Afrow UK View Post
How about UnicodeInstall.
Will this not be confusing? What about the uninstaller?

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 11th March 2012, 20:24   #15
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
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
MSG is offline   Reply With Quote
Old 11th March 2012, 21:50   #16
LoRd_MuldeR
Major Dude
 
LoRd_MuldeR's Avatar
 
Join Date: Sep 2005
Location: Somewhere over the Slaughterhouse
Posts: 797
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 )

My Plugins: StdUtils | NSISList | CPUFeatures | ExecTimeout | KillProc
My source of inspiration: http://youtu.be/lCwY4_0W1YI
LoRd_MuldeR is offline   Reply With Quote
Old 11th March 2012, 23:11   #17
Yathosho
Forum King
 
Yathosho's Avatar
 
Join Date: Jan 2002
Location: AT-DE
Posts: 3,366
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)
Yathosho is offline   Reply With Quote
Old 12th March 2012, 01:45   #18
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Lightbulb

Quote:
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)

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 12th March 2012, 02:45   #19
LoRd_MuldeR
Major Dude
 
LoRd_MuldeR's Avatar
 
Join Date: Sep 2005
Location: Somewhere over the Slaughterhouse
Posts: 797
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...

My Plugins: StdUtils | NSISList | CPUFeatures | ExecTimeout | KillProc
My source of inspiration: http://youtu.be/lCwY4_0W1YI
LoRd_MuldeR is offline   Reply With Quote
Old 12th March 2012, 03:51   #20
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 12th March 2012, 03:53   #21
redxii
Senior Member
 
Join Date: Nov 2005
Posts: 115
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.
redxii is offline   Reply With Quote
Old 12th March 2012, 18:08   #22
Pawel
Moderator
 
Pawel's Avatar
 
Join Date: Aug 2004
Location: Poland
Posts: 525
Send a message via ICQ to Pawel
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.
Pawel is offline   Reply With Quote
Old 12th March 2012, 19:04   #23
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 12th March 2012, 19:11   #24
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
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
DrO is offline   Reply With Quote
Old 12th March 2012, 22:12   #25
Koopa
16-Bit Moderator
 
Koopa's Avatar
 
Join Date: Apr 2004
Posts: 4,341
Quote:
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.
Koopa is offline   Reply With Quote
Old 12th March 2012, 22:21   #26
Pawel
Moderator
 
Pawel's Avatar
 
Join Date: Aug 2004
Location: Poland
Posts: 525
Send a message via ICQ to Pawel
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).
Pawel is offline   Reply With Quote
Old 12th March 2012, 22:28   #27
LoRd_MuldeR
Major Dude
 
LoRd_MuldeR's Avatar
 
Join Date: Sep 2005
Location: Somewhere over the Slaughterhouse
Posts: 797
Quote:
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 ^^

My Plugins: StdUtils | NSISList | CPUFeatures | ExecTimeout | KillProc
My source of inspiration: http://youtu.be/lCwY4_0W1YI
LoRd_MuldeR is offline   Reply With Quote
Old 1st June 2012, 06:48   #28
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Thumbs down

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.

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


so
PHP Code:
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)

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 1st June 2012, 09:30   #29
MSG
Major Dude
 
Join Date: Oct 2006
Posts: 1,892
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.
MSG is offline   Reply With Quote
Old 8th June 2012, 15:19   #30
Damian Kohlfeld
Junior Member
 
Join Date: Jun 2012
Posts: 1
Smile 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,
Damian Kohlfeld is offline   Reply With Quote
Old 8th June 2012, 17:09   #31
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
Originally Posted by Damian Kohlfeld View Post
As far as unicode, yes yes yes. But, support win2k, perhaps in a separate branch, whatever.
The 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...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 22nd June 2012, 16:21   #32
JamesB7
Junior Member
 
Join Date: Jun 2012
Posts: 4
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.
JamesB7 is offline   Reply With Quote
Old 22nd June 2012, 16:35   #33
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
Originally Posted by JamesB7 View Post
Please don't break compatibility with Windows 9X.
We will break 9x compatibility...for makensis.exe (because this thread really is about the compiler). It will be Win2000+ probably.

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 22nd June 2012, 16:41   #34
JamesB7
Junior Member
 
Join Date: Jun 2012
Posts: 4
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.
JamesB7 is offline   Reply With Quote
Old 22nd June 2012, 19:18   #35
Yathosho
Forum King
 
Yathosho's Avatar
 
Join Date: Jan 2002
Location: AT-DE
Posts: 3,366
btw, would be interesting to get some insights on the usage stats. do you run any sort of analytics software on the nsis website?
Yathosho is offline   Reply With Quote
Old 22nd June 2012, 19:45   #36
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,321
Quote:
Originally Posted by Yathosho View Post
btw, would be interesting to get some insights on the usage stats. do you run any sort of analytics software on the nsis website?
Stats of what? The admins have access to Piwik. There are public download and commit stats on SF...

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Developer Center > NSIS Discussion

Tags
unicode

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