ANN: Inno Setup 7.0.0 preview 2 released

[Martijn Laan]

Hi,

Inno Setup 7.0.0-preview-2 has been released:

Download 64-bit edition
Download 32-bit edition

Using the 64-bit edition is recommended. As noted below, it can still build 32-bit installers.

Please report success or failure with this version by sending a quick email to inno...@googlegroups.com (preferred) or ml...@innosetup.nl. Thank you!

If you installed the 32-bit edition of preview-1, please uninstall it yourself before installing preview-2, because its AppId has changed.

Changes related to 32-bit vs 64-bit:

• The 32-bit edition of Inno Setup's own installer now supports a non-administrative install again.
• Added new System Path Redirection help topic.
• Pascal Scripting:
• Fixed an issue with the built-in TFindRec record type in 64-bit installers.
• Added the following note:
  In both 32-bit and 64-bit installers, Pascal Script records are always "packed". When calling a Windows API or external DLL function that expects aligned records, you may need to add manual padding fields. Even if this was not needed in a 32-bit installer, it may be needed in a 64-bit installer because alignment rules and field sizes differ.
• We tested support of Windows Server Core with WOW64 removed:
  In our tests on 'Windows Server 2016 Datacenter Server Core' and 'Windows Server 2025 Datacenter: Azure Edition Core', with all WOW64 features disabled and removed using DISM, 64-bit installers still function correctly, even when run in 32-bit install mode.
• Improved 'regtypelib' handling and documentation.

Other changes:

• [Setup] section directive ArchiveExtraction can now also be set to auto, the new default.
• Pascal Scripting: Added new optional OnLog parameter to the [Run] section.
• Updated the 7-Zip and LZMA SDK source code used by Inno Setup to the latest versions.
• As a proactive security measure, the compiler no longer allows .isl message files specified in the [Languages] section to contain compiler directives such as #include.
• Other minor improvements.

Please test your scripts and installers with this preview, even if you do not intend to use 64-bit installers, and report success or failure here. Thank you in advance. Especially please test and report this functionality:

• Using 64-bit install mode in a 32-bit installer.
  This is not new functionality but we did many changes related to system path redirection.
• Using 32-bit install mode in a 64-bit installer.
• Using Pascal Scripting in a 64-bit installer.
  Please do first ensure your script is actually compatible with 64-bit execution. Whatsnew (linked below) has some tips about this.

Please do not use this preview to build installers you will use in production.

Here are the general notes:

We are proud to announce the first preview of Inno Setup 7, which includes a 64-bit edition, as well as a 32-bit edition.

Both editions of Inno Setup 7 can build either 32-bit or 64-bit installers, and they can be installed side by side, and they can coexist alongside Inno Setup 6.

Additionally, support for extended-length paths was added, removing MAX_PATH limitations.

Great care has been taken to ensure maximum backward compatibility with Inno Setup 6, including backward compatibility for the extended-length path support, and compatibility between 32-bit and 64-bit installers.

For the complete list of changes, see What's new in this version?

Greetings,
Martijn Laan and Jordan Russell

[Gavin Lambert]

On Monday, March 16, 2026 at 1:49:25 AM UTC+13 Martijn Laan wrote:

• As a proactive security measure, the compiler no longer allows .isl message files specified in the [Languages] section to contain compiler directives such as #include.

Is there a way to opt out of this?  I quite like having an app-specific isl file which includes a suite-specific file which includes a company-specific file which includes the default.isl.  I know this is possible to achieve by listing the chain of files directly in the iss instead but that feels more fragile and inconvenient, since there are more places to update if you want to introduce more files.

[Gavin Lambert]

Mere moments ago, quoth I:

On Monday, March 16, 2026 at 1:49:25 AM UTC+13 Martijn Laan wrote:

• As a proactive security measure, the compiler no longer allows .isl message files specified in the [Languages] section to contain compiler directives such as #include.

