Archive: NSIS 3.0a1


NSIS 3.0a1
This release fixes some of the issues reported in the first alpha and also added manifest support for the Win8.1 Preview GUID.

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

(New) Known issues:


Hey Anders,
I decided to try to compile NSIS 3.0 sources. I have some problems with this. I hope you can help me with this.

I am doing this on Win7 SP1 x64, Visual Studio 2008 Express Edition (Python 2.6, wxWidgets 2.8.10). On this platform I was successfully compiling NSIS 2.46.

1. I started to build NSIS menu. Compilation is OK.
2. I started to build NSIS (using cmd via Visual Studio Command Prompt). Here is a log:

C:\NS>scons
scons: Reading SConscript files ...
Mkdir("build\urelease\config")
Delete("nsis-16-Jul-2013.cvs")
Delete(".instdist")
Delete(".test")
Using Microsoft tools configuration
Checking for memset requirement... yes
Checking for C library gdi32... yes
Checking for C library user32... yes
Checking for C library pthread... no
Checking for C library iconv... no
Checking for C library shlwapi... yes
Checking for C library version... yes
Please specify folder of zlib for Win32 via ZLIB_W32


As you can see, there is a problem with ZLIB library (there was no such problem on previous 2.64 edition)... What should I do? Should I install zlib and add it to System PATH? Or what?
-Pawel


http://nsis.sourceforge.net/Zlib


Thanks, I was checking with zlib file downloaded from official zlib website... Copied to system32... but it was not working... And I didnt see that this is described in docs.
Will let you know if my compilation is successful.


OK, I run compilation again. ZLIb problem is gone.
But, of course, there is another one...

Here is the last part of log:

Source\util.cpp(437) : warning C4290: C++ exception specification ignored except to indicate a function is not __declspe
c(nothrow)
Source\util.cpp(639) : error C2065: 'ENOMEM' : undeclared identifier
Source\util.cpp(661) : error C2065: 'ECHILD' : undeclared identifier
scons: *** [build\urelease\Library\LibraryLocal\util.obj] Error 2
scons: building terminated because of errors.
C:\NSIS3>


How to fix it?

Ps: Here is a full log: http://www.meggamusic.co.uk/shup/137..._Build_Log.txt
-Pawel


Add #include <stdlib.h> to the top of util.cpp and if that is not enough, try errno.h


It works (stdlib.h did nothing, but adding errno.h helped).

However, there is one more problem. I use "scons dist" command.
It should create zip and installer. But, when scons run makensis it hangs. So, i can not run just compiled makensis.exe. Windows displays error message - makensis.exe stopped working, etc...

Here is a log: http://www.meggamusic.co.uk/shup/137..._Build_Log.txt
Here is a screen: http://www.meggamusic.co.uk/shup/1374012698/Screen.png

Should I provide something else? I wonder why it crash...
-Pawel

Ps: Thanks for your patience, Anders... I have to tell, that each time i try to compile nsis sources i have some problems.


Does it crash if you compile example1.nsi or run it with no parameters? My guess is that the CRT is responsible for the 255 exit code.

You could try running it in WinDbg and see what "!analyze -v" says.


I am not sure if you understood me well. I can not compile any script, as makensis.exe seems to be broken. It crash on open (in my case, during source compilation, when it tries to compile makensis.nsi).

So, something went wrong during source compilation... god knows what.
-Pawel


PS: I made a video, that presents compilation:
http://www.meggamusic.co.uk/shup/137...ompilation.zip
You will see that makensis.exe is broken. It crashes ("scons dist" starts at 3 minute of video).

Edit:
Problem is now solved. To compile NSIS 3 using Visual Studio 2008 Express Edition (maybe also other versions) you need to:
1. Add errno.h header to util.cpp
2. Change ExpandoStrFmtVaList_vsnwprintf from utils.cpp to: #define ExpandoStrFmtVaList_vsnwprintf(d,c,f,v) ( INT_MAX==(c) ? _vscwprintf((f),(v)) : _vsnwprintf((d),(c)?(c)-1:0,(f),(v)) )
-Pawel


Can't break alpha
I have some rather complex scripts, with code ranging from classic stuff to not-so-standard usage. So far, I couldn't detect any unexpected behaviour or get compiler errors (tested both ansi&unicode where possible). I realize I'm one user and there isn't much value in 'no-bug reports'; just wanted to say it's looking proper and I'd be surprised if any significant number of bugs is reported until the final release.


@Anders
Here are few problems to fix in NSIS 3.0a1 (minor)

1. In the About dialog of MakeNSISW "Close" button do nothing.
http://www.meggamusic.co.uk/shup/137...SISW_about.png
It should perform some action (here: the same procedure as defined for OK button - Close the form). As I remember, it was the same in older NSIS builds (maybe there is some reason for that)

2. When you choose "NSIS update" menu entry from MakeNSISW it shows a dialog that a new version is available (it is not true, as the newest one is already installed)
http://www.meggamusic.co.uk/shup/137...SIS_Update.png

