Old 5th August 2015, 01:21   #1
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
Lightbulb 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.

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 5th August 2015, 01:41   #2
JasonFriday13
Major Dude
 
JasonFriday13's Avatar
 
Join Date: May 2005
Location: New Zealand
Posts: 878
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).

"Only a MouseHelmet will save you from a MouseTrap" -Jason Ross (Me)
NSIS 3 POSIX Ninja
Wiki Profile
JasonFriday13 is offline   Reply With Quote
Old 22nd August 2015, 15:30   #3
parasoul
Senior Member
 
Join Date: Aug 2007
Posts: 117
Great.
Where can we find more information about "!appendfile /RawNL switch" ?
parasoul is offline   Reply With Quote
Old 22nd August 2015, 19:53   #4
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
Quote:
Originally Posted by parasoul View Post
Where can we find more information about "!appendfile /RawNL switch" ?
The documentation?

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 26th October 2015, 00:03   #5
aerDNA
Senior Member
 
aerDNA's Avatar
 
Join Date: Feb 2007
Location: Rijeka, Croatia
Posts: 225
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.
Attached Files
File Type: nsi Bug_FileReadUTF16LE.nsi (745 Bytes, 86 views)

PostEnd:
aerDNA is offline   Reply With Quote
Old 26th October 2015, 01:16   #6
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
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.

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 26th October 2015, 11:04   #7
aerDNA
Senior Member
 
aerDNA's Avatar
 
Join Date: Feb 2007
Location: Rijeka, Croatia
Posts: 225
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.

PostEnd:
aerDNA is offline   Reply With Quote
Old 26th October 2015, 15:24   #8
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
Quote:
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.

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 26th October 2015, 19:59   #9
aerDNA
Senior Member
 
aerDNA's Avatar
 
Join Date: Feb 2007
Location: Rijeka, Croatia
Posts: 225
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).

PostEnd:
aerDNA is offline   Reply With Quote
Old 26th October 2015, 22:38   #10
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
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)

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

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 27th October 2015, 00:54   #11
aerDNA
Senior Member
 
aerDNA's Avatar
 
Join Date: Feb 2007
Location: Rijeka, Croatia
Posts: 225
"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.

PostEnd:
aerDNA is offline   Reply With Quote
Old 15th December 2015, 15:14   #12
Kriggi
Junior Member
 
Join Date: Dec 2015
Posts: 9
Hi! (Sorry, English translation - Google)

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

PHP Code:
!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 
$$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.
Kriggi is offline   Reply With Quote
Old 15th December 2015, 19:38   #13
Anders
Moderator
 
Anders's Avatar
 
Join Date: Jun 2002
Location: ${NSISDIR}
Posts: 5,142
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")'

IntOp $PostCount $PostCount + 1
Anders is offline   Reply With Quote
Old 16th December 2015, 16:12   #14
Kriggi
Junior Member
 
Join Date: Dec 2015
Posts: 9
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.
Kriggi is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Developer Center > NSIS Discussion

Tags
release

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