Is there a way to opt out of this?  I quite like having an app-specific isl file which includes a suite-specific file which includes a company-specific file which includes the default.isl.  I know this is possible to achieve by listing the chain of files directly in the iss instead but that feels more fragile and inconvenient, since there are more places to update if you want to introduce more files.

(I don't quite use all those layers myself, but I have used up to three layers and I can easily imagine someone wanting more.)

Another handy use case for #include in isl (which I don't do myself, but I can easily imagine) is if you're using a designer tool to create separate .isd files for custom pages, you might want each page to have its own separate .isl file, which becomes very messy to cram into the MessagesFile, and much simpler to #include each one from the app-specific or shared .isl.

I don't really see what possible security harm there is in allowing #include in particular.  Even #define and friends could be useful in some cases, although there perhaps Exec() and a few other functions that can cause disk writes might be considered more risky.  But no worse than anywhere else; you should always vet any third-party content you include.

[Jordan Russell]

On 3/15/2026 8:57 PM, Gavin Lambert wrote:
> Is there a way to opt out of this? I quite like having an app-specific isl
> file which includes a suite-specific file which includes a company-specific
> file which includes the default.isl. I know this is possible to achieve by
> listing the chain of files directly in the iss instead but that feels more
> fragile and inconvenient, since there are more places to update if you want
> to introduce more files.

Instead of .isl files including .isl files, you could have .iss files
including .iss files to build the list of files for the MessagesFile
parameter:

Script.iss:
#include "SuiteDefs.iss"
[Languages]
Name: en; MessagesFile: "{#SuiteMessageFiles}"

SuiteDefs.iss:
#include "CompanyDefs.iss"
#define SuiteMessageFiles CompanyMessageFiles + ", Suite.isl"

CompanyDefs.iss:
#define CompanyMessageFiles "compiler:Default.isl, Company.isl"

You could also #include trusted .isl files, with only Default.isl
specified in MessagesFile. All compiler directives will continue to work.

I realize that this change could break some (very unusual) use cases --
which is why it was done for 7.0 and not a point release -- but before
any "opt out" option is considered, I'd want to see a use case where no
reasonable alternative approach exists. I tend to not like adding
"restore the previous behavior" options because people will take
advantage of it not because they genuinely need to, but just as a "quick
fix" to avoid having to change what they're doing. And then they're
dependent on the option indefinitely.

> I don't really see what possible security harm there is in allowing
> #include in particular. Even #define and friends could be useful in some
> cases, although there perhaps Exec() and a few other functions that can
> cause disk writes might be considered more risky. But no worse than
> anywhere else; you should always vet any third-party content you include.

I doubt that the average user has ever thought of .isl files as posing a
potential security risk. It's just supposed to be translated text --
what could go wrong there? OTOH, with .iss files it's a lot more obvious
that they should be scrutinized since they specify files to install,
registry entries to set, etc.

The biggest risk comes from allowing ISPP function calls like Exec
(arbitrary command execution), but even #include is not 100% risk-free.
A UNC path could be specified to cause the system to make an outbound
SMB connection to an attacker-controlled IP address. A malicious SMB
server at that address could try to exploit unpatched/zero-day
vulnerabilities in the connecting SMB client, which if successful (a big
if) could allow the attacker to gain control over the system.

Of course, the official translations included with Inno Setup are
reviewed, but I do like knowing that even if something did slip through,
it wouldn't work.

-JR

[Gavin Lambert]

On Thursday, March 19, 2026 at 12:01:07 AM UTC+13 Jordan Russell wrote:

Script.iss:
#include "SuiteDefs.iss"
[Languages]
Name: en; MessagesFile: "{#SuiteMessageFiles}"

SuiteDefs.iss:
#include "CompanyDefs.iss"
#define SuiteMessageFiles CompanyMessageFiles + ", Suite.isl"

CompanyDefs.iss:
#define CompanyMessageFiles "compiler:Default.isl, Company.isl"

This is exactly the sort of thing that I meant by "possible, but messy".

 

You could also #include trusted .isl files, with only Default.isl
specified in MessagesFile. All compiler directives will continue to work.

This would not link them to a language, which means they'd have to be explicitly language-code-prefixed, unlike "normal" isl files.  Which isn't the end of the world, but still seems messy.

 

I realize that this change could break some (very unusual) use cases --
which is why it was done for 7.0 and not a point release -- but before
any "opt out" option is considered, I'd want to see a use case where no
reasonable alternative approach exists. I tend to not like adding
"restore the previous behavior" options because people will take
advantage of it not because they genuinely need to, but just as a "quick
fix" to avoid having to change what they're doing. And then they're
dependent on the option indefinitely.

I really don't think this is an unusual case (though perhaps the lack of others chiming in indicates that I'm wrong).

