Closed Bug 32340 Opened 24 years ago Closed 24 years ago

Netscape6 beta1 does not run under Win95 B

Categories

(SeaMonkey :: General, defect, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 95
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: ssu0262, Assigned: ssu0262)

Details

(Whiteboard: [PDT+] have low risk installer fix that would be win95b specific) 

System: Win95 B (nothing else - no upgraded IE either)
32MB Ram
Compaq deskpro 6200 (pentium pro - should be 200mhz, but I'm just guessing

Tried running both today's beta and commercial build. 
Both showed the same behaviour: 

  * after installation finished, the splash screen showed up 
  * then a window with only the title bar without title or content shows up.
    The window is only the title bar about 50 pixels wide.
  * the bottom task bar starts filling up with tasks belonging to Netscp6.exe
    (no title of course). 

This seems to go on indefinitely.  I had to kill Netscp6.exe for this to stop. 
This system does have msvcrt.dll, but not msvcirt.dll
added beta1.

This is the english version of Win95 B
Keywords: beta1
gbush, do you have the "B" version?  Can you try too?

chofmann, who gets this one?
Assignee: cbegle → chofmann
QA Contact: asadotzler → gbush
If you add msvcirt.dll to this system does it start working? I suspect not or 
you would have mentioned the dialogs about a required .DLL not found, but three 
of our components appear to require msvcirt.dll
I think this is bug 27601.  Yes!  Finally this bug's been reproduced "in house"!
I've done the following:

 * added msvcirt.dll (and left original msvcrt.dll dated 1998 alone)
 * updated msvcrt.dll and added msvcirt.dll

Still arrived at the same results.
I've forgot to mention that I selected the Typical install for all my test 
cases.

FYI: There are Win95B cds next to the compaq in Cathleen's cube.

can we get someone to copy the dist/source from debug build
over to  a win 95b system and try to take a look at what
might be going on?

we need one or more engineers to step up and take ownership for this bug
if we are going to try and figure out a solution by early next week...

thanks


choffmann, I'll see if I can duplicate this on my home system and get a trace.

(build on a Win2k-2128/Win95-B dualboot - I have another Win95B (but only a 
P90) 10 feet away both on an ethernet, so I do have remote-debugging available.)

Moved all of \bin to the second Win95B (running w/o benefit of remote debugger 
to get an idea of where to go)

1st time: Profile Manager ran ok, but when I selected "Start Mozilla" after 
that, I got an assertion about Component Manager being held past XPCom 
shutdown, cnt==0, file (K:\mozilla)\xpcom\build\nsXPComInit.cpp, line 607

Second time I run it, it just dies silently after I select "Start Mozilla".

It displays two FIX ME!!! Converting Dirty to Resize!! ... messages at line 
(K:\mozilla)\layout\xul\base\src\nsTreeOuterFrame.cpp, line 115 in the console 
while it starts up the Profile Manager.

This is with a CVS pull from about 6:30am today, PST, and the VC6SP3 debug 
libraries moved over.

I don't think I'm seeing the bug you are seeing.

I have to run and do something, sorry I can't help more, OK?
great work.  this aleast gives us something to go on.
nsTreeOuterFrame.cpp

dp, evaughan, hyatt, can you start to sort out what problem(s)
we might be having?

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/xul/base/src/nsTreeOuterFrame.cpp

 evaughan 1.18
112 evaughan 1.17     // XXX at the moment we don't handle non incremental dirty
reflow commands. So just convert them
113                   // to style changes for now.
114                   if (aReflowState.reason == eReflowReason_Dirty) {
115 evaughan 1.18         NS_WARNING("XXX Fix me!! Converting Dirty to Resize!!
Table need to implement reflow Dirty!!");
116 evaughan 1.17         nsHTMLReflowState goodState(aReflowState);
117 evaughan 1.18         goodState.reason = eReflowReason_Resize;
118 evaughan 1.17         return Reflow(aPresContext, aDesiredSize, goodState,
aStatus);
119                   }
120 evaughan 1.18




http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/build/nsXPComInit.cpp

593 dp        1.39     // Shutdown xpcom. This will release all loaders and
cause others holding
594                    // a refcount to the component manager to release it.
595 dp        1.45     rv = (nsComponentManagerImpl::gComponentManager)->Shutdown();
596 dp        1.39     NS_ASSERTION(NS_SUCCEEDED(rv), "Component Manager
shutdown failed.");
597
598 shaver    1.46     // Release our own singletons
599                    // Do this _after_ shutting down the component manager,
because the
600                    // JS component loader will use XPConnect to call
nsIModule::canUnload,
601                    // and that will spin up the InterfaceInfoManager again
-- bad mojo
602                    XPTI_FreeInterfaceInfoManager();
603
604 warren    1.22     // Finally, release the component manager last because it
unloads the
605                    // libraries:
606 dp        1.23     NS_RELEASE2(nsComponentManagerImpl::gComponentManager, cnt);
607 tbogard   1.48     NS_WARN_IF_FALSE(cnt == 0, "Component Manager being held
past XPCOM shutdown."


Did you all look at bug 27601 from fisher7@thegrid.net ?

It seems likely that we're relying on some entry point in a system dll that is 
only there after an IE install.

I forget... failure to find an implicitly linked dll causes an error dialog, but 
does failure to find an entry point in an implicitly linked dll while loading a 
dll via LoadLibrary also cause the dialog?

gkhtml.dll and gkparser.dll are implicated. I don't have a raw Win95B machine 
setup. But using "dumpbin /IMPORTS" and "depends" makes me suspicious of 
KERNEL32.DLL::DisableThreadLibraryCalls. I'll try to investigate.

I didn't find anything incriminating in my digging through importans and exports 
of dlls.

I loaded an OEM Win95 I have that I ASSUME is win95b (it is for sure not the 
original win95). It is raw with the addition of a 3com netcard driver I 
installed from Dell's site. This is on a Dell Presicion 210 PIII 500.

running the installer from...
ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-03-18-06-M15-nb1b/mozilla-win32-i
nstaller.exe

...failed with...

"Could not load C:\WINDOWS\TEMP\core.ns\bin\xpistub.dll"

I'm guessing this is from lack of msvcrt.dll and msvcirt.dll

So, what versions of those files do y'all install? Does the comercial 
version of the installer include redistributable versions of those files?
okay, I got today's beta1 branch commercial build to work.  The only thing I did 
was copy msvcirt.dll from my NT4 system to the Win95B's system folder.

When I deleted msvcirt.dll file again from the Win95B's system folder, this bug 
occurred again.

I'm not sure why Friday's beta1 branch commercial build didn't work when I did 
the same thing.

We should have the installer look for msvcirt.dll and msvcrt.dll, and install 
them *only* if they don't exist.  This will prevent the reboot dialog to show.  
Currently, the installer does not install these files.

I'll start working on this (in case this is the only solution), but won't 
checkin until I get the OK.

[bugzilla midair collision with ssu. I see we both got it to work. Please take 
at my issues and conclusions anyway.]

I downloaded the setup exe for the latest beta1 commercial build and let it do 
its thing. It failed in exactly the same way.

I verified that I do have Win95 B (4.00.950 B)

In mail from ssu he indicated that he expected msvcrt.dll to have been installed 
with the OS. On this install msvcrt.dll is NOT present. msvcrt20.dll and 
msvcrt40.dll are present. He sent me a zip of these dlls from his machine. I 
note that the msvcrt.dll in the zip has a date of 9/4/98 while the other files 
in the zip all have a date of 8/24/96. Did the msvcrt.dll come from some other 
source? e.g. did you install Nav 4.x or something? I didn't.

Anyway, besides the fact that the thing won't install on my really raw win95 B 
machine, I did copy in that msvcrt.dll and then the install worked and launching 
the app caused the problem others have seen: one little window, tons of icons in 
the taskbar, and then it runs out of resources.

With no component.reg the stdout redirected to file looks like:
RegSelf Unicode to Big5 converter complete
RegSelf Unicode to x-x-big5 converter complete
RegSelf Big5 to Unicode converter complete
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM 
FILES\NETSCAPE\SEAMONKEY\components\gkhtml.dll) Load FAILED with error: error 0
**************************************************
**************************************************
nsNativeComponentLoader: SelfRegisterDll(C:\PROGRAM 
FILES\NETSCAPE\SEAMONKEY\components\gkparser.dll) Load FAILED with error: error 
0
**************************************************
Profile Manager : Profile Wizard and Manager activites : Begin
Profile Manager : Command Line Options : Begin
Entered MigrateProfileInfo.
Profile Manager : Command Line Options : End
ProfileManager : GetProfileDir
ProfileManager : GetProfileDir
Profile Manager : Profile Wizard and Manager activites : End
WEBSHELL+ = 1
WEBSHELL+ = 2
WEBSHELL+ = 3
WEBSHELL+ = 4
WEBSHELL+ = 5
WEBSHELL+ = 6
WEBSHELL+ = 7
WEBSHELL+ = 8
WEBSHELL+ = 9
WEBSHELL+ = 10
WEBSHELL+ = 11
WEBSHELL+ = 12
WEBSHELL+ = 13
------------ ad infinitum 'till it is killed

I copied the msvcirt.dll from my NT 4 machine to the Win95 machine's 
c:\WINDOWS\SYSTEM directory, whacked component.reg again and tried to start 
mozilla.exe. And... SUCEESS it started and ran just fine!

ssu said he tried with an added msvcirt.dll. But I wonder if he deleted the 
componet.reg after that to let gkhtml.dll and gkparser.dll re-auto register them 
selves? Otherwise it might have just been in a bad state.

So...

1) don't assume that Win95B machines have msvcrt.dll
2) don't assume that Win95B machines have or don't need msvcirt.dll
3) I was annoyed that the NS installer failed after dragging the xpi files 
across the net but not leaving them around locally for me to try again.

