NSIS 3.0b1

[Anders]

NSIS 3.0b1 is released with lots of build fixes, revival of nightly builds, automatic execution of our test suite along with the nightly build to make sure releases are always up to snuff, and lots of patches from our loyal users.

• 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...

Fixed in trunk:

• MakeNsisW truncates half the log when saving it to a file

Known issues:

• The !define /date NSISV %${NSIS_VERSION} trick is broken in 3.0, use NSIS_PACKEDVERSION.

[jweinraub]

I been using the latest nsis2 for the longest time, but had to replace makensis from the nsis-2.46-strlen_8192.zip file found elsewhere within the forums. I had issues when I updated the path environment variable it cropped it and just pushed my path and erased the rest. Since the latest dells these days give you so much crap the limit of the string is a concern.

So, is the latest beta have this issue resolved. The release notes were ambiguous on strlen issues as the one mentioned I didn't know if it applied to me or not.

thanks

[Anders]

I don't think the string limit changed in v3. Updating %path% is still dangerous and should be avoided IMHO...

[jweinraub]

anders,
i use the updatepath plugin found in the wiki. what makes it dangerous? do you propose an alternate solution that is less dangerous? if the strlen hasn't been changed, and if i need to use it still, is it recommended i stay with the previous version of nsis compiler?

[Anders]

Originally Posted by jweinraub

anders,
i use the updatepath plugin found in the wiki. what makes it dangerous? do you propose an alternate solution that is less dangerous? if the strlen hasn't been changed, and if i need to use it still, is it recommended i stay with the previous version of nsis compiler?

I cannot find this updatepath plugin. StrLen can not be used because the maximum %path% length is longer than the NSIS maximum string length, this is a problem in all NSIS versions. The only way around it would be a plugin that allows you to add/remove a single path element without ever having to process the full path string with native NSIS instructions...

[jweinraub]

It was AddToPath, it was a while ago it may been deappreciated already.
Call AddToPath was how it was used. My clean machine I use for building is off right now but I can't recall how it worked. I was included as an nsh file. do you know what that replacement makensis.exe did? i forgot where i found it originally i probably googled for it or someone told me about it elsewhere in the forums.

The software that is being installed has functionality that is installed within its own directory that doesnt get copied into sys32 so it needs to have its own directory in the path.

i see the current path manipulation page has a red warning.

[JasonFriday13]

http://nsis.sourceforge.net/Path_Manipulation

Judging from the history it's quite an old page. Anders actually added that warning in February 2014.

[jweinraub]

That being said, is there any modern way to add the program's path into the environmental path? What is the safe way of doing so? I think these scripts just holds the new path into a variable, and then copies itself with the new variable ( foo += bar) rather than pushing it onto the stack foo.push(bar) or something? I haven't looked at that part in ages and now I am getting nervous with a major release version coming out soon.

[Anders]

Why do you need to be in %path%? It is a limited resource and I personally don't like it when apps add themselves there. It is possible to customize it on a per .exe basis in "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths" but the better solution IMHO is just to fix the app (unless we are talking java?, in that case, use a launcher).

A plugin would be required to do it safely from NSIS...

[Pawel]

@Anders
Please check this strange behavior of NSIS 3.0b1. When you try to save log text it is cutted (not all text is saved).

Run MakeNSISW. Choose File -> Save Output
You will see that NSIS saved this:

Usage:

- File | Load Script...
- Drag the .nsi file into this

instead of this

Usage:

- File | Load Script...
- Drag the .nsi file into this window
- Right click the .nsi file and choose "Compile NSIS Script"

The same when you compile some script with more output... Log text is cutted... To small buffer or something...

-Pawel

[Anders]

Originally Posted by Pawel

When you try to save log text it is cutted (not all text is saved).

Thanks for reporting this.

