Friendly Windows Minimum Version in InnoSetup - inno-setup

I can set the minimum version required (for example XP SP3) in Inno-Setup by going
MinVersion=0,5.01.2600
However, that leads to the rather unfriendly Message Box:
This program requires Windows NT version 5.1.2600 or later.
Is there any way to have this say instead:
This program requires WindowsXP Service Pack 3 or later.

This string is named WinVersionTooLowError and is defined as
This program requires %1 version %2 or later.
You can redefine it in the [Messages] section.

MinVersion=0,5.01.2600
Does not work, try this in [Setup] area, it can be used in quite a number of other areas in inno setup also.
MinVersion=0,5.1.2600

Related

How can I fix Microsoft Visual C++ 2017 X64 Minimum Runtime error during installing Redistributable packages (VC_redist.x64.exe, VC_redist.x86.exe)?

During installation I get "The feature you are trying to use is on a network resource that is unavailable" and prompt to specify some path to vc_runtimeMinimum_x64.msi. After providing some path to required file I get error states that this file doesn't match required version Minimum Runtime 14.14.26405.
I finally found the solution reading this question: Install vcredist_x64 with VS2017 installer project
I realized that specific VC_Redist.x64.exe files could be downloaded by links like https://aka.ms/vs/15/release/26405.00/VC_Redist.x64.exe, where 26405.00 is exactly the version I was required to fix. Note, that you need version from error text after clicking OK, not from window title.
And the last point is that this exe must be executed from cmd with argument /repair to help me with this issue. Regular execution by double click made no effect.
I found the solution elsewhere. It said to
Fix problems that block programs from being installed or removed
https://support.microsoft.com/en-us/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
download troubleshooter button on the link.
Run it - choose option - have problem with installing - it lists programs - choose the missing / problematic visual c++ runtimes in the list
it will run and get fixed.
Repeat for each visual c++ you having problems with. I ran the program multiple times.
I have to thank this comment section for helping me with this problem, since I have not been able to work more efficently with my school, since I din't know what and if a single file somewhere deep down in the computer had to be deleted for this program to work.

Text corruption in LLVM 7.0.1 installer

