We use some Pascal Scripting in our Inno Setup 5.5.8 and in our Code section are some Integer variables. In this variable we store the actual date and time in this format: YYMMDDhhmm. Since the year 2022 the value is too big for an Integer. Is there a Int64 in Inno Setup?
Unicode version of Inno Setup has Int64.
For example, see StrToInt64.
There's only the Unicode version in recent versions of Inno Setup. Though 5.5.8 still had Ansi version too. We do not know what version you are using, but I guess the Ansi one, otherwise you won't be asking. You should be using the Unicode version in any case. Int64 was introduced in Inno Setup 5.5.3. Btw, Inno Setup 5.5.8 is 6 years old. Do not use it.
Imo, storing timestamp as an integer in YYMMDDhhmm format is not a good idea. Why don't you use a string?
I am using Inno Setup version 6 and earlier I was using unofficial translation files from Inno Setup website for Korea and Chinese traditional languages they worked fine but we have our own translation team which verified the translation and converted them into Unicode. But the characters are not being converted on final setup and being displayed as it is.
Chinese traditional Language file can be downloaded from this link
UPDATE: Seems like Inno Setup does not have support for UTF-16 (Unicode Inno Setup)
Is there any option within Inno Setup to make it work?
Your ISL file has been wrongly converted to UTF-8 and contains only code characters instead of real ones.
I have converted few strings and resaved the file:
I am using Inno Setup to create an installer file. The version I am using is 5. When the installer is installed in the Windows operating system, the AppPublisher is not displayed in correctly. Here is the sample code I wrote:
[Setup]
AppId={{23ASEADS-AB2}
AppName=EmptyProgram
AppVersion=1
AppPublisher=नमस्ते
However, I see something like this नमसà¥à¤¤à¥‡ instead of नमस्ते. Is there any solution for this situation? I also tried to use Hex value like :
AppPublisher=#$92892e93894d924947
But it ended up printing the same value and not the converted value. I would appreciate if anyone can help me with this. Thank you.
As #Andrew has commented:
Make sure you are using the latest Unicode version of Inno Setup and;
Make sure your script file is encoded as UTF-8 with BOM.
Are there any disadvantages of the Inno Setup Unicode version compared to the Ansi version?
Or what is the reason that still both versions are offered in parallel and not only the Unicode one is left?
Are there any potentials problems, when using the Unicode version for my existing Inno Setup project developed with the Ansi version?
There are no real disadvantages. There are mostly advantages. Obviously the fact that the Unicode version is not limited to legacy Ansi character set. See below for details.
If you are starting new Inno Setup project, always use the Unicode version. There is no reason to use the Ansi version for new projects. Actually there's no Ansi version for the latest Inno Setup 6 anymore.
The reason, why Ansi version of Inno Setup was still available for long time, was that the Pascal Script code of Ansi and Unicode versions are not 100% compatible. Mostly they are, but there are differences.
So if your existing installer script does not have any Pascal Script code (there's no [Code] section in your .iss), you can (and should) switch to the Unicode version straight away.
If you have some Pascal Script code, you should be more careful. See below for details.
Why you want to use Unicode version
For example of problems with the Ansi version, if you run Japanese-only installer built with Ansi version of Inno Setup on English system, you will get:
See also Inno Setup installator has wrong text encoding.
For the same reason, the Ansi version will not be able to create files with names containing characters, that are not present in the legacy Ansi character set of the target machine.
The Unicode version does not have these problems, as documented in the Unicode Inno Setup article:
Key features of Unicode Inno Setup are its ability to display any language on any system regardless of the system code page, and its ability to work with Unicode filenames. One could consider Unicode Inno Setup as the new standard Inno Setup and Non Unicode Inno Setup as an old special Inno Setup for those who want the very smallest size possible.
Also for Inno Setup 6, there is no Ansi version at all, so if you want to use the latest version of Inno Setup with all its new features, you need to switch to the Unicode version along.
Additionally there are some small improvements in the Unicode version Pascal Script. They are documented in the Unicode Inno Setup article. On top of that, there are few undocumented improvements:
Inc/Dec functions/statements. See Inc function Inno Setup.
Better Variant support. For example, see Inno Setup: Iterate through array of type Variant (from OleObject) or Is there a way to read the system's information in Inno Setup.
Better high-DPI (and non-standard screen in general) support. For example, see Inno Setup taskbar icon blurred or Inno Setup Installer has squished window on XP?
Ranges in case statement: "colon (':') expected" compiler error on character range in case statement in Inno Setup Pascal script.
in operator with a constant set: It seems that in Ansi version, you always get "Type mismatch" error, unless you store the set into a set of variable first.
Note, that while the Unicode version does support the in operator with a constant set, it does not support ranges in the set expression, so X in [1, 2, 3] is possible, but X in [1..3] is not possible, you will get "Closing square bracket (']') expected."
TLabel has transparent background in the Unicode version. See Inno Setup - Transparency under text in page name and description labels
Calling standard event handlers of some custom wizard pages is not possible in Ansi version, while is work fine in Unicode version. What can be useful for things like Inno Setup event that is generated when folder is browsed on TInputDirWizardPage?
Better support for RTF. See How to add clickable links to custom page in Inno Setup using RichEditViewer?
Possible problems in Pascal Script code
There are few areas, where problems can emerge in the Pascal Script code:
Any calls to DLL functions that take string parameters - string and PChar types. AnsiString should be ok, as it's the same in the Unicode version.
In Unicode version, PChar was renamed to PAnsiChar.
If you invoke any Windows API function that uses strings, you should switch to its Wide version. E.g. use GetFileAttributesW, instead of GetFileAttributesA. There's no PWideChar type. So if your declaration used PChar type in Ansi version, and you switch to Wide version of the function, you have to use string type instead. Inno Setup will automatically marshal it to the LPCTSTR (or similar), aka the PWideChar.
The declaration below is correct in Ansi version, but wrong in Unicode version, as the GetFileAttributesA takes PAnsiChar, but the string marshals to PWideChar in the Unicode version.
function GetFileAttributes(lpFileName: string): DWORD;
external 'GetFileAttributesA#kernel32.dll stdcall';
For a full example and solution, see Inno Setup FileExists unable to find existing file.
In rare cases, that you are calling a function that has an out PWideChar parameter (var S: PWideChar), it's very tricky to use it, without the actual PWideChar type, as in this case you cannot use the string marshaling. But it's doable, see Constant for AppData\LocalLow in Inno Setup?
Similarly to Windows API, some 3rd party libraries also provide a separate Unicode version with Unicode strings in its API. For example ISSkin has ISSkinU.dll. See Getting ISSkin to work with latest Inno Setup Unicode.
Any code that uses string type as byte array (as in Unicode version, the string is wide char (2-byte) array). That's mostly concern, only if your code uses TStream class methods like:
function Read(Buffer: String; Count: Longint): Longint;
function Write(Buffer: String; Count: Longint): Longint;
procedure ReadBuffer(Buffer: String; Count: Longint);
procedure WriteBuffer(Buffer: String; Count: Longint);
These methods should have really been re-declared with AnsiString. Looks like a bug to me.
To make these methods usable in Unicode version, use BufferToAnsi function by #TLama that is used in many existing answers, like:
Inno Setup LoadStringFromFile fails when file is open in another process
Read bytes from file at desired position with Inno Setup
For another approach, see see Writing binary file in Inno Setup
Unicode version does not allow set of char variable (as set is not allowed for multi-byte types). Though interestingly it supports set of char constants in expressions. See "Type mismatch" error on "set of char" in Pascal Script of the Inno Setup Unicode version.
FloatToStr uses a locale specific decimal separator in Ansi version, while always a dot in Unicode version.
Unicode version is more strict about use of semicolons. The Ansi version tolerates some missing semicolons, so it can compile even code that is not 100% syntactically correct in this respect.
If your code does not use any of the above, and you have your semicolons right, you should not have any problems with the Unicode version.
Last minor thing is that the Unicode version creates slightly larger installers. And Inno Setup 6 yet bit larger. See Why is installer compiled in Inno Setup 6 one MB larger than in Inno Setup 5
After the clear answer here that there is not a real reason to stay with the Ansi Inno Setup version, we switched the beta setup of our product to the Unicode version yesterday and did not see any problems in our own tests.
But one of our beta tester reported now today that this version crashes while creating a firewall exception with following code:
try
FirewallObject := CreateOleObject('HNetCfg.FwAuthorizedApplication');
FirewallObject.ProcessImageFileName := 'C:\Program Files (x86)\FS-FlightControl\FS-FlightControl.exe';
FirewallObject.Name := 'FS-FlightControl';
FirewallObject.Scope := NET_FW_SCOPE_ALL;
FirewallObject.IpVersion := NET_FW_IP_VERSION_ANY;
FirewallObject.Enabled := True;
FirewallManager := CreateOleObject('HNetCfg.FwMgr');
FirewallProfile := FirewallManager.LocalPolicy.CurrentProfile;
FirewallProfile.AuthorizedApplications.Add(FirewallObject);
except
Log('Error setting firewall exception: ' + GetExceptionMessage);
end;
If this code is executed the setup crashes with
Exception code: 0xc0000005
Error offset: 0x0005584c
in the Windows event log. I asked the beta tester to run the setup with "/LOG" parameter and there is no error shown there at all. Just the complete setup crashes.
To be sure it was the change from Ansi to Unicode causing this problem, we send the beta tester another identical build, just compiled with the Ansi version and no crash there.
So there seems to be some more (negative) side effects of the Unicode version.
We could not reproduce this issue ourselves, just one of our beta testers using this setup:
https://www.fs-flightcontrol.com/download/FS-FlightControl-Beta-InnoUnicode.exe
Just keep the firewall exception checked and it should crash somewhere near the end of the setup process.
Based on the setup log file the tester sent he has Windows version 10.0.14393. As I wrote no traces of this problem can be found in the log, it just crashes.
Are there any direct consequences of toggling between Unicode, MBCS, and Not Set for the VS C++ compiler settings Configuration Properties->General->Character Set, apart from the setting of the _UNICODE, _MBCS and _T macros (which then, of course, indirectly has consequences through the generic text mappings for string functions)?
I am not expecting it to, but since the documentation says "Tells the compiler to use the specified character set", I'd like to be certain that, specifically, it doesn't have any influence on how any literal non-ASCII text put into strings or wstrings is encoded? (I am aware that non ASCII literals in the source is not portable, but am maintaining a solution where this is used heavily.)
Thanks in advance.
No, it only affects the macro definitions. Which in turn can have wide-ranging effects on anything from <tchar.h> or the Windows T string pointer types (LPTSTR etc).
If you use any non-ASCII codes in your string literals then you depend heavily on the way the compiler decodes the text in your source code file. The default encoding it assumes is your system code page as configured in Control Panel + Regional and Language options. This will not work well when your source code file ever strays too far away from your machine. Specifying utf8 with a BOM is wise so this is never a problem. In the IDE that's set with Save As, arrow on the Save button, "Save with encoding", pick 65001. Support for utf8 encoded source code files is spotty in older versions of C++ compilers.
For unadorned strings, C++ follows C: it's ASCII. If you wrap them with anything, the game changes.
C++0x standardises Unicode strings. UTF in particular. This is a new feature.