Re: SeaMonkey 2.35b7

Doug Bissett wrote:
>> I've mentioned before that I think there's room for two means of
>> >packaging and distribution here:
>> >
>> >a) yum install seamonkey thunderbird firefox
>> >I believe this is the eventual goal of bitwise, but as everyone knows,
>> >this simply does not work yet.
>> >
>> >b) static build with minimal external dependencies, like Mozilla
>> >distributes, and we had previously.  Both ZIP and installer package
>> >(WarpIn or otherwise) are perfectly viable.
>> >
>> >Doug has been making WarpIn packages for quite some time, which I
>> >commend him for, but I feel they are currently pointless, since it
>> >doesn't do anything about dependencies.  Isn't the point of an
>> >installation package to set everything up for you?  I'm not faulting
>> >Doug for that, just pointing out that option b above is what needs to be
>> >packaged for it to be viable.
> I think that a) will be an option, in the near future, and that will
> make other methods obsolete. If you haven't looked seriously at
> installing, and using Arca Noae Package Manager (ANPM), I suggest that
> you do so. It makes life a whole lot easier. I don't agree with the
> way the RPM/YUM does things, but that is the way that was chosen by
> those who do it, so we are stuck with it, and it will become even more
> important to follow that path in the future as more programs are
> packaged that way. The whole thing is a LOT better than it was when
> the ANPM project was started, and ANPM makes it easy to operate
> RPM/YUM.
>
> On the other hand, option b) may become necessary just to overcome the
> shared memory problems, but that doesn't mean that it can't be
> distributed by RPM/YUM. After doing some investigation, we need to get
> high shared memory working (it does work, as long as you never unload
> the DLLs),

It does work here, at least until memory gets fragmented or some other 
resource runs out. Currently with TB and SM loaded, I have 256 MBs of 
low shared memory available. If I restart SM enough times, the system 
will usually spontaneously reboot when loading SM or opening a new SM 
window. Occasionally the system just freezes. This usually happens here 
when Free Shared Memory app shows about 200MBs free.

> or we need a way to keep, at least, XUL.DLL (perhaps
> others) loaded all of the time (preferably high),  so it doesn't run
> into a situation where it can't get enough contiguous memory to load.

Which XUL.DLL? Right now I loaded TB and then SM without RUN! or 
LIBPATHSTRICT and Theseus shows both XUL.DLLs being loaded. Trying to 
also run FF now gives a sqlite error about the version being too old, 
which seems like a new error.
The wildcard seems to be Calendar, or its DLL, calbscmp.dll. Without 
Calendar installed, I was running all 3 Mozilla apps without 
LIBPATHSTRICT. With it installed in only TB, I can load TB and then SM 
but lately it fails if I have it installed in both SM and TB, with SM 
crashing when loading the mail & news window. SM also seems to keep 
reverting to an older version and even when the DLL is the same in both 
apps, it crashes lately.
Really it seems that it is just safer to use LIBPATHSTRICT or RUN!

> It also needs to be fixed so that it just fails when it can't load the
> DLLs. Now, it seems that it just keeps retrying, until the user
> reboots (and a user won't know what is going on, if they don't have
> Process Dumps enabled).

I haven't seen this. Here it seems to just reboot or freeze the system. 
Occasionally I get a TRAP E in SM

> I would also suggest that those who use only a
> browser, should use FF. Those who use only e-mail, (and news etc.)
> should use TB. Those who need both, should use SM.

Lots of people don't like FF, so prefer browsing with SM. I also run TB 
for testing purposes.

> The idea is to have
> only ONE XUL.DLL loaded. Apparently, if you can get the right one,
> they can all share XUL.DLL, but that seems to be hit and miss, at the
> moment. In fact, part of the answer may be to simply drop FF and TB,
> and only update SM, but SM is not an "official" project, so that
> causes other problems.

Then there are the people who don't like SM and prefer FF.

>
> I will note, that I gave up trying to verify requirements, with
> WarpIn, because Bitwise gave up trying to document that stuff (too
> complicated), and simply said to use RPM/YUM (meaning ANPM to make it
> easy). I did consider looking to see if the user has RPM/YUM
> installed, and simply run the command to do the updates, if it was
> found, but that didn't seem to be a good idea if the user had it
> installed, but wasn't actually using it. As it turned out, those who
> use ANPM spent about 2 minutes (depending on download speed) getting
> the requirements installed, and those who don't use ANPM spent days
> trying to figure it out. Steve made that much easier, but his package
> still doesn't contain all of the parts that ANPM includes, and it will
> be the same thing next time. Possibly worse.
>
> One thought (Dave, perhaps you can do something), is to have a program
> that will simply load XUL.DLL, and keep it loaded in high shared
> memory space when FF is closed. currently, it seems to take about 90
> meg to load XUL.DLL, and it seems that that must be contiguous memory.

That should be possible. Mozilla used to pre-load the DLLs if you ran 
their pre-loader program and Dink had a program that did similar.
I'd assume that you just need a small program linked against XUL.DLL 
that is left running. Not sure how it handles XUL data, does it get 
unloaded when FF closes?

> If another program loads something after that, and it stays in memory
> when FF is closed, and something else  uses another chunk of shared
> memory, it can come out of the part that XUL.DLL was using. Now, when
> XUL.DLL tries to load, it can't find enough contiguous shared memory
> space to be able to load XUL.DLL. That just happened to me, and the
> result was repeating Process Dumps, all pointing to Firefox (no *.TRP
> files, or entries in POPUPLOG.OS2). That kept on repeating until I
> rebooted. If XUL.DLL was loaded, and stayed in memory, that problem
> wouldn't happen. Of course, FF should also detect that it couldn't
> load the DLL, and inform the user of the problem.

I don't know why Mozilla hasn't added code to inform about not being 
able to allocate enough continuous memory as it is also a major problem 
on 32 bit Windows. Eventually it'll probably be only 64 bit to avoid 
these issues.
Dave