I have tried install llvm 7.0.1 on Windows 10.
But the installer has text corruption like below.
It make so harder to install.
How do I fix it?
I using Windows 10 1809, chcp is 65001.
I using Japanese.
I have enabled "Use Unicode UTF-8 for worldwide language support" in Region settings".
Is this change cause of the error?
But A installer of other application does not be text curruption.
Update:
The Picture of installer with compatibility mode (Windows XP SP3)
That LLVM installer is not a Unicode NSIS installer. The LLVM team can fix it by adding Unicode True to their NSIS script.
That LLVM installer looks like it supports multiple languages (I could not find it's source, it might be using CMake/Ninja) and NSIS does try to guess the correct language but this is based on the return value of GetUserDefaultUILanguage() and not the active codepage.
I could not replicate your issue on build 18290 (after changing to UTF-8 and rebooting I verified that GetACP() returns 65001) but this is probably because my system is detected as English by NSIS.
Based on the (N) in your Next button in your screenshot I'm going to guess that your UI language is detected as Chinese or Japanese?
Without more information about your system it is hard to guess if this is a bug in NSIS or Windows. NSIS is a relatively normal application and does not call MultiByteToWideChar on its interface strings (IIRC).
Edit:
By forcing a installer to pick Japanese I can replicate your issue. The solution for this issue is to switch your "language for non-Unicode programs" back to Japanese if you wish to install this application using Japanese as the display language. Another solution you can try is to set the locale for a single application. AppLocale was Microsoft's solution to this but it is not supported on Windows 10 but there are other alternatives out there.
When building a NSIS installer without Unicode support the program stores the text internally as raw bytes encoded with the codepage of the specific language. At run time it uses functions like SetWindowTextA to set the text of UI elements. This is how non-Unicode applications have worked since the dawn of time on Windows. All non-Unicode programs that display text outside the ASCII range will have the same issue unless they have been specifically written to support UTF-8 as the active codepage (which is unlikely since it is a new feature). This feature is only useful for console applications and ported POSIX applications that assume that the narrow string is UTF-8 encoded.
Too long for a comment.
UPDATE: Looking at this a little, I am wondering if the problem is a font corruption issue. There is a description of rebuilding the font cache here: http://www.trishtech.com/2013/11/rebuild-fonts-cache-windows-8/. I think you must install a good copy of the font file first though? You do that by copying the font files into the Fonts folders I believe. I will check with Anders what font NSIS uses.
Similar issue with an MSI file: Windows Installer ugly font rendering.
Compatibility Mode: Pretty sure that UTF8-setting would cause it. I don't think it would work, but the first thing I would try would be to run the executable in compatibility mode.
Locate the setup.exe in question.
Right click the EXE, hold right mouse button down, now drag to empty desktop area and release mouse button. Click "Create Shortcut Here".
Right click Shortcut => Properties => Compatibilty tab.
Try various combinations of "Run program in compatibility mode for..."
I would try "Windows XP" highest service pack first. Click OK when done.
Now double click the shortcut to launch the executable and see what happens.

InstallShield adding diffrerent prerequisite for x86 and x64

I want to add different version of Crystal Reports as a setup prerequisite using InstallShield depending on platform. For x86 32bit version should be installed, for x64 - 64bit.
What kind of condition should I add to do so? I've found that I can select particular OS as condition but there is no option to just select 32 or 64 bit.
Thanks in advance.
UPD1: In InstallShield I can choose the following types of condition:
Check if registry entry exists. I wanted to check for WoW6332Node
but then I found that this node can be listed in 32bit OS:
http://support.microsoft.com/kb/2582176 Also I found that I can
check some registry entries
https://superuser.com/questions/290906/check-if-32-or-64-bit-windows-os-via-registry/290929
but I'm not sure that they present in all windows versions.
Check if certain file exists. I can check some file in Program Files
(x86) folder to detect 64bit OS, but it's not a good idea in my
opinion.
I think you can use the VersionNT64 property for this.
More details can be found here:
http://msdn.microsoft.com/en-us/library/aa372497(v=vs.85).aspx
Edit: As it can be seen in the documentation, this property is only set on a 64-bit computer otherwise it is empty.
EDIT: 13.VIII.2014
After the prerequisite has been selected to be added to your installation package, a feature has been assigned.
So, you can go in the "Features" view and select the created feature. I can see it has a Condition field, most likely there you can use the VersionNT64 property.

Silent Installer with custom selection

Currently my installer is need user to choose which type of setting they want to use when install. Lets say got setting A,B and C.
If want to make this in silent installer. Is there any method can use?
I'm using install shield.
You can set PUBLIC PROPERTIES inside the MSI file from the msiexec.exe command line like this:
msiexec /i test.msi /qn TESTPROPERTY=1
These properties are the ones you have hooked up to values input in the GUI. They are now set by the command line (or defaults are used from the Property table) and the entire GUI section of the MSI gets skipped on install.
Here is a sample showing how INSTALLDIR is hooked up to the GUI (Wise for Windows Installer shown, same concept in Installshield and other MSI tools):
To play around with complex command lines for msiexec.exe I always recommend this nifty tool from Altiris: http://www2.wise.com/filelib/WICLB.exe - broken link, resurrected from Wayback Machine, seeing as the tool was freeware I assume that is legal - (see a screenshot of it here: installation using msi.exec open help options every time). Please run the download by virustotal.com for safety.

Pinned shortcut in MFU (Most Frequency Used) Start menu after NSIS setup

A NSIS created deployment setup, installs two executable. After setup, one of them appears in the MFU (Most Frequency Used) list of the start menu. But I don't that.
Is it possible to remove this link or prevent it during install? I have found this document from Microsoft but is very difficult to code this (my knowable is .NET/C#). Or maybe is it possible with NSIS? All tips are welcome.
You could use WriteRegStr to write the NoStartPage value but it is usually not something you should set explicitly except if this .exe is some kind of generic host program for plugin modules.
Is it possible that you just tested the program on this particular machine so many times that the program ended up on the MFU list?
There is no official API to add things to the MFU list and NSIS does not do anything to try to get the program listed there...

Resources