My Browser Builds (Part 4)

[DanR20]

8 hours ago, roytam1 said:

a missing follow-up is pushed, and will be available in next build.

for the time being you can do it yourself:

- open omni.ja with winrar in application's folder

- goto omni.ja\chrome\toolkit\content\mozapps\extensions and extract extensions.xul (better keep this window opening)

- edit extracted extension.xul, following https://github.com/roytam1/UXP/commit/7c4d0444bd58b0726a2448e294738c1a7df3d298 to remove lines and save file

- drop edited extensions.xul back to previous window to update omni.ja

- start serpent

That worked perfectly. Had to deoptimize omni.ja first to make the change but that fixed it.

[modnar]

I think I can wait a week without editing Serpent; Addons page gets rarely visited here. :-)

[nicolaasjan]

3 hours ago, roytam1 said:

archives updated

Thanks!

Now it works.

[UCyborg]

1 hour ago, modnar said:

I think I can wait a week without editing Serpent; Addons page gets rarely visited here. :-)

I never remember command line arguments to repack omni.ja the same way it's packed "from the factory".

[VistaLover]

1 hour ago, UCyborg said:

I never remember command line arguments
to repack omni.ja the same way it's packed "from the factory".

... You need the zip CLI of the Info-ZIP utility; Windows binaries courtesy of the German developer Dirk Paehl:

https://www.paehld.de/open_source/?Old_programs___ZIP_UNZIP

I myself use the 3.1d26+beta version ...

1. Place zip.exe adjacent to extracted directory "omni"

2. CD in the Windows Command Prompt to inside the "omni" DIR; then:

"..\zip" -qr9XD "..\omni.ja" *

Archive omni.ja created besides the zip.exe binary; NB: this archive is still "un-optimised", so it then needs to be additionally "optimised"...

3. Place the py2.7 script "optimizejars.py" next to zipped archive "omni.ja"

4. With py2.7 installed, execute:

python "optimizejars.py" --optimize ./ ./ ./

A copy of that script has been uploaded here ...

Edited July 1, 2023 by VistaLover

[roytam1]

23 hours ago, ClassicNick said:

FYI: The UXP browser builds (New Moon tested) compiled with Visual C++ 2017 still supports Windows XP SP2. @roytam1 Now that you're building UXP applications using Visual C++ 2017 (version 15.9?), will they still compile with Visual C++ 2015 update 2 if JPEG-XL is disabled?

for now, yes.

may not work with vc2015 later.

[Mathwiz]

On 6/27/2023 at 12:21 AM, nicolaasjan said:

Web Archive has all 4.3.12 flavours :

https://archive.org/details/paintdotnet_v4_3_12.

Yes, the Wayback Machine is an excellent resource. And thanks for finding it and posting the link. I'm still disgusted with dotPDN's attitude, though.

Perhaps I'll have better luck with the above link, but I tried the portableapps version, but couldn't get the JPEG XL plug-in to work with it, even though I have a 64-bit system.

Speaking of which....

On 6/27/2023 at 10:12 AM, VistaLover said:

And one thing mentioned in that quote above that seems to be the new "vogue" among app authors is the deprecation of 32-bit binaries (latest Paint.NET runs exclusively on Win10/11 64-bit), a development I face all the more lately when searching for Windows binaries (of various software) compatible with my x86 OS.

I still rely on a few 16-bit apps, which of course don't work on 64-bit Windows, because Micro$not has decreed that only the two latest "bitness" levels shall be supported. The need for a 32-bit OS to run those apps was a major reason for installing "XP Mode" on Win 7 when I upgraded back in 2015 or so!

[UCyborg]

8 hours ago, VistaLover said:

Archive omni.ja created besides the zip.exe binary; NB: this archive is still "un-optimised", so it then needs to be additionally "optimised"...

Wasn't aware about that part, is there an explanation written in plain English somewhere about what the process does? Probably can't tell the difference with naked eye since hardware is so fast these days.

[nicolaasjan]

3 hours ago, Mathwiz said:

but couldn't get the JPEG XL plug-in to work with it, even though I have a 64-bit system.

(offtopic)

IrfanView 64bit has JPEG XL support when you install the additional plug-ins and enable support in Help ---> Installed plug-ins:

(support not for 32bit)

Edited July 2, 2023 by nicolaasjan

[VistaLover]

22 hours ago, UCyborg said:

Wasn't aware about that part, is there an explanation written in plain English somewhere about what the process does?

... I trust you'll find the article below quite enlightening  :

https://whatsoftware.com/edit-files-inside-firefox-4-omni-jar-to-auto-save-password/

... specifically this part:

Quote

