Were there ever non-x86 NPAPI plugins?
Forum rules
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
This General Discussion board is meant for topics that are still relevant to Pale Moon, web browsers, browser tech, UXP applications, and related, but don't have a more fitting board available.
Please stick to the relevance of this forum here, which focuses on everything around the Pale Moon project and its user community. "Random" subjects don't belong here, and should be posted in the Off-Topic board.
-
- Lunatic
- Posts: 323
- Joined: 2022-03-23, 16:41
- Location: Chamber of Secrets
Were there ever non-x86 NPAPI plugins?
Were there ever any non-x86 NPAPI plugins on Linux systems? If so, what were they?
I suppose in theory you could compile GNU GNASH or Lightspark NPAPI plugins for non-x86 systems, but I am moreso asking about official/popular plugins such as Adobe Flash.
If there were not NPAPI plugins for non-x86 architectures, is it even worth compiling UXP applications on non-x86 with the NPAPI support enabled?
I suppose in theory you could compile GNU GNASH or Lightspark NPAPI plugins for non-x86 systems, but I am moreso asking about official/popular plugins such as Adobe Flash.
If there were not NPAPI plugins for non-x86 architectures, is it even worth compiling UXP applications on non-x86 with the NPAPI support enabled?
-
- Board Warrior
- Posts: 1138
- Joined: 2019-04-24, 09:38
Re: Were there ever non-x86 NPAPI plugins?
Adobe Flash existed for amd64 (x86_64).
The profile picture shows my Maico EC30 E ceiling fan.
-
- Lunatic
- Posts: 323
- Joined: 2022-03-23, 16:41
- Location: Chamber of Secrets
Re: Were there ever non-x86 NPAPI plugins?
Sorry if it wasn't implied that x86 included 64-bit x86 as well. I had assumed that the implication was obvious. I was referring to anything that is not x86 compatible in any way (for example, ARM or SPARC).
-
- Board Warrior
- Posts: 1138
- Joined: 2019-04-24, 09:38
Re: Were there ever non-x86 NPAPI plugins?
IIRC ARM was not used in desktops when NPAPI was widely used.
A version for Solaris on SPARC existed: https://community.adobe.com/t5/flash-pl ... -p/3156210
A version for Solaris on SPARC existed: https://community.adobe.com/t5/flash-pl ... -p/3156210
The profile picture shows my Maico EC30 E ceiling fan.
-
- Contributing developer
- Posts: 1537
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Were there ever non-x86 NPAPI plugins?
I think there was an ARM version of Flash for Chromebooks and Android at one point... don't know how well it would work on modern Linux, though. However, I'm pretty sure there was an ARM version of the old Java NPAPI plugin that might work.
And yeah, Solaris had plenty of NPAPI plugins for SPARC like the guy above me said, but aside from that I don't think many other architectures ever had it. It's mostly an IA-32/AMD64 thing. Maybe there was an Itanium version, but Itanium is pretty dead. On Mac, I do believe PPC had some NPAPI plugins. So really it's mostly older, more established architectures that were once used on desktop. SPARC was used at one point by some Sun workstations, and Mac used to be PPC, and that's why those architectures have NPAPI plugins.
However, right now it's a bad idea to disable NPAPI support because there are a few issues that have been found with my build flag for doing so. For one thing, WebRTC currently depends on NPAPI, and Travis just found that mouse wheel scrolling doesn't work without NPAPI right now either. I'm trying to tracking that latter issue down, and hoping to find a way of fixing that that won't involve adding half the NPAPI back in despite the build option saying it disables it... seems kind of pointless to have a build flag that partially disables NPAPI if there's supposed to be a way to disable it.
But yeah, if you want the "full" experience, the Windows on IA-32/AMD64 version is always likely to be the "flagship" version of the browser because it's the platform on which NPAPI works best. Everything else is kinda compromised and broken in that regard. Linux already has issues with NPAPI due to GTK3 and later, plus Wayland and newer glibc, and the increasing adoption of ARM on Mac is making things more difficult on that platform as well. If AMD64 ever gets fully replaced by ARM or RISC-V, then NPAPI is as good as dead on all platforms.
And yeah, Solaris had plenty of NPAPI plugins for SPARC like the guy above me said, but aside from that I don't think many other architectures ever had it. It's mostly an IA-32/AMD64 thing. Maybe there was an Itanium version, but Itanium is pretty dead. On Mac, I do believe PPC had some NPAPI plugins. So really it's mostly older, more established architectures that were once used on desktop. SPARC was used at one point by some Sun workstations, and Mac used to be PPC, and that's why those architectures have NPAPI plugins.
However, right now it's a bad idea to disable NPAPI support because there are a few issues that have been found with my build flag for doing so. For one thing, WebRTC currently depends on NPAPI, and Travis just found that mouse wheel scrolling doesn't work without NPAPI right now either. I'm trying to tracking that latter issue down, and hoping to find a way of fixing that that won't involve adding half the NPAPI back in despite the build option saying it disables it... seems kind of pointless to have a build flag that partially disables NPAPI if there's supposed to be a way to disable it.
But yeah, if you want the "full" experience, the Windows on IA-32/AMD64 version is always likely to be the "flagship" version of the browser because it's the platform on which NPAPI works best. Everything else is kinda compromised and broken in that regard. Linux already has issues with NPAPI due to GTK3 and later, plus Wayland and newer glibc, and the increasing adoption of ARM on Mac is making things more difficult on that platform as well. If AMD64 ever gets fully replaced by ARM or RISC-V, then NPAPI is as good as dead on all platforms.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
-
- Pale Moon guru
- Posts: 35650
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: Were there ever non-x86 NPAPI plugins?
I did build an x86_64 version of a PDF reader, and there's really nothing stopping anyone from building for ARM, M1SoC, SPARC, Risc or similar. The NPAPI is an API that doesn't care about the actual binary code as long as the API's messaging is followed, it will work.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
-
- Contributing developer
- Posts: 1537
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Were there ever non-x86 NPAPI plugins?
That's a good point. I guess if we want NPAPI to have a future, there need to be more open source NPAPI plugins that can be compiled on newer platforms. The API itself isn't the problem, the problem is that most of the stuff people want to use on it is commercial binaries that are no longer produced.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind
-
- Board Warrior
- Posts: 1138
- Joined: 2019-04-24, 09:38
Re: Were there ever non-x86 NPAPI plugins?
Because FF and Chrome don't support it anymore, almost all vendors discontinued it.athenian200 wrote: ↑2024-02-03, 22:37That's a good point. I guess if we want NPAPI to have a future, there need to be more open source NPAPI plugins that can be compiled on newer platforms. The API itself isn't the problem, the problem is that most of the stuff people want to use on it is commercial binaries that are no longer produced.
I don't think there will be something new here.
The profile picture shows my Maico EC30 E ceiling fan.
-
- Fanatic
- Posts: 122
- Joined: 2017-06-21, 02:37
Re: Were there ever non-x86 NPAPI plugins?
People are also generally unaware of the existence of a truly independent web engine and platform. yet here we are. We just need to get interested parties aware of the potential of the NPAPI technology.
-
- Board Warrior
- Posts: 1138
- Joined: 2019-04-24, 09:38
Re: Were there ever non-x86 NPAPI plugins?
Te question is just: Which benefit does it provide?
Adobe Flash prospered at a time when browsers weren't able to play videos.
Now HTML 5 exists.
Most browsers also support PDF viewing inside them - other people can still use their favorite PDF reader.
Which use-cases you think about?
The profile picture shows my Maico EC30 E ceiling fan.
-
- Contributing developer
- Posts: 1537
- Joined: 2018-10-28, 19:56
- Location: Georgia
Re: Were there ever non-x86 NPAPI plugins?
When it comes to Flash, I don't really think HTML5 is a good replacement for everything Flash can do, but Ruffle's ability to simulate it using WebAssembly comes a lot closer, so the argument has merit even if we disagree on the specifics of what counts as a replacement for Flash player.Pentium4User wrote: ↑2024-02-04, 18:57Te question is just: Which benefit does it provide?
Adobe Flash prospered at a time when browsers weren't able to play videos.
Now HTML 5 exists.
Most browsers also support PDF viewing inside them - other people can still use their favorite PDF reader.
Which use-cases you think about?
There's also stuff like Silverlight, Shockwave, Java applets, the Unity web player, plus more obscure uses.
Having to rely on a PDF reader as functionality baked into the browser rather than having a selection of optional extensions is antithetical to our philosophy, but it does raise another point... couldn't a PDF reader just be implemented as a XUL extension rather than an NPAPI plugin? It's an interesting thought.
One use case I am considering, is using an NPAPI plugin to recreate a modern IE Tab using WebView2. Though honestly I'd rather put that effort into improving UXP itself, it is something that is on my agenda to try some day. The point is, it does offer ways of adding functionality to the browser without having to bake things into the codebase. So far the benefits are only theoretical, because it's just being used to load legacy plugins, but in theory there might even be ways of adding newer technologies we can't license as open source into the browser as optional NPAPI plugins with different licensing.
All that said, it is becoming a huge maintenance burden, particularly on Linux, and it doesn't seem to have a bright future for the reasons you stated.
"The Athenians, however, represent the unity of these opposites; in them, mind or spirit has emerged from the Theban subjectivity without losing itself in the Spartan objectivity of ethical life. With the Athenians, the rights of the State and of the individual found as perfect a union as was possible at all at the level of the Greek spirit." -- Hegel's philosophy of Mind