ssu,  installing only if does not exist sounds like a great solution.
you are approved to make that change when you have it tested 
and ready to roll.  It would be great if the monday morning
build contained this fix.  

thanks for all the great help on knocking this one dead.
Assignee: chofmann → ssu
Whiteboard: have low risk installer fix that would be win95b specific
Sorry if this is obvious, but... Please be sure to use copies of those files 
from the redistributable directory of a recent Microsoft developer kit and not 
just copies that happen to be in the system dir of one of our machines.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
The commercial tip and beta1 branch installer have been updated to install 
msvcrt.dll and msvcirt.dll only if they do not already exist.

I'm closing this bug and reopening bug #27601 and reassigning to myself because 
this fix has not yet been applied to the mozilla builds.  I will need release 
team coordination for fixing the mozilla builds.

ps. I've used the official redistributable msvc*.dll files from the MS CD.

After going through another big MSVCRT bug problem with Mozilla I though the 
goal was not to force a restart?  Installing MSVCRT ect would require a restart.
The fix is to install those files only if they don't already exist.  If they do 
exist, then we're okay.  This way a reboot will not be required.
Responding to an earlier jband question: Windows will complain if it can't find 
a .dll or entry point in a .dll, but only for libraries loaded implicitly at 
startup time.  gkhtml (etc) does have imports for msvcirt, but the mozilla 
executable doesn't have any imports for gkhtml. Libraries loaded later won't 
trigger the alert, the LoadLibrary() will simply fail.
The previous bug where we required a restart was because we upgraded an 
*existing* MSVCRT.DLL -- this is different. If we don't have to replace a file 
then no restart is needed.

