Unicode

[jimpark]

That's too bad. Visual Studio 2011 is supposed to support std::atomics and a lot of the std threading library. I was looking forward to that. No XP support would effectively kill it for us also. We need to support WinXP. Time to write to Microsoft.

[mrjohn]

Originally Posted by LoRd_MuldeR

There has been a new Unicode NSIS release shortly:
http://code.google.com/p/unsis/downloads/list

Unicode Setup from this location is detected as Adware :

http://www.virustotal.com/file-scan/report.html?id=82b3056fbbcf76cc6e177a22f48d0f48aa46e769039495ca2651ac29aa5e8c0b-1317715970

[mrjohn]

This is Avira response :

Dear Sir or Madam,thank you for your email to Avira's virus lab.
Tracking number: INC00846451.

We received the following archive files:
File ID Filename Size (Byte) Result
26326890 suspect_FALSE.zip 1.69 MB OK

A listing of files contained inside archives alongside their results can be found below:
File ID Filename Size (Byte) Result
26326891 nsis-2.46.3-Unico...up.exe 1.71 MB MALWARE


Please find a detailed report concerning each individual sample below:
Filename Result
nsis-2.46.3-Unico...up.exe MALWARE

The file 'nsis-2.46.3-Unicode-setup.exe' has been determined to be 'MALWARE'.Our analysts named the threat ADWARE/Adware.Gen.This file is detected by a special detection routine from the engine module.
Please note that Avira's proactive heuristic detection module AHeAD detected this threat up front without the latest VDF update as: ADWARE/Adware.Gen.

[jimpark]

Originally Posted by mrjohn

Unicode Setup from this location is detected as Adware :

http://www.virustotal.com/file-scan/report.html?id=82b3056fbbcf76cc6e177a22f48d0f48aa46e769039495ca2651ac29aa5e8c0b-1317715970

I've checked the link and saw that they had listed nsis-2.46.3-Unicode-setup.zip which is not a name of any file I've uploaded. The MD5 digest it has listed do not match any file I've uploaded either. So I can only conclude that whatever file they've tested is not mine.

[LoRd_MuldeR]

I'd write a mail to virus_malware@avira.com in order to clearify that.

In my experience they are quite responsive...

[jimpark]

I wrote to avira and they verified that the Unicode NSIS files are showing as being clean.

[Zinthose]

Can we get a direct link? I can't find the download link on the site.
Можем ли мы получить прямую ссылку? Я не могу найти ссылку на скачивание на сайте.

[Yathosho]

Originally Posted by Zinthose

Can we get a direct link? I can't find the download link on the site.
Можем ли мы получить прямую ссылку? Я не могу найти ссылку на скачивание на сайте.

http://code.google.com/p/unsis/downloads/list

[Zinthose]

Originally Posted by Yathosho

http://code.google.com/p/unsis/downloads/list

.... OPPS....

I meant to post this in another topic... CURSE you multi-tabbed browsing!!

[Yathosho]

it seems obvious, but is that ANSI build fully compatible with the official nsis? just asking, cause i'd prefer to install it over my current installation and not in a seperate folder.

[jimpark]

Yes, the ANSI build should be a superset of the official NSIS build.

[fhkd]

Hello,

I compiled following Code with Unicode NSIS 2.46.3:

code:


!define File "program.exe"

OutFile "GetVersion.exe"



Function .onInit

 ## Get file version

 GetDllVersion "${File}" $R0 $R1

  IntOp $R2 $R0 / 0x00010000

  IntOp $R3 $R0 & 0x0000FFFF

  IntOp $R4 $R1 / 0x00010000

  IntOp $R5 $R1 & 0x0000FFFF

 StrCpy $R1 "$R2.$R3.$R4.$R5"



 ## Write it to a !define for use in main script

 FileOpen $R0 "DefineValues.txt" w

 FileWrite $R0 '!define PRODUCT_VERSION "$R1" $\n'

 FileClose $R0



 Abort

FunctionEnd



Section

SectionEnd

I get a GetVersion.exe, but if I try to start it from the Windows Explorer, I get the message

GetVersion.exe is not a valid Win32 application.

If I use NSIS 2.46, it works fine and I get DefinesValues.txt with the entry !define PRODUCT_VERSION ....

I know the post

Originally Posted by vcoder

This script work well on ANSI version of NSIS and failed on Unicode version: ...

I use Windows 7 64 bit, and other more complex Setup-Skript get compiled well with Unicode NSIS.

[LoRd_MuldeR]

I saw this once. Try to include at least one FILE in your installer. Can be any non-empty dummy file.

@jimpark: Any ideas?

[fhkd]

Originally Posted by LoRd_MuldeR

I saw this once. Try to include at least one FILE in your installer. Can be any non-empty dummy file.

@jimpark: Any ideas?

Thanks for the answer.

I tried first following solution:

code:


Section

!tempfile DUMMYFILE

!appendfile "${DUMMYFILE}" "${DUMMYFILE}"

File "${DUMMYFILE}"

