Unicode

Originally Posted by MSG View Post

So, I guess it's unlikely that there will ever be a new version of NSIS, then?

We can still do ansi builds...

I'm all for that, I'm sure, but I'm thinking that would require some amount of decisive effort on the devs' part, what with the year and a half hiatus?

Originally Posted by MSG View Post

I'm all for that, I'm sure, but I'm thinking that would require some amount of decisive effort on the devs' part, what with the year and a half hiatus?

All the unicode changes are inside #ifdef UNICODE blocks...

Originally Posted by Anders View Post

We can still do ansi builds...

Except for on Linux (needs tchar.h)... hmm, mingw-w64 has tchar.h, I guess the cross-compile checks are in need of an update for the new toolchains.

Originally Posted by pabs View Post

Except for on Linux (needs tchar.h)... hmm, mingw-w64 has tchar.h, I guess the cross-compile checks are in need of an update for the new toolchains.

I'm going to try to fix all the ansi problems, but I'm not sure if we should move to mingw-w64 or stick with the original. Anyways, we probably need our own tchar.h or hacks in platform.h since not all compilers/CRT agree on how swprintf works.

NSIS Unicode High-DPI Awareness?

Hello all,

Is there any way to enable High-DPI awareness in an NSIS Unicode installer? Currently it seems to rely on display scaling in Windows 7 which does not look really good on high-DPI screens.

High-DPI awareness requires a manifest as describe in the article at:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx (Declaring DPI Awareness)

I tried to use mt.exe to apply the DeclareDPIAware.manifest but after that I get a message that the installer integrity check failed.

If this is not currently supported, could this be considered for an upcoming version? Thank you.

Originally Posted by noeld View Post

Hello all,

Is there any way to enable High-DPI awareness in an NSIS Unicode installer? Currently it seems to rely on display scaling in Windows 7 which does not look really good on high-DPI screens.

You could try system::call 'user32::SetProcessDPIAware()' in .onInit, if that does not work you two other options:

A) Use !packhdr and resource hacker to change the manifest (Or maybe mt.exe, who knows)

B) Recompile from source

Originally Posted by pabs View Post

Except for on Linux (needs tchar.h)... hmm, mingw-w64 has tchar.h, I guess the cross-compile checks are in need of an update for the new toolchains.

I'm now able to compile (ansi) with MinGW, get latest source from SVN and add these changes:

--- SConscript-HEAD
+++ /trunk/Contrib/SubStart/SConscript Thu Jun 16 19:42:13 2011
@@ -9,8 +9,7 @@
libs = Split("""
""")

-Import('BuildUtil')
-
-substart = BuildUtil(target, files, libs)
-
-env.DistributeBin(substart, names=['makensis.exe'], alias='install-compiler') # install as makensis
+if env['PLATFORM'] == 'win32': #Using cross_platform = True just to force console app in PE header...
+ Import('BuildUtil')
+ substart = BuildUtil(target, files, libs, cross_platform = True)
+ env.DistributeBin(substart, names=['makensis.exe'], alias='install-compiler') # install as makensis

And you need to rename Call.S to Call.sx if you want to compile system.dll

I did not add the substart change to SVN since it is a bit of a hack, it would be better if we actually fixed the SCons stuff.

Not sure what to do about the Call.S issue, it might be SCons/MinGW version specific.

Thanks Anders,

system::call 'user32::SetProcessDPIAware()' in .onInit and un.onInit seems to work just fine. Some text looks a bit small but this should be ok for now.

Changing default font size

Now that I am able to build a High-DPI aware NSIS, I'd like to be able to make the default fonts larger (and consequently the size of the dialog boxes) so that the text (all statics, buttons, etc.) is easier to read on large screen with high DPI.

Is it possible to change the default font size when the installer starts so that the size of the default font is adjusted based on the current custom DPI setting in Windows Control Panel? If yes, how can I do that?

Thank you.

For Win95 to 2003, the correct font to use is MS Shell Dlg @ 8pt and that is what we are using. MS messed things up with Vista (Segoe needs to be 9pt)

Could you recommend a way to handle this? Is this enough to correctly handle both low and high DPI displays? Thank you.

Originally Posted by Instructor View Post