Maybe a compromise would be to fall back to Inno Setup 3/4 behaviour, where #include still works even with ISPP disabled?

 

The biggest risk comes from allowing ISPP function calls like Exec
(arbitrary command execution), but even #include is not 100% risk-free.
A UNC path could be specified to cause the system to make an outbound
SMB connection to an attacker-controlled IP address. A malicious SMB
server at that address could try to exploit unpatched/zero-day
vulnerabilities in the connecting SMB client, which if successful (a big
if) could allow the attacker to gain control over the system.

Doesn't every firewall block internet SMB these days?

Or maybe Inno could just block UNC #include.  It's a trivial check and would still allow most use cases -- even if people really need to include files on a server they can map a drive letter to it. 

[Jordan Russell]

On 3/18/2026 5:19 PM, Gavin Lambert wrote:
> I really don't think this is an unusual case (though perhaps the lack of
> others chiming in indicates that I'm wrong).

Surely the overwhelming majority of users specify a single
"compiler:Xxx.isl" file as shown in the docs, examples, and Script
Wizard output. Of the few who use multiple files, I would think that
most use the comma-separated syntax shown in the [Languages] help topic.
The topic doesn't mention #include or preprocessing.

I'm actually not even sure whether the preprocessing of .isl files was a
deliberate design decision, or just a consequence of using the same code
as .iss files. Later supporting ISPP on .isl files (i.e., more than just
#include) was intentional, but definitely not a good idea in retrospect.

> Doesn't every firewall block internet SMB these days?

Windows Firewall's "domain" profile doesn't. They expect the ports to be
blocked at the perimeter -- but I've always had to manually add rules
for that.

> Or maybe Inno could just block UNC #include.

True, that would help -- but might there be other exploitable cases? It
just doesn't seem right to me that a "data" file can make the compiler
open arbitrary files in arbitrary locations. A text file assigned to
LicenseFile can't do that, nor can a bitmap file assigned to
WizardImageFile.

If this broke things for 10% of users, then certainly a strong case
could be made for continuing to support it in some limited form. But it
doesn't make a lot of sense to me when it looks to be one or two users,
and there already is another, "officially supported" way of specifying
multiple files.

-JR

[CyberMania]

my setup will fail to uninstall using 7.0.0 preview 2... Internal error: pathredir: not initialiized 

[Martijn Laan]

Hi,

Op 3-4-2026 om 11:39 schreef CyberMania:

my setup will fail to uninstall using 7.0.0 preview 2... Internal error: pathredir: not initialiized 

Thank you for reporting, that's not supposed to happen for sure.

Do you have an example script reproducing the issue? Thanks in advance.

Greetings,
Martijn

[Martijn Laan]

Hi,

Op 3-4-2026 om 11:39 schreef CyberMania:

my setup will fail to uninstall using 7.0.0 preview 2... Internal error: pathredir: not initialiized

I have found the issue: the error occurs if there's no [Code] section.

Adding one should fix the issue, for example by adding this:

[Code]

function InitializeSetup: Boolean;

begin

  Result := True;

end;

I will make sure this is not necessary in the next version.

Thank again for testing and reporting.

Greetings,
Martijn