Author Topic: SeaMonkey 2.21b3  (Read 7092 times)

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
SeaMonkey 2.21b3
« on: March 14, 2015, 03:10:13 am »
Hi, I've uploaded https://bitbucket.org/dryeo/dry-comm-esr24/downloads/seamonkey-2.21b3.en-US.os2.7z.
This is based on the same Gecko code as the Bitwise Firefox beta 4 release with the addition of libsydneyaudio to re-enable HTML5 sound. Requirements are the same.
Note that due to combining mozjs.dll into xul.dll, Lightning needs to be updated, I'll upload a new release soon.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 470
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #2 on: March 14, 2015, 01:58:18 pm »
Dave, thank you so much. Just installed and all seems to work well. Including lightning and lightbird. Since a long time I've a working calendar on eCS again.

I did 'highmem -b xul.dll' and it seems to be okay. But till now not extensively tested. Should I try to load all other dlls high too?

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #3 on: March 14, 2015, 06:21:28 pm »
I've been running it with all DLLs marked to load high without problems.
I do get problems it I also mark Thunderbird to load xul.dll high and run both at the same time, so I run SM DLLs marked high and TB DLLs not marked high.
Note that some of the security DLLs are marked read-only, probably as a security measure and after marking high it might be a good idea to restore the read-only attribute.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #4 on: March 17, 2015, 02:51:07 am »
Just a reminder that my builds are not associated with Bitwise other then using much of the same code so issues should only be raised with them if reproducible with their build.

Eric Erickson

  • Newbie
  • *
  • Thank You
  • -Given: 1
  • -Receive: 0
  • Posts: 40
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #5 on: April 28, 2015, 08:56:19 pm »
Any suggestions on how to debug a start up issue. I'm running on eCS V2.1 and use SM V2.14. Since one of my banking websites has gone wonky with V2.14 I thought I'd give v2.21b3 a try.

I installed all the updates as requested via yum and tried all the debugging tips in the README.OS2, but none seem to help. When I try and start seamonkey I get a quick flash of the window and then nothing. No seamonkey.exe in the process list, no entries in POPUPLOG.OS2, no beeps from exceptq and when I tried the parameter to get the console.log created, its empty? Tried all the various SET Statements listed, but nothing changes the behavior.

The only thing I have not tried is totally blowing away my V2.14 profiles and starting with new profile. Any assistance here would be greatly appreciated.

Cheers,

guzzi

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 18
  • Posts: 313
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #6 on: April 28, 2015, 11:20:07 pm »
I saw the same with the latest AOO. Turned out one of the dependencies was the the wring version. Do make sure everything you have to install with yum is the proper version. Yum list installed will give you the version numbers.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #7 on: April 29, 2015, 01:48:55 am »
Besides what guzzi said, make sure your @UNIXROOT\usr\lib directory is close to the front of your LIBPATH statement, You can quickly test with BEGINLIBPATH and LIBPATHSTRICT=T and also especially make sure you don't have an old version of exceptq anywhere.
You can also launch seamonkey.exe 2>error.log > reg.log and look in the logs.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #8 on: April 29, 2015, 01:55:17 am »
While on the subject, what are peoples preferences for dependencies for SM2.28? I can build with the same dependencies as the Bitwise builds of Firefox or as few as just mmap.dll, exceptq.dll and libc066.

Greggory Shaw

  • Global Moderator
  • Sr. Member
  • *****
  • Thank You
  • -Given: 39
  • -Receive: 19
  • Posts: 420
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #9 on: April 29, 2015, 03:17:30 am »
While on the subject, what are peoples preferences for dependencies for SM2.28? I can build with the same dependencies as the Bitwise builds of Firefox or as few as just mmap.dll, exceptq.dll and libc066.


May as well keep a standard - stay with the Bitwise setup please it will really help me out !

I'm modifying my FireDD (SM & TB) install script for Yum users (default no dlls installed, with the option to install Bitwise dlls).

http://os2notes.net/os2firefoxdd.html

(Note: ver 028 has not been released yet. )


Greggory
« Last Edit: April 29, 2015, 03:28:04 am by Greggory Shaw »

ivan

  • Hero Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 36
  • Posts: 1080
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #10 on: April 29, 2015, 10:39:59 am »
Dave, I may be the descenting voice here but the less external dependences the better.  It saves us having to try and find the odd DLL and put it where it won't cause trouble at a later date.  It also means that what you build is much more in the OS/2 way which is 'a good thing'.

I am using your build of firefox in preference to the Bitwise one because yours 'just works', for which I say thank you.

Andi B.

  • Sr. Member
  • ****
  • Thank You
  • -Given: 1
  • -Receive: 22
  • Posts: 470
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #11 on: April 29, 2015, 04:43:53 pm »
Quote
...but the less external dependences the better.
Sounds good but OTOH this would mean less use of shared dlls which leads to more memory usage. And memory is getting more and more a scare resource on our OS. So sooner or later this will lead to more trouble than solving in the short term.

Quote
It saves us having to try and find the odd DLL and put it where it won't cause trouble at a later date.
This should not be much of a problem. Only install what the readme says. Or is there some dll missing in the readme?

Quote
It also means that what you build is much more in the OS/2 way which is 'a good thing'.
Avoid using shared dlls contradicts the 'OS/2 way' IMHO.

