Closed Bug 27601 Opened 25 years ago Closed 24 years ago

Mozilla Fails to Launch Properly without msvcirt.dll

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: charlesloosen, Assigned: leaf)

References

(
URL
)

Details

Attachments

(2 files)

Mozilla M17 install log (from Uninstall directory)
226.55 KB, text/plain
Details
Netscape PR2 install log (from Uninstall dir)
389.44 KB, text/plain
Details 
When attempting launch Mozilla.exe in M13 I get several errors. Eventually a 
small title bar appears at the top left hand corner of my screen. It has all 
three minimize, maxamize and close buttons but when I click maxamize it only 
expands the title bar, there is no actual application window. I have searched 
for bug reports similar to this. One involving win32 users suggests we remove 
the mozprofile.dat file or rename it. I did this but I still encounter the same 
problem with the title bar and the same errors appearing during mozilla's 
launch.  

Steps to recreate:

1) Unzip the win32 M13 file
2) Double click on Mozilla.exe
3) DOS Consol should appear
4) After several seconds the small title bar window should appear in the top 
left hand corner of screen but no application window.

These are the error messages I see in the DOS Consol when Launching Mozilla:

**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\WINDOWS\DESKTOP\BIN\components\xpacc
t32.dll) Load FAILED with error: error 0
**************************************************
*** Deferring registration of sample JS components
*** Registering sidebar JS components
*** Registering sample JS components
nNCL: registering deferred (0)
nNCL: registering deferred (0)
WEBSHELL+ = 1
**************************************************
nsNativeComponentLoader: GetFactory(C:\WINDOWS\DESKTOP\BIN\components\gkhtml.dll
) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\WINDOWS\DESKTOP\BIN\components\gkhtml.dll
) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\WINDOWS\DESKTOP\BIN\components\gkhtml.dll
) Load FAILED with error: error 0
**************************************************
DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=
text/xul
**************************************************


I have verified that all the files which are having errors *do* exist so this 
isn't a problem of mozilla not having the files.  When I click the close button 
on the small title bar I get the following Illegal Operation error:

**********************************************
MOZILLA caused an invalid page fault in
module APPSHELL.DLL at 0157:60015d26.
Registers:
EAX=00000000 CS=0157 EIP=60015d26 EFLGS=00010246
EBX=00c12e20 SS=015f ESP=0063f4c8 EBP=0063f54c
ECX=0063f544 DS=015f ESI=80000000 FS=12c7
EDX=0063f544 ES=015f EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 08 ff 51 48 85 c6 75 6c 8d 4d 8c 89 7d e8 e8 
Stack dump:
00000000 0063f544 00000000 00c14450 0f0e0d0c 13121110 17161514 1b1a1918 
1f1e1d1c 23222120 27262524 2b2a2928 2f2e2d2c 33323130 37363534 3b3a3938 
***********************************************


