Closed Bug 135570 Opened 23 years ago Closed 23 years ago

Error 1114: Could not load xpistub.dll due to static linkage to nspr4.dll (which uses TLS - Thread Local Storage)

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
x86
Windows 95
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jmautz, Assigned: dveditz)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [adt1] [m5+])

Attachments

(5 files)

dependency results,installlogs,zipped re install error win95
141.08 KB, application/octet-stream
Details
exe that indicates the OS version
28.00 KB, application/octet-stream
Details
loaddll.exe - cmd line tool to load any .dll file into memory, then unload it.
36.00 KB, application/octet-stream
Details
patch that backs out nspr patch to bug 121975
14.96 KB, patch
Details | Diff | Splinter Review
Error message for missing setup.exe file
13.06 KB, image/jpeg
Details
All of the nightly builds since 4/1/02 give the following error on install: Error 1114: Could not load C:\WINDOWS\TEMP\ns_temp\xpcom_ns\bin\xpistub.dll The nightly build of 2002-04-04-11-trunk is the last version I have tried. Version 2002-03-30-09 worked fine. I checked the directory and xpistub.dll does exist during the install process (the whole ns_temp directory is deleted once I click to OK button for the error message). The xpistub.dll file is 7152 bytes in size. I am running an AMD K6-500 with Win95 OSR2 and 128MB RAM. Thanks for the help, John.
Same problem here on Win95 with latest releases. The reporter means the the installation method via Net Installer. The full package with exe file also does not work yesterday (haven't tested today.) The zip package for selfinstallation do function.
I see this too. I'm running a Pentium 233/MMX with 64MB RAM and this is precisely what happens when I try to use mozilla-win32-installer-sea.exe
Just tried 2002-04-05-11 and the same error occurs. John.
*** Bug 135911 has been marked as a duplicate of this bug. ***
Just tried 2002-04-06-11-trunk. Still no go. When is this bug going to get looked at? It's still marked 'unconfirmed' and there have been at lease 3 other poeple reporting the problem. I'm not trying to be impatient, it's just hard to test the newest builds if I can't install them. John.
Confirming. Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0
Kyle and Gerv: are you guys also running Win95? This is obviously not happening to most people, what's different about the setups that are experiencing this problem? Can't fix it without more info, and that's hard to come by if I can't see the problem. Do any of you have the MSVC development tools or equivalents? When you see xpistub.dll on your machine run "depends" on it and see if it'll load that way. If not, depends might give some info about what's missing
Keywords: nsbeta1
Yep, I'm running Win95 (OSR 2). I'm happy to run any test builds or debugging builds you may make, but I don't have a copy of the MSVC development tools. Gerv
I'm running Win95 (4.00.950 B). Unfortunately, I don't have the MSVC tools installed. I will try some other Win95 PC's to see how reproducible this is, though.
Microsoft's free dependency walker is available from http://www.dependencywalker.com and also in various larger free packs from microsoft itself. Also available from http://download.cnet.com/
I downloaded the Dependency Walker and used it to open the xpistub.dll that exists temporarily under \windows\temp\ns_temp\xpcom.ns\bin . It loads with no error messages (so I presume that no are no loadtime errors), and I can see a tree of dependencies (beginning with XPCOM.DLL, MSVCRT.DLL, KERNEL32.DLL). Unfortunately I have no idea what else to look for here. I see no obvious errors... The only oddity is that the Dependency Walker (and also Mozilla's install_status.log) reports my Win95 version as 4.00.1111B, whereas ControlPanel->System reports it as 4.00.950B. Probably not a big deal.
Thanks for checking! It was a long shot, but one possible reason it only seems to be a problem on Win95 was that we were trying to use some Windows API that didn't exist until later versions. Depends would have shown that. There's really not much that can go wrong loading xpistub itself. xpistub hasn't changed, the wizard code hasn't changed, your OS hasn't changed. Kinda stumped here. Grace and Ktrina: have we tested the installer on Win95 recently? If we have a machine that fails I'd like to see it. This one's a stumper.
Status: NEW → ASSIGNED
Confirmed on Win95, PII/MMX, 233Mhz, 64MB (i.e. minimal configuration!) with build from 2002040809. I've seen this happening since about 20020401. The last known working install was from march 30. I've seen some bugs related to xpinstall being closed at that time. May be it is related to http://bugzilla.mozilla.org/show_bug.cgi?id=105087 ?
The only time this error is displayed is if LoadLibraryEx() fails on the library. There's code to check that the file exists, so it really should be a load problem. The fixes for bug 105087 wouldn't have anything to do with loading the library, any potential problems would be caused later. Unless it changed the XPCOM .dll dependencies along the way, but then depends would have caught that.
Could one of you guys try downloading the zip version of Mozilla and see if that runs? If that fails too it'll let xpistub specifically off the hook and does point at a dependency problem of some kind. If it works I don't know where to go from there, debugging on Win95 is going to be hard.
Ok, here I'm again: Using todays Net Installer. Net Installer fails at the point "Preparing Setup, please wait..." with "1114 : Could not load C:\WINDOWS\TEMP\ns_temp\xpcom.ns\bin\xpistub.dll" Now directory from dos command line on win95: C:\WINDOWS\TEMP\ns_temp\xpcom.ns\bin>dir Datenträger in Laufwerk C: hat keine Bezeichnung Seriennummer des Datenträgers: 094B-11D2 Verzeichnis von C:\WINDOWS\TEMP\ns_temp\xpcom.ns\bin . <DIR> 09.04.02 11:35 . .. <DIR> 09.04.02 11:35 .. MOZREG DLL 24.688 09.04.02 11:35 mozreg.dll XPCOM DLL 508.064 09.04.02 11:35 xpcom.dll ZLIB DLL 39.584 09.04.02 11:35 zlib.dll COMPON~1 <DIR> 09.04.02 11:35 components JS3250 DLL 331.008 09.04.02 11:35 js3250.dll PLC4 DLL 29.792 09.04.02 11:35 plc4.dll PLDS4 DLL 25.424 09.04.02 11:35 plds4.dll REN8DOT3 EXE 38.240 09.04.02 11:35 ren8dot3.exe XPISTUB DLL 7.152 09.04.02 11:35 xpistub.dll NSPR4 DLL 168.432 09.04.02 11:35 nspr4.dll MSVCIRT DLL 77.878 09.04.02 11:35 msvcirt.dll MSVCRT DLL 254.005 09.04.02 11:35 msvcrt.dll 11 Datei(en) 1.504.267 Bytes 3 Verzeichnis(se) 285.900.800 Bytes frei C:\WINDOWS\TEMP\ns_temp\xpcom.ns\bin> Now using Full Download with installer 2002040809: fails on the same point. Now using todays talback.zip: After unpacking mozilla is start and useable. xpistub.dll does exist with 7.152 Byte length. Hope that helps.
For information: Between 21.03. and 24.03. someone has add the dll-Informations (Like copyright, version, internal name and so on) to the xpcom dll's. But the entry internal name for xpistub.dll is false (is only "(" [or is this only on win95 so??]). If later the loader/installer changed to use the dll internal name for verifying then the loader fails. This is what I can say ... but I can't test it yet and I don't know the internals of the mozilla installer. Hope that helps.
Confirmed on my humble win95 laptop: the zip-version does work (and feels faster than before).
Identify that the problems are starts between 2002-03-31-11-trunk and 2002-04- 01-06-trunk Hope that helps.
It would be nice to have this for 1.0. The workaround we can offer, I suppose, is to use the zipped builds if you're on win95.
Keywords: mozilla1.0 → mozilla1.0+
Hi, all. Same Problem, same timeframe, with win95b. No changes to the operating system as such. Error 1114: Could not load c:\windows\temp\ns_temp\xpcom.ns\bin\xpistub.dll Again, the mentioned file is in existence at this point (before dismissing the message). This is after run .exe, Next/Accept/Next/Next/Install. install starts but then above error message shown. Did perform an uninstall beforehand, and manually removed all traces of the previous mozilla directories from Program Files and windows directories, and removed the registry entries for mozilla.org. mozilla-win32-installer-sea.0.9.8.2002031109.exe (I probably modified this name. OK at install). install failures with these builds. mozilla-win32-installer-sea.20020410.exe NoGo mozilla-win32-installer-sea.20020409.exe NoGo mozilla-win32-installer-sea.20020408.exe NoGo mozilla-win32-installer-sea.20020407.exe NoGo mozilla-win32-installer-sea.20020406.exe NoGo mozilla-win32-installer-sea.20020405.exe NoGo mozilla-win32-0.9.9-installer.exe 200203?? OK mozilla-win32-installer-sea.0.9.8.2002031109.exe OK win95b 96M memory, tried with all other applications closed, ie only explorer and systray in task list. dependency_Walker results: attached. i notice it highlights the MOZILLA-WIN32-INSTALLER-SEA.20020410.EXE entry with RED for the Link Checksum column, which is not equal to the real checksum file for this .exe file, whereas the other used modules have idnetical link/real checksums (except:kernel32.dll). also, the profile highlights a few lines: 1. GetProcAddress(0xBFF70000 [KERNEL32.DLL], "IsProcessorFeaturePresent") called from "MSVCRT.DLL" at address 0x78001E3C and returned NULL. Error: The specified module could not be found (126). 2. GetProcAddress(0xBFF70000 [KERNEL32.DLL], "IsProcessorFeaturePresent") called from "SETUP.EXE" at address 0x00422448 and returned NULL. Error: The specified module could not be found (126). 3. LoadLibraryExA("C:\WINDOWS\TEMP\ns_temp\xpcom.ns\bin\xpistub.dll", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: A dynamic link library (DLL) initialization routine failed (1114). my c:\windows\system\Msvcrt.dll is 2001/05/04,6.10.8924.0 version extracted (then deleted during install) is 6.00.8168.0 Hope this helps, or ask me further questions...DaveT
*** Bug 136923 has been marked as a duplicate of this bug. ***
Syd: please plus this so we can officially work on it. Sean: heard of any win95-only problems like this? Mozilla itself runs fine on the same machines if un-zipped, yet I can't find any relevant installer changes in the timeframe when this started happening.
Installer build 2001-04-08 has the error for me with Win95 OSR2. I was going to download the latest installer until I read this bug. Will try the .zip package. This HAS to be fixed somehow for the 1.0 milestone though! - Nick
Sean: any ideas you could throw our way? Syd: I took the liberty of adding adt1 since this sounds stop-ship to me, please adjust if you think that's wrong.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt1]
*** Bug 137875 has been marked as a duplicate of this bug. ***
*** Bug 137879 has been marked as a duplicate of this bug. ***
Updating QA Contact.
QA Contact: jimmylee → ktrina
Not much point in nominating this for the "Make RC1 Not Suck" bug (bug 134771), but it needs to be release-noted. CCing endico - Dawn, who's doing release notes for this release? Gerv
For those that are running into this bug, I'm attaching a .exe file (getosver.exe). Can you run this from the command line and paste what it say to this bug? I'm trying to see if there's a different in os version info between: * install_status.log * ControlPanel-System * winver.exe (run from the command line) * getosver.exe (attached to this bug) I'm interested in this infor because Kyle Krom mentioned that he had version info descrepancies. I'm trying to see if a problem could be from a corrupted OS (somehow). I'm gonna try a few other things here at the same time. by the way, error 1114 means: A dynamic link library (DLL) initialization routine failed. ERROR_DLL_INIT_FAILED
Sean, I am seeing this error at home, I saved the contents of ns_temp before the download finished. Your attachment is showing as a .cgi file and I can't get to it- any secrets as to how to get the .exe file to check my system. Will seeing any of the saved files help? xpistub.dll is there in the xpcom.xpi fyi I also saw this error on my WIn98 system at work using a test build for testing Desktop Integration- but not on optimized builds
You should be able to select 'All Files' instead of '.cgi' when saving this file, then just give it a name with a .exe extension. It will run this way (I just tried it). I've also just found a Win95C laptop that can reproduce this problem. I'm working on getting a debug build and vc6 on it without altering too many files.
I also see this on Win95 OSR2. Here is what the different sysinfo say: install_status.log (from build 2002-04-18-02): System Info: OS Type: Win95 Major Version: 4 Minor Version: 0 Build Number: 1111 Extra String: b Total Physical Memory: 64956KB Total Available Physical Memory: 4692KB ControlPanel-System: Microsoft Windows 95 4.00.950 b IE 5 5.50.4134.0600 winver.exe: Windows 95 getosver.exe: System Info: OS Type: Win95 Version: 4.0.1111 Extra String: b Total Physical Memory: 64956KB Total Available Physical Memory: 0KB Hope this can be of any help, Torben
My results: install_status.log- System Info: OS Type: Win95 Major Version: 4 Minor Version: 0 Build Number: 1212 Extra String: B Total Physical Memory: 97808KB Total Available Physical Memory: 55856KB My computer|properties|Ms Windows 95 4.00.950 B (no ie installed at all!) winver- Windows 95 getosver.exe- System Info: OS Type: Win95 Version: 4.0.1212 Extra String: B Total Physical Memory: 97808KB Total Available Physical Memory: 38892KB --- For a giggle, I am going to install win95b in a fresh directory, and try one of the faulty installers, let you know how I go.
I've the same installation like #33 with a newer IE 5.50
On my Pentium 200 MMX, 96M, over 1Gig free Pc, renamed windows directory and installed in to a new directory. Configured hardware and added network settings. and tested that ping works OK to a local machine. The mozilla-win32-installer-sea.20020411.1.0.0.exe build was then installed, same unable to load xpistub error during install. Tried adding the dial-up networking upgrade 1.3 (including winsock 2). Same error trying to install. What else can I try ? Maybe I'll try some different msvcrt.dll's ?
System Info: OS Type: Win95 Version: 4.0.1111 Extra String: B Total Physical Memory: 65004KB Total Available Physical Memory: 720KB I've got another PC that I can check tonight.
Severity: major → normal
Severity: normal → major
As Alexander Opitz had pointed out, the problem has indeed manifested itself between 2002-03-31-11-trunk and 2002-04-01-06-trunk. I've updated added a URL to this bug to show the checkins that happened between: 03/31/2002 03:00:00 04/01/2002 09:00:00 I took a look at it, but nothing jumped out at me. Dveditz, can you look at the link to see if anything catches your eye? I'm speculating that it's a build config change that broke this as I can't think of anything that can affect so many different files listed below. I'll attach another .exe tool (loaddll.exe) that I wrote. It's an easier way to reproduce this problem. The interesting thing that I've noticed is that for the build that fails (04/01/02), the following dlls (from xpcom.xpi) fail to load using my tool: js3250.dll mozreg.dll nspr4.dll plc4.dll plds4.dll xpcom.dll xpistub.dll The following loads just fine. Notice that zlib.dll is the only one that belongs to the mozilla build: msvcirt.dll msvcrt.dll zlib.dll For the build that works (03/31/02), all of the dlls listed above load fine with my tool. I'm still not sure how depends.exe loads both sets of dlls without any errors while my tools catches the problem. My tool simply calls LoadLibrary() (the installer calls LoadLibraryEx() but appearently it does not matter). I've also tried newer msvc*.dll in the same dir and in my os's system dir. Still didn't help. I think a big clue is that the error number is 1114, as opposed to the more common one of 1157: 1114: an initialization routine failed in the dll 1157: one of the dependent dlls was not found. I think this might be why depends.exe does not complain, while LoadLibrary() does. Because it doesn't try to initialize (or call the initialization routine of) the loaded .dll file...? I also wonder if there was a major build change on 04/01/02 that does not show up on bonsai?
URL: 0%3A00&cvsroot=%2Fcvsroothttp://bonsa...
to use this tool to reproduce this bug, use the following steps: 1) get a xpcom.xpi file either from ftp.mozilla.org or by running the full mozilla installer with a '-u' parameter. It will extract its contents into the current dir. 2) from a new dir, unzip xpcom.xpi. you will need to preserve the dir structure. 3) copy msvcrt.dll and msvcirt.dll, that was uncompressed, into the uncompressed 'bin' dir. 4) from the 'bin' dir, run: loaddll.exe [dll file] As I mentioned in comment #38, most files will fail, while a few will not.
here's something interesting that I found: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q118816
is this the same time frame that gmake builds kicked in? dveditz, Sean, maybe need to talk with seawood. or .dll file versioning updates?
*** Bug 138539 has been marked as a duplicate of this bug. ***
*** Bug 138594 has been marked as a duplicate of this bug. ***
I've been thinking about this some more. My suspicions were correct. It has something to do with nspr4.dll. I've noticed that a common .dll required by all the other .dlls is nspr4.dll. I replaced the bad nspr4.dll from the bad build (04/01/02) with the one from the good build (03/31/02), and all the .dlls from the bad build (04/01/02) loaded up just fine using loaddll.exe. I've used bonsai to see what was changed in the nsprbpub dir, but it's always coming up as empty for those two days. Does anyone know how to work this Bonsai thing? I'm having issues with it :)
> I'm interested in this infor because Kyle Krom mentioned that he had version > info descrepancies. I'm trying to see if a problem could be from a corrupted > OS (somehow). This is almost certainly a red herring. The control panel, the version number on the desktop (if applicable), what ver says at the command prompt, and any third-party version-determination utility almost never match eachother exactly on MS Windows. Version numbers seem to be stashed in several places, and generally don't match. For one thing, the command intepreter carries its own version info, though this is not obvious to most users. (Proof: if you take cmd.exe and run it on 95OSR2, it'll tell you that you're running NT.) Obvious Question: Has anyone tested whether it matters whether you try to install into a clean empty dir versus into the existing Mozilla install dir? If not, I will, but probably not until next week (so if someone with nothing better to do is twiddling thumbs over the weekend, feel free). This probably shouldn't impact the installer's ability to load DLLs that haven't been installed yet even, but it's worth testing just in case, on the grounds that this has caused weird unexpected issues in the past. Adding self to Cc.
Yes, I've tried moving the original mozilla install directory before attempting to install from mozilla-win32-1.0rc1-installer.exe on a Win95OSR2 machine. Same 1114 errors. The .zip of 1.0rc1 works fine.
Confirmation of what Sean Su explained in AC#44. Using mozilla-win32-1.0rc1-installer.exe on W95 OSR2; 1) execute (using command line interpreter) full installer with '-u' 2a) unzip and backup (using a ZIP tool) bin\nspr4.dll from xpcom.xpi 2b) update (using a ZIP tool) xpcom.xpi with bin\nspr4.dll from the v0.9.9 full installer build 3) run setup.exe 4) replace nspr4.dll in Mozilla directory with the one backed up from v1.0.0rc1 Everything seems fine like this...
I think I found something. Bug 133659 was fixed on 03/31/2002 which merged many fixes from the nspr trunk to the branch tag that mozilla trunk pulls from. I wonder if the fix from nspr bug 121975, which deals with static TLS for Win95, had anything to do with this bug. Adding wtc to the CC: list for any insight.
Whiteboard: [adt1] → [adt1] [m5+]
*** Bug 138823 has been marked as a duplicate of this bug. ***
Ok, so, what sean is implying here is that we fail to install on Windows 95 due to an NSPR change. Here is why: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q118816
*** Bug 139144 has been marked as a duplicate of this bug. ***
i'm going to mark this as a blocker. it blocks anyone with w95 from testing this application.
Severity: major → blocker
Keywords: relnote
Summary: Error 1114: Could not load xpistub.dll → Error 1114: Could not load xpistub.dll due to static linkage to nspr4.dll (which uses TLS - Thread Local Storage)
i'm told that people on win95 can use the zip build so unless that info is wrong, this is not a blocker.
True, it's actually a blocker for only the installer, not Mozilla Then again: If the install program working on win95 is not a blocker because you can run a different program then you might as well say Mozilla never running is ok because, hey, you can run IE. Ok, that was a bit harsh, but you get the point.
I agree with jbeaupre, neither the installer nor net installer operate for win95. It is reasonably difficult for a non-programmer ? to install an application in to a useful directory out of the zip file. Must make sure the path info is extracted, then if wanting to put it in normal mozilla location, renaming the /bin directory to /mozilla, and placing under mozilla.org. Add a shortcut to start the application. Basically, to me this means cutting of almost every win95 user because it will be toooooo hard to install. I am sure there are a lot of users out there who don't want to be forced to internet explorer, or are trying to get off iexp, yet still have a 3 or 4 year old PC of the pentium200/pentium2 variety running win95 that could otherwise happily run mozilla, and have access to its advanced features (esp tabbed browsing, password manager, image blocking etc).
*** Bug 139312 has been marked as a duplicate of this bug. ***
I think I was able to successfully back out wtc's merge, but only the part that affects win95. The draw back to undoing this is this (an excerpt from bug 121975): comment from bratell@lysator.liu.se: ------------------------------------ I don't know if this is a Windows-only win but 20% is quite a lot for functions that must be thread safe but apart from that doesn't do much. I found this while looking at xpconnect overhead. The monitor overhead is as much as 70 percent for some functions there that can be called thousands or tens of thousands of times on DHTML web pages. All measurements done with Quantify on a build from CVS today 2002-01-26. ------------------------------------ I'll attach a patch after cleaning things up a bit.
I should have elaborated that the draw back is a porformance hit as the comment indicates. Also, I'm updating the URL link in this bug to one that shows the checkins that caused this bug. The link will show more checkins than necessary. The files modified to fix 'Bugzilla bug 121975' are the ones in question.
URL: 0%3A00&cvsroot=%2Fcvsroothttp://bonsa... → %2Fcvsroothttp://bonsai.mozilla.org/c...
I've tried to just initialize _pr_use_static_tls to FALSE for all win95 cases, but it didn't seem to have an effect. Might be a compiler related issue (but I'm not 100% sure about it) because backing out the patch fixes the problem. Also, a really easy way to see if nspr4.dll was compiled correctly is to do: dumpbin /headers nspr4.dll and look at 'Thread Storage Directory'. Its size needs to be 0 (zero) for it to work under Win95.
Can we get any Win32 compiler/make gurus on this? If there is a significant(!) perf hit (please quantify with real jprofs or testcases) for win95 support, we could make separate win95 and >win95 builds, and have the installer for >win95 tell you it can't install on win95 (when run there), and the wind95 package tell you the >win95 package will be faster (if you try to install the win95 package on >win95).
why does the installer need nspr? seams like breaking the circular dependancy is the right thing to do.
can't remove the dependancy... duh.... well, in any case, I would hate to lose a 2% performance improvement because the installer needs tls or whatever. Lets make it work and save the improvement.
*** Bug 139518 has been marked as a duplicate of this bug. ***
Where did you get the 2% from. Did it make improve things so much? Wow! I know it does improve js<->C++ some since there are so much locking there but I didn't think we did very much of that except on DHTML pages where we really suck anyway. Anyway, it's clearly not right to ship something that Win95-users can't use. If I understand correctly, Mozilla.exe itself works, but the installer does not? Why? If we can not create a version that supports both win95 and all other Windows versions I would like the intelligent installer best. The installer would download/install the nspr4 that was best for the current OS. I guess that's hard to do before 1.0, so maybe backing out is the only alternative. :-(
*** Bug 139553 has been marked as a duplicate of this bug. ***
Now I've read the knowledge base article. Why do the installer load nspr4 dynamically with LoadLibrary? Why do it load it at all? Seems at that's the way to attack this problem? If we need it, we can load it implicitly at startup as Mozilla does. If we don't need it we can remove the LoadLibrary.
The installer does not load load nspr4 dynamically with LoadLibrary. It loads xpistub.dll which has an implicit link to xpcom.dll which has an implicit link to nspr4.dll. This is all rather unavoidable. One solution that I didn't see mentioned above [oops, I see dveditz did bring this issue up in bug 121975 - but I'll say it anyway] would be to have an implicit link to nspr4.dll from setup.exe. This means that the TLS mapping gets 'discovered' when the exe loads rather than when the LoadLibrary runs. This is why mozilla.exe still works on Win95. This could be done by adding a bogus call into nspr4.dll from the exe and (of course) packaging up a copy of nspr4.dll to be in the ns_temp dir when setup.exe runs. That means another 165k of download before setup.exe can start. It also means some amount of work and testing - work that we might not want to do now. Nevertheless, I'd vote for undoing the nspr change for now. It causes an unacceptable regression. There is a small hit on JS DOM perf. But, it should be noted that the locking overhead associated with JS rooting mentioned in 121975 will go away completely with the patch in bug 139243. That change is not tested anywhere near enough to be checked in now, but relief is on the way!
Well, (in case it was not clear) I guess my 'link to nspr4.dll' suggestion is a little different from Dan's. I think he was talking about building a special win95 friendly version just for installer use. I'm suggesting using the existing version and forcing it to implicitly load when setup.exe loads. Either way, there is a fair amount of work to be done to impelement and test this. Whereas returning nspr4 to its previous state is pretty much a known quantity.
*** Bug 140231 has been marked as a duplicate of this bug. ***
looks like wtc is backing out the patch in question that's causing this bug. see bug 121975 (marking this bug as dependent of it).
Depends on: 121975
marking this fixed cause bug 121975 is backed out.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Adding fixed1.0.0 keyword because it was also backed out of the Mozilla1.0.0 branch. Please remove the fixed1.0.0 if this still exists.
Keywords: fixed1.0.0
*** Bug 140610 has been marked as a duplicate of this bug. ***
*** Bug 140559 has been marked as a duplicate of this bug. ***
I can confirm that the mozilla-win32-installer-sea.exe 2002042708 1.0.0 build installs correctly on windows 95b. The back out patch seems to work. Note that this was an overwrite into existing mozilla directory that had the zip extracted onto it. Futher to the above, I tried the installer-sea on a bare install of win95b, with only the dial-up networking/winsock 2 installed (ie no other patches of any kind). I got the same original error message during install. I tried a few different things: adding the mozilla.org directory and the mozilla directory, and copying over a working mozilla.org dir before install, and none of these allowed the installer-sea to complete. Also tried removing the registry entries under software/mozilla and mozilla.org. but it still did not install. (note: this install is an absolute minumum install that does not install internet explorer 3, nor the online_services stuff, and limits the "accessories" installed to the absolute minumum.) I have then gone to my normal win95b installation and uninstalled this same version that installed and ran fine. And deleted all traces (that I can tell) of mozilla, mozilla.org dirs, the mozilla/profiles directory under windows dir, the mozilla.org registry entries. Again, the installer-sea works fine in these circumstances, but I don't know why.
confirming works now for me on my win95a and win95b clean new installation.
In reply to msg "Comments From dtimms@bigpond.net.au 2002-04-28 06:48 " Tested builds mozilla-win32-installer-sea.exe 2002042708 1.0.0 mozilla-win32-installer-sea.exe 2002042806 1.0.0 Tested by running the installer to install over an existing installation WORKS CORRECTLY Tested by running uninstall from Control Panel, the installing the new build WORKS CORRECTLY. Note: Considering windows simple end-user skills, I only performed Control Panel -> Add/Remove programs -> Mozilla -> uninstall. I did not manually remove any left-over files and registry entries.
Andrei: Given that I failed to install successfully on a fresh win95b install, I thought it wise to install on my current setup, modified to be as virginal as possible eg. like a first time mozilla install on a current netscape 4.7x machine. It may be wise to hear a few other successful 95b installs with this back out patch , before confirming OK. It's difficult to get that virginity back ;) for a real test.
Results of my test: - Blew away the Mozilla program directory--whoops there goes all my plugins again. - Tried mozilla-win32-1.0rc1-stub-installer. Failed on XPISTUB.DLL error as expected. - Tried mozilla-win32-installer from nightly/2002-04-27-08-1.0.0 directory. Install correctly. WFM so I'm satisfied that it's been fixed. I hope it's unrelated, but one thing that I did notice is that I couldn't run the installer from yesterday's nightly/2002-04-28-09-1.0.0 directory. Got a "too many networks errors" message without it downloading any files. I checked the build directory and there is no windows-xpi directory. Could be a one-time build problem, otherwise I'm sure this will get fixed pronto since it will affect all Windows users.
*** Bug 140998 has been marked as a duplicate of this bug. ***
Re: Comments From dtimms@bigpond.net.au Agree. As I stated, my tests were succesfull in an upgrade situation. I'm not sure if I can test it on a clean system, but If I can today/tomorrow, I'll sure report the results.
*** Bug 141544 has been marked as a duplicate of this bug. ***
I tested this from home with trunk build 2002050204 and got by the xpi stub error, but after download, install and just before launch I got a message about a missing setup.exe file or libraries required. After pressing ok on the message, I launched and things were ok
I tested trunk build 20020502 on JA Win95 OSR2 and SC Win95 OSR2, Error 1114 is not reproducible. The error message (please refer to the attachment) which was found by Grace Bush in Comment #84 can also be reproduced on many localized OSes, (I saw it on EN 95OSR2, EN 98SE, EN 2K, JA 95OSR2, JA 98SE, JA NT4, JA 2K, SC 95OSR2, SC 98SE, SC Me, SC NT4 and SC 2K with trunk build 20020502). should we separate this problem?
what you're seeing is bug 141858
*** Bug 141925 has been marked as a duplicate of this bug. ***
*** Bug 142002 has been marked as a duplicate of this bug. ***
*** Bug 142027 has been marked as a duplicate of this bug. ***
Verified
Status: RESOLVED → VERIFIED
"I can confirm that the mozilla-win32-installer-sea.exe 2002042708 1.0.0 build installs correctly on windows 95b." The Mozilla I downloaded on May 5th from the mozilla.org download page does not install on Windows95B, so whatever it was that that tested OK didn't make it onto the site for downloading - if you have a version that does work for Win95, please make it available or at least label the download as "doesn't work with Win95 yet, please click HERE to get MSIE". mozilla-win32-1.0rc1-installer.exe is what I downloaded and had problems with. It is a recent install of Win95 from the original distribution CD from 1998 - could there be a missing upgrade I need?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'm re-resolving this as fixed. Tsu Dho Nimh, please test a nightly trunk or branch build and reopen the bug if it still occurs to you. The nightly builds can be found at ftp://ftp.mozilla.org/pub/mozilla/nightly/latest and ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-1.0.0 .
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I'll try it - but speaking for the non-technical, swoop in and grab a download to install user, not a serious bug-tester - part of the problem is from your web design leading persons to get the wrong version. With 25% of so of Windows users still using WIN95, that's a lot of disappointed customers. And many will say "Mozilla is ****" and not report anything. The link from the mozilla.org front page blurb about the release goes straight to http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0rc1/mozilla-win32-1.0rc1-i nstaller.exe ... isn't that the one with the installer bug? That's where I got my problem version from. On the DOWNLOAD page there is an link to a Win95 only version, but only after two links that say WINDOWS, including the text that says "talkback enabled Full Installer .exe (9.8 MB) for reporting crash data. If you don't understand what the other Win32 builds are, then get this build." You should state "not for Win95" on the links for any version that has the installer problem, or place the link to the Win95 version right next to the other Windows version links, because the user tendency is to click the first link they see that looks good and not bother reading the rest of the page. You can blame the user all you want for not carefyully reading the page, but that's the way they use the web. Ask any web designer :(
*** Bug 140559 has been marked as a duplicate of this bug. ***
removing item for this bug from the release notes since the bug is marked fixed. If this is in error, please make a note in the release notes bug for the current milestone. As of today, this is bug 133795. In a ew weeks, it will be some other bug.
Verified. Please reopen if problem reoccurs.
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.0 → verified1.0.0
*** Bug 167640 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: