OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Internet => Topic started by: Dave Yeo on May 21, 2017, 01:22:14 am
-
Hi I've uploaded builds of SeaMonkey and Thunderbird built on the ESR branch using Bitwises Gecko code. They're 2 commits behind, so the readme and changelog haven't been updated to the same level as Firefox ESR and still require RUN!. They also only have the extra requirement of libvpx as well as possibly the nspr in the experimental repository (untested with the stable version of nspr, the experimental one was needed to build)
SeaMonkey is a special case as 2.42 was never released. I've backported a couple of patches and have more that don't apply, need to hunt through more bugs :) Both apps seem to run fine here though they seem to use more shared memory and SM is somewhat slow.
Not sure that Lightning will be automatically installed, it was here with an unpackaged binary. If needed I'll upload the XPI.
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42b8.en-US.os2.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42b8.en-US.os2.zip)
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/thunderbird-45.8.0b8.en-US.os2.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/thunderbird-45.8.0b8.en-US.os2.zip)
-
I've installed and run both SeaMonkey and Thunderbird on a system that was already running Firefox 45. I did update nspr; I'm not sure that is needed.
Integration between Thunderbird and Firefox looks broken. Firefox 45 no longer uses Run!, but it appears to be required to make integration work.
-
Here, where I've updated both thunderbird.exe and seamonkey.exe with dmik's patch for firefox.exe so run! is no longer required, thunderbird still opens seamonkey when I right click a link and choose "Visit in Browser" (required due to having thunderbrowse installed?).
This works both in eCS 2.0 and ArcaOS.
Have you changed the default web browser to firefox.exe? In ArcaOS, it is in System Setup -->Network-->TCPIP-->Default Applications.
-
Here are updated exes for SM and TB that have dmiks patch applied and no longer require run!.
Backup the original exe, with the program closed and replace the exe and test. Note that the thunderbird.exe currently has a broken icon.
I hope to rerelease the packages next weekend once I backport some patches from SM2.44
-
Fixed the icon resources for both executables. Should be now compatible with most of the buggy display drivers used nowadays. Both executables are tested, but require now Warp 3, because I accidently removed OS/2 2.0 support. But I think nobody uses them without XUL.DLL which requires WSEB (4.5).
Btw. what's up with the diamond marker which is too huge in all mozilla applications now?
-
Thanks Andreas. What the problem actually is, is that when packaging Mozilla, lxlite is run on the executable (and DLLs) which screws up the icons if they're high colour, so what I actually need is a thunderbird.ico that is 256 colour.
-
Thanks Andreas. What the problem actually is, is that when packaging Mozilla, lxlite is run on the executable (and DLLs) which screws up the icons if they're high colour, so what I actually need is a thunderbird.ico that is 256 colour.
That's the reason I attached the file moz-icon.zip which only contains 8-bit (256 colour) icons to my message before.
-
Dave,
If you look on an ArcaOS 5 DVD, you will find under \CID\SERVER\MOZILLA the following files:
FFOXICON.ZIP
SMICON.ZIP
TBRDICON.ZIP
These each contain 256-colour icons including for main, safe mode and profile manager. All the icons that are not from the original packages were created by me, so I give you full permission to use them.
-
Just in case somebody needs a localised lightning add-on I attached the german xpi here.
-
SMICON.ZIP
lxLite won't touch the seamonkey\chrome\icons\default *.ICO files, which a properly working install script could use.
-
The build adds the icons to the exes and then make package runs lxlite on the DLLs and exes. When lxlite compresses the exe, hi-colour icons get corrupted. It's an lxlite bug.
Lxlite is needed now that we use wlink as the binaries are huge, xul.dll is 469212KBs as an example.
-
The build adds the icons to the exes and then make package runs lxlite on the DLLs and exes. When lxlite compresses the exe, hi-colour icons get corrupted. It's an lxlite bug.
Excuse me, I was talking about any own install script of the user. So far the right original SM icons are always included by you, so the user can avoid this problem of damaged icon data of the EXE. Avoiding the problem for all users may be better, but the right original icons are already available for all users. The user shouldn't need a SMICONS.ZIP file. This is verified with SM only, I don't know about TB.
-
I accidently removed OS/2 2.0 support.
In general it's safe to assume the use of a 80386 Y2K-proof OS by now, i.e. any OS/2 Warp or newer products, unless you know that you have to keep a specific, professional real user of OS/2 2.0 in mind. Users of OS/2 2.0 will be aware of the fact that their setup is old, and they'll contact (and pay) you if their old, specializied professional setup really requires a modern browser. So, for example, you can stop using the "OS2ENVIRONMENT" of Rexx, unless one of your customers still has to use Microsoft OS/2 and needs your Rexx script. Only if the software in question is FF/SM, then you can safely add 300 to the number of the CPU because of the specific memory requirements of FF/SM to visit about:blank.
-
@André, it is the Thunderbird icon that is currently broken, a regression.
BTW, Mozilla has never supported OS/2 2.x due to compressing the executables to the max.
-
Starting with the seamonkey 2.35 builds two other icon files don't look proper from subdirectory chrome\icons\default.
They should be replaced by their counterparts from seamonkey 2.7.2 builds which are fine but have different filenames (in parentheses).
- bookmarkproperties.ico (bmPropsWindow.ico)
- places.ico (bookmark-window.ico)
-
Thanks Andreas, I'll add them to my tree.
BTW, next release will have changes to Lightning so you'll have to redo your localized version.
Also seems that dmik made an error in his libpathstrict patch for Firefox.exe and as I just copied his patch... Here's updated binaries.
-
I've rebuilt SeaMonkey, now 2.42.9. Frank-Rainer Grahl supplied a bunch of backported patches from upstream to bring 2.42 up to release standards. Some icons fixed thanks to Andreas Kohl. I fixed the merge, a couple of files didn't originally merge correctly. The Mozilla tree is now slightly ahead of Firefox 45.5, now at the 45.9 level with H264, AAC and now MP3 playback working (volume still broken). Seamonky.exe is also patched to not need LIBPATHSTRICT or RUN! anymore.https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2.zip (https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.42.9esr.en-US.os2.zip). Same requirements as previously, the latest FFmpeg 3.3.1 (Hobbes incoming currently) should also work for H264, AAC and MP3.
-
When I run the new version 2.42.9, I get this added to POPUPLOG.OS2
06-03-2017 20:16:06 SYS2070 PID 0054 TID 0001 Slot 0078
H:\SEAMONKEY2\SEAMONKEY.EXE
XUL->LIBCX0._fread
127
OK, it works with an updated LIBCX0.DLL you supplied.
-
Shoot, sorry I forgot that I updated libcx, try this, it'll find itself into the RPM tree.
Should be able to backup and replace the version on @UNIXROOT\usr\lib, might need unlocking and a reboot or at least a Mozilla restart.
-
the latest FFmpeg 3.3.1 (Hobbes incoming currently) should also work for H264, AAC and MP3.
FFPLAY.EXE, apparently a requirement of QWinFF, is no component of FFMpeg anymore?
-
Need a more up to date SDL2, ffplay no longer supports SDL and the port on Hobbes is to old or configure should have updated version.h but was not run due to the porter going the OpenWatcom route with Doodles in tree patches.
The failure in config.log
check_cpp -Ik:/ffmpeg/include/SDL2
BEGIN k:/ffmpeg/tmp/ffconf.AwYCwzvr.c
1 #include <SDL.h>
2 #if !((SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100)
3 #error "unsatisfied condition: (SDL_MAJOR_VERSION<<16 | SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100"
4 #endif
END k:/ffmpeg/tmp/ffconf.AwYCwzvr.c
Probably bad line wrap above.
I'll revisit when I have time, unless someone else wants to fix SDL2
-
QWinFF may be the only app which requires FFPLAY.EXE. I cannot recall another example, and remembered the setting of QWinFF.
Which ZIP file is the home of LZMA5.DLL ("available as zips in the http://rpm.netlabs.org/release/00/zip/ directory
libc066, zlib, bzip2, freetype, fontconfig, libzma0")?
Edit: xz-5_2_3-2_oc00.zip