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.