Provide MSI (Microsoft Installer) package for SeaMonkey



17 years ago
3 months ago


(Reporter: Henrik Gemal, Unassigned)



Windows 2000

Firefox Tracking Flags

(Not tracked)


(Whiteboard: WONTFIX ? -- fix doesn't solve more problems than it introduces)



17 years ago
To overcome some of the problems that are in the installer, why not use the MSI 
(Microsoft Windows Installer).
This would help let the developer focus on coding Mozilla instead of coding a 
"dumb" installer...

More info:

Comment 1

17 years ago
:-) Thank you.

Would you make this block all of the bugs that I mentioned so it would be clear 
how useful this is. [Netscape4 just destroyed my bugzilla mailbox]
Keywords: helpwanted

Comment 2

17 years ago
It would be helpful if you could list the problems in the current mozilla 
installer that MSI will overcome.  This will assist in a cost estimation as to 
whether fixing these bugs in the current installer is cheaper than modifying the 
build system and requiring developers to use the MSI SDK if they want to create 
their own installable mozilla build.  Thanks.

Comment 3

17 years ago
Just in case you want a (good) example of a XP software package that uses MSI
for its win distribution:

Comment 4

17 years ago
I'm pretty sure that one solution to the bugs I'm blocking is MSI.


17 years ago

Comment 5

17 years ago
These dependencies are wrong: this bug is not blocking the fixing of the 
depending bugs. They *could* be fixed by fixing this bug, but it has not been 
decided that that this approach is necessary or even desirable.

