276515 - Installer quickly and silently crashes on Windows NT 4.0 without version 5.80 or newer of Comctl32.dll

Status: RESOLVED WORKSFORME

(Firefox :: Installer, defect)

Description

[Eduard Rindt]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: FireFox 1.0+ en-US win32 installer

The EXE-installer unexpectedly crashes/terminates on an old box with Windows 
NT 4.0 following way:
1. It opens "Extracting" progress dialog, runs silently for a while, then it 
extracts (an installation) quite quickly.
2. It opens an info dialog "Initilizing Setup..." for short and closes it.
3. It opens an info dialog "Verifying integrity of archives..." for short and 
closes it.
4. Nothing more appears and the process terminates.

I repeated the procedure (getting the same result) with:
a) FireFox 1.0 Czech language [official download]
b) FireFox 1.0 (US) English language [official download]
c) FireFox 1.0 (US) English language [nightly build from 28-Dec-2004]


Reproducible: Always

Steps to Reproduce:
1. Download an installer.
2. Run the installer.
3.

Actual Results:  
Installer silently dies.

Expected Results:  
Go on with installing or at least report something.

I suspect an incompatibility with an obsolete CPU or something alike. I do not 
know how to force the installer to produce a log-file or a similar report, so 
I cannot provide more details at the moment.

See an attached report from "Windows Diagnostics" for details about the 
hardware configuration.

Comment 1

[Eduard Rindt]

Attachment: Windows NT Diagnostics report

Comment 2

[Mike Connor [:mconnor]]

What service pack is the NT box running?

Comment 3

[Hermann Schwab]

I assume you´ve got an incompatible CPU:
 
Processor list:
   0:  x86 Family 5 Model 4 Stepping 1 CentaurHauls  // ERT's note: IDT WinChip
C6 MMX @200 MHz

Firefox used to compile for i586, but changed to i686 lately.

WinChip was about compatible to Pentium (Pentium 1), I guess option i686 is for
Pentium II 

Perhaps you can change to Mozilla, as that one is still compiled for i586, see
about:buildconfig

I´m using mozilla.org zip-builds nightlies. 

Comment 4

[Eduard Rindt]

(In reply to comment #2)
> What service pack is the NT box running?

Build 1381: Service Pack 6

Comment 5

[Hermann Schwab]

Seems it is a problem of the 7-zip compressed installer,
maybe you can try to install the zip-build of Firefox, it is 2 MB larger, but in
the traditional zip format.

[ 1058884 ] Unpacking Firefox.exe
http://sourceforge.net/tracker/index.php?func=detail&aid=1058884&group_id=14481&atid=114481

Unpacking Firefox.exe
Can't unpack FireFox on an AMD K6-II 500 mhz machine.
Running in Windows 98 SE gives you an error dialog.
Running in a Windows 98 SE dos promt gives you a
crc failed error. Runing RAR 3.40 on same machine
gives you a corrupted archive error. Runing 7z on
the same machine gives you an archive error. Identical
achive loads succesfully on an AMD 2000+

Comment 6

[Eduard Rindt]

(In reply to comment #5)
> Seems it is a problem of the 7-zip compressed installer,
> maybe you can try to install the zip-build of Firefox, it is 2 MB larger, but 
in
> the traditional zip format.
> [ 1058884 ] Unpacking Firefox.exe
> http://sourceforge.net/tracker/index.php?
func=detail&aid=1058884&group_id=14481&atid=114481
> Unpacking Firefox.exe
> Can't unpack FireFox on an AMD K6-II 500 mhz machine.
> Running in Windows 98 SE gives you an error dialog.
> Running in a Windows 98 SE dos promt gives you a
> crc failed error. Runing RAR 3.40 on same machine
> gives you a corrupted archive error. Runing 7z on
> the same machine gives you an archive error. Identical
> achive loads succesfully on an AMD 2000+

I confirm that an installation from a ZIP archive succeeded and also that the 
FireFox smoothly runs on the machine, including multiple profiles and few 
plug-ins.

Thus, it seems probable, that the problem is located somewhere in the 
installation unpacker.

Comment 7

[Bill Gianopoulos [:WG9s]]

1.  The issue is definitely NOT that it won't install on any Pentium I.  I just
fired up my old 100mhz Pentium I Windows 98 second edition ssytem and the latest
trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b)
Gecko/20050117 Firefox/1.0+) installs and runs just fine.

2.  I have personally never had this make a difference, but others swear by it.
 If you are running anti-virus software, have you tried doing the install with