How plugin can detect that it has been called from Unicode NSIS or from Ansi NSIS? Maybe add some new parameter in "extra_parameters" structure.

Found the workaround, maybe for someone it will be useful:

stack_t **g_stacktop;

char *g_variables;

unsigned int g_stringsize;

extra_parameters *g_pluginParms;

BOOL g_unicode;



#define EXDLL_INIT()         \

{                            \

  g_stacktop=stacktop;       \

  g_variables=variables;     \

  g_stringsize=string_size;  \

  g_pluginParms=extra;       \

  {                                                     \

    wchar_t wszPath[]=L"C:\\";                          \

    g_pluginParms->validate_filename((char *)wszPath);  \

    g_unicode=(wszPath[2] == L'\\')?FALSE:TRUE;         \

  }                                                     \

}

Or more optimized:

stack_t **g_stacktop;

char *g_variables;

unsigned int g_stringsize;

extra_parameters *g_pluginParms;

BOOL g_unicode=-1;



#define EXDLL_INIT()         \

{                            \

  g_stacktop=stacktop;       \

  g_variables=variables;     \

  g_stringsize=string_size;  \

  g_pluginParms=extra;       \

  if (g_unicode == -1)                                  \

  {                                                     \

    wchar_t wszPath[]=L"C:\\";                          \

    g_pluginParms->validate_filename((char *)wszPath);  \

    g_unicode=(wszPath[2] == L'\\')?FALSE:TRUE;         \

  }                                                     \

}

Hello.

The unicode installer works great for me, but in some locations strings are not displayed correctly.

All the calls which are displayed wrong seem to be coming from
!insertmacro INSTALLOPTIONS_WRITE "DatabaseServer.ini" "Field 1" "text" "$(MSG118)"
type calls.

Does the InstallOptions.nsh script not work for Unicode?

Thanks

Does this .ini start with a UTF16 BOM ?

The ini files were UTF-8 encoded, I converted them to ut6-16-le and it works. Thanks.

2.46.2 Released

2.46.2 is actually a fairly major release. Although based on the official NSIS 2.46 release, there has been some extensive improvements.

• For example, we've added two new commands: GetFontVersion and GetFontVersionLocal. These commands can be used to get the version information from a TTF font file. This command is valuable for those who are distributing and updating fonts with their products.
• Changed linear look-up of keyword tokens to a hash table which greatly increased NSI compilation speed. Although NSI script compilation is generally not a bottleneck in the build process, you will notice a marked improvement in NSI compilation speed.
• The log generated by the logging build now outputs a BOM at the beginning of a new log file so that many text editors can recognize the file as UTF-16LE.

Apart from these major changes, there has been some general bug fixes and improvements to translations. The source code also now builds on Microsoft Visual Studio 2010's version of C++, as well as previous versions of VC++.

You can get it from the usual place: www.scratchpaper.com.

Thanks Jim.
Already installed 😁
-Pawel

while i'm personally interested in unicode versions of these, please take this as documentation of plugins that aren't yet available 😉

-FontName
-Locate
-TextReplace
-ToolTips (source)

the sources come with each plugin unless mentioned otherwise

just find out about CallAnsiPlugin, but i can't get it to work with the locate plugin.

ansi plugin call:
locate::_Open /NOUNLOAD `${_PATH}` `${_OPTIONS}`

callansi call
CallAnsiPlugin::Call "$PLUGINSDIR\Locate" _Open /NOUNLOAD `${_PATH}` `${_OPTIONS}`
CallAnsiPlugin::Call "$PLUGINSDIR\Locate" Open /NOUNLOAD `${_PATH}` `${_OPTIONS}`

both don't work (Invalid command: locate::_Open), what am i doing wrong?

@Yathosho: You need to look at the CallAnsiPlugin documentation on the wiki, you can't just copy and paste a working ansi plugin command!

(Hint: /NOUNLOAD is not valid, read about using the * prefix, also, you need to specify the parameter count)

Even if you get all that stuff correct it might not work since CallAnsiPlugin will not work with every plugin.

Problem with the parameter /CMDHELP (Missing Commands).

When run this: makensis.exe /CMDHELP, only show this:
MakeNSIS v2.46.2-Unicode - Copyright 1995-2009 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.