Microsoft Windows 95 Version 4.00.950.00 B
Pentium 200 MHz MMX
64 MB EDO Ram
4.1 GB Hard Drive
I think you have some left over cruft from a previous build of mozilla
in your .\components subdirectory (the "Load FAILED with error: error
0" is consistent with that statement -- see 
http://bugzilla.mozilla.org/show_bug.cgi?id=23018).

Do the following: 
 o delete c:\windows\mozregistry.dat
 o delete your .\Users50 subdirectory (should be located somewhere
   under c:\program files\, most likely under c:\program files\netscape).
 o delete your current install directory for mozilla; in your case,
   that would be c:\windows\desktop\bin\*

Then try this again. Please mark this bug as WORKSFORME if this clears up
your problem. Thanks.
I did as the read me file asks and followed your instructions. The problem has 
still not been resolved. I did several searches in an attempt to locate old 
files but I deleted them all the last time I removed mozilla from my hard disk. 
I'm going to try to install it on another computer which runs windows 95 
tomorrow and will post the results here.
I've now tested the M13 Milestone using the *.exe version with the updated 
DLL's on a school computer. It was a clean install, mozilla had never been put 
on that computer before. I encountered the same problem as on my home PC. 
Mozilla fails to launch under a Windows 95 system at my school running a 333 
MHz Pentium II processor. Because this was a clean install, we can now conclude 
that this problem is not a result of files left over from a previous build.
Severity: critical → blocker
Sound good.  marking this Invalid.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Marking Verified.
Status: RESOLVED → VERIFIED
Reopening. (This wasn't really resolved, although I'm probably going to regret
reopening, because it's not clear at this point why some people are having a 
problem with the M13 build on win95. However, someone else just noted this same
problem in n.p.m.general. I expect that this is just a transient problem, but
in the wonderful world of win32, there has been a number of bugs that only 
affect some subset of people with some (undefined) combination of DLLs.)

terrigena@home.com : any further comments?
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
[Since I reopened it, I'll take this bug for now].
Assignee: leger → 3jrgm
Status: REOPENED → NEW
Within the past week this problem seems to have been resolved. I downloaded a
nightly build today and it is working fine now. I'm going to mark this bug as
FIXED as of 2-25-2000
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I had the same problem in M13. Deleting mozregistry.dat didn't help. I do not
have a directory Users50. Problem is not fixed in M14, I still only get a small
titlebar. Im usings W95 4.00.950b on a pentium with 32Mb
sander@win.tue.nl : a couple of questions :

1) do you get the "nsNativeComponentLoader: ..." messages that are noted at 
the top of the bug report?

2) you do have a .\Users50 directory somewhere (mozilla will create one any
time it is run, if it doesn't already exist). Use the 'Tools -> Find -> Files 
or Folders' menu selection in Windows Explorer to locate this directory. When
you do find it, *DON'T* delete it -- rename it to .\Users50XXX or whatever. 
The "title-bar-only-window" may be due to a corrupt file in your profile
(see bug #26834 for a different example). 

When you rename .\Users50 out of the way, a default one will be generated. If
this fixes your problem, then either attach a zipfile of the old directory to 
this bug report, or email it to me (But first delete any .\Mail and .\News
subdirectories if you want). Thanks. 

p.s. jrgm@netscape == 3jrgm@qlink.queensu.ca ... it's the same person, just 
different email address.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Here are my answers:

1) Starting M13, with the installer. With \PF\Netscape\Seamonkey\mozilla I get
the following errors:

**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\NETSCAPE\SEAMONKEY\com
ponents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\NETSCAPE\SEAMONKEY\com
ponents\gkparser.dll) Load FAILED with error: error 0
**************************************************
nNCL: registering deferred (0)
WEBSHELL+ = 1
DocLoaderFactory: Unable to create ContentViewer for command=view, content-type=
text/xul

Closing mozilla gives an 'illegal operation' in APPSHELL.DLL

Starting M14 first gives a nice dragon and the the small title bar. I don't see
any error messages. When I close it the illegal operation is gone. 
 
2) 
Start->Find-> Files or Folders , searching for Users50 produces nothing.

I unpacked the M14 zip file in \tmp, After running \tmp\mozilla it produced
the folders 

\tmp\bin\{chrome,components,defaults, OurTestData, res}

Are you sure that Mozilla didn't crash before he's supposed to make the Users50
directory?

I have had the same problem with both M13 and M14.  The program launches as 
a "small title bar... at the top left corner..."  I also am using a 200Mhz 
Pentium, 64 of RAM running Windows 95 4.00.950 B.  Shouldn't this bug be 
nominated for PDT+ or whatever?  
Are those that are seeing this crash still seeing this crash in a nigtly build? 
You might delete the mozilla registry files in c:\windows\moz*.dat
Also remove the User50 directory and the bin directory then.  Install the latest 
build from 

ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/

Other Win95 people are not seeing this (like me) so we need to know what makes 
you "special".


asj@ipa.net: I took your advice and I tried the mozilla-win32-installer.exe 
build in the ..nightly/latest/ directory.  The result was similar to my 
experiance with M13 and M14... "small title bar... at the top left corner..." 
but with a slight variation.  Instead of exiting nicely and cleanly it started 
spawning multiple copies of itself and sucking up system resources until 95 
crashed.  

I'm thinking what needs to be done is to do a clean install of 95 and see if 
M14 works. If it doesn't then this a pretty serious bug (my PC hardware is 
fairly common). If it does work then I'll add programs, and drivers, one at a 
time to see when M14 stops working. 
fisher7@thegrid.net, when you tried M14 did talkback activate when you crashed?

A talkback report might help the developers.  If you are able to send a talkback 
report back include this bug number in the takback report and they can attach 
all the results to this bug list.  

If you try the latest M15 again you might also try running it with -console 
paramater as in "mozilla -console".  The output might also have something 
interesting.