!delfile "${DUMMYFILE}"

!undef DUMMYFILE

SectionEnd

It doesn't help, also the dummyfile was packed.

But after I tried

code:


Section

File "program.exe"

SectionEnd

it works, also it is not nice.

Thanks for the help!

[jimpark]

Interesting. I will look into it.

[fhkd]

Hello again!

While I tried to implement the solution with File "program.exe", I noticed the command !define /product_version in the NSIS User Manual.

Solutions like

Originally Posted by vcoder

OutFile "GetVersion.exe"

with GetDLLVersion or GetDLLVersionLocal are for getting the version from a file on the building machine as a compiler constant during compile time, I think.

With the command !define /product_version it's quite easier.

So I write a little NSIS header GetVersionLocal.nsh with the macros GetFileVersionLocal and GetProductVersionLocal.
Now I can get a constant with the version number without makeing a dummy setup.

code:


!insertmacro GetProductVersionLocal "$%windir%\system32\kernel32.dll" version

!echo "${version_0}.${version_1}.${version_2}.${version_3}"

!echo "${version}"

For a description see the header file.

[Yathosho]

when trying to compile a script on windows 2003 server, i get this error:

"The procedure entry point EncodePointer could not be located in the dynamic link library KERNEL32.dll"

some seconds later a second message pops up:

"Unable to initialize MakeNSIS. Please verify that makensis.exe is in the same directory as makensisw.exe"

(it is in the same directory)

[Afrow UK]

SP1 installed?

Minimum supported server
Windows Server 2008, Windows Server 2003 with SP1

Stu

[LoRd_MuldeR]

Originally Posted by Yathosho

when trying to compile a script on windows 2003 server, i get this error:

"The procedure entry point EncodePointer could not be located in the dynamic link library KERNEL32.dll"

some seconds later a second message pops up:

"Unable to initialize MakeNSIS. Please verify that makensis.exe is in the same directory as makensisw.exe"

(it is in the same directory)

Please see my post here:
http://forums.winamp.com/showpost.ph...&postcount=474

In short: Binaries compiled with VS2010 don't run on systems prior to WinXP with SP-2, unless countermeasures are taken.
(Probably not a big deal for MakeNSIS, which runs on developer machine only, but important for the EXE stubs)

[Yathosho]

Originally Posted by Afrow UK

Minimum supported server
Windows Server 2008, Windows Server 2003 with SP1

i wonder where you even found that, such things should be mentioned on the website. anyway, i'm only using win 2003 because i have no legit copy of windows xp. so there should be no troubles when using xp (sp3)?

[Afrow UK]

Originally Posted by Yathosho

i wonder where you even found that, such things should be mentioned on the website. anyway, i'm only using win 2003 because i have no legit copy of windows xp. so there should be no troubles when using xp (sp3)?

EncodePointer function's MSDN page.

Stu

[LoRd_MuldeR]

Originally Posted by Yathosho

i wonder where you even found that, such things should be mentioned on the website. anyway, i'm only using win 2003 because i have no legit copy of windows xp. so there should be no troubles when using xp (sp3)?

This is not a limitation of NSIS or Unicode NSIS in general. It's just a limitation of the Visual C++ 2010 CRT libraries. And, as jimpark switeched to VS2010 for his latest builds, these builds will now require Windows XP with SP-2 or later. To make it clear again: This only applies to MakeNSIS, not to the rersulting installer EXE. The created installer EXE even runs on Windows 2000...

(Just be sure you really use the latest Unicode NSIS. There was a version that is broken with Win2k!)

[Anders]

Stdin handling is broken:

code:
makensis - < Examples\example1.nsi

[Larsen]

@Jim: Thanks a lot for the unicode version! It made my supporting other languages in my installer a lot easier.

I didn´t read through all of the previous 13 pages: Is there already a date when unicode will be available in the vanilla NSIS version? I read something about MakeNSIS v2.50...

[MSG]

There is no date, nor is there any progress to speak of concerning the unicodification of NSIS trunk. If it will ever happen, it won't be any time soon.

[Larsen]

