Upon running the mozilla-win32-talkback.zip builds for 2000-05-07-16-M16 and 2000-05-06-16-M16 on WinNT, an alert appears stating that Windows was unable to locate MSVCP60.DLL; after clicking OK Mozilla continues to load and appears to run normally; the alert only appears once. Steps to Reproduce: 0. Go to a machine without VC6 and verify that MSVCP60.DLL is not present anywhere in the Windows system directory. 1. Download mozilla-win32-talkback.zip from ftp://ftp.mozilla.org/pub/mozilla/nightly/2000-05-07-16-M16/ 2. Create a new directory and unzip the build into it. 3. Run mozilla. 4. Click OK to the alert: "mozilla.exe - Entry Point Not Found" "The procedure entry point ?Compare@nsString@@UBEHABV1@HH@Z could not be located in the dynamic link library xpcom.dll." (bug 37125) Actual Results: Another alert appears: "Unable to locate DLL" "The dynamic linked library MSVCP60.DLL could not be found on the specified path..." ( ".", the normal Windows dystem directories) After clicking OK, Mozilla continues to load. Expected Results: Mozilla continues to load. Other Information: The URL above points to a search results page at the Microsoft KB for "MSVCP60.DLL". Given the histories of bug 19165, "[DOGFOOD][PP] Win32 - App won't start with old MSVCRT.DLL" and bug 37792, "Entry Point Not Found in XPCOM.DLL when starting browser first time", it seems unlikely that MSVCP60.DLL is actually needed -- and if it is, it would be better if it wasn't, as that may require a restart, something to be avoided -- see bug 10432, "No Re-Start required during Install and First Run process". Passing this to Build Config for triage, but the code causing this is probably in a checkin from the period Thurs-Sat; no such alert in a build from 05-03.

The mozilla ActiveX control was put back in on Thursday by Adam Lock. Quoting from news://news.mozilla.org/391300F7.B899DC5E%40netscape.com Jerome Kwok wrote: > > "msvcp60.dll" not found during start up. Mozilla latest 2000050412 ZIP > version on WinNT4 SP6. This is required by mozctl.dll that was just added into the mozilla delivery. Rats. If that control weren't in the components directory it wouldn't get grovelled by AutoReg and thus wouldn't be a startup problem. Adam, and chance of moving it up to the bin directory? Of course that still leaves a non-working control without that file, so I guess we'll have to also add that one to the mozilla package and install script to really solve the problem (I assume it's one of the redistributables from MSVC++). We had to do something similar with msvcrt.dll for old win95 systems that didn't have it. -Dan Veditz

Windows.

Thanks, John. Based on that newsgroup post, Adam belongs on the Cc: list here, adding him. Adam, is MSVCP60.DLL really needed by mozctl.dll? Quoting from http://www.iol.ie/~locka/mozilla/faq.htm > Will the control be released with Mozilla? > Most probably. TODO > Will the control be released with Netscape 6.0? > Probably not. TODO Based on that, if MSCVP60.DLL *is* needed for the activeX control, another bug will likely be needed to disable the latter in the Netscape builds, because if an earlier version of MSCVP60.DLL is already present, a reboot would be required.

Yes MSVCP60.DLL is needed by mozctl.dll because it uses STL, however I moved mozctl.dll out of the components subdirectory so there should be no time in normal operation when it will be loaded. So unless you are developing using the control, I don't understand why it would still be loaded unless this bug happened against the brief period of time when mozctl.dll was in the components directory.

This won't happen if you clean out the install directory and reinstall... marking fixed because adam moved the dll from the component directory up to bin/

(Leaf will now begin to curse my name ...) But ... the *-talkback.zip builds (including the most recent one from noon today) are shipping two mozctl.dll 1) in \bin dated may 10 12:42 2) in \bin\components dated may 05 13:23

*slaps forehead* I checked the staging areas, but i must have missed one. I'll go check again. Thanks for not letting me get away with this.

talkback staging area now getting purged before zip file creation occurs.

Verified with the 2000-05-15-08-M16 nightly binary on WinNT; this would only ever have affected Win32, and there is now no alert after unzipping into a fresh directory.