Why Windows Installer can only install a single program at a time?

Solution 1:

It would be very complex to guarantee correctness, when concurrent installations take place - assuming that they share some of the files. This would need some form of transactions.

• You need to lock files
• It should be possible to undo intermediate changes, if the installation fails (not sure, if that's possible now?)

These concepts are known from transactional databases - but the topic isn't trivial, and you usually don't find a fully transactional infrastructure in file systems (even though journaling file systems provide a part of that). One problem is, that multiple locks can lead to a deadlock - then you need deadlock detection (or both installers will hang forever), and a way to treat that. Deadlocks can be avoided (e.g. by always locking files in the same order), but there are other problems:

If you lock all the required files up front, you get effectively what you have: One installer must wait until the other is finished. If you don't lock all required files up front, and keep on going, you risk that the "transaction" will fail. That would mean, that one of the installers would have to be restarted.

Then you may have to think about transaction isolation levels - to be fully correct, your transactions would have to be "serializable" - but that's not easy, even for many databases.

There may even be alternative strategies to deal with the problems, which circumvent full isolation, but it would usually be even harder to prove their correctness.

I believe, with concurrent installation, we would have a lot more intractable post-installation problems - especially because I don't think, an OS vendor (or a distribution) would go through all the trouble to make it 100% clean. So I would prefer not to use it, even if it were offered by the OS.

Note

But maybe what you really want is not even installing "at the same time". Maybe it would be sufficient, if you could queue up the installations, which are then executed one after the other (ideally without asking any questions in between). And that's really something, some other OS (distributions) handle a lot better.

Solution 2:

This is by design, in order to avoid having two installations manipulating the same files/folders/registry keys/etc.; it could probably have been done in different ways, but Microsoft made this choice.

Solution 3:

Concurrency: You can kick of several MSI files to install in rapid sequence one after the other using a batch file. You can not run two MSI files simultaneously in the sense that they both write to disk at the same time.

Transaction & Rollback: The reason is that part of an MSI installation is run as a "transaction" - a sequence of changes that are either committed or rolled back depending on whether the actions in the transaction list complete without error. All must complete without error, and then the transaction is committed, otherwise a full rollback of all changes occur. It follows that only one such transaction can be active at any given time.

Technical Sequences: At the technical MSI level, only the actions between the standard actions InstallInitialize and InstallFinalize in the InstallExecuteSequence are run as a transaction. No system changes are supposed to happen outside these actions, but sometimes MSI files are erronously designed to make changes in other sequences.

Links:

• More elaborate explanation.
• More on MSI and mutexes.