This bug has probably been there since the Unicode merge. It called WriteFile with the character count and not the byte size. The good news is that it has already been fixed shortly after beta 1. It now uses EM_STREAMOUT and Windows has to deal with most of the buffering internally. It will also write a BOM now...

[JasonFriday13]

I know 64 bit isn't officially supported yet, but there is a text buffer problem in makensisw when using the 'Best Compressor' option (not present in 3.0b1). I would say it's similar to the heartbleed bug which surfaced earlier this year.

Example output (example1.nsi):

...
Processed 1 file, 1 command line command, writing output (amd64-unicode):
Processing pages... Done!
Removing unused resources... Done!
Generating language tables... Done!

Output: "C:\Program Files XP\NSIS\Examples\example1.exe"
Install: 2 pages (128 bytes), 1 section (2072 bytes), 3 instructions (84 bytes), 211 strings (1700 bytes), 1 language table (230 bytes).

Using lzma (compress whole) compression.

EXE header size: 45568 / 47104 bytes
Install code: (4606 bytes)
Install data: (912 bytes)
Compressed data: 1302 / 5518 bytes
CRC (0x355A8BFB): 4 / 4 bytes

Total size: 46874 / 52626 bytes (89.0%)


The lzma compressor created the smallest installer (46385 bytes).

EXE header size: 45056 / 46592 bytes
ble (230 bytes).
<Install code: 843 / 4606 bytes

ble (230 bytes).
<Install data: 482 / 912 bytes


ble (230 bytes).
<CRC (0x8C9DB71E): 4 / 4 bytes
s


ble (230 bytes).
<
RC (0x8C9DB71E): 4 / 4 bytes
s


ble (230 bytes).
<Total size: 46385 / 52114 bytes (89.0%)
bytes).
<

Also I put up an unrelated bug ticket on sf.net, thankfully after some testing it's an easy fix.

[Pawel]

@JasonFriday13
I also noticed this in my own NSIS test builds (for Polish users). When I translate for example this: "EXE header size:" and translation is longer it happens the same, like buffer is to short...
So, maybe this is a good idea to increase the buffer or rewrite it.

[Anders]

Fixed. (The person that wrote the stats parser never checked MSDN because EM_GETLINE is rather special and does not zero terminate the buffer in most cases)

[bnicer]

I have a compiler warning message for a custom MUI2 uninstaller welcome/finish page:

code:
!warning: MUI_HEADERIMAGE_UNBITMAP_STRETCH set to unknown value, defaulting to FitControl

My script does not call the macro.

