If you're a Windows user, then you're probably somewhat familiar with .MSI and .EXE files. Maybe you don't know much about them or how they work, but you probably recognize these as files that run or install applications on your computer. But have you ever wondered what makes them different? Is one better than the other? Do we really need both .MSI and .EXE files? Let's find out.
.EXE (executable) files are probably one of the most recognizable file types in computing. Users generally know that when they double-click an .EXE file, stuff's about to go down. Maybe something cool like launching a little obscure game called The Elder Scrolls V: Skyrim, or maybe something not so cool like installing ransomware because you opened a file called Mariah Carey - All I Want for Christmas Is You-mp3.exe. Either way, you're in for a treat.
While it's true that .EXE files can install software, they're actually more robust than that. .EXE files can be installer packages or self-extracting zip files. .EXE is also the standard file extension for Windows programs. In fact, whenever you launch an application from your desktop, taskbar, or start menu, you're just launching a shortcut to the actual executable. To see this for yourself, right-click on a shortcut on your desktop and click Properties.
When the properties window opens, click on the Shortcut tab. Here you'll see a Target: field which tells you what file is actually being launched when you double-click the desktop shortcut.
If you click the Open File Location button at the bottom of the Shortcut window, it will take you directly to the executable file in File Explorer.
Now, if we double-click on chrome.exe, the browser will launch, just as if we had launched it from the desktop. It's important to understand that not all .EXE files serve the same function. You might install an application with an .EXE file and then launch the application with a different .EXE file.
Another important attribute to know about .EXE files is that they are highly customizable. Developers can build out intricate installation GUIs or leave things minimalistic. Dependencies can be built-in. This flexibility is beneficial for developers because they can build out exactly what they need and control almost every aspect of the installation process. However, when you have a high degree of customizability, you tend to lose out on standardization, which we'll cover more in a moment.
If you are interested in seeing the contents of an .EXE installation package, common archiving tools, such as 7-Zip, will allow you to do so. If the contents aren't extracting properly, you can try something more purpose-built, such as Universal Extractor 2. Here are the contents of the Dropbox.exe installation package.
As you can see, this package includes both .EXE and .MSI files, as well as several .DLL files. These are pretty common files to find in an installer package. Other common files include images, icons, .INI files, .XML files, sound files, registry data, languages packs, fonts, and more.
.MSI files are a little more straightforward than .EXE files. When we're talking about .MSI files, we are strictly talking about installation files. Installing, updating, and uninstalling is what these files are designed to do.
The .MSI extension is in reference to the Microsoft Installer service, which was renamed the Windows Installer because renaming stuff is what Microsoft likes to do to keep things fresh and people on their toes. The Windows Installer is a component of Windows that handles the installation, maintenance, and removal of software. .MSI files are Windows Installer database files and interact exclusively with the Windows Installer, unlike .EXE files which can use custom installation scripting or can be used as a wrapper to contain .MSI files which utilize the Windows Installer.
You can view the contents of .MSI files using many of the same utilities that you use to extract or view the contents of .EXE files. Here are some of the files extracted from the Zoom.msi installer.
As you can see, we have many common files here, including .EXE and .DLL files. You'll also find many of the same files found in .EXE install packages. However, you won't find any .MSI files contained within an .MSI file because only one instance of Windows Installer can be running at any given time. If you've ever tried to install an .MSI while another .MSI is already installing, then you've probably seen this error message.
.EXE and .MSI installers share many similarities but also have many differences. So is one format better than the other? Let's compare the two and find out.
Can be more than just installer packages.
Are highly customizable, offering flexibility to developers.
.EXE installers can contain other .EXE and .MSI files.
Can contain and install dependencies.
Can be compiled in many different ways and languages.
Don't require the Windows Installer.
Are always installer packages.
Are standardized and must meet certain requirements
Switches are universally known and available
Have verbose logging options.
Uninstallation parameters are defined.
Network deployments are simplified with always available silent switches.
So which one is the winner? Well, the boring answer is that there really isn't a winner. Both .EXE and .MSI files have their place and use cases. And that's a good thing. Having options is almost always better than being limited to a single choice.
If an application developer provides both an .EXE and .MSI installer for their software, which should you use? While it often won't matter which you choose, there are certain situations where you would want to choose one over the other.
Occasionally, developers will nudge users towards a particular version to use. This suggestion is great for inexperienced users and is usually the best choice for them. If the developer doesn't recommend any particular version, then home users may be best served by using an .EXE installer, which may include dependencies that .MSI installers may not include. .EXE files are also likely to include more customization options during the installation process.
So what are some situations when you would want to use a .MSI installer? Well, if you're a sysadmin needing to deploy applications to several computers remotely, then .MSI files will be your new best friends. While there are many reasons why IT professionals may prefer .MSI files over .EXE files, including logging and uninstall strings, the main reason is because of the silent switch.
The silent switch allows users to deploy applications silently, meaning the application will install without displaying any installation prompt messages, which would require user input to advance the installation. This functionality is great for a couple of reasons. First, a silent installation means that you won't need to physically or remotely work through the installation prompts to get the application installed, which is almost a necessity if you are deploying to a large number of computers. Second, if you are deploying an application during business hours, imagine the chaos that would ensue if several of your users suddenly received random installation prompts on their computers. Many of them would probably think a virus is being installed on their computer.
Now, before I get yelled at, yes, you can silently deploy many, if not most .EXE files. However, as we've said, many aspects of .MSI files are standardized, including their switches, meaning you aren't required to figure out what the silent switch is for .MSI files because it's the same for all .MSI files. In fact, you can view all of the Windows Installer switches by typing the following command into your Windows search bar or the command prompt.
This image shows some of the options and switches available when using Windows Installer (msiexec.exe). The primary silent switch is going to be /qn which means no UI. The /quiet switch will often provide the same functionality, though technically, it just means it doesn't require user interaction, so some UI elements may still be shown.
Deploying .EXE files silently can be a much more frustrating experience. While there are some common silent switches used by .EXE files, it's really up to the developer to decide what to use. Worst of all, they might not even include a silent switch, making deployments much more difficult.
When it comes down to it, the primary difference you'll want to remember is that .EXE files are highly customizable and great for single installations, and .MSI files are heavily standardized, making them great for office environments and deployments.
If you find yourself needing to deploy an .EXE file to a bunch of computers remotely and are struggling to find the silent parameters, check out our article on Silent Install And Finding Silent Parameters. If you're a sysadmin struggling with deployments in general, check out PDQ Deploy. We take the guesswork out of most deployments by providing hundreds of pre-built packages in our package library. We do the work, so you don't have to!
Born in the '80s and raised by his NES, Brock quickly fell in love with everything tech. With over 15 years of IT experience, Brock now enjoys the life of luxury as a renowned tech blogger and receiver of many Dundie Awards. In his free time, Brock enjoys adventuring with his wife, kids, and dogs, while dreaming of retirement.