Dave, I clearly vote for one 'standard way'. At this times as defined by bww.

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 167
  • Posts: 2341
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #12 on: April 29, 2015, 05:28:52 pm »
Quote
...but the less external dependences the better.
Sounds good but OTOH this would mean less use of shared dlls which leads to more memory usage. And memory is getting more and more a scare resource on our OS. So sooner or later this will lead to more trouble than solving in the short term.

A couple of points about this, the gcc dlls are very small and there is likely more overhead loading them then is saved by having them in a dynamic library. Even the bigger DLLs such as mzfntcfg are statically linked to xul.dll so it seems they'd still be in shared memory.
As well my understanding is that each program gets its own private memory arena whereas shared is shared though we do have high memory now.
Personally it is the small dlls such as the gcc ones that I find irritating and even on Windows developers usually statically link them.

Quote
Quote
It saves us having to try and find the odd DLL and put it where it won't cause trouble at a later date.
This should not be much of a problem. Only install what the readme says. Or is there some dll missing in the readme?

Usually we seem to miss at least one and sometimes there is a surprise such as old exceptq.dll breaking SM

Quote
Quote
It also means that what you build is much more in the OS/2 way which is 'a good thing'.
Avoid using shared dlls contradicts the 'OS/2 way' IMHO.

Is having so many dependencies really the OS/2 way? Before Bitwise the developers in charge of Mozilla, first IBM, then Peter and Rich always strived to have the least dependencies as possible. I remember reviewing the source of GCC 3.4.5 to see if we could legally load the gcc345.dll statically and after getting Knut to update the license on his code (GPL with linking exception) Peter kept the dependency limited to libc

Quote
Dave, I clearly vote for one 'standard way'. At this times as defined by bww.

Dmitriy Kuminov

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 4
  • Posts: 17
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #13 on: April 29, 2015, 07:07:35 pm »
My comments. The gcc DLL is made dynamic so that some C/C++ machinery could work across DLLs (e.g. exceptions). And no, mozft libraries are not statically linked into XUL.DLL — since FF 24 beta 4 we we link against our fntcfg2 / freetyp6 DLLs (which are pretty much the same as mozft but they have standard names and are used by a variety of other OS/2 apps out there).

In general, the all-in-one approach (best deployed by Apple on Mac) has its own benefits, for sure (especially from the end user's POV). But you have to pay the price of increased memory usage for that. On Mac, it's not a big issue because it allows to handle much more memory than OS/2 and its memory management is apparently superior to that on OS/2 (and it can handle its memory usage patterns pretty well). Besides, the majority of Mac apps is written using Apple's own toolkits and these toolkits are provided as DLLs by the system (so a typical native Mac app rarely needs anything besides the system libraries). Going further, OS/2 has never had this all-in-one approach implemented to a smooth degree: IBM-provided hacks like LIBPATHSTRICT are clear evidences of that. So it's simply not correct to say that it's the OS/2 way to deploy apps. And I do remember a lot of DLL hell in the past with various OS/2 applications.

Putting it all together, the lack of proper DLL management on OS/2 doesn't allow apps to have their own, private versions of DLLs. The lack of proper memory management doesn't allow to have them all built statically. We have major problems with private / shared memory arenas which get quickly exhausted if one uses a couple of heavy apps in parallel (e.g. Firefox and OOo and/or a Qt app). All this leaves us only one choice: put as much common code to DLLs as possible and make as much apps use these DLLs as possible. Of course this isn't a way to go w/o a decent package manager that ensures DLL integrity and this is where we came to YUM/RPM.

And if you take the modern user's perspective, it doesn't really matter what the application does under the hood as long as you have the application store where you just type its name to smoothly install or remove it. This is basically what Apple Store does on Mac and a respective application manger on any other modern OS (including mobile devices). And if you go with the YUM/RPM approach provided by BWW, OS/2 differs from those only by the fact that on OS/2 the application manager has no handy GUI yet so you have to use the command line. But given that an average OS/2 user is not unfamiliar with the command line and that Yum command line is very simple to use (for basic things like installing an application), it doesn't look like a big price for the convenience for both the developer and the end user. More over, a Yum GUI is on its way so this will make things even more user friendly when it's out.

Firefox will become an RPM installable with Yum very soon too. For this reason, we are trying to reuse DLLs already provided by RPM/YUM as much as possible with each FF release (and will even create more of such DLLs in the future).
CPO of bww bitwise works GmbH

Eric Erickson

  • Newbie
  • *
  • Thank You
  • -Given: 1
  • -Receive: 0
  • Posts: 40
    • View Profile
Re: SeaMonkey 2.21b3
« Reply #14 on: May 05, 2015, 04:50:49 am »
Besides what guzzi said, make sure your @UNIXROOT\usr\lib directory is close to the front of your LIBPATH statement, You can quickly test with BEGINLIBPATH and LIBPATHSTRICT=T and also especially make sure you don't have an old version of exceptq anywhere.
You can also launch seamonkey.exe 2>error.log > reg.log and look in the logs.

Ok, whats defined as an old version of exceptq? The only one I have is located at \ecs\dll and is dated 05-05-2011.

As for trying the launch with the redirection, both files are empty. No output at all. I successfully got this version running on the Wife's eCS V2.2 and getting it to run on my eCS V2.1 is not working out very well so far.

All the various package levels check out, now I need to start checking levels between the \ecs\dll and \usr\lib, but would still love to get any input on next steps.