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.
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.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.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.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
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 '[email protected] 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:
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With