3. NSIS.exe application has a header image. It has a gap from the right side. Should be eliminated (title text bug is already reported)
http://www.meggamusic.co.uk/shup/137.../NSIS_Menu.png

4. I think, there is a problem with lang files with UTF-8 encoding, in Unicode installers.
I had a file encoded in that format and after compilation NSIS installer displayed wrong characters (I have no screenshot). Everything works perfect with UCS-2 Little Endian.

5. Problem (or not) with output language value stored in exe resource file. It is hard to explain, will try to do this...
I am not sure, but in NSIS 2.46 when you compiled your installer it saves to installer resource file "Neutral Language". http://www.meggamusic.co.uk/shup/1375653170/Lang.png

Now, it saves last defined language in script...
For example:
Last language in code is "English". Result:
http://www.meggamusic.co.uk/shup/137...st_English.png

And now:
Last language in code is "Turkish". Result:
http://www.meggamusic.co.uk/shup/137...st_Turkish.png

Or maybe this is how it was ment to be?

-Pawel


Originally posted by Pawel
Here are few problems to fix in NSIS 3.0a1 (minor)
Thanks for finding and reporting all these issues!
  1. Fixed
  2. Todo: I believe this is a issue on the server
  3. I made the dialog 2 pixels thinner, might not fix it 100% on your end, some font & dialog unit calculation is probably required to completely fix this (The gap is probably from wxWidgets changes, not something we did)
  4. Do you have a small sample file I can use for testing?
  5. There was a change to the language blocks in the version info a while back but I'm guessing you are not adding the info correctly, if you don't use /LANG= the language used is indeed the last loaded. You should either add the VI keys for a language after you load the language or use /LANG.
    http://i.imgur.com/4qtk3lAs.png
    (Resource Hacker is buggy when it comes to multiple language blocks and cannot be trusted)

Anders,
Ad4. Sent example installer code via PM (it seems that the problem exists with UTF-8 without BOM).
Ad5. Thanks. You are right. I forgot about that lang switch.
-Pawel


Small problem (not a real bug) which is really annoying me:

When I compile .nsi file with makensisW (right click the .nsi file -> Compile NSIS Script) and compilation is successful I cannot run generated installer by pressing Enter (or Space) key because Close button has focus and makensisW closes. This is because Close is default button for this form.

My suggestion is to set Test Installer button as default.
If anyone wants to close the window he can do that with Esc key (this is already working).


Originally posted by T.Slappy
My suggestion is to set Test Installer button as default.
Fixed

What about creating About dialog and adding it into NSIS's menu?

I saw something similar in Inno Setup and I think it is really nice feature which can propagate NSIS further.

http://graphical-installer.com/temp/nsis-about.jpg

Simple MessageBox could be enough, no large fancy stuff.

What's your opinion?


Originally posted by T.Slappy
What about creating About dialog and adding it into NSIS's menu?

What's your opinion?
BrandingText is not enough?

I'm not a big fan of apps that change the system menu and adding to the bottom is horrible, that is right where close is supposed to be when you right-click its taskbar button on <= Vista.

If you wanted to put your own stuff there you could create a plugin...

I tried to compile one of my ready installers (compiled with v2.46) and I got the following error:

(C:\Program Files (x86)\NSIS\Include\StrFunc.nsh:52)
Internal compiler error: installer's shell constants are different than uninstallers!

abnormal program termination

Can you help me to solve it, please???


Originally posted by TrifonovS
I tried to compile one of my ready installers (compiled with v2.46) and I got the following error:

(C:\Program Files (x86)\NSIS\Include\StrFunc.nsh:52)
Internal compiler error: installer's shell constants are different than uninstallers!
Could you provide a minimal code sample?

I tried to prepare for you a simpler installer that reproduces the problem, because my installer needs a lot of additional files, plug-ins,... But when I removed code from the script I found what makes the problem. I have my own MultyUser.nsh (of course with changed name). If I remove it, all works fine. Now I have to find out why it can be compiles with v2.46, but not with v3.0. If I need additional help I will ask again.


Hi Guys,

I will use NSIS for the first time. Even though issues are sourceforge or in this thread are minor, I'm not sure if I should use 3.0a1 since it's an alpha release.
Do you think it's stable enough or should I use 2.46 for now ?

Sorry if it's on wrong thread.


Originally posted by yclkvnc

I will use NSIS for the first time. Even though issues are sourceforge or in this thread are minor, I'm not sure if I should use 3.0a1 since it's an alpha release.
Do you think it's stable enough or should I use 2.46 for now ?
The license URL bug is the only one the end user will see, if you don't have URLs in your license then I guess you can.

There should be another alpha soon. The remaining work before we can do betas is mainly POSIX related...

Big thanks for the NSIS Unicode work.

I am curious about the plans for POSIX.

The command "scons UNICODE=no utils makensis" fails to build the ANSI versions of utils and makensis from source. I thought about resurrecting the defunct ANSI makensis and utils for POSIX. This may sound awkward. However the wchar_t type is ambiguous and compiler-specific.

