NSIS 3.0b2

Release notes

If you find any new issues, report them in this thread and/or on the SF bug tracker and please include compiler error messages and sample code if possible...

Known issues:

• [Fixed in trunk] MUI (v1) might display a warning when inserting MUI_LANGUAGE even when the page and language macros are in the correct order.

Awesome, I just happened to be online when this was released, I already have a copy installed on my machine. I'm still working on a linux port of zip2exe, it's mostly complete apart from an unzipping bug that only appears on certain zip files (zips with many files).

Great.
Where can we find more information about "!appendfile /RawNL switch" ?

Originally Posted by parasoul View Post

Where can we find more information about "!appendfile /RawNL switch" ?

The documentation?

I don't know if this has been reported but I found an issue with FileReadUTF16LE. While testing a script, WordFind macro kept failing on the first string read from UTF-16LE file. First line only, even if all lines were identical. When displayed in Msgbox/DetailPrint, strings are also identical but StrLen of the first one is 1 byte larger. Writing the strings to Ansi with FileWrite results in 0x3F prepended to the first line. Since it only happens on the first line it must have to do with not discarding the first 2 bytes (FFFE) that designate utf-16le. My temporary fix is to skip them with FileSeek before using FileReadUTF16LE. Script to reproduce the problem is attached.

Well, technically the BOM is a valid character but I agree that we might want to give it special treatment.

StrLen returns the number of code units (char or wchar_t) not bytes and not necessarily a count of what a human would call a character.

I mentioned StrLen because it was an indicator of where the problem lies. I definitely agree BOM should be given special treatment because FileRead is primarily intended for dealing with human text, that's why it reads until newline. When you use it to read from a .txt you're supposed to get a string that can be safely processed as plain text (+newline). Like I said, BOM currently breaks the much-used WordFind macro, probably others too. This can cause massive cockups in scripts relying on FileReadUTF16LE, especially since it is not documented.

Also, maybe you should consider modifying FileWriteUTF16LE so that it inserts a BOM if offset=0. Presently you can add lines to an existing file but you can't create a new standard-compliant file using solely FileWriteUTF16LE.

Originally Posted by aerDNA View Post

...especially since it is not documented.

The documentation is technically correct, the function reads UTF-16LE characters until it finds \r, \n or \0 or maxlen is reached.

You need to keep in mind that the BOM is actually Unicode Character 'ZERO WIDTH NO-BREAK SPACE' (U+FEFF) and is a legal character. It is not the only zero-width/invisible character so once you join the Unicode party you need to be prepared for files with invisible characters etc.

When special BOM handling is added it will be called out in the documentation.

You are technically correct about everything but I think users will tend to assume FileReadUTF16LE returns the same thing they see in text editor (or MessageBox or DetailPrint). Until special handling is implemented, it wouldn't hurt to add a note pointing out they need to handle BOM themselves (that's what I meant by undocumented).

Yes, it was clear that we had to do something about this but deciding on the behavior was not that easy.

I have now changed FileReadUTF16LE so that it will always skip the BOM at the start of a file. (If you need to detect the BOM you must use FileReadByte or FileReadWord.

FileWriteUTF16LE can now optionally add a BOM if you specify the /BOM switch. The thinking here was that not all apps can handle the BOM so you have to be specific about it. This is especially important if we decide to add UTF8 support as well since it is very common for *nix based tools to choke on the BOM.

This last issue is of course open for discussion while we are still in Beta but kichik and I have already spent all day discussing this and we came down on the side of no BOM by default vs BOM by default and a /NoBOM switch... (Inno Setup does not seem to support UTF16, the _wfopen MS CRT function wants a Unicode flag and finally "cmd.exe /U /C echo.Foo > Bar.txt" does not write a BOM)

Originally Posted by aerDNA View Post

You are technically correct about everything but I think users will tend to assume FileReadUTF16LE returns the same thing they see in text editor (or MessageBox or DetailPrint).

You cannot see the BOM because it has zero-width 🙂 , converting to Ansi however will fail and you get a '?'.

"You cannot see the BOM because it has zero-width" - It's what made the issue sneaky - string would seemingly be what you expect it to be but the code that processes it could mysteriously fail (if you did proper testing and realized it at all). Glad to see that's now taken care of, old behavior was asking for trouble.

Regarding FileWriteUTF16LE, I think as long as there's a switch now, it's no longer an issue. Weighing pros and cons of /BOM vs /NoBOM is not something I can contribute to, I trust your judgement, but either way, appropriate usage will be coders' responsibility and there won't be any justified complaints since it's documented.

Hi! (Sorry, English translation - Google)

I compiled from the source code NSIS v3.0b2 rev.6682 and builded the following script:

!define PRODUCT_NAME "My application"
SetCompressor lzma
!include "MUI.nsh"
 
!define MUI_CUSTOMFUNCTION_GUIINIT onGUIInit
 
!insertmacro MUI_PAGE_WELCOME
!insertmacro MUI_PAGE_DIRECTORY
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
 
!insertmacro MUI_LANGUAGE "English"
 
Name "SkinH"
OutFile "setup_SkinH.exe"
InstallDir "$PROGRAMFILES\My application"
 
Section
SectionEnd
 
Function onGUIInit
  InitPluginsDir
  SetOutPath $PLUGINSDIR
  File "${NSISDIR}\Plugins\x86-ansi\SkinH.dll"
  File skinh.she
  System::Call SkinH::SkinH_Attach()
 
#################### Patches for SkinSharp ####################
  System::Call Kernel32::GetModuleHandle(t"SkinH.dll")i.r0
  IntOp $0 $0 + 0x0002CA98
  System::Call Kernel32::GetCurrentProcess()i.s
  System::Call Kernel32::VirtualProtectEx(is,ir0,i4,i0x40,*i)
  System::Call "*$0(&i1 0)"
###############################################################
FunctionEnd
 
Function .onGUIEnd
; Delete plug-ins folder
  System::Call Kernel32::GetModuleHandle(t"SkinH.dll")i.s
  System::Call Kernel32::FreeLibrary(is)
  System::Call Kernel32::SetCurrentDirectory(t"$EXEDIR\")
FunctionEnd 

Unfortunately on OS Windows 64-bit installer does not start (crash).



On 32-bit operating system is functioning properly.

Downgrade NSIS revision and fulfilling its compilation I found that in the revision 6644 compiled script works fine on 64-bit OS. But in the revision 6645 and above - does not work. In the revision 6645 you have the following changes "bug # 1125: Does not load modules from the application nor current directory." As a result there was a problem.

Yes, there are some new limits on how dlls are loaded.

The crash is probably your fault, you never check the return value of GetModuleHandle and $0 is probably 0 because the dll is not loaded.

After extracting the dll you can try adding System::Call 'Kernel32::LoadLibrary(t"$PluginsDir\SkinH.dll")'

Yes, you are right. On 64-bit systems GetModuleHandle function now returns a value 0 instead of the handle DLL. For the script to work, we must first load the DLL using LoadLibrary. The issue resolved. 🙂

Thank you very much for your help, Anders.