Jump to content

Firefox 53 (and other unsupported software) working on windows xp


Duck42069

Recommended Posts

I extracted the core folder from the firefox 53 installer and patched all .exe files with XomPie. You just have to install it and it adds xpatcher.cmd to the send to thingy when you right click and it only needs the kernel32 patch so you hit 1 and enter and then it just works. This won't patch any system files.

XomPie: https://github.com/tumagonx/XomPie/releases

Working Software:

Firefox: https://ftp.mozilla.org/pub/firefox/releases/53.0.3/win32/ Extract, then patch all .exe files

Sugar Sync: https://filehippo.com/download_sugarsync/3.9.5/ Install, then patch SugarSync.exe

 

untitled.JPGuntitled.thumb.JPG.c58215662cc6a80ff6bb31304142942f.JPG

Edited by Duck42069
Link to comment
Share on other sites


Yes, great to know that's possible to do, but just going one version up doesn't seem really worth it.
Accepting that "Quantum" Firefox versions will never run on XP, it would be good to be able to go to version 56, IIRC the last non-Quantum version.
:)

Link to comment
Share on other sites

1 minute ago, Duck42069 said:

I tried, no luck ):

The latest version that I have gotten working is 53.0.2, even 54 beta 1 won't work with the patches.

That's sucks!

I'm still using the ESR version, if someone is able to get newer versions working I might update

Link to comment
Share on other sites

On 11/8/2019 at 8:18 AM, Vistapocalypse said:

IIRC no NPAPI support (with the exception of Flash Player).

I think there's an about:config preference you can set to false: plugin.load_flash_only

Try it and see. Edit: Yep, it works! You have to create the Boolean pref above and set it to false, but it works.

BTW, Serpent 55 is essentially an updated version of FF 53, and it does support NPAPI plugins.

Also, it's probably worth pointing out that you will lose some security fixes in moving from FF 52.9 ESR to FF 53.

Edited by Mathwiz
Link to comment
Share on other sites

When I tried out FF 53, I discovered that some of my add-ons got disabled. The problem was with "unsigned" add-ons. Usually these were legacy add-ons that continued to be maintained after Mozilla banned pre-WebEx add-ons, and thus could no longer get Mozilla to sign them. The biggest example was the legacy version of uBlock Origin, which I use because it offers more privacy protections than the WebEx version does on FF 52 and 53. (A couple were add-ons that were originally signed, but from which I had removed the signature in order to implement some hack.)

In FF 52 ESR, unsigned add-ons aren't much of a problem. You simply set the about:config preference xpinstall.signatures.required to false and you're good to go. The unsigned add-ons will produce warnings in the about:addons page, but they work. You can even hide the warnings with an add-on like Classic Theme Restorer.

But FF 53 is a "stable" release, and xpinstall.signatures.required doesn't work in stable FF releases. Luckily, there is a workaround, but it's a bit more complex than just setting a preference.

The workaround at the link can be combined with @VistaLover's fix for re-enabling SSUAOs in Firefox 52:

First, follow the instructions there; then add this JavaScript to the config.js file you just created:

try {
Components.utils.import("resource://gre/modules/addons/XPIProvider.jsm", {})
.eval("SIGNED_TYPES.clear()");
}
catch(ex) {}