If the GNU C Compiler is instructed to override the underlying type for 'wchar_t' to be 'short unsigned int' by the flag '-fshort-wchar' then standard and third-party library code using the POSIX default definiton of wchar_t (32 bit) won't be usable from code compiled with '-fshort-wchar' due to incompatible wchar_t sizes. WCHAR could be used but also with the expense to reimplement the used standard library functions.

makensis and utils as ANSI/UTF-8 executables could be implemented in way to be able to produce Unicode installers. The plugins and stubs are anyway built in a version for ANSI as well as Unicode. One of the open issues is the internal representation of language and text strings. My guess is that UTF-8 could be easier converted into Unicode respectivly other required codepages. Though the current implementation of ANSI makensis seems to use CP_ACP (system default Windows ANSI code page) if I correctly understood the code.


Why is using wchar_t (32bit) in makensis/cputils a problem?

The old ANSI makensis did not really care, all NSIS instructions are ASCII safe and anything above 127 is just "bytes" and so CP_ACP does not really come into the picture until setup is running on the end users machine IIRC...


Hi, testing nsis 3.0a1 and I found a quirk (sorry if it's reported on the sf bug tracker, I haven't checked there yet). Firstly I like how the .nsi file can be ansi or unicode, and it will still compile to what the Unicode statement defines (true or false).

The quirk is that the license file has to be the same encoding as the Unicode statement, ie using an ansi license file with "Unicode true" results in a bunch of chinese or japanese characters. The other way round results in 3 weird chars and the rest is blank.

So I think the fix could be making the license file reading code the same as the .nsi reading code, where it doesn't matter what the input encoding is, it will output the correct encoding as defined with the Unicode statement.


I wrote the nsi reader from scratch, the license handling mostly comes from the unicode fork/merge.

Just to be clear, you are talking about a .txt license file and not RTF?


Correct, though I haven't used *.rtf files in installers yet.


So the idea looks similar to this:

handle = openfile(filename.txt);
if (isUnicodeInstaller()) // returns true or false
{
if (isUnicodeFile(handle)) // if both the same, do nothing
{
}
else // ansi file, convert to unicode
{
convertToUnicode(handle);
}
else // ansi installer
{
if (isUnicodeFile(handle)) // if unicode file, convert to ansi
{
convertToAnsi(handle);
}
else // both the same, do nothing
{
}
}
I have had a quick look at the code for the license loading, but I don't understand alot of it because I'm not familiar with the c++ side, though it looks like the LoadLicenseFile function (in script.cpp) is converting the text to wchar_t regardless of the file encoding.

I have done a bit more testing, and it turns out that .rtf files are fine, it's the .txt encoding that's the problem.
If it's ansi, the compiler will compile both ansi and unicode installers correctly.
If it's unicode, the compiler will throw the same error for both ansi and unicode installers. Compiler log:

SetCompressor: lzma
!define: "MUI_CUSTOMFUNCTION_GUIINIT"="onGUIinit"
!insertmacro: MUI_PAGE_LICENSE
LicenseData: wchar_t conversion failed!
Error in macro MUI_PAGEDECLARATION_LICENSE on macroline 17
Error in macro MUI_PAGE_LICENSE on macroline 6
Error in script "D:\Jason\Projects\maketest.nsi" on line 21 -- aborting creation process
Which is this part (CEXEBuild::LoadLicenseFile) in script.cpp:
// We have to convert the content of the license file to wchar_t
const WORD srccp=strm.StreamEncoding().IsUnicode() ? strm.StreamEncoding().GetCodepage() : AnsiCP;
const UINT cbcu=NStreamEncoding::GetCodeUnitSize(srccp);
if (sizeof(TCHAR) < cbcu)
{
l_errwcconv:
ERROR_MSG(_T("%s: wchar_t conversion failed!\n"),cmdname);
return PS_ERROR;
}
I will be diving into the source code for those first two lines to see what is happening, and if I can make a patch to fix this problem.

[edit]
I decided to test other encodings first. I use notepad in Windows 7 to save the encoding type. UTF-8 and Unicode big endian work fine, it's the vanilla Unicode setting that throws the error. I don't know what that encoding type is so unfortunately I can't go any further there.
[/edit]

The problem is not the lines you posted, it was the Dup before the goto. Anyway, I fixed the bug...


Awesome, if I see any other quirks I'll shout out :D.


Linux build
Can I build source of nsis3.0 on linux? :)


Not yet, though it will be worked on later in development, probably once everything is integrated and working well enough.


Originally posted by nidzadragon
Can I build source of nsis3.0 on linux? :)
It would be really helpful if someone would be willing to try to fix POSIX and submit some patches...

I already tried to build this version using SCons, but I get error "zlib is missing" even if I set correct path to zlib trough ZLIB_W32 environment variable.


I know very little about python but I'm giving posix compiling a go.

I'm using ubuntu 12.04, 64 bit.
If I have to, I'll do my testing on virtualbox under the 32 bit version.

This is the line I'm using: scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all SKIPDOC=all