The optimized omni.ja file is not a standard ZIP format, because the layout has been changed.
Usually, the index is placed at the end of the file, but an optimized omni.ja places the index at the front of the file
to minimize disk seeks and to maximize read ahead benefits.

Later additions:

1. MDN entry for file omni.ja, saved via the WA:

http://web.archive.org/web/20210620190432/https://developer.mozilla.org/en-US/docs/Mozilla/About_omni.ja_(formerly_omni.jar)

Mozilla, in their infinite wisdom , have annihilated that article in the autumn of 2021...

2. Relevant "discussion" in an old (2013) thread of the 7-zip Support Forum (hosted by Sourceforge):

https://sourceforge.net/p/sevenzip/discussion/45797/thread/dab0da38/

Quote

 ... is another zip file named omni.ja (originally omni.jar). This is a zip format, but it has been optimized to load quicker by moving the directory from the end of the file to the beginning.
 This optimization is performed by a python script (optimizejars.py). This script can be used to optimize or deoptimize the jar, so that it then can be read by 7zip. The script uses a log file that contains a list of the files in the order that Firefox loads them and arranges the contents of the zip file in that order, so that Firefox can start up quicker by loading content before the entire file has been completely read.

Pinging @UCyborg ...

Edited July 3, 2023 by VistaLover
Additional references included

[roytam1]

On 7/2/2023 at 7:09 AM, roytam1 said:

for now, yes.

may not work with vc2015 later.

after merging intl updates, vc2015 no longer builds without fixing:

 6:52.88 c:\devel\myUXP\obj-vc15-i686-pc-mingw32\dist\include\mozilla/TextUtils.h(142): error C3250: 'uc': declaration is not allowed in 'constexpr' function body
 6:52.88 c:\devel\myUXP\js\src\builtin/intl/LanguageTag.h(530): note: see reference to function template instantiation 'bool mozilla::IsAsciiDigit<char>(Char)' being compiled
 6:52.88         with
 6:52.88         [
 6:52.88             Char=char
 6:52.90         ]

if you want vc2015 able to build again, you may need to create a patch.

EDIT: created a rebase-branch for HACKFIX vc2015: https://github.com/roytam1/UXP/tree/vc2015

I don't know how far it can go, but at least we can try for now.

Edited July 4, 2023 by roytam1

[UCyborg]

On 7/1/2023 at 7:38 PM, VistaLover said:

Archive omni.ja created besides the zip.exe binary; NB: this archive is still "un-optimised", so it then needs to be additionally "optimised"...

This whole thing is confusing and that Python script still doesn't make it exactly like "the factory" does.

So one thing, compression, some Mozilla applications have files in the archive compressed, some of them not. All factory baked omni.ja (or palemoon.res) in case of official Pale Moon come with header error when clicking Info in 7-Zip. optimizejars.py you linked to does not introduce header error. palemoon.res even has some weird "129:v1" written for compression method of each file, so 7-Zip doesn't even unpack it. I use 7-Zip 21.03 ZS v1.5.0 R2 (x64) ATM, will update it at some point.

Mozilla stopped compressing files in the archive at some point, see https://stackoverflow.com/questions/32038251/how-to-correctly-repack-omni-ja-in-firefox:

zip -0DXqr omni.ja <file(s)/dir(s) to pack>

They also sign it now, but we don't have to worry about that in certain forks, UXP apps included. Uncompressing implies more work at runtime, at least that's my thinking. So is it better to not compress or is there a catch?

More questions than answers in the end.

[VistaLover]

On 7/4/2023 at 11:17 PM, UCyborg said:

This whole thing is confusing and that Python script still doesn't make it exactly like "the factory" does.

... The "optimizejars.py" script is contemporary with the Firefox ESR 17 release, i.e. late 2012 (!) : 

https://dxr.mozilla.org/mozilla-esr17/source/config/optimizejars.py

https://hg.mozilla.org/releases/mozilla-esr17/raw-file/tip/config/optimizejars.py

Until that period, it was actually part of Mozilla Firefox's (open) source code... Later on, Mozilla deprecated that script and opted to use (non-public) omni.ja optimising routines built inside their compilers' infrastructure ... So, the publicly available optimising script is a reflection of how omni.ja optimisation was done in 2012, but I find is an acceptable approximation for, at least, the FxESR 52 era (2017) ...

On 7/4/2023 at 11:17 PM, UCyborg said:

Mozilla stopped compressing files in the archive at some point,
...
They also sign it now,

I haven't actually followed the rest of that story on Firefox versions > 52.9.0, because Mozilla dropped support for my OS...

On 7/4/2023 at 11:17 PM, UCyborg said:

All factory baked omni.ja (or palemoon.res) in case of official Pale Moon come with header error when clicking Info in 7-Zip. optimizejars.py you linked to does not introduce header error. palemoon.res even has some weird "129:v1" written for compression method of each file, so 7-Zip doesn't even unpack it. I use 7-Zip 21.03 ZS v1.5.0 R2 (x64) ATM, will update it at some point.

This all regarding the official Pale Moon browser is quite a different story ; for "normal" omni.ja archives, in order to extract them successfully with 7-zip without the header warnings, you first have to de-optimise them, as already reported by @DanR20 :

On 7/1/2023 at 5:04 PM, DanR20 said:

Had to deoptimize omni.ja first to make the change

Place "omni.ja" adjacent to the script, then (with py2.7.18 installed) run:

python optimizejars.py --deoptimize ./ ./ ./

Then extract the de-optimised archive with the program of your choice...

As for "palemoon.res", this is indeed a renamed "omni.ja" file, but Moonchild, in an attempt to protect his copyrighted resources, decided to pack it with a custom encryption/optimisation, utilising the Brotli compression encoder, in a way to specifically thwart normal extracting applications ; if you ask me, it was just to vex those advanced PM users who were accustomed to making special modifications to the browser by modifying code extant inside omni.ja itself... I have kept records and the "encrypted"/un-extractable omni.ja archives first appeared in:

PaleMoon_unstable-29.0.0a6-uxp-master-git-20201114-g511ac54-pm-master-git-20201114-g07d3f0a.win32[buildID=20201114181134]

omni.ja was renamed to core.dll at that time; the final renaming to palemoon.res was implemented in the next unstable build:

PaleMoon_unstable-29.0.0a6-uxp-master-git-20201116-g241f06b-pm-master-git-20201117-g86b6cb4.win32[buildID=20201117182045]

The first stable PM version with its "omni.ja => palemoon.res" archives made un-extractable was v28.16.0; there were some complaints in their forum, but soon all was forgotten ; if you'd care to read, some links (there are more ) :

https://forum.palemoon.org/viewtopic.php?p=204401#p204401
https://forum.palemoon.org/viewtopic.php?p=204337#p204337
https://forum.palemoon.org/viewtopic.php?p=216675#p216675
https://forum.palemoon.org/viewtopic.php?p=229232#p229232

 

On 7/4/2023 at 11:17 PM, UCyborg said:

so 7-Zip doesn't even unpack it.

... The great JustOff to the rescue:

https://github.com/JustOff/mozjarr/tree/master

However, I have no intention of upsetting MC and co. at all ; this tool exists, but JustOff's traces are currently lost ; that fact alone makes the tool itself probably an "abandonware"; besides, this community here is not in need of it, because @roytam1 has not followed MCP's path and "omni.ja" files in all of his UXP releases remain user-readable/extractable ; in any case, under normal conditions, a simple user shouldn't even mess with those archives:

https://mike.kaply.com/2013/05/06/dont-unpack-and-repack-omni-jar/

(the latest case where the maintainer himself posted instructions necessary to fix the "about:addons" bug in latest St52 is just an exception to that rule ...)

Edited July 7, 2023 by VistaLover

[Mathwiz]

28 minutes ago, VistaLover said:

I haven't actually followed the rest of that story on Firefox versions > 52.9.0, because Mozilla dropped support for my OS

Doesn't FF 53 run on Vista?

28 minutes ago, VistaLover said:

https://mike.kaply.com/2013/05/06/dont-unpack-and-repack-omni-jar/

I actually do that intentionally with Serpent, in order to change the Help / About Serpent pop-up window. You can replace/improve the logo and text:

I don't bother to re-optimize, which undoubtedly slows down launching the browser, but I don't do that often enough to care! (Image at left courtesy of @dencorso; unfortunately we couldn't confirm it was free of copyright restrictions, so it was never made generally available. But it looks cool so I'm using it on my own personal copy  .)

[VistaLover]

16 minutes ago, Mathwiz said:

Doesn't FF 53 run on Vista?

Nope!

https://www.mozilla.org/en-US/firefox/53.0/releasenotes/

Quote

Changed

Windows XP and Vista are no longer supported.

The Fx53 "installer" version won't install the browser under Vista SP2; the "zip" version of Fx53 can be made to run under Vista SP2 if the "subsystem version" string inside the main EXE's PE Header is lowered (with specialised tools) from 6.1 to 6.0; media capabilities of the browser will remain broken, though; the app does no longer have access to Vista SP2's WMF patented decoders (h.264, aac, mp3), because Mozilla devs had excised all support for Vista SP2's WMF version (which is inferior to Win7's WMF version, but this was already discussed in the (distant) past) ...