it disabled?

3.  Microsoft stopped supporting service pack 6 quite some time ago.  You might
try upgrading to service pack 6a (if you can find the download, might be
difficult at this point).  They may have dropped spport for that by now too but
at least it has been recently supported.

4.  I suspect that the real issue is that some Pentium I class processors had
bugs in the hardware floating point, and this may be rearing its head during the
7-ZIP decompression and the image is being currupted during the decompression.

Comment 8

[Bill Gianopoulos [:WG9s]]

> 4.  I suspect that the real issue is that some Pentium I class processors had
> bugs in the hardware floating point, and this may be rearing its head during the
> 7-ZIP decompression and the image is being currupted during the decompression.

But upon re-examining the diagnostic output, this would appear to be a 1998
vintage system, so that seems unlikely too.

Comment 9

[David G King]

How can an Unconfirmed bug be a Smoketest Blocker?

Comment 10

[David G King]

No response from drivers or those on bug mailing list, removing Smoketest
keyword from this Unconfirmed bug.

Comment 11

[Ross Boylan]

I am seeing this problem too, both with the 1.0.0 and 1.0.2 installers.  I run
the installer, it unpacks, and gets to the dialogue about verifying the archive
integrity.  Then it just dies.  No dialogue, no messages to the event logs.

I solved this for 1.0.0 by downloading a zip file, and found some references to
them for 1.0.2 in mozillazine.  But it's pretty annoying.

The system is nominally inadequate (Pentium 100, 64Mg RAM), but firefox does run
(slowly) from the zip.