I got the zlib dependancy working, and halibut compiles up correctly but it won't execute, throwing up an error saying "Permission denied", so I have commented that section out of Sconstruct for now.

Question: is pluginapi.c really required for compiling makensis? Because the first line in it is: #include <windows.h>, which of course doesn't exist on linux, and it throws an error. I have substituted a basic cross-plaform ready file in it's place.

Also, I noticed that the first file that doesn't compile is related to makensis, specifically:
o build/urelease/makensis/7zip/7zGuids.o -c -Wno-non-virtual-dtor -Wall -O2 -DNSISCALL="__attribute__((__stdcall__))" -D_UNICODE -DUNICODE -D__BIG_ENDIAN__ -DMAKENSIS -D_WIN32_IE=0x0500 -DCOMPRESS_MF_BT -Ibuild/urelease/config Source/7zip/7zGuids.cpp
sh: 1: o: not found

I wil do some more testing on the 32 bit version and see if these pop up there too.


[REMOVED]

...nevermind, stupid me - found the issue on my end. Compiler flags FTW. ;)


I'm running a 32 bit environment now, and all those errors above have vanished, with a new one (several, actually) popping up:

g++ -o build/urelease/makensis/DialogTemplate.o -c -Wno-non-virtual-dtor -Wall -O2 -DNSISCALL="__attribute__((__stdcall__))" -D_UNICODE -DUNICODE -DMAKENSIS -D_WIN32_IE=0x0500 -Ibuild/urelease/config Source/DialogTemplate.cpp
Source/DialogTemplate.cpp: In function 'void ReadVarLenArr(unsigned char*&, WCHAR*&, unsigned int)':
Source/DialogTemplate.cpp:62:38: error: cannot convert 'WCHAR* {aka short unsigned int*}' to 'const wchar_t*' for argument '1' to 'wchar_t* wcsdup(const wchar_t*)'
I am also getting a bunch of functions that aren't declared: _wcsnicmp, _wcsicmp. It also appears the family of "wcs" functions are either not declared or have type-cast conversion problems. I'm still looking through the source code to find these functions and maybe fix them if I'm confident enough. I wish Visual Studio worked on linux, the "Find in Files" search is so great.

[edit] I managed to type-cast that function above so it will compile, wether it works or not is another story: readInto = _wcsdup((wchar_t*)arr);.

Here's one of the "not declared" errors:
Source/DialogTemplate.cpp: In member function 'void CDialogTemplate::AddItem(DialogItemTemplate)':
Source/DialogTemplate.cpp:306:44: error: '_wcsdup' was not declared in this scope
Also, these functions that aren't declared are confusing, I followed the include chain and the function prototype is definitely being declared, so I don't know what's going on there :igor:.

Another question: I see there are some defines like this: '#if 0 '. Are these really needed? Because the number of errors are reduced alot when they are removed (like the one above is resolved). Should I put them in #ifdef _WIN32, #else, #endif blocks? Or remove them altogether?

We should try to stay away from casting to shut up the compiler. In the dialog stuff there might be some strings that are always UTF16LE that end up as resources in the .exe. IIRC there is a StrLenUTF16 in utf.h and some other helpers in winchar.cpp

I'll jump on IRC now if you want some more help...


I have found most of the type-cast's are dealing with TCHAR*, WCHAR* and wchar_t*. There are also some missing function prototypes, but I am making a list of each change I'm making so it's easier for experienced programmers to change. gcc is an anal b**** :mad:.


Archive: NSIS 3.0a1


I noticed that WCHAR is typedef'ed unsigned short in Platform.h. Apparently these two can be directly type-cast with no problems, though I don't know the truth.

#if !defined(_NATIVE_WCHAR_T_DEFINED)
typedef unsigned short WCHAR;
#else
typedef wchar_t WCHAR;
#endif

Originally posted by JasonFriday13
I noticed that WCHAR is typedef'ed unsigned short in Platform.h. Apparently these two can be directly type-cast with no problems, though I don't know the truth.
Yes but I believe it really is there just for the exehead stuff, you should not be calling the wcs* string functions with a WCHAR* parameter in makensis code (Not portable)

I've had enough for now. I don't know if windows is smart and knows about the implied cast-typing, but gcc sure doesn't and it catches every type problem, which makes it very hard to troubleshoot. I might start on the non unicode version first as that seems easier to get change it around between ansi and unicode versions.


The ANSI version is going to have even more issues so I don't think that is a good idea. What about the diff I sent you?


I applied that patch to a fresh 3.0a1 source (compiling with unicode on) and it's getting better, DialogTemplate.cpp compiles with no errors now. Also I have to remove 'ExDLL' from the lib_plugins list in Sconstruct, because it tries compiling pluginapi.c, which of course includes windows.h and throws an error about not finding it.

I am now getting another error in ResourceEditor.cpp, in:
return UpdateResourceW(szType, MAKEINTRESOURCEW(szName), wLanguage, lpData, dwSize);
saying "no type conversion found for argument 1". So I added this function to convert it:

