At last. The problem comes down to the nspr4.dll. If you look in the production Windows 98 Netscape 6.2 directory, the nspr4.dll located there is 160,064 bytes in length. If you download the binary Mozilla distribution, the nspr4.dll located within it is 160,064 bytes in length. However if you download the source mozilla tarball, dated the same as the binary windows .zip file, you will get a nspr4.dll that is 147,456 bytes in length.
Now in the secmod.db, located in the Netscape Windows 98 profile, you will find a complete path reference to the nssckbi.dll, which is in fact, loaded during the database initialization. This in turn causes the nspr4.dll, located in the same directory, to be loaded. Now my application directory has the nspr4.dll, which is 147,456 bytes in length. So it would appear that there is some type of conflict between the two dll's. If I delete the nspr4.dll located in my application directory, and replace it with the nspr4.dll I got with the mozilla binary, then everything works fine. What really confused me was the fact that in the mozilla binary download, you get the same dll that is used by the production Netscape 6.2 product. However if you download the source tarball, same date, same html page, and build the complete mozilla distribution, you end up with the "old" nspr4.dll. I looked over every page on the www.mozilla.com web site and cound not find anything that would explain what you had to do to get the "newer dll" when you compile the latest tarball. It also implies the binary distribution is the result of compiling the source tarball, assuming you used CVS to bring it up to date. Why does the binary distribution contain a different dll than results from compiling the source distribution? The only clue I see is if you examine the "newer" nspr4.dll, it is marked internally as "4.2 Beta" whereis the one that gets built from the tarball is marked internally as "4.1.2". The one distributed with the binary Mozilla is also marked as "4.2 Beta". So how do I get a "4.2 Beta" nsrp4.dll when I compile the mozilla source tarball? Ken "Robert Relyea" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Kenneth R. Robinette wrote: > > > Beats me. Since there must be people in the world that runs Netscape 6.2 on > > Windows 98, I suspect Netscape knows about the problem and have bypassed it. > > Since it knows where the nspr4.dll is, perphaps they use the extended > > NSS_Initialize call and request no load of the secmod.db file. Are perhaps > > they don't even use the nsrp4.dll. Or perhaps they monkey with the file > > prior to reading it with nspr. > > > No, Netscape 6 calls NSS_InitReadWrite(), just like everyone else. There > is no private Netscape 6 interface. Netscape 6 *IS* and NSS application. > They also use nspr4. The difference is Netscape 6 builds from source, > and their own tag. It is possible that they have put their own fixes > into NSPR. It looks like that is not the case. (Both the NSS and NSPR > teams monitor what the client checks into the branch). > > > > > > All I know is if you use the nspr4.dll that comes with the NSS distribution, > > it will fail. A call to NSS_Init will ABORT (you get the nasty windows > > message stating the problem has behaved very badly), not simply fail. This > > includes the tools that come with the NSS distribution such as modutil, > > certutil, etc. > > > > Since it is a "NSPR" issue, does that mean it will never get fixed? > > > No, we need a bug written up in mozilla, though, so we can track this > issue. It looks like someone on NSS (probably me) will have to take a > debug build on win98 and see what is crashing where. > > bob >
