Windows Installer Technology

[Consuela Ellett]

Howeverone thing that I have never really worked out is what part does Windows Installer itself actually do, and where do these tools start and end? For that matter, what exactly is the msi technically, and why is it no one (I couldn't even find information on how it could be done in theory, like if its actually just some kind of DLL type thing that implements a simple interface) create an msi themselves, without using one of these tools to make it for them?

Some years ago I asked me myself the questions like "What is MSI file?", "How one can create or decode it?", "Why MSI database structure looks so strange?". So I answered for me on the questions. If you have an interest I can share the knowledge with you.

About the history. Windows Installer technology was introduced by Microsoft Office installer team during developing of Office 2000 setup. Before that Office 97 setup was STF based. The STF file consist from two tables: one with general information which can be compared with Properties table of MSI and another table which described the order of execution of different installation steps. Three main starting modes was supported: Installation (Administrative installation is sub-mode), Remove and Maintains. Office Software was going more and more complex and Microsoft wanted to make the setups more stable. See here for some more information.

Last years of the 20-century was the COM and COM+ time at Microsoft. The format of WinWord documents was COM Structured Storage too. So the format of the MSI file was chosen also as the structured storage. In general one wanted only to save some separate information like tables in one file. It's important that some tables will be modified during the installation. So one want be sure that the whole MSI file will be not corrupted in case of failed installation. The structured storage provided minimal support for the case, so the format will used since the time. The modified MSI files will be saved in the %SystemRoot%\Installer folder.

If you open MSI file with respect of Orca tool and export all tables in the files you will have exact the same information set which you have in MSI. You can modify the text tiles and then import the files back. If you would get some empty MSI file and import the tables you will create new Windows Installer setup.

Windows SDK has a list of Scripts which you can find in the C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\sysmgmt\msi\scripts folder. You can use the scripts to create empty MSI and to import the tables in MSI. So you can use the scripts instead of WiX. The WiX uses XML format which makes the input information more readable as idt-files (tables exported by Orca) and more easy to maintain.

For better understanding I wrote some years ago some small utilities which create the empty MSI files without Windows Installer API and which just used COM Structured Storage API. Additionally I created utility which decodes full information from MSI files on the low-level (also without usage of Windows Installer API). So I am sure that MSI files are really not more as I described above.

Windows Installer is an Microsoft Windows Platform service and associated SDK. The SDK contains tools such as Orca to edit MSI databases. The platform service exposes a specification for the database and a Win32 and COM Automation interface for interacting with it. The Windows Installer team was not asked with creating full blown authoring tools. Instead, for the most part authoring tools was left to the industry to create by building applications on top of that API and database specification. My understanding was that this was an olive branch to several company such as InstallShield and Wise who already had their own frameworks for authoring installers and was an attempt to consolidate the technology without alienating these companies.

Since then Microsoft has published the Windows Installer XML open source project which is an authoring tool in it's own right. Also the Visual Studio team had Setup and Deployment Projects ( defunct in the next release of Visual Studio ).

The MSI database file contains tables with details about the files to be installed, shortcuts, Windows Registry settings, and more. These tables are then compressed, packaged, and saved as a single MSI file for distribution.

Windows MSI files use a standardized format that leverages the Windows Installer technology, making it easier for system administrators and end users to install programs in a corporate IT environment. This ensures the software is installed correctly and consistently across different Windows machines.

On the other hand, an EXE (executable) installer is a file format containing the actual program code and resources required to run an application. It is a self-extracting archive that often includes an installer program to guide users through the installation process.

EXE files may contain software installers but are also generally used for any executable program on Windows. This differentiates them from MSI files, which are only used for software installation and uninstallation. EXE files can also contain viruses and malware, so system administrators and users must take care to only obtain them from trusted sources.

When they are used for installing software, EXE files contain all of the necessary code and other resources required to run the program, such as dynamic-link libraries (DLLs). This is because EXE installers do not depend on the underlying infrastructure of the Windows Installer, unlike MSI installers.

MSI installers come with built-in support for both installing and uninstalling software. This makes it easy for users to add or remove programs via the standard Windows interface. They also have a built-in rollback mechanism that can help protect your system from damage. If an error occurs during software installation or uninstallation, the system can automatically revert to its previous state, ensuring a smoother and more reliable process.

MSI installers integrate with the Windows Installer service, which provides security features such as user account control, digital signatures, and verification of package integrity. These features ensure that the software being installed is trustworthy and has not been tampered with. Enterprise-grade MSI installers can be deployed using Group Policy or other software deployment tools, ensuring centralized control and security compliance.

EXE installers may lack the built-in security features provided by the Windows Installer service. However, developers can still implement security measures by digitally signing their EXE installers, which helps validate the authenticity and integrity of the installer. Additionally, system administrators can leverage third-party software deployment tools to control and secure the distribution of EXE installers.

When it comes to customization options, MSI installers offer more flexibility compared to EXE installers. The Windows Installer technology provides a rich set of features for customizing the installation process, such as specifying installation options, creating custom dialogs, and defining conditions for component installation. This level of customization is particularly beneficial for system administrators who need to deploy software with specific configurations across multiple machines.

The choice between MSI vs EXE installers largely depends on the specific use case and target audience. MSI installers are well-suited for enterprise deployments and system administrators who need a standardized approach to software installation. The consistency of MSI installers makes managing and maintaining software easier across multiple machines. Additionally, the security features and customization options offered by MSI installers make them ideal for large-scale deployments in organizations.

For enterprise deployments, MSI installers provide a standardized and secure approach to software installation. They offer ease of management, customization options, and compatibility with the Windows operating system. By contrast, EXE installers offer versatility and reduced dependence on the Windows Installer, making them suitable for software distribution to a wider audience.

Building an efficient and effective IT team requires a centralized solution that acts as your core service deliver tool. NinjaOne enables IT teams to monitor, manage, secure, and support all their devices, wherever they are, without the need for complex on-premises infrastructure.

Note: configure now enables DCO build by default on FreeBSD and Linux. On Linux this brings in a new default dependency for libnl-genl (for Linux distributions that are too old to have a suitable version of the library, use "configure --disable-dco")

Note that OpenVPN 2.5.x is in "Old Stable Support" status (see SupportedVersions). This usually means that we do not provide updated Windows Installers anymore, even for security fixes. Since this release fixes several issues specific to the Windows platform we decided to provide installers anyway. This does not change the support status of 2.5.x branch. We might not provide security updates for issues found in the future. We recommend that everyone switch to the 2.6.x versions of installers as soon as possible.

The OpenVPN community project team is proud to release OpenVPN 2.5.6. This is mostly a bugfix release including one security fix ("Disallow multiple deferred authentication plug-ins.", CVE: 2022-0547). The I605 installers include OpenVPN GUI with a bug fix, as well as updated OpenSSL (1.1.1o).

The OpenVPN community project team is proud to release OpenVPN 2.5.5. The most notable changes are Windows-related: use of CFG Spectre-mitigations in MSVC builds, bringing back of OpenSSL config loading and several build fixes. More details are available in Changes.rst.

The OpenVPN community project team is proud to release OpenVPN 2.5.4. This release include a number of fixes and small improvements. One of the fixes is to password prompting on windows console when stderr redirection is in use - this breaks 2.5.x on Win11/ARM, and might also break on Win11/amd64. Windows executable and libraries are now built natively on Windows using MSVC, not cross-compiled on Linux as with earlier 2.5 releases. Windows installers include updated OpenSSL and new OpenVPN GUI. The latter includes several improvements, the most important of which is the ability to import profiles from URLs where available. Installer version I602 fixes loading of pkcs11 files on Windows. Installer version I603 fixes a bug in the version number as seen by Windows (was 2.5..4, not 2.5.4). Installer I604 fixes some small Windows issues.

3a8082e126