return UpdateResourceW(WinWStrDupFromTChar(szType), MAKEINTRESOURCEW(szName), wLanguage, lpData, dwSize);
I did this to the four "Resource" functions, and there are no errors there now. Also I changed this function call at line 985 to:
return WinWStrLen(m_szName); // wcslen(m_szName);
which cleared up that error.

I am getting one error for this file still (other files don't compile if there are errors):
Source/ResourceEditor.cpp: In member function 'int CResourceDirectory::Find(const WCHAR*)':
Source/ResourceEditor.cpp:865:40: error: '_wtoi' was not declared in this scope
I'll look around for alternatives for that function.

Calling WinWStrDupFromTChar like that is a memory leak but its fine for testing.

There is probably something like myatoi in util.c or one of the plugin files, use it to create a WinWStrToInt in winchar.cpp/h if you cannot come up with anything else. I'll try to take a look at the code tonight...


There is, it's in "source/exehead/util.c", so I copied it over into "winchar.c" and renamed it like this:

#ifndef _WIN32 // existing #ifdef
int WinWStrToInt(const WINWCHAR *s)
{
unsigned int v=0;
int sign=1; // sign of positive
TCHAR m=10; // base of 10
TCHAR t=_T('9'); // cap top of numbers at 9

if (*s == _T('-'))
{
s++; //skip over -
sign=-1; // sign flip
}

if (*s == _T('0'))
{
s++; // skip over 0
if (s[0] >= _T('0') && s[0] <= _T('7'))
{
m=8; // base of 8
t=_T('7'); // cap top at 7
}
if ((s[0] & ~0x20) == _T('X'))
{
m=16; // base of 16
s++; // advance over 'x'
}
}

for (;; )
{
int c=*s++;
if (c >= _T('0') && c <= t) c-=_T('0');
// clever little trick to do both upper and lowercase A-F.
else if (m==16 && (c & ~0x20) >= _T('A') && (c & ~0x20) <= _T('F')) c = (c & 7) + 9;
else break;
v*=m;
v+=c;
}
return ((int)v)*sign;
}
I added it to the header and to ResourceEditor.cpp, and it compiles. I hope it actually works.

Now I'm getting this error:
In file included from Source/ResourceVersionInfo.h:30:0,
from Source/ResourceVersionInfo.cpp:19:
Source/strlist.h: In member function 'int SortedStringListND<T>::find(const TCHAR*, int, int, int, int*)':
Source/strlist.h:402:38: error: there are no arguments to '_wcsicmp' that depend on a template parameter, so a declaration of '_wcsicmp' must be available [-fpermissive]
Source/strlist.h:402:38: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
It comes up a few times. This is one of the code parts the function refers to in "strlist.h":
if (case_sensitive)
res = _tcscmp(str, pCurr);
else
res = _tcsicmp(str, pCurr);
It's weird how it's brother "_wcscmp" is declared, but "_wcsicmp" is not declared in this scope. There are also some "'_swprintf' was not declared in this scope" errors, I would change these to "wsprintf", but is this a good function or should a different one be used?

What about adding "|| !defined _WIN32" to line 53 in tchar.h? Because swprintf is recongnised under linux.


I also noticed on linux, swprintf also requires a max length argument:

int swprintf(wchar_t *wcs, size_t maxlen, const wchar_t *format, ...);
I quick dodgied the code (with #warning tags for stuff I changed or removed) to see what other errors I got, and it looks like build.cpp has lots of errors there. Also I had to comment out line 246 in Sconstruct because "tchar.h" doesn't exist in the build directory. And all the TEXT() macros that are in the source files I have been changing to _T(), because that is supported under linux.

The *icmp stuff is not really part of the standard, the string support sucks.

Here is another diff, should probably apply it to svn trunk and not alpha 1 if you can.

Not sure what to do about swprintf, I'll have to think about it some more...


you could try this

#ifndef _WIN32
int swprintf(wchar_t*buf, const wchar_t*fmt, ...) // non-standard overloaded version for MSVC compatibility
{
va_list val;
va_start(val, fmt);
int res = vswprintf(buf, -1, fmt, val);
va_end(val);
return res;
}
#endif

So went and downloaded the trunk source-tree, and added both of those diff's you gave me to a fresh copy.

I put that function into "Source/util.cpp" and it's prototype in "Source/util.h", it still gave a compile error saying it's undeclared, so I changed line 53 in "tchar.h" to

#if (defined(_MSC_VER) && (_MSC_VER<=1310)) || defined(__MINGW32__) || !defined _WIN32
and it compiles without an error.

So far these are the files that are compiling successfully (in this order):
scons: Cleaning targets ...
Removed build/urelease/halibut/biblio.o
Removed build/urelease/halibut/bk_xhtml.o
Removed build/urelease/halibut/contents.o
Removed build/urelease/halibut/error.o
Removed build/urelease/halibut/help.o
Removed build/urelease/halibut/index.o
Removed build/urelease/halibut/input.o
Removed build/urelease/halibut/keywords.o
Removed build/urelease/halibut/licence.o
Removed build/urelease/halibut/main.o
Removed build/urelease/halibut/malloc.o
Removed build/urelease/halibut/misc.o
Removed build/urelease/halibut/style.o
Removed build/urelease/halibut/tree234.o
Removed build/urelease/halibut/ustring.o
Removed build/urelease/halibut/version.o
Removed build/urelease/halibut/halibut
Removed build/urelease/Docs/html/IndexPage.html
Removed build/urelease/Docs/html/Contents.html
Removed build/urelease/Docs/html/Chapter1.html
Removed build/urelease/Docs/html/Chapter2.html
Removed build/urelease/Docs/html/Chapter3.html
Removed build/urelease/Docs/html/Chapter4.html
Removed build/urelease/Docs/html/Chapter5.html
Removed build/urelease/Docs/html/AppendixA.html
Removed build/urelease/Docs/html/AppendixB.html
Removed build/urelease/Docs/html/AppendixC.html
Removed build/urelease/Docs/html/AppendixD.html
Removed build/urelease/Docs/html/AppendixE.html
Removed build/urelease/Docs/html/AppendixF.html
Removed build/urelease/Docs/html/AppendixG.html
Removed build/urelease/Docs/html/AppendixH.html
Removed build/urelease/Docs/html/AppendixI.html
Removed build/urelease/makensis/7zip/7zGuids.o
Removed build/urelease/makensis/7zip/7zip/Common/OutBuffer.o
Removed build/urelease/makensis/7zip/7zip/Common/StreamUtils.o
Removed build/urelease/makensis/7zip/7zip/Compress/LZ/LZInWindow.o
Removed build/urelease/makensis/7zip/7zip/Compress/LZMA/LZMAEncoder.o
Removed build/urelease/makensis/7zip/7zip/Compress/RangeCoder/RangeCoderBit.o
Removed build/urelease/makensis/7zip/Common/Alloc.o
Removed build/urelease/makensis/7zip/Common/CRC.o
Removed build/urelease/makensis/DialogTemplate.o
Removed build/urelease/makensis/Plugins.o
Removed build/urelease/makensis/ResourceEditor.o
Removed build/urelease/makensis/ResourceVersionInfo.o
Removed build/urelease/makensis/ShConstants.o
scons: done cleaning targets.
Next on the fail list is build.cpp, which gives all these errors (I combed out the duplicates to save some space):
g++ -o build/urelease/makensis/build.o -c -Wno-non-virtual-dtor -Wall -O2 -DNSISCALL="__attribute__((__stdcall__))" -D_UNICODE -DUNICODE -DMAKENSIS -D_WIN32_IE=0x0500 -Ibuild/urelease/config Source/build.cpp
Source/build.cpp: In member function 'void CEXEBuild::initialize(const TCHAR*)':
Source/build.cpp:388:44: error: '_wgetenv' was not declared in this scope
Source/build.cpp:394:16: error: invalid conversion from 'const char*' to 'wchar_t' [-fpermissive]
/usr/include/c++/4.6/bits/basic_string.h:560:7: error: initializing argument 1 of 'std::basic_string<_CharT, _Traits, _Alloc>& std::basic_string<_CharT, _Traits, _Alloc>::operator=(_CharT) [with _CharT = wchar_t, _Traits = std::char_traits<wchar_t>, _Alloc = std::allocator<wchar_t>, std::basic_string<_CharT, _Traits, _Alloc> = std::basic_string<wchar_t>]' [-fpermissive]
Source/build.cpp: In member function 'int CEXEBuild::add_string(const TCHAR*, int, UINT)':
Source/build.cpp:487:33: error: '_wcsdup' was not declared in this scope
Source/build.cpp: In function 'char* convert_processed_string_to_ansi(char*, const TCHAR*, WORD)':
Source/build.cpp:533:90: error: cannot convert 'const TCHAR* {aka const wchar_t*}' to 'LPCWSTR {aka const short unsigned int*}' for argument '3' to 'int WideCharToMultiByte(UINT, DWORD, LPCWSTR, int, LPSTR, int, LPCSTR, LPBOOL)'
Source/build.cpp:543:34: error: 'LOBYTE' was not declared in this scope
Source/build.cpp:544:34: error: 'HIBYTE' was not declared in this scope
Source/build.cpp: In member function 'int CEXEBuild::preprocess_string(TCHAR*, const TCHAR*, WORD)':
Source/build.cpp:655:69: error: 'MAKEWORD' was not declared in this scope
Source/build.cpp: In member function 'int CEXEBuild::add_label(const TCHAR*)':
Source/build.cpp: In member function 'int CEXEBuild::resolve_jump_int(const TCHAR*, int*, int, int, int)':
Source/build.cpp:1364:29: error: '_wtoi' was not declared in this scope
Source/build.cpp: In member function 'int CEXEBuild::AddVersionInfo()':
Source/build.cpp:1816:112: error: no matching function for call to 'CResourceEditor::UpdateResource(LPSTR, int, LANGID&, BYTE*, int)'
Source/build.cpp:1816:112: note: candidate is:
Source/ResourceEditor.h:117:9: note: bool CResourceEditor::UpdateResource(const TCHAR*, WORD, LANGID, BYTE*, DWORD)
Source/ResourceEditor.h:117:9: note: no known conversion for argument 1 from 'LPSTR {aka char*}' to 'const TCHAR* {aka const wchar_t*}'
Source/build.cpp: In member function 'int CEXEBuild::ProcessPages()':
Source/build.cpp:2186:10: error: no matching function for call to 'CResourceEditor::GetResource(LPSTR, int, int)'
Source/build.cpp:2186:10: note: candidate is:
Source/ResourceEditor.h:118:9: note: BYTE* CResourceEditor::GetResource(const TCHAR*, WORD, LANGID)
Source/ResourceEditor.h:118:9: note: no known conversion for argument 1 from 'LPSTR {aka char*}' to 'const TCHAR* {aka const wchar_t*}'
Source/build.cpp: In member function 'int CEXEBuild::pack_exe_header()':
Source/build.cpp:2505:28: error: '_wremove' was not declared in this scope
Source/build.cpp:2511:26: error: '_wremove' was not declared in this scope
Source/build.cpp: In member function 'int CEXEBuild::write_output()':
Source/build.cpp:2947:7: error: 'LPTSTR' was not declared in this scope
Source/build.cpp:2947:14: error: expected ';' before 'cmdstr'
Source/build.cpp:2948:14: error: expected ';' before 'arg'
Source/build.cpp:2949:11: error: 'arg' was not declared in this scope
Source/build.cpp:2952:9: error: 'cmdstrbuf' was not declared in this scope
Source/build.cpp:2952:30: error: expected ';' before 'malloc'
Source/build.cpp:2958:47: error: 'cmdstr' was not declared in this scope
Source/build.cpp:2965:49: error: 'cmdstr' was not declared in this scope
Source/build.cpp:2974:12: error: 'cmdstrbuf' was not declared in this scope
scons: *** [build/urelease/makensis/build.o] Error 1
scons: building terminated because of errors.

This should contain all fixes so far except swprintf.


because "tchar.h" doesn't exist in the build directory.
I don't really know what this means. nsis-version.h?

Yeah, Sconstruct writes "#include "tchar.h"" into "nsis-version.h", but tchar.h is in the source directory, not the current directory ("build/urelease/config").

I'll add that patch now and get back to you.


So I added that patch you gave me, and I had to add #include "tchar.h" and #include "utf.h" to "ResourceVersionInfo.cpp" for it to compile with no errors.

That Sconstruct patch has caused a problem, these two lines:

defenv.Append(NSIS_CPPDEFINES = [('PREFIX_CONF', 'L"%s"' % defenv.subst('$PREFIX_CONF'))])
defenv.Append(NSIS_CPPDEFINES = [('PREFIX_DATA', 'L"%s"' % defenv.subst('$PREFIX_DATA'))])
gives this as it's output in "nsis-defines.h":
definedlist.add(_T("PREFIX_CONF"), _T("L"/usr/local/etc""));
definedlist.add(_T("PREFIX_DATA"), _T("L"/usr/local/share/nsis""));
Which of course causes a few compiler errors.
I'm still getting these errors in build.cpp (I combed the duplicates to save space):
Source/build.cpp:1816:112: error: no matching function for call to 'CResourceEditor::UpdateResource(LPSTR, int, LANGID&, BYTE*, int)'
Source/build.cpp:1816:112: note: candidate is:
Source/ResourceEditor.h:117:9: note: bool CResourceEditor::UpdateResource(const TCHAR*, WORD, LANGID, BYTE*, DWORD)
Source/ResourceEditor.h:117:9: note: no known conversion for argument 1 from 'LPSTR {aka char*}' to 'const TCHAR* {aka const wchar_t*}'
Source/build.cpp:2186:10: error: no matching function for call to 'CResourceEditor::GetResource(LPSTR, int, int)'
Source/build.cpp:2186:10: note: candidate is:
Source/ResourceEditor.h:118:9: note: BYTE* CResourceEditor::GetResource(const TCHAR*, WORD, LANGID)
Source/ResourceEditor.h:118:9: note: no known conversion for argument 1 from 'LPSTR {aka char*}' to 'const TCHAR* {aka const wchar_t*}'
[edit] Turns out these are related to the MAKEINTRESOURCE macros in "Platform.h", and I've come up with a fix in "Platform.h" on line 491. The macro is basically a type-cast, so I just made up another that works for wchar_t (don't know if this will work at runtime though). The "D" suffix is obviously for 'define':
#ifndef _UNICODE
# define MAKEINTRESOURCED MAKEINTRESOURCEA
#else
# define MAKEINTRESOURCED(i) ((wchar_t*)((ULONG_PTR)((WORD)(i))))
#endif

#ifndef RT_BITMAP
# define RT_BITMAP MAKEINTRESOURCED(2)
#endif
#ifndef RT_ICON
# define RT_ICON MAKEINTRESOURCED(3)
#endif
#ifndef RT_DIALOG
# define RT_DIALOG MAKEINTRESOURCED(5)
#endif
#ifndef RT_GROUP_ICON
# define RT_GROUP_ICON MAKEINTRESOURCED(14)
#endif
#ifndef RT_VERSION
# define RT_VERSION MAKEINTRESOURCED(16)
#endif

Oh and I managed to fix "pluginapi.c" from trying to compile on linux. I changed line 691 in Scontruct from this:

for plugin in plugin_libs + plugins:
To this:
for plugin in plugin_libs and plugins:

New Diff, I believe I fixed the tchar.h path issue and maybe messed up something else ;)