I've now experienced the same problem with *multiple* windows. I can say for 
sure that these errors are NOT from previously installed builds. I reformatted 
my entire hard disk two days ago and when I installed the nightly build 
yesterday. I launched mozilla and it started spewing hundreds of those little 
title bar windows, as if the program was trying to make hundreds of browser 
windows. I was able to CTRL+ALT+Delete and close mozilla before it crashed 
Windows.

I don't believe this has anything to do with prior installations of Mozilla, at 
least not in my case.

This problem has become more severe because it is now eating up system 
resources at a very fast rate and it appears to be more wide spread than 
originally thought.
Whiteboard: PDT+
terrigena@home.com only the PDT team can add put PDT+ on bugs.  I am putting 
beta1 as a keyword so it will be evaluated by the PDT team.  The problem is as 
deadlines approach not as many bus will get that status.  Especially on a bug 
that may be hard to reproduce.  Not sure what the developers would want, but 
they might be interested in specifics about your computer, software versions, 
ect.

Did you try the -console option or try an M14 build with talkback?
Keywords: beta1
Whiteboard: PDT+
Well, we seem to have enough reports of this that it seems to bite
certain win95 configurations. However, it's not clear why these
certain platform configs are affected, and others aren't.

To sum up: 

  1) This has been appearing in M13 and M14 builds (and the latest
     builds? can someone try out a recent build at
     ftp://ftp.mozilla.org/pub/mozilla/nightly/ -- note: you will need
     to launch mozilla from a DOS prompt with the command 'mozilla -console'
     in order to see the error messages)

  2) messages like "nsNativeComponentLoader:
     GetFactory(C:\WINDOWS\DESKTOP\BIN\components\gkhtml.dll ) Load FAILED
     with error: error 0" are dumped to stderr/stdout.

  3) the mozilla window comes up as only the title bar. (Not a big surprise, 
     since if gkhtml.dll doesn't get loaded, there is no layout engine, and 
     hence no canvas and chrome). 
 
  4) the application crashes after that point.

  5) this has only been reported on Win95 (and not on other win32 OS).

Someone with a larger brain than me, may have a better clue, so I am
nominating dp/XPCOM.
Assignee: 3jrgm → dp
Status: REOPENED → NEW
Component: Browser-General → XPCOM
Accepting. Jan I need your help in reproducing this inhouse. Jan assign this 
back to me.

Folks who are seeing this problem, please confirm these:

1. you are seeing the problem with the M14 nightly
2. you deleted your previous installation (program directory) before installing 
the new M14 build

gkhtml.so failing could mean two things:

a) No memory since this is a HUGE dll
b) This dll is has an external dependency on some dll that some of you dont 
have. Could this be VC releated ?

Eitherway, we need to reproduce this inhouse.
Assignee: dp → leger
Target Milestone: M14
Putting on PDT- radar for beta1.  We do not see thsi in house.  Please send 
reproducible steps to reproduce if found on today's tip.
Whiteboard: [PDT-]
OK, just did a completly clean install of Win95 B to see if the problem would 
still be there. I tried the M14 installer program and ran into bug 30652.  
Anyway, after I installed IE 5.01 the M14 installer program worked and I was 
able to confirm that a nearly clean install of 95B running M14 shows the "small 
title bar... at the top left corner..." problem.

Also tested out latest M15 nightly build (3/7/00), the "small title bar... at 
the top left corner..." problem is still evident. However, it also has the 
multiple spawning windows problem as mentioned in this bug.  Here is a output 
from the console option for nightly build 3/7/00 (note, all previous mozilla 
installs were deleted before running this, and mozregistry.dat was removed):

stdout directed to dynamic console
stderr directed to dynamic console
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\c
omponents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\c
omponents\gkparser.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\c
omponents\TestDynamic.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\c
omponents\xpacct32.dll) Load FAILED with error: error 0
**************************************************
nNCL: registering deferred (0)
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Entered MigrateProfileInfo.
Profile Manager : Command Line Options : End
WEBSHELL+ = 1
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
WEBSHELL+ = 2
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
WEBSHELL+ = 3
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
WEBSHELL+ = 4
**************************************************
nsNativeComponentLoader: GetFactory(C:\PROGRAM FILES\MOZ-M15-NITE-3-7\BIN\compon
ents\gkhtml.dll) Load FAILED with error: error 0
**************************************************
WEBSHELL+ = 5

It keeps up like that until WEBSHELL+ = gets into the hundreds and system 
resources run out. My PC is a P200MMX, 64 MB SDRAM, Shuttle 569 MB. Only 
software installed is Windows95 B (4.00.950 B) IE 5.01, Quicken 4, and video 
card, modem, and moniter drivers.