(I put it after @VistaLover's code, but it will probably work before it too.)

One last thing. Since FF 53 doesn't expect to have add-on signing disabled, it doesn't have the yellow "warning" text that FF 52 ESR does for an "unverified" add-on. Instead, you'll see a scarier, red "This has been disabled" message. However, it has not been disabled; you'll still see a "disable" button which wouldn't be there if the add-on were already disabled. Luckily, hiding warnings (with, e.g., the Classic Theme Restorer add-on) will hide these scarier messages just as it hides the yellow warnings in FF 52 ESR.

Link to comment
Share on other sites

20 hours ago, Mathwiz said:

for re-enabling SSUAOs in Firefox 52

It's funny you mentioned SSUAO in Firefox, because today I became aware of another Mozilla change involving SSUAO support in Firefox... :angry:

During the pre-Australis era, Mozilla had implemented native SSUAO support in Firefox (but I'm now too lazy to search and quote relevant Bugzilla bugs, it's 01:50 AM on Friday already here...), but then disabled it at some point (in Fx 25.0 ?) in desktop Firefox (but kept it in the mobile version) to, supposedly, gain a 7% speed increase in page loading times...

The feature supporting module (UserAgentOverrides.jsm) was still kept in the source tree, but was not initialised in desktop Fx versions - hence the need of an extension (or additional code) to re-initialise it properly in Fx ESR 52.9.x :angry:

In a previous MSFN post, I had searched Bugzilla and found that the SSUAO native feature was again restored in Fx 55.0, so from Fx 55.0+ one would not need extensions (legacy/WE) or JS code to apply SSUAOs in the browser...

However, it appears that this native useful feature was again binned, starting with Firefox Browser (previously known as "Quantum") v71.0 (currently in the beta channel); this time, the original SSUAO supporting module (UserAgentOverrides.jsm) was completely excised, reason being "it was just old code", and those users wanting the removed functionality back should, once again, resort in using a dedicated (WE) addon...

I was alerted by the following Mozillazine thread:

http://forums.mozillazine.org/viewtopic.php?f=23&t=3055169

Bugzilla bug #1513574 : Remove UserAgentOverrides.jsm

Quote

the technical burden of maintaining the code that does this (even assuming it's "bug free") is not worth it.
I agree that it was more convenient just to add a pref for what you wanted, but webExtensions allows you to do that just as easily, and is well tested.

Once again, I beg to differ... :realmad:

Edited by VistaLover
Link to comment
Share on other sites

19 hours ago, Mathwiz said:

hiding warnings (with, e.g., the Classic Theme Restorer add-on)

If you want to hide from view various addon-related warnings inside Firefox's AOM, but don't wish to install CTR just for that function, then you can achieve the same using the following CSS code (inside a userstyle manager, like [legacy] Stylish 2.1.1 or Stylem, or inside your chrome\userChrome.css file in your browser profile) :

@-moz-document 
url-prefix(chrome://mozapps/content/extensions/extensions.xul),
url-prefix(about:addons) {
	 .warning {
	  visibility: collapse !important;
	 }
}

:P

Link to comment
Share on other sites

4 hours ago, VistaLover said:

"it was just old code", and those users wanting the removed functionality back should, once again, resort in using a dedicated (WE) addon...

4 hours ago, VistaLover said:

Extensions allows you to do that just as easily, and is well tested.

That sounds familiar....

Link to comment
Share on other sites

Mozilla's restored boycott of site-specific useragents keeps showing their contempt of user needs. And keeps infuriating me :realmad:

VistaLover said:


During the pre-Australis era, Mozilla had implemented native SSUAO support in Firefox, but then disabled it at some point (in Fx 25.0 ?) in desktop Firefox (but kept it in the mobile version) to, supposedly, gain a 7% speed increase in page loading times...
The feature supporting module (UserAgentOverrides.jsm) was still kept in the source tree, but was not initialised in desktop Fx versions - hence the need of an extension (or additional code) to re-initialise it properly in Fx ESR 52.9.x :angry:
In a previous MSFN post, I had searched Bugzilla and found that the SSUAO native feature was again restored in Fx 55.0, so from Fx 55.0+ one would not need extensions (legacy/WE) or JS code to apply SSUAOs in the browser...
However, it appears that this native useful feature was again binned, starting with Firefox Browser (previously known as "Quantum") v71.0 (currently in the beta channel); this time, the original SSUAO supporting module (UserAgentOverrides.jsm) was completely excised, reason being "it was just old code", and those users wanting the removed functionality back should, once again, resort in using a dedicated (WE) addon...


"it was just old code" ?! Incredible. Now they don't even bother anymore to think up some phony pretense why their continued destruction of useful features should be "necessary". Not that it would matter anyway, since the real purpose is always very obvious by the effect of their deeds: driving even the most loyal users away as fast as possible.

Bugzilla said:
> the technical burden of maintaining the code that does this (even assuming it's "bug free")
> is not worth it. I agree that it was more convenient just to add a pref for what you wanted,
> but webExtensions allows you to do that just as easily, and is well tested.

What a phony lie too. At the same time claiming this task were super easy for addon hobby devs, yet for their mega-corporation it's supposedly a too heavy burden! Although they wouldn't even need to do anything new, just KEEP an already existing file :realmad:

By the way this native function allows users to just toggle PREFS to use it. To give them a better GUI, this simple-pref toggling could also be done by addons in enabled builds, or if necessary xpi-addons could just enable it themselves with 2 lines. If already enabled anyway, as in roytam's builds, that pref-toggling can easily be done by K-Meleon macros too (like useragents2018). Yet all xpi-addons that I've looked at closer in the past, overruled instead this native browser function completely, rendering those native prefs useless. Never quite got it.

Edited by siria
Link to comment
Share on other sites

11 hours ago, siria said:

Now they don't even bother anymore to think up some phony pretense why their continued destruction of useful features should be "necessary". Not that it would matter anyway, since the real purpose is always very obvious by the effect of their deeds: driving even the most loyal users away as fast as possible.

... But all Mozilla devs live under the illusion that constantly aping Google Chrome (by removing native browser features and GUI customisations, delegating removed features to WEs instead) IS the way to deter Fx users from changing camp over to the competition, ie. Chrome! They've also assigned a "name" to this illusion, it's "Chrome parity" (!) But, as you say, the net result is quite the opposite...

Edited by VistaLover
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...