Yeah something else did mess up:

In file included from Source/util.h:25:0,
from Source/DialogTemplate.cpp:21:
Source/ResourceEditor.h: In member function 'bool CResourceEditor::UpdateResource(const WCHAR*, WORD, LANGID, BYTE*, DWORD)':
Source/ResourceEditor.h:129:28: error: cast from 'const WCHAR* {aka const short unsigned int*}' to 'WORD {aka short unsigned int}' loses precision [-fpermissive]
Source/ResourceEditor.h: In member function 'BYTE* CResourceEditor::GetResource(const WCHAR*, WORD, LANGID)':
Source/ResourceEditor.h:134:25: error: cast from 'const WCHAR* {aka const short unsigned int*}' to 'WORD {aka short unsigned int}' loses precision [-fpermissive]

Also, the compile system stops on the first error encountered, so several files still need to be compiled. For one, I know "dirreader.cpp" will need it's function prototypes changed, and "script.cpp" isn't being compiled yet either, along with a few others like "lineparse.cpp" and "lang.cpp".


I have also been working on some stuff and I have made a .txt file that should describe everything that's wrong (though I might have missed something) and a few minor fixes that I've done. It's over 1600 lines but 3/4 of it includes one of the patches you gave me.


When I compile my existing projects with the new NSIS version 3.0a1, it prints only several lines in the output window of the editor. With the older version 2.46 this is different. I see a lot of prints during the whole compilation. Of course I don't read all of them, but this can give me information what the compiler is doing currently. My script is huge and it needs probably 7-8 minutes for compilation and without prints with V3.0a1, it looks that it hangs and I don't know when it will finish. So is this behavior expected? Can I enable the prints similar to V2.46?