Here's a stab at steps to reproduce this bug, based on my experiances and other 
peoples comments:

1.  Find a midrange computer, around P-200 64 ram 

(Not sure if this is necessary. Any machine might work, maybe it's just that 
people running 95B use midrange PCs, but who knows?)

2.  Reformat your windows partition 
3.  Install Windows 95 *B* (You can have my copy if needed)
4.  Install IE 5 (Until bug 30652 is fixed mozilla won't run at all on a clean 
windows install)
5.  Try a nightly M15.  The "small title bar... at the top left corner..." and 
multiple spawning windows problem should be evident.

Sorry for the insanely long post, but there was a lot to say :-)

I confirm this. I get the exact same errors and then lots of windows are opened.
I used the nighly build of 03/05/00 named mozilla-win32.zip

Following up on my previous post: I tried the nightly build
mozilla-win32-installer.exe. I get the same errors except for TestDynamic and
xpacct32.dll. Then the multiple windows bug kicks in.

BUT. I get the Users50 directory for the first time! No previous build/milstone
did that for me
Ok.  I just downloaded the March 10 mozilla-win32-installer.exe and then the 
mozilla-win32.zip.  Both installed, unzipped, and launched just fine.  I am on 
Win95.

I have to mark this works for me.  We cannot reproduce this anywhere in house.
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
I just tried the March 10 mozilla-win32-installer.exe and the mozilla-
win32.zip.  Neither worked.  Both had the small title bar in left hand corner 
bug, and the multiple window bug.  I also tried the March 12 installer and 
zip.  Same behavior as the March 10.

leger@netscape.com: Did you follow the steps to reproduce (four comments above 
this comment)?  If not, in bug 30652, second to last comment, someone at 
netscape says they have a box to test 30652.  Both bugs require a clean win95B 
install to reproduce.  If you want to reproduce this bug "in house" test it on 
that machine.
OK, just to let everyone still following this bug know that a fix has been found
in bug 32340 (a duplicate of this bug, essentially).  Find msvcirt.dll on the
net (here is a copy http://www.winappz.com/msvcirt.zip), and put it in your
c:\windows\system directory. Then mozilla loads up perfectly!

Hey fisher7 : thanks for keeping on top of this one. [You're making me feel
remiss for not pursuing this more thoroughly myself.]. The good news is that
there is (in the end) a diagnosis/fix for this problem. Thanks to terrigen 
and sander too. 
reopening this bug because bug #32340 is for the commercial build.  This bug 
refers to the mozilla build which still needs to be addressed.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
reassigning to myself.
Assignee: leger → ssu
Status: REOPENED → NEW
Status: NEW → ASSIGNED
need to fix in mozilla build to install missing msvc* dlls.
Target Milestone: M14 → M15
updated Summary
Summary: Mozilla Fails to Launch Properly → Mozilla Fails to Launch Properly under Win95
clearing PDT and beta1 keyword
Keywords: beta1
Whiteboard: [PDT-]
*** Bug 28695 has been marked as a duplicate of this bug. ***
*** Bug 33386 has been marked as a duplicate of this bug. ***
Changing summary to reflect real problem, it has been seen on NT (see bug 
28695).  More things on NT install the library so it's more likely to strike on 
older versions of Win95.
Summary: Mozilla Fails to Launch Properly under Win95 → Mozilla Fails to Launch Properly without msvcirt.dll
*** Bug 32675 has been marked as a duplicate of this bug. ***
*** Bug 34192 has been marked as a duplicate of this bug. ***
mass change to M16
Target Milestone: M15 → M16
*** Bug 34192 has been marked as a duplicate of this bug. ***
*** Bug 34946 has been marked as a duplicate of this bug. ***
Any chance of this making the M15 train for the mozilla installer? (the 
dups are a-piling up :-\
maybe.  I will need leaf's help.

*** Bug 34600 has been marked as a duplicate of this bug. ***
In addition to MSVCIRT.DLL a clean install of Win95 retail also needs MSVCRT.DLL
*** Bug 38144 has been marked as a duplicate of this bug. ***
*** Bug 38144 has been marked as a duplicate of this bug. ***
I've updated the installer build scripts to attempt to install msvcrt.dll and 
msvcirt.dll files.  The build scripts will look for (and copy if exist) the 
following:

  %MOZ_SRC%\redist\microsoft\system\msvcrt.dll
  %MOZ_SRC%\redist\microsoft\system\msvcirt.dll

They will be copied to the appropriate location so the build scripts can bundle 
them into the appropriate .xpi file.

If the files are not there, the installer build scripts will not fail, nor will 
the installer that is built.  This bug will just reappear in this scenario.

The only part left to fully resolve this bug is to have the microsoft 
redistributable files be manually copied to the above path *prior* to running 
the installer build scripts.

Reassigning to leaf.
Assignee: ssu → leaf
Status: ASSIGNED → NEW
*SPAM* - adding mostfreq keyword to bugs with loads of DUPEs. Please aid this 
effort by adding this keyword to any bugs with more than 15 DUPEs.

Gerv
Keywords: mostfreq
ok, i've finally gotten to this... ssu, why did we move the fetching of these 
dlls from the staging area on lithium to the local machine, again?

This isn't something easily done automatically on the client side, because there 
are any number of mscvrt.dlls to choose from!
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
URL: ftp://ftp.mozilla.org/pub/mozilla/nig...
Status: RESOLVED → REOPENED
QA Contact: cbegle → jrgm
Resolution: FIXED → ---
Hey, leaf, the msvcirt.dll is not getting installed by the installer (or 
otherwise not packaged). This means that a user who does not already have
msvcirt.dll (which implement ifstream/ofstream and friends from C++), will
still be exposed to this error (which potentially will freeze Windows).

My test: 
1) reboot into DOS
2) delete c:\windows\system\msvcirt.dll
3) reboot into win95 (or whichever windows one is running). 
4) run the installer. In my test, the M16 candidate build: 
  ftp.mozilla.org/..../nightly/2000-06-08-15-M16/mozilla-win32-installer.exe