Abort [message]

Hello. First of all: Thanks for the new release!

But unfortunately I just noticed that there is major bug in the 2.46.2 release:
The installer won't run under Windows 2000 anymore, while previous version (2.46.1) worked perfectly fine 😢
Error message is "Not a valid Win32 application" and installer won't even start up.

I was able to track down the problem with the help of CFF Explorer:
The OperatingSystemVersion field in the PE header is now set to 5.1 rather than 5.0 🙁

Has support for Windows 2000 been dropped intentionally (I don't hope so!) or has this happened by mistake?

(And yes, I still have users on Windows 2000. And I just figured out how to make VS2010 binaries work on Win2k)

Important info
In order to make VS2010 compiled binaries work on Windows 2000 (and WinXP RTM!), two simple steps are required:
(1) You need to set "Minimum Required Options" (in the Linker/System options) to 5.0
(2) You need to link your binary against EncoderPointer.lib in order to remove a dependency on a certain export from Kernel32.DLL which did not exist in systems prior to Windows XP with Service Pack 2 (which includes Windows 2000, of course)

Regards,
MuldeR.

Thank you, Lord Mulder. Perhaps, the best thing would be for me to build with Visual Studio 2008 for now. I personally don't need to release any software to Win2K users but I see how this is a problem. I will rebuild and re-release 2.46.2 soon. Thanks for letting me know.

Originally Posted by jimpark View Post

Thank you, Lord Mulder. Perhaps, the best thing would be for me to build with Visual Studio 2008 for now. I personally don't need to release any software to Win2K users but I see how this is a problem. I will rebuild and re-release 2.46.2 soon. Thanks for letting me know.

Thank you 👍

(BTW: You know that VS2010 can use the VS2008 toolset? The toolset can be selected in project properties)

I just released a beta version of 2.46.3. I've still compiled it using MSVC 2010 and I did not need the EncoderPointer.lib since I do not link to the standard library in exehead. So NSIS itself still requires Windows XP+ to build installers but the installer it generates should be able to run under Windows 2000. Lord Mulder, can you check this when you have the time? I've also added GetFontName and GetFontNameLocal to round out the font commands.

Originally Posted by jimpark View Post

I just released a beta version of 2.46.3.

Thanks!

Originally Posted by jimpark View Post

I've still compiled it using MSVC 2010 and I did not need the EncoderPointer.lib since I do not link to the standard library in exehead.

I see.

Originally Posted by jimpark View Post

So NSIS itself still requires Windows XP+ to build installers but the installer it generates should be able to run under Windows 2000.

Actually it needs Windows XP with Service Pack 2. The RTM version or Service Pack 1 won't work either.

(That's why you still may consider linking EncoderPointer.lib into makensis.exe)

Originally Posted by jimpark View Post

Lord Mulder, can you check this when you have the time? I've also added GetFontName and GetFontNameLocal to round out the font commands.

I just compiled an installer with NSIS v2.46.3 and it ran through on Windows 2000 just fine 🙂

Thanks for checking so quickly. If after a week of testing, I don't see any problems, I will release it. I don't think it's a problem to request WinXP SP2 for the developer boxes do you? I would like to keep moving forward with compiler updates as I move my other projects to the new tools.

On a side note, I'm considering dropping the third digit versioning and just moving forward to 2.47 and onwards. If and when the new NSIS comes out it is likely to be version 3, anyway. Besides, my code has forked enough that I don't think I can easily port over any changes from the trunk anyway. And there has been quite a lot of improvements to my code base since 2.46 came out two years ago. Kichik and I have very different philosophies on how NSIS should move forward. I personally think ANSI is dead. I don't believe in creating multiple versions of the build: big string version, logging version, logging with big string etc. I don't care about saving a few kilobytes on a setup that is a couple of megabytes big. So starting the next release, the builds will have the logging ability built in.

If the "new NSIS" you're hoping for is NSIS Unicode, I don't think it'll ever come unless the current unicode branch (your branch) gets merged into the trunk. Right now NSIS development is stalled because of this branching. If you want to continue development, please work on merging, instead of increasing the distance from trunk. You can't shoulder the entire development of NSIS on your own...