Open Bug 52052 Opened 24 years ago Updated 1 year ago

Provide MSI (Microsoft Installer) package for SeaMonkey

Categories

(SeaMonkey :: Installer, enhancement)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

Details

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

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: http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/msi/wiport_6gf9. htm
:-) 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]
URL: http://msdn.microsoft.com/library/def...
Keywords: helpwanted
Gemal, 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.
Just in case you want a (good) example of a XP software package that uses MSI for its win distribution: http://www.mozart-oz.org/download/winarchive.shtml
I'm pretty sure that one solution to the bugs I'm blocking is MSI.
Blocks: 11210, 18916, 22210, 23222, 27577, 27586, 28172, 28174, 28332, 30166, 32860, 33351, 48815, 51928, 51988, 51991, 52037
Blocks: 39223, 43792, 46018, 47732, 47959, 48623
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.
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.
> 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 embraced.
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 designed.
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.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Priority: P3 → P4
Reassigning.
Assignee: ssu → nobody
Status: ASSIGNED → NEW
After playing a lot with MSI, I'm begining to think it's a bad idea to use MSI...:)
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.)
Blocks: 60843
I posted the information about irregularly shaped windows: bug 60843.
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) <rant> 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. </rant> 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)
No longer blocks: 60843
> 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.
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 http://home.planet.nl/~ajbanck/mozillamsi/msi_wizard.html 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 script. 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.
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, http://bugzilla.mozilla.org/ will probably do. the pictures look great. installers seem to live in one of two places mozilla/build/ [package/] mozilla/xpinstall/ 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
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 cool....
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
Nope, dont remove me. I just dont think this bug is very important. Some of the MSI features are cool though...
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
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?
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. ajbu@planet.nl: could you zip a current msi (that uses urls) and attach it here?
URL: http://msdn.microsoft.com/library/def... → http://home.planet.nl/~ajbanck/mozill...
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: http://msdn.microsoft.com/vstudio/nextgen/beta.asp
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 52037.
No longer blocks: 11210, 18916, 22210, 23222, 27577, 27586, 28172, 28174, 28332, 30166, 32860, 33351, 39223, 43792, 46018, 47732, 47959, 48623, 48815, 51928, 51988, 51991, 52037
I have .net beta1 but i haven't installed it on my computer.. maybe this summer. The thing is that ajbu@planet.nl already created an msi, and it works...
Hi, 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 (http://www.linkcad.com/index.asp?in=/msi2xml/msi2xml.htm) that might be useful for storing the installer in CVS.
*** Bug 84670 has been marked as a duplicate of this bug. ***
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 :)
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...
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
verified
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → gbush
*** 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" section 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.
*** 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).
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).
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 mozilla.org'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 mozilla.org 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.
Status: VERIFIED → REOPENED
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
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 interaction. - 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.
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
Status: REOPENED → NEW
Priority: P4 → --
QA Contact: agracebush → general
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.
URL: http://home.planet.nl/~ajbanck/mozill...
Summary: Mozilla installer for Windows should use the MSI (Microsoft Installer) → Provide MSI (Microsoft Installer) package for SeaMonkey
Assignee: nobody → installer
QA Contact: installer → xpi-packages
Now bug 231062 has been closed as RESOLVED/WONTFIX. So MSI is not provided for Firefox.
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.
See Also: → 1738953
You need to log in before you can comment on or make changes to this bug.