Result: endless number of zombie windows get thrown up, until mozilla crashes 
when it has exhausted system memory available.

I have searched for the msvcirt.dll, but it is not anywhere on my disk.

(I think I am going to open a separate bug for XPCOM on the abusive behaviour 
when this DLL is not found -- i.e., we're doomed without it, so why trash the 
system -- just shut down gracefully).
d'oh! i'll add the appropriate dlls to the correct locations on the client
machine.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
John: Did you file a bug on XPCOM's "abusive behaviour"? I was just bitten by
it and I would like to track what happens w.r.t. this issue.
Yes, I filed bug 42198 'mozilla bootstrap behaviour could be more well-behaved'
(although perhaps that summary needs to be a bit punchier, as it really is 
abusive when it happens).
leaf : do we want to get this retroactively fixed for the M16 installer, or 
is this too much risk/effort. I will do the testing if you give me a candidate
set of bits.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 43545 has been marked as a duplicate of this bug. ***
I'll try and fix this in the package retroactively for m16... is this *still* a
problem in the most current builds?
Status: REOPENED → ASSIGNED
In the trunk M17 builds, this is being done correctly (adding msvcirt.dll if
not already in place on a user's system).

This is only a problem for the M16 blessed stable bits, for users who do not 
have msvcirt.cll; this is a minority of Windows users, but, for example, any 
clean install of win9x, winNT, win2k will not include this dll. 
Since the current builds are fixed (No new dupes for a allmost a month) 
shouldn't this bug be resolved? If it was held open for a retroactive fix of M16 
it's a little late to worry about it now.
*** Bug 46317 has been marked as a duplicate of this bug. ***
quite right. marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Seems fine to me. Verified
Status: RESOLVED → VERIFIED
Of course, the other way to check this is to remove msvcirt.dll from your
machine and do the mozilla install. And (sorry, leaf) the most recent build of
the installer (2000-08-04-05-M17), the one that will be the M17, does not
install msvcirt.dll if it does not exist in \windows\system.

So, it's just a matter of time until someone gets their system trashed, and
reports this bug ... need to fix this baby (wah!).
URL: ftp://ftp.mozilla.org/pub/mozilla/nig... → ftp://ftp.mozilla.org/pub/mozilla/nig...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
By the way, the Netscape installer does the right thing. This is just about
the Mozilla installer for M17. (Passing this bug on to Asa, as I'm sure Leaf
has gotten quite tired of me. (Gee, when this bug started, I was a completely 
different 3jrgm living in Canada.))
QA Contact: jrgm → asa
Ok, to be clear, are you saying that a new msvcrt.dll does get installed if
there is one in the system directory already!? I don't understand what's changed
between when you saw it working and now, because the process hasn't changed
since then.
Status: REOPENED → ASSIGNED
What I am saying is ... if I do not have a 'msvcirt.dll' in the windows\system
directory, the mozilla installer exe will NOT install one for me. (And when
the browser starts I get the endless series of tiny windows being opened).

On June 26, I did not have this problem but, no, I can't explain what has
changed so that this no longer gets installed.

I'll go try this on another machine and let you know if that fails or passes
(i.e., installs msvcirt.dll if not already available). I will also check that
the PR2 bits work correctly (since I was assuming they would work). 
Using the mozilla-win32-installer.exe from 2000-08-04-05-M17 on ftp.mozilla.org
on a win98 machine that does not have 'msvcirt.dll' in windows\system, the 
installer does NOT install that DLL if it is missing. Mozilla will then not
run.

Using the PR2 candidate build, machine without msvcirt.dll, etc. the PR2
installer DOES install msvcirt.dll and Mozilla will run correctly.

So, this is only for the mozilla installer, and it is definitely not putting
the DLL in place.
ok, installer people, what am i doing wrong with mozilla installers?
A couple of things to look at. First let's verify that the install is going 
through the right motions: John, could you verify in your uninstall log that 
the install detected that msvcirt was missing, and then got a failure when 
adding it?

Assuming that to be the case I'd suspect the two .dll's aren't getting put into 
the xpcom.xpi archive. Leaf, when you run the build do you see a big warning 
like

print "**  The following required Microsoft redistributable system files were 
not found\n";
print "**  in $ENV{MOZ_SRC}\\redist\\microsoft\\system:\n";
print "**\n";
if(!(-e "$ENV{MOZ_SRC}\\redist\\microsoft\\system\\msvcrt.dll"))
{
  print "**    msvcrt.dll\n";
}
if(!(-e "$ENV{MOZ_SRC}\\redist\\microsoft\\system\\msvcirt.dll"))
{
  print "**    msvcirt.dll\n";
}
print "**\n";
print "**  The above files are required by the installer and the browser.  If 
you attempt\n";
print "**  to run the installer, you may encounter the following bug:\n";
print "**\n";
print "**    http://bugzilla.mozilla.org/show_bug.cgi?id=27601\n";
print "**\n";
print "***\n\n";

If you see that warning we've got a problem, but it tells you where it expects 
to find that file during the build process. Is the file there? I'd check the 
Mozilla version of xpcom.xpi to see if they're in there but the zippies don't 
appear to be available separately and I don't have time right now to download 
the entire thing over my modem.
The install log show that the Mozilla install detects the missing msvcirt.dll
and then fails on installing it (whereas the Netscape install succeeds on 
installing it). 

I also note from the logs that Mozilla does not contain a msvcrt.dll (no "i")
while the Netscape installer does). [I also note that the Mozilla install
refers to MSVCIRT.DLL in both upper and lower case, but that should make no
difference on a case-insensitive OS].

