NSIS 3.0b1

Originally Posted by simplix View Post

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

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

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:

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.

Originally Posted by simplix View Post

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)

Anders, thank you very much!

Fix for Armenian.nsh

Originally Posted by simplix View Post

Fix for Armenian.nsh

Fixed, thanks!

@Anders
Delphi source file for NSIS (\NSIS\Examples\Plugin\nsis.pas) had some bugs for unicode support.
Here is the fixed version:


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

Originally Posted by Pawel View Post

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?

Originally Posted by Anders View Post

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 View Post

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 View Post

3: Yes, PAnsiChar is probably a bug there.

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

-Pawel

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

Originally Posted by Anders View Post

If anyone has Delphi installed and are able to try that would really help.

I compiled it successfully in Delphi XE7. Here are sources I used.


Example NSIS script compiled without problems. Works OK. No crash. So, you did it well.

Ps: I changed 1 line, as compiler displayed warning:

Changing it to nil gives compilation without warnings.

-Pawel

Originally Posted by Pawel View Post

Ps: I changed 1 line, as compiler displayed warning:

http://www.meggamusic.co.uk/shup/1423068306/Warning.png

Changing it to nil gives compilation without warnings.

http://www.meggamusic.co.uk/shup/1423068340/OK.png

The plugin callback function is really supposed to return a UINT_PTR but I don't know which type that maps to in Delphi or how far back it is supported. I assume you can use some type of ifdef to map to the equivalent of UINT_PTR and UINT depending on the compiler version but it is less maintenance to just pretend it's a pointer and return nil. The return value is currently not used IIRC but needs to be NULL/0 to be forward compatible...

Hi!

I think that I found a small (visual problem). If German language is selected, one of the texts in the Component selection dialog by uninstallation is partially hidden (see the attached screenshot). What is the easiest way to solve my problem now?

Originally Posted by TrifonovS View Post

Hi!

I think that I found a small (visual problem). If German language is selected, one of the texts in the Component selection dialog by uninstallation is partially hidden (see the attached screenshot). What is the easiest way to solve my problem now?

I'm guessing this is not a NSIS3 beta issue? I made the label taller now, thanks. You can fix your current NSIS install by editing the UIs with resource hacker. Make the label 25 DLU's high...

Thank you Anders. Actually I fixed the problem by the define MUI_COMPONENTSPAGE_TEXT_TOP. I defined a new (shorter text) for German and I copied the same text for English.

Hello world, I'd be interested in the current project state. Is there a place (blog or something) about it? Are there any (preliminary) dates or a roadmap for a non-beta NSIS 3.x release? Or is development currently stalled for some reason?

It's not stalled, there just hasn't been much activity lately. The last commit on the trunk was a couple of weeks ago. After my exams I'll be doing some more work on a zip2exe port for linux that I started last year.

Is NSIS 3.0b1 stable for production usage?

There are version 2.46 ( last updated in 2009 ) , and the newer 3.0b1 .

It seems the newer one is in beta and I worry about stability issues.
I wonder if any of you have experience with both versions and willing to comment on them .

BTW, is NSIS still under active maintenance ?

You could easily check the source code repository yourself to see when the last change was made...

Hi there,

I ran into two minor issues with beta1:

On a 4k display, "ManifestDPIAware" doesn't work for the "verifying installer" dialog (fonts are scaled), while the langdll and the main installer GUI is fine.

This loop to remove empty folders doesn't work anymore (with $sm_folder set to e.g. "foo\bar\test\123":

StrCpy $R0 "$SMPROGRAMS\$sm_folder"

RMDir /r "$R0"

ClearErrors

${Do}

	GetFullPathName $R0 "$R0\.."

	${If} $R0 == $SMPROGRAMS

		${ExitDo}

	${EndIf}

	RMDir $R0

${LoopUntil} ${Errors}

The outer "RMDir /r" works, but the first inner doesn't and fails to remove the empty directory "foo\bar\test".
It doesn't work in either, ansi nor unicode build/path, but used to work with v2.

Thanks!

Originally Posted by noisehole View Post

On a 4k display, "ManifestDPIAware" doesn't work for the "verifying installer" dialog (fonts are scaled), while the langdll and the main installer GUI is fine.

The verify dialog is created with CreateDialog and InitCommonControls has already been called so I don't understand why anything should be different with this dialog. The ManifestDPIAware attribute only changes the manifest, the exehead code is the same.

Originally Posted by noisehole View Post

This loop to remove empty folders doesn't work anymore (with $sm_folder set to e.g. "foo\bar\test\123":

Works for me:

!include LogicLib.nsh
Var sm_folder
Section
StrCpy $sm_folder "foo\bar\test\123"
StrCpy $R0 "$temp\$sm_folder"
CreateDirectory "$R0"

!if 0 ; Your version, works fine for me

RMDir /* /r */ "$R0"
ClearErrors
${Do}
GetFullPathName $R0 "$R0\.."
${If} $R0 == $temp
${ExitDo}
${EndIf}
RMDir $R0
${LoopUntil} ${Errors}

!else ; My version, also works...

RMDir /* /r */ "$R0"
${Do}
StrCpy $R0 "$R0\.."
ClearErrors
RMDir $R0
${LoopUntil} ${Errors}

!endif

SectionEnd

Originally Posted by Anders View Post

The verify dialog is created with CreateDialog and InitCommonControls has already been called so I don't understand why anything should be different with this dialog. The ManifestDPIAware attribute only changes the manifest, the exehead code is the same.

Hmm, I also tested a nightly build and I'm seeing this issue.

Originally Posted by Anders View Post

Works for me:

Huh, today it works for ansi paths but doesn't with a unicode path containing chinese chars. Maybe it's another process having open handles and blocking the removal, like antivirus crap, I'll do some further testing.

Thanks!