Sean -- we probably have to put these files in the core.xpi because xpistub 
requires them also, at least msvcrt.  msvcirt you could leave in the 
browser.xpi if the core size were a problem, but we might as well not split 
them up.
Core.xpi is where I've place them (it was easier keeping them together).  This 
way it will also fix the problem that some people have when they try to run the 
installer and get the "1157 error: could not load 
[temp]\core.ns\bin\xpistub.dll"

marking PDT+ per chofmann.
Whiteboard: have low risk installer fix that would be win95b specific → [PDT+] have low risk installer fix that would be win95b specific
ssu- does this work for you now with todays branch Win32 bits?
2000-03-20-06-M15-nb1b from sweetlou installs and runs just fine for me on the 
raw Win95B install where the builds from the 18th failed to install and run. 
msvcrt.dll and msvcirt.dll got installed correctly and worked. Good Work!
I've tested today's beta1 build on the same system that I first encountered this 
bug using the two tests:

  1) no msvcrt.dll and no msvcirt.dll files
  2) msvcrt.dll and msvcirt.dll both exist

Case 1 worked.  I didn't see this bug occur.  Both msvcrt.dll and msvcirt.dll 
got installed properly.

Case 2 worked too.  I didn't see this bug occur.  I didn't see a reboot dialog 
show up either.  I also verified that the msvcrt.dll and msvcirt.dll files did 
*not* get replaced.

gush has also verified that this works great with todays build.  marking 
Verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.