NT 4.0, I think SP6 (I'm not on the machine now).  ZoneAlarm is running.  System
connects to the internet via a server that does NAT (I doubt that matters...)

I am not changing the "confirmed" status since I'm guessing that's for the
developers to mess with.

Comment 12

[Ross Boylan]

Added myself to cc list, as I'm not sure if that happens automatically.

Comment 13

[Hermann Schwab]

(In reply to comment #11)
> I am seeing this problem too, both with the 1.0.0 and 1.0.2 installers. 

> The system is nominally inadequate (Pentium 100, 64Mg RAM), but firefox does run
> (slowly) from the zip.
> 
> NT 4.0, I think SP6 (I'm not on the machine now).  ZoneAlarm is running.  System
> connects to the internet via a server that does NAT (I doubt that matters...)


The original report was about a non-intel CPU. Winchip and others were used in
cheap computers, were mostly compatible, but sometimes failed when a program was
coded regarding to the instruction timing, or using some very rarely used
instructions.

You are seeing the bug on an original intel Pentium 100?
IIRC the Pentium 100 was a new development, didn´t have cache, to be cheap.
I don´t know the buglist, but new CPUs at intel and elsewhere are having bugs
and buglists, there are workarounds in the BIOS for that.

64 MB should be sufficient, but maybe 7zip needs more RAM then available to
decompress? can you check the amount of RAM available and used?
There is a nice free utility at sysinternals, Process Explorer. 
http://sysinternals.com/
http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

Use View->SystemInformation to see the usage of CPU and RAM while decompressing.
Program is running on win9x, WinNT, Win2k, WinXP.
use the system Information 

Comment 14

[Ross Boylan]

(In reply to comment #13)
> (In reply to comment #11)
> > I am seeing this problem too, both with the 1.0.0 and 1.0.2 installers. 
> 
> > The system is nominally inadequate (Pentium 100, 64Mg RAM), but firefox does run
> > (slowly) from the zip.
> > 
> > NT 4.0, I think SP6 (I'm not on the machine now).  
I can confirm SP6
> ZoneAlarm is running.  System
> > connects to the internet via a server that does NAT (I doubt that matters...)
> 
> 
> The original report was about a non-intel CPU. Winchip and others were used in
> cheap computers, were mostly compatible, but sometimes failed when a program was
> coded regarding to the instruction timing, or using some very rarely used
> instructions.
> 
> You are seeing the bug on an original intel Pentium 100?
Yes.  System is from Dell.
> IIRC the Pentium 100 was a new development, didn´t have cache, to be cheap.
> I don´t know the buglist, but new CPUs at intel and elsewhere are having bugs
> and buglists, there are workarounds in the BIOS for that.
> 
> 64 MB should be sufficient, but maybe 7zip needs more RAM then available to
> decompress? can you check the amount of RAM available and used?
> There is a nice free utility at sysinternals, Process Explorer. 
> http://sysinternals.com/
> http://www.sysinternals.com/ntw2k/freeware/procexp.shtml
> 
> Use View->SystemInformation to see the usage of CPU and RAM while decompressing.
The failure is not in the decompression but at or immediately after the
"verifying archive integrity step."
Anyway, there was no indication of high memory useage at this point; it was
considerably higher during the decompression (c 94Mg, vs 64Mg when the
installation process crashed).  I have only 64 Mg physical ram, but c 150 with
virtual RAM.

By the way, I think I could have gotten overall memory useage from the task
monitor.  I also looked at memory use of the process as it attempted the
install, but that showed the same pattern.

Comment 15

[Max]

For bug #276515:
I experience the same bug on german Windows NT SP 6a
with the following Mozilla products (language de-DE):

* Firefox
  - versions 1.0.0 up to including 1.0.3 are broken
  - all release candidates for 1.0 are broken
  Previous versions up to 0.9.3 were fine.

* Thunderbird
  - versions 1.0.0 and 1.0.2 are broken
  - release candidate(s) for 1.0 is unknown to me
  - version 0.9 is broken
  Previous versions back to 0.7 were fine.


- Reproducible: Always (if at all; see below)
- Steps to reproduce: run "Firefox Setup 1.0.x de-DE.exe"
  or "setup.exe" after extracting it with 7-zip on a 
  clean Windows NT 4.0 SP6a machine.
- Actual results: installer (setup.exe) quietly dies; 
  occasionally a message box can be observed (see below).
- Expected Results: Install wizard shows a dialog.


The problem is always reproducible for these versions of
both Firefox and Thunderbird on several different machines.
It does not seem to be dependent on old processors as proposed;
I observed the problem at least with current processors, too.

I also know of one (1) machine (Athlon, NT 4.0 SP6a german)
on which both Firefox 1.0.3 and Thunderbird 1.0.2 installers
(both german) do actually work, but I don't know anything about
previous versions or its other software configuration.

The products run fine when installed from zip-package provided
for Firefox 1.0.0 and 1.0.1 or if installed  on another 
machine and then copied to a NT machine.

With Firefox version 1.0.2+ there is no zip-package available,
so installation of current versions of Firefox is no longer
possible.

When extracting Firefox executable install image to disk
with stand-alone 7-zip tool and starting setup.exe, I got
sometimes an empty (no message, no title) error popup message 
with an 'critical' icon. This dialog box is not reproducible.
Otherwise, setup.exe is dying quietly; therefore I suppose 
the setup.exe program is broken.

related Thunderbird bug report: 284998

Comment 16

[John Andrea]

Installer fails for me in same manner as described above for Firefox 1.0.4 on
Pentium II with 256 mb RAM plus loads of disk and swap space running MS-Windows
NT4.0 SP6a. Otherwise this machine runs very well and no toubles with Mozilla 1.7.8

Comment 17

[Hermann Schwab]

https://bugzilla.mozilla.org/show_bug.cgi?id=263812#c1 is also suffering from
this long standing bug.

Which version of 7zip is used to produce the exe-installers of firefox and Tbird?

This bug was created 2004-12-30, at that time 7z313.exe or 7z413b.exe was up to
date.

http://www.7-zip.org/ now offers 7-Zip 4.23  	2005-06-29, followed by a beta
with some bugfixes: 7-Zip 4.24 beta  	2005-07-06 

Maybe the tinderboxen should get an update of 7zip?

Comment 18

[Benjamin Smedberg]

We are currently using 7zip 3.12

Comment 19

[Anthon Pang]

I just started seeing this bug with an attempted install of Firefox 1.0.5. 
Strangely, now, I can't revert to the previous version which I was able to
install before (and was using happily using).  I've cleared temp folders,
deleted profiles/registry keys/application directories, and rebooted numerous
times to no avail.

Pentium Pro, NT4 sp6a
0 x86 Family 6 Model 1 Stepping 9 GenuineIntel ~199 Mhz

BTW Mozilla Suite 1.7.8 installed fine.

Comment 20

[Hermann Schwab]

(In reply to comment #19)
> I just started seeing this bug with an attempted install of Firefox 1.0.5. 
> Strangely, now, I can't revert to the previous version which I was able to
> install before (and was using happily using).  I've cleared temp folders,
> deleted profiles/registry keys/application directories, and rebooted numerous
> times to no avail.
> 
> Pentium Pro, NT4 sp6a
> 0 x86 Family 6 Model 1 Stepping 9 GenuineIntel ~199 Mhz
> 
> BTW Mozilla Suite 1.7.8 installed fine.

Mozilla Suite doesn't use 7-zip.
As you are one of the few people having problems with 7zip-compressed firefox,
could you download 7zip and try to uncompress firefox.exe with the 7zip
filemanager? If that works the bug must be in the stub for uncompressing.

http://www.7-zip.org/
The 1 MB exe-installer needs about 3.6 MB space on disk and also creates an
uninstaller entry in settings/Software.
There are some help files: readme.txt and 7-zip.chm.
7zFM.exe (on WindowsNT 7zFMn.exe) is the filemanager, use it to open the
firefox-installer.exe using the command File -> Open Inside, or test or extract
or whatever.

In comment 15 Max extracted all files using this tool, and the started
setup.exe, and it was always crashing.

If you need a tool for  calculating and comparing MD5SUMs, here it is:
http://digestit.kennethballard.com/

07045a82409bf677d6ebf40203ee7a49    Firefox Setup 1.0.5.exe

http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.0.5/MD5SUMS

07045a82409bf677d6ebf40203ee7a49  ./win32/en-US/Firefox Setup 1.0.5.exe

you don't have to compare visually, just copy the sum and use digestIT to verify.

Comment 21

[Anthon Pang]

The hash for "Firefox Setup 1.0.5.exe", 07045a82409bf677d6ebf40203ee7a49, is as
expected, ruling out a corrupted download.

We should also rule out insufficient resources given previous reports and my
case: physical memory: 96 MB RAM (192 MB virtual); available disk space (C:,D:):
4.7 GB and 7 GB, respectively.

Also, I think we can eliminate 7-Zip as the culprit.  Using both 7-Zip v3.12
(2003-12-09) and 7-Zip v4.23 (2005-06-29), I tested & extracted the contents of
"Firefox Setup 1.0.5.exe" successfully.  I was also able to test & extract
successfully the contents of the individual *.xpi files contained within. 
Nonetheless, as previously observed, setup.exe exits after displaying "Verifying
integrity of archives, please wait...".

Can we narrow the problem search to "setup.exe"?  (How is it packed?  How does
it interface to 7-Zip?  etc.)

Comment 22

[John Andrea]

Thunderbird 1.0.6 and Sunbird 0.2 behave exactly the same; extract then verify
then stop. I can open with 7Zip 4.15b.

Comment 23

[John Andrea]

Further to above comment about similar troubles with Sunbird. Sunbird provides a
zip file which allows me to run the product with no troubles.

Comment 24

[Hermann Schwab]

I'm not using NT, so I don't experience this bug. But I wanted to see a debugger
in action and downloaded Ollydbg110, free, unzipped the installer package and
stepped through setup.exe using the debugger.

I got a message that the programm will call an external address, msvcrt20.dll,
and after that the 'Verifying Archives' message came.
A quick search on my Win98 was showing two different versions of Msvcrt20.dll:

C:\windows\system\msvcrt20.dll Version 2.11.000
and in another place a version 2.10.000

Maybe you can upgrade to a newer version?

Language is English: http://www.ollydbg.de/

I wanted to look at the source code in LXR, but seems to me LXR is only for the
suite?

http://lxr.mozilla.org/aviary101branch/source/toolkit/mozapps/installer/windows/wizard/setup/

Comment 25

[timeless]

you're also welcome to use windbg, currently
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.5.3.7.exe

it's free, not shareware. probably a better use of time is to read older bugs
about our installers on nt4. most of them related to image resolution and fonts
iirc.

Comment 26

[Anthon Pang]

On my NT4 box, all copies of msvcrt20.dll are 2.11.000.  For the moment, I'm
going to say this is a red herring.

Comment 27

[Anthon Pang]

From comment 24, I traced setup.exe.  After returning from MakeFont() [deduced
from seeing this sequence of function calls: GetDC(), GetDeviceCaps(),
ReleaseDC(), and CreateFontIndirect()], the next significant API function called
was GetCurrentProcess() and TerminateProcess().  setup.exe isn't crashing, per
se; rather, the wizard doesn't start in
/mozilla/toolkit/mozapps/installer/windows/wizard/setup/dialogs.c, and the
process exits quietly without checking the return value from PropertySheet():

  // Start the Wizard.
  if (psh.nPages > 0) {
    PropertySheet(&psh);
  } else {

Looking at the initialization of psh:

  psh.dwFlags           = PSH_WIZARD97|PSH_HEADER;

We note that PSH_WIZARD97 and PSH_HEADER were introduced in version 5.80 of
Comctl32.dll which only shipped with Internet Explorer 5. (Reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/versions.asp)

This conclusion is supported by bug 302169 where the reporter found that IE5 (or
later) had to be installed.

Can version 5.80 of Comctl32.dll (and presumably 5.0 of Shlwapi.dll and
Shell32.dll) be downloaded separately or redistributed in the Firefox installation?

Comment 28

[Anthon Pang]

I will confirm this tomorrow, but it appears NT4 users can download updates to
the common controls (verson 5.80.2614.3600) here:

"Platform SDK Redistributable: Common Controls DLL" (CC32inst.exe)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6F94D31A-D1E0-4658-A566-93AF0D8D4A1E

Comment 29

[OstGote!]

*** Bug 302169 has been marked as a duplicate of this bug. ***

Comment 30

[Anthon Pang]

I can now confirm that once I updated the common controls, I was able to
successfully install Firefox 1.0.6 on my NT4 box (and more importantly, without
installing IE5+ beforehand).

Comment 31

[Sven Coenye]

We (reporters of bug 302169) can now confirm this too. Installation of the
updated controls allows the installation of Firefox to continue on an otherwise
fresh installation of NT4 + SP6a

Comment 32

[Hermann Schwab]

I assume this bug needs a relnote.
Firefox/Thunderbird/Sunbird can't be installed on a NT4 system, if it isn't
updated to IE5.5 or 
"Platform SDK Redistributable: Common Controls DLL" (CC32inst.exe)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6F94D31A-D1E0-4658-A566-93AF0D8D4A1E

Thanks to Anthony Pang for resolving this issue.

What if MS is abandoning this update link?
Can Mozilla.org host that and other needed redistributables (GDIplus.dll for
SVG) somewhere?

Is updating NT4 a solution or a workaround, as the suite doesn't have this problem?

Comment 33

[Anthon Pang]

According to the release notes and license text in the CCinst.exe
self-extracting package, these updated DLLs are freely redistributable as a
package; thus, Mozilla could host a copy, guarding against the (likely?) event
that the URL changes.

Comment 34

[Casey Allen Shobe]

This one had me stumped...fresh install of NT 4 Server SP1 - installer died. 
Installed SP2 - installer died. 
Installed SP3 - installer died. 
Installed SP4 - installer died. 
Installed SP5 - installer died. 
Installed SP6a - installer died. 
Installed IE3 - installer died. 
Installed IE4 - installer died. 
Installed IE5 - installer died. 
Installed IE5.5 - installer died. 
Installed IE6 - installer worked. :P 

Comment 35

[Hermann Schwab]

requesting blocking, as the bug can be fixed by a relnote.
Cause of bug was found in comment 27, workaround in comment 28.
Bug also exists in Thunderbird, not in Seamonkey.

Comment 36

[Mike Connor [:mconnor]]

This isn't appropriate for the 1.0.x branch.  We know what's required by the
installer, but we don't know what code uses those libraries or if there's an
acceptable workaround.  This should be added to the Help and Release Notes
sections, but its probably not going to affect 2.0 since we're building a new
installer.

Comment 37

[Jay Patel [:jay]]

mconner:  Is this still an issue with 1.5x?  If so, what would you like to see in the release notes?  

Comment 38

[Mike Connor [:mconnor]]

Jay, suggested wording is as follows:

On some older versions of Windows NT 4.0, the installer may fail to run.  Affected users may install a new version of the Common Controls DLL from the following URL: 

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6F94D31A-D1E0-4658-A566-93AF0D8D4A1E

Comment 39

[Eric Windisch]

Testing against a new install with NT4+SP6a, this is still a problem with Firefox 1.5.

I should also note that the Requirements page at Mozilla.com lists Windows NT4 as being compatable.  Perhaps until a proper fix is provided, a link can be made on that page providing a link to a page providing information on installation on NT4.  (as it is fairly straight forward on other platforms).

Comment 40

[Andreas Morawietz]

(In reply to comment #39)
> Testing against a new install with NT4+SP6a, this is still a problem with
> Firefox 1.5.


Same here on an old laptop with windows nt 4.0 SP6a

There should be at least a message while installing, that windows nt isn't supported. It's very bad that the installation closes and aborts without saying anything :(

Comment 41

[Anthon Pang]

Attachment: Obligatory one-liner.

Patch: fallback to a silent install if call to PropertySheet() fails.

Comment 42

[Hermann Schwab]

Comment on attachment 207984 [details] [diff] [review]
Obligatory one-liner.

Benjamin, could you please review this, before NT4 gets obsolete?

Comment 43

[Maarten Geurts]

Same behaviour happens here on a windows 98 (NOT Second edition) machine that is freshly installed in a vmware virtual machine. 

It goes through verifying an the installer disappears.

Installing internet explorer 6.0 sp1 over the i.e. 4.0 solved this, but it kind of weird to have to install internet explorer just to install firefox. 

Tried to install with firefox 1.5.0.1 & 1.0.7 installer. 

Comment 44

[timeless]

[e-mail]: that seems like a terrible fallback. how important is the property sheet, what's it doing, and can't it be worked around in some more reasonable way? i can't imagine an nt4 user really wanting a silent install.

Comment 45

[Hermann Schwab]

(In reply to comment #43)
> Same behaviour happens here on a windows 98 (NOT Second edition) machine that
> is freshly installed in a vmware virtual machine. 

You are the 1st to see this bug on something other than NT4, but I assume Win98  will be rarely fresh installed nowadays, so it looks as you are seeing the same bug:

> It goes through verifying an the installer disappears.
> 
> Installing internet explorer 6.0 sp1 solved this, but it kind
> of weird to have to install internet explorer just to install firefox. 

You don't have to, if you read comment #27 and comment #28.

> Tried to install with firefox 1.5.0.1 & 1.0.7 installer. 
 

Comment 46

[Anthon Pang]

re: comment 44 - the user's expectation is that Firefox is going to be installed.  The "silent install fallback" at least meets that expectation, and it only happens when the latest common controls aren't installed.  Since the installation wizard is implemented using property sheets, the alternatives are to (1) rewrite the wizard, or (2) pop up a message box.  From comment 36, rewriting the installer specifically for the 1.x branch doesn't appear likely.  (Do we want to see if a backport from 2.x is possible?)  The one-liner "fix" at least doesn't require the respective i18n/l10n teams to translate the message.

Comment 47

[Benjamin Smedberg]

Comment on attachment 207984 [details] [diff] [review]
Obligatory one-liner.

Whatever the correct fix is, it's not to make this into a silent installer.

Comment 48

[Anthon Pang]

Attachment: Fallback to auto install

There is an existing code path for a simple dialog-based, non-wizard, installation.  This patch changes conditions so that this code path is also -- or rather, "should also be", seeing as I haven't yet rebuilt FF to test this -- executed if the call to PropertySheet() fails.

Comment 49

[Hermann Schwab]

(In reply to comment #48)
> Created an attachment (id=212617) [edit]
> Fallback to auto install
> 
> There is an existing code path for a simple dialog-based, non-wizard,
> installation.  This patch changes conditions so that this code path is also --
> or rather, "should also be", seeing as I haven't yet rebuilt FF to test this --
> executed if the call to PropertySheet() fails.

Do you want to ask for review? 1.5.0.x and Firefox2 will be the last ones working on WinNT and Win9x, current Trunk is for Win2k and newer only.  

Comment 50

[Robert Strong (they/them - no direct email)]

There is a new installer. Reporter, could you please confirm with a latest 1.8.1 branch nightly? Thanks.
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8

Comment 51

[Dave Townsend [:mossop]]

*** Bug 346685 has been marked as a duplicate of this bug. ***

Comment 52

[Robert Strong (they/them - no direct email)]

I'd appreciate it if someone that has experienced this problem could try to reproduce it with a latest 1.8.1 branch nightly. Thanks.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/

Comment 53

[Amir Szekely]

I have not experienced this bug in the past, but I found it because of the release notes of Firefox 2 that mention comctl32.dll as a requirement for Windows NT 4. I found it quite surprising as NSIS should work on NT4. So I found my NT4 installation and tested this again. With SP1 and comctl32.dll 4.70, the installer works without any problem. I believe the bullet on the release notes can be removed.

Comment 54

[timeless]

[e-mail]: would you please remove this bug from the release notes?

the installer referenced in this bug was replaced by nsis which as mentioned doesn't have this feature.

Comment 55

[Steven Garrity [:sgarrity]]

Timeless: which version of the release notes?

Comment 56

[Amir Szekely]

Firefox 2.0 release notes:

http://www.mozilla.com/en-US/firefox/2.0/releasenotes/

Comment 57

[Steven Garrity [:sgarrity]]

Ok, this was removed from the 2.0 release notes and is tagged for production - just needs to be pushed live by IT.