I grabbed a copy of the .\ns_temp directory for each install (before it quit),
and can poke around the contents if you need some more information.
*** Bug 46317 has been marked as a duplicate of this bug. ***
*** Bug 46317 has been marked as a duplicate of this bug. ***
should be fixed on the trunk (that is, the redistable files are in the right
place, and the warning is not getting produced).

checking on the branch build systems.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
branch build system also should have fix. verifyme!
http://www.mozilla.org/build/distribution.html references this bug number, and
gives a location where the two DLL's can be found on the web
(http://www.winappz.com/msvcirt.zip). This URL is a *broken link*. Please fix.

Looks like this is an issue again. See bug 59554.
*** Bug 59554 has been marked as a duplicate of this bug. ***
I just built the installer, and saw this:

***
**
**  The following required Microsoft redistributable system files were not found

**  in /cygdrive/d/cvs-1.11.5/mozilla/../redist/microsoft/system:
**
**    msvcrt.dll
**    msvcirt.dll
**
**  The above files are required by the installer and the browser.  If you attempt
**  to run the installer, you may encounter the following bug:
**
**    http://bugzilla.mozilla.org/show_bug.cgi?id=27601
**
***

Does the fact that this bug is fixed mean I can ignore that, or I have to
manually copy the DLLs?
this bug was "fixed" by making sure the files were in the right place on the
build machine. I don't know if the Gecko dependency has been removed.

Firefox most definitely depends on msvcrt.dll, though that should come on all
recent versions of windows now. I don't see a dependency on msvcirt.dll anymore
with a quick depends check, but I may have missed a component.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: