Re: Firefox 38.8.0 Beta 7 released

Lars Erdmann wrote:
> I figured that some DLLs from the Thunderbird distribution could be
> deleted as they are also contained in \usr\lib (if you use yum/rpm ...).
> The ones that had to be left in where:
> ldap60.dll
> ldif60.dll
> mozalloc.dll
> mozqslt3.dll
> prldap60.dll
> xul.dll

They'll be a few more once I get SM/TB compiling with the external NSS 
and NSPR packages (I'm having problems building ssldap60.dll where they 
didn't build an OS/2 DEF file for some reason)
Does secure connections work with TB the way you have it set? Others 
reported errors about the security center (Netscape era error message) 
when trying to use Firefox with the SM NSS and NSPR dlls.

>
> as they either do not exist in \usr\lib or they are not yet "unified"
> between Firefox and Thunderbird. I guess once "xul.dll" gets "unified"
> that that will also eliminate the shared memory problem (this thing is
> HUGE).

There's unified and there's unified. Windows now puts sqlite3, nss and 
nspr into xul.dll, making it even more huge. I haven't experimented with 
that route yet as it'll probably take more build system changes then 
just adding OS2 to a configure line :).
Right now if all the apps are built from the same revision (or close), 
with mostly the same options, you can share xul.dll unless you're using 
calendar, in which case you have to use TBs xul.dll. I still run out of 
shared memory in a couple of days even sharing all the DLLs.
We just don't have enough address space and once it gets fragmented, 
things break. Win32 has the same problem, with the leading crash causes 
being shutting down (there's code to crash if shutdown hangs) and out of 
memory (OOM) errors, mostly caused by fragmented memory. And they have 
jemalloc, which I believe does rudimentary garbage collection, whereas 
we're stuck with mozalloc. I think to port jemalloc, memory has to be 
committed at specified addresses which OS/2 does not do.
Dave