That´s a pity =(

[DrO]

as there's no proper focus on getting things done, different people want it to be done in different ways (i.e. some just want to go all unicode and leave at that, others want to sort out what is basically a final ansi version, etc etc) and there's no consensus on how it should be done which makes what MSG said pretty reasonable for there being no eta.

-daz

[Larsen]

What about branching? NSIS 3 would be unicode and NSIS 2 could still get bug fixes.

[DrO]

Originally Posted by DrO

as there's no proper focus on getting things done

that is the biggest issue. and branching won't help - in fact i think that it's gotten us into this mess to begin with as people are using the unofficial unicode version yet expect support for it, etc. doing another branch with all of the issues i mentioned is just going to be even more of a pain for everyone concerned, ignoring the fact of who is going to do it?

-daz

[Yathosho]

Originally Posted by DrO

as there's no proper focus on getting things done, different people want it to be done in different ways [...] there's no consensus on how it should be done

even open-source projects need decisions and people who make them. so why not let the community decide which direction nsis will go or who will be the decision-makers? that only leaves the question who should be able to vote.

[DrO]

i'm not disagreeing with that point and things can or should be decided on, it still requires people to do things and that seems to be the biggest issue with getting things actually put into place and moving.

hell i'd love to help out (like i did many years back) but this pesky thing known as work gets in the way.

no one is disagreeing that a proper unicode version needs to be done. but how that is to be done (which is more about the implementation than what the end user actually sees) is the biggest stopping point it seems. and with your point, no one is gong to be able to do that if there's no proper structure on who is in proper control of things.


between jim's version, the stuff wizou started to do, what anders has been doing, we've got 3 instances of things being all over the shop without any true focus, not quite doing things the same and just overall causing more confusion - look at the number of posts from people who cannot get plug-ins to work as they think this unicode one is official and don't know what is / isn't correct.


it's really just a big cockup when you look at it all overall which is more detrimental to the community in the long run it seems (going on what i've seen from people's posts over the last few years).

-daz

[Anders]

The major problem is that the unicode fork uses MS 2005+ CRT specific stuff and the official NSIS supports compiling (and building) on VC6, MinGW and POSIX. (The unicode fork is broken in certain places (scroll up to my previous post) since it just relies on the MS code to do all conversion for it) The current code also mixes WCHAR and wchar_t which is a major no-no on POSIX, on Windows they are both UTF16LE but wchar_t can be any type on other platforms...

Except for the UTF8 langfile support in the ANSI build, all the other stuff I have been doing is generic and should benefit both.

[LoRd_MuldeR]

@jimpark:

I am running into a little problem with latest Unicode NSIS (v2.46.4) release:

My code looks like this:

code:
!searchreplace PRODUCT_VERSION_DATE "${LAMEXP_DATE}" "-" "."

LAMEXP_DATE contains something like "2012-03-10"

The expected output in PRODUCT_VERSION_DATE is "2012.03.10" (right?), but I only get "2012."

Went back to Maknsis.exe from Unicode NSIS v2.46.3 release and the issue is gone.

Can you look into this? Thanks!

[georgik]

Hi!

I patched Python plugin for NSIS. Now it also supports Unicode NSIS.
Here is more information about that: http://georgik.sinusgear.com/2013/05...-unicode-nsis/

You can find projet at github - nsPythonUnicode

It was tested on Windows XP, Vista, 7, 8, 2003, 2008, 2012.

Happy Python coding with Unicode NSIS. ;-)

[MaGoth]

Hi all,
On the official website there is a new version NSIS 3.0a1 (Released July 14, 2013).
Do you plan to update to version Unicode NSIS?

[redxii]

3.0 has unicode support already.

[roytam1]

Unicode NSIS 2.46.5 fails with packhdr again?

code:
I:\>upx --best --force "C:\DOCUME~1\User\LOCALS~1\Temp\exehead.tmp" 

                       Ultimate Packer for eXecutables

                          Copyright (C) 1996 - 2013

UPX 3.09w       Markus Oberhumer, Laszlo Molnar & John Reiser   Feb 18th 2013



        File size         Ratio      Format      Name

   --------------------   ------   -----------   -----------

upx: C:\DOCUME~1\User\LOCALS~1\Temp\exehead.tmp: CantPackException: superfluous data between sections



Packed 1 file: 0 ok, 1 error.

[MaGoth]

Greetings,
Please tell me the right to write this code in the Unicode(v.2.46.5)?

PHP Code:

...
!define SND_ASYNC 1
!define SND_FILENAME 0x20000
!define SND_LOOP 8
!define SND_NAME "InstallTheme.wav"

  ReserveFile "${NSISDIR}\Plugins\system.dll"
  SetOutPath "$TEMP\${MOD_NAME_BASE} Installation2\bgi_ground"
  ReserveFile "${SND_NAME}"
  File "${SND_NAME}"  

System::Call 'Winmm::PlaySound(t"$TEMP\${MOD_NAME_BASE} Installation2\bgi_ground\${SND_NAME}", i0, i${SND_FILENAME}|${SND_ASYNC}|${SND_LOOP})'
... 


In general, as a whole, the issue is resolved related to their music, they automatically repeat, etc., in ANSI Nsis it works...


MfG MaGoth,

[Anders]

Originally Posted by MaGoth

Please tell me the right to write this code in the Unicode(v.2.46.5)?

Have you tried v3.0? It should work there.

I don't remember the details for the Unicode forks system plugin but it has problems when there are 3 versions of a function and PlaySound is one of these special 3 version exports. Try changing PlaySound to PlaySoundW and t to w.

[MaGoth]

Hi, Anders

Have you tried v3.0? It should work there.

I do not use this version.

I don't remember the details for the Unicode forks system plugin but it has problems when there are 3 versions of a function and PlaySound is one of these special 3 version exports. Try changing PlaySound to PlaySoundW and t to w.

The problem resolved, in my case it was necessary to swap quotation marks, ' ' inside..

Tnx,
MfG MaGoth,