code:
${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\fmodern-wizard.bmp" $IMAGE

If I remove the image entirely, compiling still produces the same warning.

[JasonFriday13]

Originally Posted by bnicer

I have a compiler warning message for a custom MUI2 uninstaller welcome/finish page:

code:
!warning: MUI_HEADERIMAGE_UNBITMAP_STRETCH set to unknown value, defaulting to FitControl

My script does not call the macro.

First of all, MUI_HEADERIMAGE_UNBITMAP_STRETCH is a define, and it affects the main installer window, not a single page. I take it you are using a header image in the installer?

Originally Posted by bnicer

code:
${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\fmodern-wizard.bmp" $IMAGE

If I remove the image entirely, compiling still produces the same warning.

See above, the warning is not for the page.

How are you creating this page? Pasting up the page function would help. (Post isn't really relevant to 3.0b1 as I don't think the MUI2 code has changed much at all since 3.0a0).

[Pawel]

To remove this warning message, try to add this line:

PHP Code:

!define MUI_HEADERIMAGE_UNBITMAP_STRETCH FitControl 


You will define default behavior for bitmap, to fit the control.
However, you should not see that for custom page...

[bnicer]

I have not tested installers with standard MUI2 welcome/finish pages. I usually use custom pages in the installers and the uninstallers, for instance: !insertmacro PAGE_FINISH

code:
; Finish Page

Function nsDialogsFinish

  Call HideControls

  ${If} $LANGUAGE == 1031

    StrCpy $R1 20 #

    StrCpy $R2 318 #

  ${Else}

    StrCpy $R1 69 #

    StrCpy $R2 265 #

  ${EndIf}

  GetDlgItem $R0 $HWNDPARENT 1

  ${NSD_SetText} $R0 "$(M_BUTTONTEXT_FINISH)"

  nsDialogs::Create 1044

  Pop $DIALOG

  nsDialogs::SetRTL 0

  ${NSD_CreateCheckbox} 256u 100u 55u 8u "$(M_TEXT_FINISH_SHOWREADME)"

  Pop $CHECKBOX_1

  ${NSD_CreateCheckbox} 256u 115u 55u 8u "$(M_TEXT_FINISH_RUN)"

  Pop $CHECKBOX_2

  ${NSD_CreateLabel} 46u 175u 246u 16u "$(M_TEXT_FINISH_INFO_TEXT)"

  Pop $1

  ${NSD_CreateBitmap} 0 0 331u 193u ""

  Pop $IMAGECTL

  ${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\fmodern-wizard.bmp" $IMAGE

  SetCtlColors $DIALOG "" 0xb4c6ff

  SetCtlColors $CHECKBOX_1 0x000000 0xd8e2f4

  SetCtlColors $CHECKBOX_2 0x000000 0xd8e2f4

  SetCtlColors $1 0x4f5235 transparent

  nsDialogs::Show

  Call ShowControls

  ${NSD_FreeImage} $IMAGE

FunctionEnd

Interestingly the warning appears only once, even though there are four images (welcome + finish; installer + uninstaller), but that said, it is unlikely the warning stems from my script, because not embedding the images does not remove the warning.

The script in its entirety is posted online. I'll send you the link in a pm, if you can't reproduce the warning.

The above code is actually an installer finish page, but the uninstaller is the same.

[bnicer]

Thanks, Pawel.
Adding the !define line to the unpage welcome function got rid of the warning message.

code:
; Welcome UnPage

Function un.nsDialogsWelcome

  Call un.spawn_abort

  StrCmp $SPAWN "\U" +2

  File "/oname=$PLUGINSDIR\modern-wizard.bmp" "${LOCAL}tigwsu.bmp"

  Call un.HideControls

  nsDialogs::Create 1044

  Pop $DIALOG

  !define MUI_HEADERIMAGE_UNBITMAP_STRETCH FitControl

  ${If} $LANGUAGE == 1031

  nsDialogs::SetRTL 0

  ${NSD_CreateLabel} 234u 16u 95u 80u "$(M_UNTEXT_WELCOME_INFO_TITLE)"

  ${Else}

  nsDialogs::SetRTL 1

  ${NSD_CreateLabel} 10u 16u 93u 80u "$(M_UNTEXT_WELCOME_INFO_TITLE)"

  ${EndIf}

  Pop $1

  nsDialogs::SetRTL 0

  ${NSD_CreateLabel} 58u 166u 221u 24u "$(M_UNTEXT_WELCOME_INFO_TEXT)"

  Pop $2

  ${NSD_CreateBitmap} 0 0 331u 193u ""

  Pop $IMAGECTL

  ${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\modern-wizard.bmp" $IMAGE

  SetCtlColors $DIALOG "" 0xb4c6ff

  ${If} $LANGUAGE == 1031

  CreateFont $R1 "Verdana" 12 700 ; font size German title

  ${Else}

  CreateFont $R1 "Verdana" 16 700 ; font size English title

  ${EndIf}

  SendMessage $1 ${WM_SETFONT} $R1 0

  SetCtlColors $1 0x4f5235 transparent

  SetCtlColors $2 0x4f5235 transparent

  nsDialogs::Show

  Call un.ShowControls

  ${NSD_FreeImage} $IMAGE

FunctionEnd

I have two questions. Why is a warning necessary, if the behavior defaults to FitControl anyway? And, does NsDialog have one setting for stretching or can the !define also define the other new bitmap stretch mode settings?

[Anders]

Please post a minimal example that I can actually compile. If custom pages/nsDialogs is required to reproduce, don't include references to things that are not required like ShowControls etc. To be clear, I want you to start with a empty text file and add things until you get the warning...

MUI_HEADERIMAGE_[UN]BITMAP[RTL]_STRETCH is new and might not have been tested in every possible configuration. It applies to every page that uses the "small header image" (Not the welcome and finish pages). It should have no effect at all unless MUI_HEADERIMAGE is defined. It replaces the _NOSTRETCH define in older MUI versions.

You are supposed to use it like this:

!include MUI2.nsh
!define MUI_HEADERIMAGE
!define MUI_HEADERIMAGE_BITMAP_STRETCH AspectFitHeight

!insertmacro MUI_PAGE_COMPONENTS
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE English

[bnicer]

Chunk of code.

code:
; TEST NSI

!define PRODUCT_NAME "FitControl - Test"

!define PRODUCT_UNINST_KEY "Software\Microsoft\Windows\CurrentVersion\Uninstall\${PRODUCT_NAME}"

Unicode false



!include "MUI2.nsh"



;--------------------------------

; Configuration

RequestExecutionLevel admin

Caption "${PRODUCT_NAME} Setup"

Name "${PRODUCT_NAME}"

BrandingText " "

OutFile "test.exe"

SetCompress auto



; Variables

Var DIALOG        ; nsDialogs control

Var TEXT1         ; nsDialogs control

Var TEXT2         ; nsDialogs control

Var IMAGECTL      ; nsDialogs control

Var IMAGE         ; nsDialogs handle



;--------------------------------

; Macros



!macro PAGE_WELCOME

  Page custom nsDialogsWelcome ""

!macroend



!macro PAGE_INSTALL

  PageEx instfiles

    PageCallbacks "" instFilesShow ""

  PageExEnd

!macroend



!macro UNPAGE_INSTALL

  PageEx un.instfiles

    PageCallbacks "" un.instFilesShow ""

  PageExEnd

!macroend



!macro PAGE_FINISH

  Page custom nsDialogsFinish ""

!macroend



;--------------------------------

; Sections



Section "InstallFiles" id1

  SetOutPath $WINDIR

  File "/oname=$WINDIR\modern.exe" "modern.exe"

  WriteRegStr HKLM "${PRODUCT_UNINST_KEY}" "DisplayName" "FitControl - Test"

  WriteRegStr HKLM "${PRODUCT_UNINST_KEY}" "DisplayIcon" "$INSTDIR\unins000.exe"

  WriteRegExpandStr HKLM "${PRODUCT_UNINST_KEY}" "App Path" "$WINDIR"

  WriteRegExpandStr HKLM "${PRODUCT_UNINST_KEY}" "UninstallString" "$INSTDIR\unins000.exe"

  SetOutPath "$INSTDIR"

  WriteUninstaller "$INSTDIR\unins000.exe"

SectionEnd



Section Uninstall

  Delete "$WINDIR\modern.exe"

  Delete "$WINDIR\FitControl - Test\unins000.exe"

  DeleteRegKey HKLM "${PRODUCT_UNINST_KEY}"

SectionEnd



;--------------------------------

; MUI Settings



; modern ui

!define MUI_HEADERIMAGE_BITMAP "header.bmp"

!define MUI_HEADERIMAGE_UNBITMAP "header.bmp"

!define MUI_HEADERIMAGE



; Installer

; Welcome page

!insertmacro PAGE_WELCOME

; Instfiles page

!insertmacro PAGE_INSTALL

; Finish page

!insertmacro PAGE_FINISH



; Uninstaller

; Confirm unpage

!define MUI_PAGE_CUSTOMFUNCTION_PRE un.confirm

!insertmacro MUI_UNPAGE_CONFIRM

; Instfiles unpage

!insertmacro UNPAGE_INSTALL



; Language files

!insertmacro MUI_LANGUAGE "English"



; Reserve files

ReserveFile /plugin "nsDialogs.dll"



;--------------------------------

; Functions



; Welcome Page

Function nsDialogsWelcome

  nsDialogs::Create 1044

  Pop $DIALOG

  nsDialogs::SetRTL 0

  ${NSD_CreateLabel} 185u 24u 140u 88u "Welcome to the $(^Name) installation!"

  Pop $TEXT1

  ${NSD_CreateLabel} 185u 123u 140u 187u "$\n$\r$\n$\rThis setup wizard will install $(^Name) on your computer.$\n$\r$\n$\rClick Next to install the test, or Cancel to exit the setup."

  Pop $TEXT2

  ${NSD_CreateBitmap} 0 0 331u 193u ""

  Pop $IMAGECTL

  ${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\modern-wizard.bmp" $IMAGE

  SetCtlColors $DIALOG "" "${MUI_BGCOLOR}"

  SetCtlColors $TEXT1 0xfff9f2 transparent

  SetCtlColors $TEXT2 0x32465b transparent

  CreateFont $R1 "Verdana" 11 700

  SendMessage $TEXT1 ${WM_SETFONT} $R1 0

  nsDialogs::Show

  ${NSD_FreeImage} $IMAGE

FunctionEnd



; Install Files Page

Function instFilesShow

FunctionEnd



; Finish Page

Function nsDialogsFinish

  GetDlgItem $1 $HWNDPARENT 1 ; Next button

  ${NSD_SetText} $1 "&Finish"

  nsDialogs::Create 1044

  Pop $DIALOG

  nsDialogs::SetRTL 0

  ${NSD_CreateLabel} 174u 46u 146u 88u "Installation complete"

  Pop $TEXT1

  ${NSD_CreateLabel} 161u 155u 167u 187u "Click Finish to close the setup wizard."

  Pop $TEXT2

  ${NSD_CreateBitmap} 0 0 331u 193u ""

  Pop $IMAGECTL

  ${NSD_SetStretchedImage} $IMAGECTL "$PLUGINSDIR\fmodern-wizard.bmp" $IMAGE

  SetCtlColors $DIALOG "" "${MUI_BGCOLOR}"

  SetCtlColors $TEXT1 0xfff9f2 transparent

  SetCtlColors $TEXT2 0x32465b transparent

  CreateFont $R1 "Verdana" 11 700

  SendMessage $TEXT1 ${WM_SETFONT} $R1 0

  nsDialogs::Show

  ${NSD_FreeImage} $IMAGE

FunctionEnd



Function .onInit

  ; Default locations

  StrCpy $INSTDIR "$WINDIR\${PRODUCT_NAME} Uninstaller" #

  StrCpy $ICONS_GROUP "$SMPROGRAMS\FitControl - Test" #



  ; Temporary Folder

  InitPluginsDir

  ReserveFile "header.bmp"

  SetOutPath $PLUGINSDIR

  File "/oname=$PLUGINSDIR\modern-wizard.bmp" "modern-wizard.bmp"

  File "/oname=$PLUGINSDIR\fmodern-wizard.bmp" "fmodern-wizard.bmp"

  ClearErrors

FunctionEnd



;--------------------------------

; Uninstaller Functions



; Confirm UnPage

Function un.confirm

  Abort

FunctionEnd



; Install Files UnPage

Function un.instFilesShow

FunctionEnd



Function un.onInit

  InitPluginsDir

  ReserveFile "header.bmp"

FunctionEnd

I stripped out everything I could in an existing script. The warning message is not displayed when you take out this macro line: !insertmacro MUI_UNPAGE_CONFIRM.

In another uninstaller script I'm using the warning message is still displayed after removing MUI_UNPAGE_CONFIRM.

[bnicer]

You are supposed to use it like this:
Quote:
!include MUI2.nsh
!define MUI_HEADERIMAGE
!define MUI_HEADERIMAGE_BITMAP_STRETCH AspectFitHeight

!insertmacro MUI_PAGE_COMPONENTS
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE English

Works for me. Thanks.

[Anders]

It should be fixed now, please try to update your install with this.

[bnicer]

There is still the warning. The confusing part is that it warns about the unbitmap and for the installer bitmap it does not warn.

"!define MUI_HEADERIMAGE_UNBITMAP_STRETCH FitControl" produces no warning.

Edit: Oops. No. That was a mistake. Anders, I copied your patch to the wrong folder. It works now. Excellent. 10 out of 10!

[heatheralexea123]

most of programs that use NSIS are still being detected as a false positive by few AVs. I created an empty installer and here is the result

https://www.virustotal.com/en/file/7...748b/analysis/

[JasonFriday13]

I use AVG and I have never had a false positive from them. False positives are an ongoing battle, and as long as software is being developed there is no outright winning.

[heatheralexea123]

Originally Posted by JasonFriday13

I use AVG and I have never had a false positive from them. False positives are an ongoing battle, and as long as software is being developed there is no outright winning.

Ok could you please check your software using virustotal and see how many AVs detect it as a threat ?

[JasonFriday13]

About the only installer I actually distribute is for my InstallSpider User Interface, every other installer I've made is for personal use and doesn't leave my computer (or it's for programming or testing).

An older version passed all tests: https://www.virustotal.com/en/file/0...is/1415360022/

And the current version passed all tests except for McAfee-GW-Edition: https://www.virustotal.com/en/file/c...is/1415360371/

I'm not a professional so false positives don't really concern me. Maybe if I was working in programming then I might be concerned and do something about it. I tend to change brands if something breaks down, so I've come to rely on brands such as Asus, Corsair, Kingston, Western Digital and LG optical drives (out of 5 drives, one is 9 years old and still hasn't broken yet, and it's in my main machine with an ide->sata converter).

This isn't relevant to the thread, so I'm not going to say anything more about it in this thread.

[bnicer]

I second not relevant to the thread, but it is reassuring nonetheless. I expected false positives, after what’s been said here. I got a perfect score too. NSIS must be doing something right. https://www.virustotal.com/en/file/1...9e7b/analysis/

Again, maybe it would be better to post this in another thread, ie, the only thing that flags up is under behaviourial information: System.dll (failed)

[simplix]

Commit [r6568] breaks x86 plugins, without .reloc they not works.
Example:

code:
UserInfo::GetAccountType

Pop $0

MessageBox MB_OK "$0"

[Anders]

Originally Posted by simplix

Commit [r6568] breaks x86 plugins, without .reloc they not works.

Thanks, VS2010+ only applies /FIXED to the stubs now.

[simplix]

Hello and Happy New Year!

I can't understand - the error in System plugin or WinAPI. When I use the function OpenProcessToken like this, for example:

code:
StrCpy $R1 0

System::Call "Kernel32::GetCurrentProcess() i .R0"

System::Call "Advapi32::OpenProcessToken(i R0, i 0x0008|0x0020, *i R1R1) i .R0"

MessageBox MB_OK "$R0"

Then in 32-bit NSIS it's works (return 1), but not works in 64-bit NSIS (return 0).
If you have the opportunity, please take a look.

[Anders]

Originally Posted by simplix

Then in 32-bit NSIS it's works (return 1), but not works in 64-bit NSIS (return 0).
If you have the opportunity, please take a look.

This has nothing to do with the beta, you must use the p type for pointer-sized types in 64-bit NSIS:

System::Call "Kernel32::GetCurrentProcess()p.s"
System::Call "Advapi32::OpenProcessToken(ps, i 0x0008|0x0020,*p.R1)i.R0"
DetailPrint "return=$R0, token=$R1"

(The p type works in all versions on NSIS 3+ but it does not exist in NSIS 2.4x)

[simplix]

Anders, thank you very much!

[simplix]

Fix for Armenian.nsh

[Anders]

Originally Posted by simplix

Fix for Armenian.nsh

Fixed, thanks!

[Pawel]

@Anders
Delphi source file for NSIS (\NSIS\Examples\Plugin\nsis.pas) had some bugs for unicode support.
Here is the fixed version:
http://www.meggamusic.co.uk/shup/1422914824/nsis.pas

Here are the differencies (compared to nsis.pas from NSIS 3.0b1):
1. line 56: removed unnecessary comma
2. line 131: added a condition
3. line 159: changed PAnsiChar(msg)-> Pchar(Msg)

Ps: Fixed by Artem (http://aimp.ru).
-Pawel

[Anders]

Originally Posted by Pawel

Here are the differencies (compared to nsis.pas from NSIS 3.0b1):

1: Unnecessary maybe, but unless it fails to compile I don't seen the need to change it.

2: I don't understand why the code needs a duplicate extrap_t in the extrap global in the first place. The code should be rewritten to only use g_extraparameters. (When using a copy, if you call exec_code_segment and that ends up changing a flag you now have a out of sync exec_flags_t in extrap). Checking g_extraparameters against nil might not be necessary, it depends on the minimum supported NSIS version. Most plugins assume it is non-nil AFAIK.

3: Yes, PAnsiChar is probably a bug there.

It has been so long since I coded in Delphi/Pascal so I don't really remember the language anymore but the code does not really make sense to me as is: Call() checks (g_extraparameters <> nil) but then uses extrap.exec_code_segment so who called Init() to fill in extrap?

[Pawel]

Originally Posted by Anders

1: Unnecessary maybe, but unless it fails to compile I don't seen the need to change it.

You can indeed compile "exdll.dpr" example project and create a dll (but this doesn't include nsis.pas).
However, you can not compile "exdll_with_unit.dpr" example project - it uses nsis.pas that has mentioned issues (need to delete comma (line 56) and change incorrect PAnsiChar type(line 159) to create a dll).

Originally Posted by Anders

2: I don't understand why the code needs a duplicate extrap_t in the extrap global in the first place. The code should be rewritten to only use g_extraparameters. (When using a copy, if you call exec_code_segment and that ends up changing a flag you now have a out of sync exec_flags_t in extrap). Checking g_extraparameters against nil might not be necessary, it depends on the minimum supported NSIS version. Most plugins assume it is non-nil AFAIK.

I didn't analyzed this... I just sent you what my friend fixed for me. As I can see this indeed maybe be not neccessary, but maybe there is a possibility that nil will be passed as parameter

Originally Posted by Anders

3: Yes, PAnsiChar is probably a bug there.

Yes. It will not compile (tested on Delphi XE7)

-Pawel

[Anders]

I have made some changes now but I could not get RegisterPluginCallback to work 100% correctly, not sure if it is because I was using Free Pascal or a problem with my code but it crashes in a call to FreeLibrary. If anyone has Delphi installed and are able to try that would really help (Grab exdll_with_unit.dpr and nsis.pas from here).

This is how I'm compiling:

.\bin\i386-win32\fpc -Fu.\units\i386-win32\winunits-base -FE.\ -CX -XX -Os -Sd C:\NSIS\trunk\Contrib\ExDLL\exdll_with_unit.dpr

Edit:
It might just be a threading bug in Free Pascal. Calling exdll_with_unit::registerplugincallback in .onGuiInit instead of a section does not crash...

Edit2:

The bug is still there in 2017 with:

.\bin\i386-win32\fpc -Fu.\units\i386-win32\winunits-base -FE.\ -CX -XX -Os -Sd exdll_with_unit.dpr -Fu.\units\i386-win32\rtl-objpas