10

I have always been wondering why Windows Installer only allows you to install one program at a time. It is very frustrating not to be able to launch multiple installations, especially when setting up a new installation of Windows. What is the reason for that?

Rytis
  • 325
  • 5
  • 16

3 Answers3

7

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.

Massimo
  • 68,714
  • 56
  • 196
  • 319
6

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.

Chris Lercher
  • 3,982
  • 9
  • 34
  • 41
  • 1
    While correct, this answer seems to me too verbose. Someone asking why the installer service works the way it does is not likely to understand this answer. – gWaldo Aug 27 '10 at 13:32
  • 2
    @gWaldo: Okay, maybe you're right... Then again, I don't just want to say "It's complex, believe me (period). You wouldn't understand it anyway". Maybe the OP (or someone else stumbling on this question) is truly interested, and an answer that gets to the bottom of the problem will help him to estimate, if there's *really* a lot of complexity involved to solve something that looks so easy on its surface. Who knows? – Chris Lercher Aug 27 '10 at 14:08
  • Very true. That's a good point. – gWaldo Aug 27 '10 at 14:21
  • While all the talk about isolation sounds plausible, you can run multiple installers if they do not use Windows Installer framework. I've never had any of them break when running side by side... Maybe I'm just lucky :) As for queueing installations, there are tools for that, but given multicore CPUs (heck, desktop CPUs can now run 8 threads...), it seems that running them side by side would be the answer (although they may still fight for I/O). – Rytis Aug 27 '10 at 15:33
  • 2
    @Rytis: I wish I had the same luck :-) - I've had installers break randomly even without running them concurrently. About multicores: There would be another way to utilize them: By using multiple cores within one installation process. That's still not always possible or easy, but can be coordinated a lot better. Overall I think, the biggest time saver is still, if the entire installation process (queue) only asks questions at the beginning and at the end. Then you can get a coffee, or do something else while the installation runs (and utilize the remaining cores for whatever you want to do.). – Chris Lercher Aug 27 '10 at 16:32
1

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:

Stein Åsmul
  • 2,566
  • 4
  • 25
  • 38