Of particular concern is that MSI is under the control of a competing software 
producer; if/when things get ugly, MSI could be updated in such a way that a 
Mozilla installation fails. For example, MSI could act to prevent Mozilla from 
subsuming the `Internet' control panel with a Mozilla version, or block attempts 
to replace IE hooks throughout Windows with Mozilla equivalents.
I agree that using Microsoft's Utility would not be good. There are other 
installation utilities out there such as installshield. It seems, though that 
you pretty much have the installer created and just need to do a few changes. 
Using the installer SDKs are not as easy as people would imagine. I would 
consider it the equivalent of learning how to use a development platform such 
as MSVC. 

Comment 7

17 years ago
Bleh.  Current Install Shields can build MSIs.  Learning MSI may or may not be 
worth it, but generating MSIs are. 

WRT hooks. Windows2000 has a collection of security measures to protect system 
files, afaik you can't replace those files unless you use MSIs.  Attempting to 
replace the files w/ your typical braindead installer will not fail, but it 
will not last (for more than an instant) as windows will just retrieve the 
files it prefers.

wrt MSVC: for some reason we do that. Feel free to work on getting Borland or 
egcs+mingw32 working for the build process, but we don't yet.

A nontrivial fact that you two are overlooking is that the installer app is 
supposed to be os native and should comply w/ os preferences, MSI is the os 
preference.  It makes admin/automated installs much easier, it means that if a 
feature is added to the os, the users get it.  The installer is supposed to do 
this stuff, whereas mozilla is supposed to be XP.

Comment 8

17 years ago
> the installer app is supposed to be os native

That's not the case with any OS I know of. Nor was it taught in my operating 
systems theory course.

>                                               and should comply w/ os
> preferences, MSI is the os preference.

The OS preference on Windows is to use Internet Explorer for browsing. The OS 
preference on Mac OS X is to use Mail for e-mail. If we weren't trying to subvert 
OS preferences at least some of the time, we might as well not be trying to 
produce an XP Internet suite at all.

MSI may indeed be the easiest option for solving installer problems in the short 
run. But if it poses *any* risk at all of locking us out in the long run, if 
there is *anything* that MSI can do that a custom installer can't, then that 
should not be tolerated, and MSI should be reverse-engineered rather than 
I for one think that although the installers might have slightly different 
functionality - they should be very similiar on all systems and should be well 

Comment 10

17 years ago
I have found MSI to be extremely unstable on Windows 95, 98, NT4, and 2000. If
you spend to much time choosing your options on most computers I've tested the
installed will lock up. The only computer that would properly run MSI installer
with out locking up was a Intel 486 DX-2 66Mhz (Win98). The platforms it locked
up on were Pentium 150 (NT4/95/98), Celeron 300A (NT4/95/98/2000), Pentium III
450 (NT4/95/98/2000), Pentium 90 (95/98/2000).

As a system administrator, I'd recommend against MSI.


17 years ago
Severity: normal → enhancement
Priority: P3 → P4

Comment 11

17 years ago
Assignee: ssu → nobody

Comment 12

17 years ago
After playing a lot with MSI, I'm begining to think it's a bad idea to use 
Windows has built in APIs for installing. MSI takes advantage of those. 
Therefore, MSI is just a program that uses the preferred method of using the 
APIs. And anyond that has installed using MSI knows it stinks and is buggy. 
What if someone doesn't have MSI? It will probably also make it hard to have 
special graphics that describe mozilla appear, windows that are irregularly 
shaped, special window colors, or anything else you might want to do to make 
the installer more pretty. I, also personally have a bad opinion about software 
the instant I start installing if it uses MSI. The writer just needs to take 
advantage of the Windows APIs that allow installing system files.   (By the 
way, if you want to know how to make irregularly shaped windows, let me know 
and I'll tell you - it's easy and will make mozilla be really cool.)


17 years ago
Blocks: 60843
I posted the information about irregularly shaped windows: bug 60843.

Comment 15

17 years ago
Microsoft is encouraging everyone to get the MSI system. Installing it is 
painless.  Using it is actually painless, if you disagree then you can contact 
ms w/ suggestions.  But first, please check out the various apps that are 
distributed using it, ActiveState:* [ActivePerl, ActivePython, Komodo], PSP, 
... The installer will be familiar and is very easily scriptable for admins.  

ActiveState and probably most of the other vendors include a link to the MSI 
Engine, this is not unusual for commericial platforms (macos w/ 
appearnace, carbon, quicktime; windows: comdlg, vbrun, msvcrt, ie)

Oddly shaped windows will not earn you points for installers.  Nor will they 
earn you points nearly anywhere else.  The first app I encounter that used them 
was norton crash guard 1.0 [probably one of the crashiest programs ever made by 
norton/symantec] -- it was shaped like a shield. I have made an app in the 
shape of a chess piece, but once you look at it for a bit, it's useless.  

Being locked into an installer is nonsense.  If you're really concerned, then 
please consider installshield and just build the msi target.

One good thing about MSI is dependencies and regeneration, yes once mozilla is 
installed we'd prefer people to use XPIs, but if you want to get Komodo, 
Netscape6, Mozilla, and other things cooperating, it'd probably be easier for 
them to use MSI dependencies [offer to skip the installation an old mozilla.exe 
if you can find a newer one].  Another is centralized management.

There is no point in reinventing the installer when the mozilla mandate is to 
be platform friendly.  MSIs are very lightweight since they're basically a 
payload (the app) and a tiny script.  This is a top priority for the platform 
installer.  And there is no need for a special uninstaller app or the nonsense 
about scheduling the deletion of said uninstaller.

Updating summary to remind all that this is windows only.
Summary: Mozilla installer should use the MSI (Microsoft Installer) → Mozilla installer for Windows should use the MSI (Microsoft Installer)


17 years ago
No longer blocks: 60843

Comment 16

17 years ago
> if/when things get ugly, MSI could be updated in such a way that a
> Mozilla installation fails

While I share this concern, note that all of Windows is under Microsoft's control.

Comment 17

17 years ago
After playing around with the Windows Installer SDK, I created a rough first 
version of an MSI based Mozilla installer.
This test version is available at
Note that the webinstaller (downloading the requested features as needed) is 
not working due to lack of space on that server.

I used VBScript to create an installer builder, using the stage directories 
created by the XPI builder to scan the files needed for installation. The 
Installer SDK has VBScript samples I used as a bases for  this script.
I'm not sure what would be the best way to go from here. Where do we want to 
place the script to build the installer msi, and what files to package? Should 
it be added to the current build script with some ifdefs, or use a different 

Another problem is installation of XPI's. I simply install the installed-
chrome.txt file, not sure if this can cause any problems. I don't know if it is 
possible to use the XPCOM engine to register stuff during the install. The MSI 
installer can embed javascript/vsbscript or call dll's during installation.

Comment 18

17 years ago
hrm, can the installer embed jscript? if so could we work on converting from 
vbscript to jscript?

regxpcom.exe and regchrome.exe should be run after you deposit the components 
and installed-chrome.txt

ack. the license is in rtf? doesn't ms support html? [if it does, switching 
would probably good]

unfortunately, that server is serving .msi as text/plain. for now, if the 
server serves .zip as binary could you zip a copy of the msi files?

if you could add a run application option to the ~Installation ready~ dialog 
(assuming that it's not against the msi guidelines) that'd be cool.

we should provide a support url. for now, will 
probably do.

the pictures look great. 

installers seem to live in one of two places
mozilla/build/ [package/]

since msi isn't xp, build/ sounds good. i think msi is like deb and rpm so 
build/package/msi/ should fit the naming convention
Assignee: nobody → ajbanck
> ...PSP...

Given that I am totally unable to install PSP on my Windows 2000 machine using
MSI (yes, I've installed all the MSI service packs, the PSP pre-install service
pack, and read all the FAQs from top to bottom twice and gone to MSDN and so on)
I don't like the idea of using it to install Mozilla...

Also, every time I've used MSI I've had to reboot, and I sure as **** am not 
ready to reboot every time I install Mozilla, considering how often that is.

Regarding the bugs that would be fixed by this: Most of them are trivial (button
alignment and digit grouping, for instance) and would merely be replaced by an
equivalent set of minor bugs in MSI. I would estimate that the effort required
for someone to learn our installer's code base, fix the bugs, and move on would
be less than the effort required for someone to change our build system to use
MSI, and then the effort required by QA to create new test plans and test it.

I strongly suggest marking this bug WONTFIX and concentrating on our existing
installer issues instead.
Whiteboard: WONTFIX ? -- fix doesn't solve more problems than it introduces

Comment 20

17 years ago
I know that I'm the one that reported this bug. But the more I use MSI the more 
I'm convinced that MSI should not be used for Mozilla. Reboot and strange 
behavior have been the results. MSI has some nice features.
But the current Win32 installer has come a long way, and is almost pretty 

Comment 21

17 years ago
Henrik, would you like to be removed from reporter ;-? I'd gadly take your 
place. Removing wontfix since there is a contributor working on this and we 
should be willing to accept the contribution just like we accept rpm and other 
optional packaging systems.
Whiteboard: WONTFIX ? -- fix doesn't solve more problems than it introduces

Comment 22

17 years ago
Nope, dont remove me. I just dont think this bug is very important. Some of the 
MSI features are cool though...

Comment 23

17 years ago
Er...if you can place whatever commands you want in the status whiteboard 
(DUPEME, anyone?), I'm pretty sure Ian can propose a resolution for this.

I know that if I was the one working on this, I'd want some feedback first, to 
gauge the public's response to this before I spent days on it.

That said, the screenshots in the url do look very cool.  But I, too, can admit 
to encountering some flakiness in MSI.
Whiteboard: WONTFIX ? -- fix doesn't solve more problems than it introduces
thanks blake

Comment 25

16 years ago
Hm...just installed the Platform SDK...wonder how hard it is to create an MSI? 
From the W2K betas, I don't remember it being that hard.

Does this bug seriously block all of those marked? Haven't looked at all of 
them, but this looks important. 

What about Windows XP?

Comment 26

16 years ago
all current versions of windows want MSI. doing this should fix most bugs 
blocked. it's not a complete dependency, but if we do this, the others should 
no longer happen. could you zip a current msi (that uses urls) and attach it 

Comment 27

16 years ago
Timeless, have you see Visual Studio.NET (beta 1) project template for creating 
an MSI? Even though I didn't spend more than five minutes on it, looked like 
that tool could make this pretty easy. 

You can get VS.NET, I think for free, here:

Comment 28

16 years ago
No, this bug doesn't block any of the bugs marked -- and indeed, some of them 
have already been fixed. For the record, those bugs were: bug 11210, bug 18916, 
bug 22210, bug 23222, bug 27577, bug 27586, bug 28172, bug 28174, bug 28332, 
bug 30166, bug 32860, bug 33351, bug 39223, bug 43792, bug 46018, bug 47732, 
bug 47959, bug 48623, bug 48815, bug 51928, bug 51988, bug 51991, and bug 

Comment 29

16 years ago
I have .net beta1 but i haven't installed it on my computer.. maybe this 
summer.  The thing is that already created an msi, and it 

Comment 30

16 years ago
sorry for not having done much on this for some time. I thought I posted some 
comments here but probably did something wrong

I'll try to update en post updates here this week.

I also want to take a look at a msi2xml/xml2msi tool 
( that might be useful 
for storing the installer in CVS.
*** Bug 84670 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
There is no point to use MSI:
- there is no control on it (reboot);
- it work only with Windows;
- there are few bugs in actual installer, how much in MSI do we know?

so...current installer is very fine :)


Comment 33

16 years ago
The Mozilla installer now does all kind of stuff that would just take to much
time converting to MSI.
Lets face it. This is never gonna happen. It wouldn't benifit anybody...
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 34

16 years ago
QA Contact: bugzilla → gbush

Comment 35

15 years ago
*** Bug 165510 has been marked as a duplicate of this bug. ***
When it first came to my attention (mid-2000), I had similar trouble with MSI as described in this 
bug. Today, however, most, if not all, of those weird crashes, dependency problems, etc. seem to 
be resolved.

"There is no point to use MSI:
- there is no control on it (reboot);"

That's not true, one of the MSI settings is whether or not the installation requires a reboot; a 
Mozilla MSI file would of course not.

The major benefit of MSI (in my point of view) is deployment. Create an MSI file of an application, 
and in an ActiveDirectory-enabled company network (i.e. with only or mostly Windows 2000 
clients), you can share the installation script over the whole network, making two choices possible:

a) force computers in the group in question to install the application in question at next reboot
b) force users in the group in question to have the computer install it at next login
c) let users manually install it from the Software panel, adding it to the "Install from network" 

These are extremely convenient ways of software deployment over a large network, and they make 
maintenance (further updates to the app) easy as well. Also, should an administrator decide to 
remove the app, he can tell all computers to automatically uninstall it again.

So yeah, there *is* a benefit in MSI. We needn't even get rid of the current installer and instead 
could offer an MSI file as an additional option.

I can't follow mpt's argument either: Assuming Microsoft gets nasty enough to keep us from using 
MSI, they might as well release a path for the whole OS that keeps the user from launching 
mozilla.exe in the first place. It's a proprietary OS, as are Mac OS, Solaris and QNX, so the ultimate 
control over it lies in the OS vendor.

MSIs, however, allow for much better control of a software, including "intelligent" shortcuts and 
self-"healing" executables (by replacing themselves with proper copies).
xpinstall has gotten better, and its being improved upon. I don't think we are
going to use a proprietary installer like MSI. It was a bad idea in 2000, but is
even worse now.

Comment 38

14 years ago
*** Bug 218952 has been marked as a duplicate of this bug. ***
In a former professionnal life, I used to work for the french national electricity
provider. 140,000 users everywhere in France, including overseas territories. A
real mess in terms of deployment without MSI. Much easier with it.

I agree FULLY with comment #36, MSI allows teledistribution of a package through
the normal Microsoft channels. It's a VERY important point/feature for big
corporate users. Saying that MSI's pointless shows just a total ignorance of the
market of big MSFTWindows-based corporate users.

I __STRONGLY__ recommend reopening the current bug and setting the radar to
Future if noone wants to take it right now. But closing it as WONTFIX goes too
far from my personal perspective. Just my 2 eurocents.
Is there any way we could hack some of the features of MSI into our own
installer? There is also a matter of pride in having our own installer instead
of relying on Microsoft's (our competitor).

Comment 41

13 years ago
That seems really silly, to need to be prideful for reinventing the wheel on how
a program gets installed into a computer.  There are plenty of options to
customize the branding of the MSI install (I know, because I install lots of
software each day and they all clearly indicate the software vendor, not
necessarily MS).  If you are at all interested in making headway into the IE
dominance of the browser market, you will make it as easy as possible to install
and manage it.  You can continue using the XPinstaller if you wish, but you
should just make it possible, if not easy, to have a .msi available to push into
that most enviable of customers, the corporate customer.  I'm not saying that
there aren't lots of companies that run on *nix clients, it's just that the
overwhelming majority rely on MS computers.  In that environment, a .msi makes
it as close to SANE as you can get to install, update, remove, reinstall, etc.
in a centralized (and minimum effort) manner.

We've even attempted to just do an install and snapshot the install into a .msi,
but the darn thing keeps trying to reinstall itself after a reboot.  Fixing this
bug will not only make that path obsolete, it will actually do a better job
(since it won't be so version and system dependant as snapshot-style installs).

Comment 42

13 years ago
Note that FF tries to use MSI, see Bug 231062 comment 0.
Michael: Two things -- 1) Only about 1/4 of programs use .msi files, in my
estimation, and programs are moving away. The rest use Installshield, or an .exe
setup file built with MSI technology. 2) MSI's interface is poor, and even the
directory selection dialog is not very good as compared to what Installshield
uses, along with lopping off the extra directory info. Such as:

C:\Program Files\Mozill Firefox

You'll lose the trailing "Mozilla Firefox" if you select a new directory, which
has an unreviewed patch for Installer in bug 51988. We can't fix Microsoft code,
can we?

Michael: An MSI package can be an alternative for when XPInstall is broken, but
it shouldn't be a replacement.

> you will make it as easy as possible to install and manage it

Agreed, so that means Microsoft is the only company that can make an easy solution?

To tell you the truth, I think MSI stinks.

> to have a .msi available to push into that most enviable of customers, the
> corporate customer.

If you want .msi (for now) use Firefox. Explain, though, why a corporation would
require their programs to use .msi installation programs? That seems ridiculous.
We could even make our installation program look identical to .msi, and they
wouldn't know the difference if we ironed out the issues.

It's true that we'll have to keep on top of platform changes, but with
Microsoft, they come around every 2 years or so?

It gives us more freedom in what we do with using our own installer, and we
don't have to worry about Microsoft charging us later because they finally
decided that .msi should cost money to use. The other problem is when there is a
bug in .msi or an improvement that needs to be made, we can't do anything about it.

Finally, xpinstall's net package download is used by Netscape, could be used to
download packages during install, and isn't available in .msi and even if .msi
does offer an equivalent (does it?), we'd be locked into Microsoft technology.
(In reply to comment #43)
> Michael: Two things -- 1) Only about 1/4 of programs use .msi files, in my
> estimation, and programs are moving away. The rest use Installshield, or an .exe
> setup file built with MSI technology. 2) MSI's interface is poor, and even the
> directory selection dialog is not very good as compared to what Installshield
> uses, along with lopping off the extra directory info. Such as:

.MSI is used for silent and unatended deployment. Having an .msi packages
simplifies the persons in charge of corpoarte desktop deployment. Thus when they
tell their managment that moving to mozilla will only cost XX days.The smaller
XX the better will management let the product be deployed on desktops env.
As of today, you can use whatever technlogy you want to deploy, but most
solutions out there support .msi out of the box meaning that desktops
administrators will likely have a small XX number because they don't need to
repackages the product into their deployment tool.

We are not saying .msi is the only solution and will solve everything, the point
is having an .msi file will help the aceptance of's product on the
corporate desktop.
I have decided to reopen this bug, re comment #36 and comment #39 (Daniel
Glazman, a former Netscape engineer), and about corporate deployment, which is
important to us. What I think will be the best option is providing the .msi as
an alternate option, but not the default download. Corporate IT managers should
have the capability to download the alternate.

What I'd like to know for the future is whether xpinstall can be modified to
work over distribution channels and what tools are the most common deployment
tools, whether we can get software samples to aid in development, and what we
need to do in order to get xpinstall to mesh with them.

xpinstall is a possible marketable technology of as a competitor to
other installation software and for use by other software built off of Mozilla
technologies, and it's not something that would be in our best interest to keep
up to date and improve.

I do hear a voice of reason, though, in trying to make Mozilla accessible to as
many people as possible.
Resolution: WONTFIX → ---
There is also the Nullsoft Install System. Anyone know if this is any good as an
alternative? Does it support deployment like MSI?
Created bug 268740 about unattended deployment.
Product: Browser → Seamonkey

Comment 48

12 years ago
Hello.  As a system administrator for small to large corporations, I thought I would take a small moment answer the question posted by Samir.  Some of the benefits include:

  - integration into Group Policy Object system of Active Directory
    - allows transparent silent installations on user desktops when computer is 
      added to Active Directory domain and logon event.  Essentially all 
      desktops in a corporation can have Firefox deployed without user 
    - allows deployment based on LDAP Organizational Unit membership, e.g. 
      remote users OU install Thunderbird, other desktops OU do not.
  - support for platform package manager for Windows.  Analogous for rpms 
    for many Linux distros, and pkgadd for Solaris.
  - support for command-line silent installs for older systems that don't 
    support Active Directory GPO, i.e. Win 9X/ME/NT.  These could be automated 
    from batch files or perl scripts.

Comment 49

11 years ago
I must agree 
MSI is very easy to deploy with GPO
if we want to get more companies to use firefox we must make deployment and administration as easy as possible...
Assignee: ajbu → nobody
Priority: P4 → --
QA Contact: agracebush → general


9 years ago
Duplicate of this bug: 460894


8 years ago
Depends on: 231062

Comment 51

8 years ago
So, whats the status? No real comments from developers in over 5 *years*? Doesn't bode well.

Also - will this bug also result in an .msi for Thunderbird, or should I open up a different bug for that?

Come on guys... the bottom line is, without full .msi/GPO support, no sane corporate Admin will *ever* deploy Firefox and/or Thunderbird on a large scale.
(In reply to comment #51)
> So, whats the status? No real comments from developers in over 5 *years*?
> Doesn't bode well.
> Also - will this bug also result in an .msi for Thunderbird, or should I open
> up a different bug for that?
> Come on guys... the bottom line is, without full .msi/GPO support, no sane
> corporate Admin will *ever* deploy Firefox and/or Thunderbird on a large scale.

This bug is for the Seamonkey product.  There are separate bugs for Firefox (Bug 231062) and Thunderbird (Bug 274624).  I encourage you to CC yourself to the Firefox bug where active development is happening.  Once the foundations are laid there it will be relatively easy to get Seamonkey, Thunderbird, et. al. working MSI installers.


7 years ago
Summary: Mozilla installer for Windows should use the MSI (Microsoft Installer) → Provide MSI (Microsoft Installer) package for SeaMonkey


7 years ago
Assignee: nobody → installer
QA Contact: installer → xpi-packages

Comment 53

5 months ago
Now bug 231062 has been closed as RESOLVED/WONTFIX.
So MSI is not provided for Firefox.

Comment 54

3 months ago
This is another bug which should just be marked "WONTFIX".
>> This is another bug which should just be marked "WONTFIX".

Why? Other than that nobody found the time yet to look into this and the bug is ages old implying the it will never happen the request seems legitimate to me.
You need to log in before you can comment on or make changes to this bug.