Originally posted by TrifonovS
When I compile my existing projects with the new NSIS version 3.0a1, it prints only several lines in the output window of the editor. With the older version 2.46 this is different.
This change is listed in the release notes. It should also compile a little faster without all the prints.

Use makensis -v4 foo.nsi to print everything...

I think that there is a problem with some existing plug-ins when the unicode support is enabled (Unicode true). For example Aero plug-in can not show correct some German letters. The problem is not in my code, because when I don't enable Aero plug-in the branding text is shown correct. I also had a problem with the caption-text of the inetc plug-in. When I disable unicode support all works fine. But when I enable it, the installer stops with a strange message.


Originally posted by TrifonovS
I think that there is a problem with some existing plug-ins when the unicode support is enabled (Unicode true). For example Aero plug-in can not show correct some German letters. The problem is not in my code, because when I don't enable Aero plug-in the branding text is shown correct. I also had a problem with the caption-text of the inetc plug-in. When I disable unicode support all works fine. But when I enable it, the installer stops with a strange message.
I thought Afrow UK already said this was a bug in his plugin?

For anything else, post some example code or something, we are not mind readers...

I thought Afrow UK already said this was a bug in his plugin?
This was for showing of the ampersand symbol. I though that this is different problem.

For anything else, post some example code or something, we are not mind readers...
Of course, you are right. I was under a big time pressure with my project and I came back to NSIS V2.46. I will try to find time to install again NSIS V3.0a1 and to prepare simple code that can reproduce the problem (at least this one with inetc plug-in). I just though that might be useful to write some notes, because probably somebody already knows about these problems.

So here is simple script that shows a strange behavior of the inetc plug-in. It just tries to download SP3 for Windows XP from a predefined location. When Unicode is true, after execution, it doesn't download anything, but just exits and the returned value is shown in a message box. The return value is unreadable. But when Unicode is set to false, the downloading is started. At the end (or if it is interrupted) the returned value is readable as it is expected.


Originally posted by TrifonovS
So here is simple script that shows a strange behavior of the inetc plug-in. It just tries to download SP3 for Windows XP from a predefined location. When Unicode is true, after execution, it doesn't download anything, but just exits and the returned value is shown in a message box. The return value is unreadable. But when Unicode is set to false, the downloading is started. At the end (or if it is interrupted) the returned value is readable as it is expected.
...and you are using the Unicode version of the plugin?

When strings are wrong/corrupted/1 character long you should always make sure that you are using the correct plugin that matches your target.

*Unicode true
*!addplugindir to inetc unicode folder
*change $TEMP\ServicePack3 to $TEMP\Download in inetc::get call
and it works...

That's right! I really forgot that I have to use an Unicode version of the plug-in. Thanks a lot and sorry for my mistake.