Why must XUL.DLL in shared memory? If next releases demand 300Mb than the game is over for me. I'm running now 24.8.1and have 206Mb left for use. Or do we have more systems which rely on XUL.DLL, but if this is an older package then we might end up in the known dll war.
It is the design of OS/2 (Windows too) that puts shared libraries into shared memory. I had a lot of tabs open which is one reason that I was using so much shared memory. Actually I had forgotten to mark the DLLs high on this build and I had SeaMonkey, Thunderbird and Firefox open when I realized that I only had 64MBs low shared free. So as long as you're not opening too many tabs and such, not marking the DLLs high does work. Note that Mozilla tries to allocate high memory as well which helps.
All Mozilla apps (Firefox, Thunderbird and SeaMonkey) use slightly different and incompatible xul.dlls, that is why we have LIBPATHSTRICT and the frontend RUN!, to keep the incompatible DLLs separate.
I posted a bug about 24.8.1, the one that download nr 3 will crash the program, but I get the stupid reply to move on to a higher version. Are they that stupid that they don't understand that not everyone had ADHD in developing? Where can I put the bug so we get a working system next level?
The problem is Mozilla and their insane quick release schedule (which they're now planning on speeding up) and the fact that the browser is the component of the operating system that is exposed to the most malicious stuff. So security fixes are important, even on our platform, as we don't want a malicious script spying on the next tab and getting your credit card info or even attempting to install something malicious and crashing the browser.
Luckily Mozilla does have the ESR (extended support release) branch which is fairly stable, mostly only getting security updates so we don't have to update every 6 weeks. But the reality is that for security reasons and also to load the latest content, we have to update every year. With only one person working on our main Mozilla port and also working on other stuff (Java update planned for example), bug reports have to be against the latest. Judging by some of the fixes that have gone into the new (not yet released) version, your download crash might already be fixed.
If you still have the issue with the new release (next week?), open an issue at the Bitwise github account.