open-source-flash
Adobe already open sourced the core of the Flash Player
In 2006, at the same time Adobe released Flash Player v9.0 and Adobe AIR v1.0, they open sourced the ActionScript Virtual Machine 2 (AVM2) and donated the project to the Mozilla Foundation.
see
- Wikipedia - Tamarin (software)
- Brendan Eich - Project Tamarin
- Frank Hecker - Adobe, Mozilla, and Tamarin
This project Tamarin was hosted on mercurial under 2 main branches
- tamarin-central (not working)
- tamarin-redux (working)
- Tamarin Bugzilla
- Tamarin-devel Archives
Later, after the project was not publicly updated anymore, Adobe moved the sources to a repository named avmplus on github
- adobe-flash/avmplus
- adobe/avmplus (latest)
If Adobe wanted to open source the Flash Player, that AVM2 would be the first thing that would need to be open sourced, and so they already did.
If you look at the repositories, the bugzilla, etc. Adobe was very serious about it, they did not drop the sources and let other people deal with it, they assigned many developers and fully embraced the open source development cycle.
Out of this project only a little part (the NanoJIT got reused by Mozilla in Firefox), but mostly nobody else contributed any code ... for years.
In short, nobody really showed any interest.
As a very tiny open source dev I took on the Tamarin sources and around 2008 published another OSS project: Redtamarin
The goal was simple, reuse the goodness of AVM2 but develop the API side and if possible provide an open source implementation of the Flash API (as much as it makes sense for the CLI).
For close to 10 years, I had exactly zero contributors, especially around 2010 after a special letter of a special someone "WHAT? AS3 on the server-side? you crazy!!!"
Let's be clear I'm not complaining, I'm perfectly happy with my own little OSS project, it does scratch my own hitch, it even lead to interesting side project tools like as3shebang (yep running AS3 as shell scripts, I do admin a dozen Linux server with that).
But I still have a point, what make people think that getting the sources of the Flash Player will magically solve the problem ?
First, the project due to its cross-platform nature is kind of complex, go ahead get the avmplus sources and compile it, then compile it for the different CPU architectures, for different operating systems, it's a whole production.
Second, now imagine that the Flash Player sources are similar to the avmplus sources but probably twice as big and twice as complex, if not bigger than that. Unless you have a team working on it full time, it's unlikely you can publish anything from it.
Third, even if you have the sources, the contributors working on it, all the browser vendors plan to remove completely the support for plugins (they already killed NPAPI), how do you get users to install a plugin that cannot be installed anymore ?
imho you are trying to solve the wrong problem
The problem is not the Flash Player not being open sourced The problem is the browsers not supporting the installation of plugin
A fork of Chromium/WebKit/Firefox to keep the support for plugin, even with a closed source Flash Player would have more chance to succeed.
Good points! The reason I put this on GitHub was that I don't know everything, so it's good to gain knowledge what's the situation!
What about .fla?
There's many people discussing about the issues, I'm not alone: https://twitter.com/bit101/status/890210621542678529 https://twitter.com/TomFulp/status/889883079137005570 https://twitter.com/tha_rami/status/890051049259663361
...so there must be something missing still?
OK, let's try to define the problem:
People want to preserve the experience of playing SWF in the browser
to be able to do that you need 3 elements
- a Flash Player plugin
- a browser that allow to install plugin (either NPAPI or PPAPI)
- domains that keep hosting their SWF content
All the major browser vendors: Google Chrome, Mozilla Firefox, Microsoft Edge/IE, Apple Safari have done the following
- removed the capability to install/run NPAPI plugins, except Flash
- blocked the Flash plugin to run automatically, eg.
Click-to-Run, except for some whitelisted domains
and they announced to plan the following
- by mid to late 2018, require the permission for Flash to run each session
- in mid to late 2019, disable the Flash plugin by default users will be able to re-enable the plugin, but still this will require user approval to run the plugin
- by end of 2020, they will remove the ability to run the Flash plugin eg. "Users will no longer have any ability to enable or run Flash."
So by end of 2020 to still be able to
People want to preserve the experience of playing SWF in the browser
you can either
- emulate it, eg. allow users to play SWF file without the need of a plugin that's the Shumway approach
- convert it to another format, eg. take a SWF and output HTML5/JS/etc. that's the Swiffy approach
- play it outside the browser, either fork one of the major browsers or use another browser that still allow to play SWF because it still support plugin
"emulate it" and "convert it" are both hard problems, both Shumway and Swiffy, while being supported by big companies like Google or Mozilla, have been abandoned.
Open sourcing the Flash Player could help a project like Shumway, but it would still be a hard problem to solve.
And if Flash Player is open sourced why not also make a petition to open source something like Swiffy ?
What about
.fla?
You can still use .fla files in Animate CC, and for the older .fla that can not be opened
you can still install in parallel old Flash CC / Flash Pro CS6 / etc. to open those
But you would still have another problem: the hosting of the SWF.
By 2020, when all browsers does not play SWF, even if you have something like Shumway that can play SWF, I doubt the domains who have huge catalog of SWF files like miniclip, kongregate. armorgame, etc. will still hosts those SWF files for the fun of it.
Also, those SWF files are not easily archived because they also depends on the domain providing an API, take miniclip for example, every single SWF game is loaded by a "game loader" that provide an API such as login, saving the score, multiplayer, etc.
Most of those SWF games are domain locked, you can not just download the SWF and play it local.
For me personally the no. 1 issue is that how do I revisit my old projects (from 1999 AS2 to AS3), which I have in either .fla, .swf or some newer format..
the simplest approach is to use Adobe AIR it does embed a browser (old Safari WebKit) and support the Flash Player plugin
from AIR 1.0 to AIR 21, the Flash plugin was embedded into the AIR runtime from AIR 22, the AIR runtime use the plugin installed on the system
see Flash Player and AIR 22 Release Notes
System level Flash Player support for AIR desktop applications
Starting in AIR 22, applications that play swf content via the HTML control (WebKit) will now load the system level NPAPI Flash Player provided by Adobe (https://get.adobe.com/flashplayer). If this plugin is not available on the system, the end user will be prompted to download and install the plugin from Adobe.
"as is" you can create a small wrapper in AIR, that create an HTMLLoader that will act as a "small" browser and that can play SWF file embed in HTML.
Either from a domain or from a local file.
I think WaterFox is still permitting people to run the plugins THEY like. It allows running of all 64-Bit NPAPI plugins and also running of unsigned extensions. See waterfoxproject.org or github.com/MrAlex94/Waterfox
zwetan: this can be only a trick, I think the best for all of us would be to hijack flash PPAPI and create it open source asap, because since FP 21 some important features and updates have been done
@madovsky but all the browser vendors plan to remove the capability to run plugins open sourcing the Flash Player will not change that
@zwetan what about prepare redtamarin to render on webgl with skia? remember me? ^^
@devlfm yes I remember and answer is still the same, redtamarin is about the CLI a bit off topic to talk about that here, but I can say that I keep the focus/scale of the project to the amount of what can be implemented by the current size of the team, eg. 1 dev
I'm still confused whether Adobe has already open sourced Flash or not? Only partly?
I believe flash will get reborn. but we can do more things exceed html5(js + css) and make the simple to flash air (stupid ane)
They open sourced the ActionScript VM which is part of the Flash Player. It is a good starting point but this is not enough.
Is it this? https://github.com/adobe-flash/avmplus
Updated 4 years ago
...
I wish adobe did the same with shockwave and director and did some more documentation like they did with flash. I think there was a program years ago that can take a DCR or DIR program and extract out the lingo code and anything else, but I'm still trying to find it.
@pakastin See the first message, there are two repos:
- adobe-flash/avmplus
- adobe/avmplus (latest)
The second one was updated last year.
2 main projects were open sourced
- Flex SDK contains the compilers: ASC, MXMLC, COMPC that what allow to compile AS3/MXML sources to bytecode and the sources for the Flex framework which basically allow to architecture apps with AS3 and MXML
- avmplus
that's what allow to interpret/execute ActionScript Bytecode
it is at the core of both the Flash Player and the Adobe AIR runtimes
it contains mainly the AS3 builtins (
String,Number,Array, etc.) and few other classes likeByteArray,Proxy, etc. but the crucial part missing are the definitions of the native classes you can find in the Flash API and the AIR API, for ex:flash.display.Sprite,flash.media.Sound,flash.net.Socket, etc.
The Flex SDK was open sourced from the beginning (well almost.. since Flex 3) under Adobe umbrella, and later on they donated the project to the Apache Foundation and the project is now known as The "Apache Flex SDK".
It's quite important to have the compilers open sourced, also new compilers (next gen) have been developed: Falcon and FalconJX, which lead to another "side project" FlexJS which allow to compile AS3 sources to JS sources.
And on top of that, Adobe also open sourced WebkitAIR which is how they can embed a browser engine inside Adobe AIR with some neat features like being able to execute AS3 code from the JS side.
In all those projects, the first common problem is the Flash API. In fact, it is the same problem that faced Shumway and other project.
The Flash API is quite complete and quite mature, it is not something you implement in a couple of months, it is much harder than that.
Even if dev like AS3 as a programming language, or the tools like the compilers or animation tools like Animate CC that can generate SWF, the real sauce that allow them to be creative is the Flash API.
The second big problem is the GUI rendering, the vector rendering engine of Flash is quite good and not that easy to replicate, if you go into things like Stage3D it get even harder to replicate.
What could be done now, providing enough developers were contributing to such big project
- take avmplus, and implement on top the Flash API to a certain point (eg. not the rendering part)
- then add something like Skia to complete the Flash API (display list, Sprite, etc.)
- then add something like WebkitAIR to allow to embed an HTML renderer in that display list (same as
flash.html.HTMLLoader)
with that you would get a somewhat equivalent open source version of Adobe AIR that could run on Windows, macOS and Linux but with not all the bells and whistles like Stage3D etc.
It would be quite an advanced and hard project.
But this project would still not play SWF files as you are used to run in the Flash Player, you would have to go into the details of the SWF spec and implement all those SWF tags and interpret/combine them into the avmplus sources and render some of them using Skia.
So, I'm not saying it is impossible, but it would certainly be extremely hard.
Off topic sorry: disabling plugins, results in giants (Google, Apple, Facebook) sniffing in everything we do. In every variable of our code. This was the goal since the beginning. Open sourcing Flash Player might not bring any benefit if browser vendors do not allow plugins anyway.
PippoApps: not accept plugins anymore is a non sense, but not for the dev browsers themselves. Rather than cooperate and find together a win win solution they just do whatever they want in the way to (as usual) kill the concurrence. Mostly controlled by big money corp (yes, even firefox is owned by google). It's now a 20 years battle, and if we, developers and users don't say enough is enough, we want our own standard and browser as any open source allow, so they will win and it will be very hard to break it in the future, unless if the real economy will finally get the last word.
zwetan: I completely agree with your analyze, yes, flash is what it is today because it took 18 years, I just want to remind that the success of Macromedia with flash at the start was because they asked to users what were their needs and wishes to make the web evolve, and they developed it (flash player & shockwave) nothing is impossible indeed, the only way to succeed is to work together with a large amount of developers to divide the tasks. But I'm pretty sure that some very high skill retired developers would love to do it ;).
Guys, here is what I think should have happened many years ago, or will hopefully happen soon.
Somebody should simply write a Flash Player in Javascript (or in some other language, and compile to JS or WebAssembly), SWF specification is public and it seems to be even simpler than e.g. PDF (for which pdf.js exists). People are emulating the whole computers in browsers (to run any OS you want) - https://copy.sh/v86/, so emulating a virtual machine to "play SWF files" should not be a problem.
I know, that Flash allows creating TCP sockets and other "low-level" things, which are not possible with current web technologies. But the emulator could prevent it or "fake" it somehow, I hope most of games would run without it.
This would not depend on OS or a browser. It will run everywhere, just like any Javascript code runs the same way everywhere. And there would be no way browsers can stop us from "playing" these great SWF files in every browser for decades to come.
Somebody should simply write a Flash Player in Javascript (or in some other language, and compile to JS or WebAssembly)
it already happened, and many years ago, see mozilla/shumway
also see the wikipedia shumway page
Development of Shumway has effectively ceased. Although the project remains available on GitHub (see External links), in February 2016, the project was moved to the "Firefox Graveyard" and is thus considered defunct from Mozilla's point of view.
the most recent project to try that again is ruffle-rs/ruffle
Guys, here is what I think should have happened many years ago, or will hopefully happen soon.
Somebody should simply write a Flash Player in Javascript (or in some other language, and compile to JS or WebAssembly), SWF specification is public and it seems to be even simpler than e.g. PDF (for which pdf.js exists). People are emulating the whole computers in browsers (to run any OS you want) - https://copy.sh/v86/, so emulating a virtual machine to "play SWF files" should not be a problem.
I know, that Flash allows creating TCP sockets and other "low-level" things, which are not possible with current web technologies. But the emulator could prevent it or "fake" it somehow, I hope most of games would run without it.
This would not depend on OS or a browser. It will run everywhere, just like any Javascript code runs the same way everywhere. And there would be no way browsers can stop us from "playing" these great SWF files in every browser for decades to come.
- yes, it is much simpler than PDF. i always hated how so many programs struggle with PDF, and i know why after reading the specs. it's a positively INSANE file format, just how unity decoder tools can't do too many productive things with THOSE for the same reason.
emulating flash player is indeed more than possible. the same applies for shockwave/director, which was only ever 'secure' from decompilers because it wasn't mainstream enough. by my observations, lingo code compilation is actually more lossless than actionscript. it's also probably easier to emulate under javascript. once the decoders are finished, that is. now, flash has some...annoying caveats that make things harder. animate HTML5 shows what happens when you don't properly process/render the shape format, for example. you get the ugly 'shape seams' that ruin vector artwork. but 'vector artwork shouldn't be rendered by clients, anyways, so who cares?' shm...
-
i think the "open standards" do in fact allow for this. any perfectly stand-alone flash game/movie will be fine without this, but a lot of games [like MMOs, which CAN still be saved] are tied to their servers. preserving them will require reverse-engineering their code and their network communications to make them work in the post-flash era. the easiest limitation to break would be the site lock. developers just cannot prevent a flash emulator from falsifying the web address the file was loaded on (;
-
i plan both to implement and extend the SWF format at some point in the future. debating my exact process for this, though... while i will facilitate the inclusion of code, i do not currently plan to facilitate its execution, as my primary goals are to leverage the asset formats. people who so gleefully preach the wonders of HTML5 are almost certainly not touching those raw APIs, or doing things which aren't exactly supported or feasible without severe performance degradation and tons of boilerplate code. the majority of HTML5 games are built with unity, construct, game maker, animate CC, RPGMaker, so on... All of which have their caveats and btw are commercial-proprietary black boxes just like flash and the flash player. only, much much worse. As someone who has tried with a mix of failure and success to wrangle the HTML5 APIs directly [which any proper library/api/framework should not be such a hassle], I think i'm more than qualified to speak to the HORRORS of dealing with them, and the things which they cannot do, or just shouldn't be used for. Some graphics effects practically mandate webGL or cutting some corners with quality/scope if you want performance.
// end that
beating a dead horse again: they say flash player was so slow, but it runs exceptionally well in stand-alone mode. amazing no one bats an eye at how despite removing these layers of "slowdown" and "insecurity" that browsers consume so much more memory/CPU thane ever before, including all suffering from memory leaks that creep-up slowly until you have to restart them. not only that, but are full of exploits, and the oh-so-secure "open" web standards keep introducing newer ways to do malicious things. particularly 'dangerous' operations are globally blacklisted and developers/end-users continue to jump through hoops and opt for NO security just to keep doing what they want to do.
shumway: Mozilla canning it doesn't surprise me, tbh... they quit caring about their end-users quite some time ago. they're also part of the main W3C circle and the hate-boner for adobe runs strong. something like shumway actually being completed would undermine the plans to kill flash/plugins off because suddenly you could continue playing flash files, independent of your operating system, and possibly without a plugin. [basically what unity did with webGL, but far as i know, the old unity games can't use the webGL loader since their code is actually stored in...embedded DLLs [scary!] ]
besides any malicious intents, they probably are trying to manage too many projects at once, as are most of these corporations. maintaining a web browser is already a task and a half, itself. note even the non-mainstream browsers tend to just fork code from the mainstream ones? or well, they start like that.
i know a guy was also working on porting shumway to work with pixijs, and he actually solved that shape seams issue, too... can't remember where he mentioned that anymore.
i only recently learned of ruffle. hopefully one of these projects will see completion some day. i so far haven't been sold on rust, however, and node/npm are/is an ABSOLUTE "no" in my book. i tried to load a rather simple SWF file on their demo site, and it did not work... i should file an issue, but too lazy/busy with my own things... also, i don't currently want to release the flash files i've been testing because they're either not appropriate, or it could undermine some of my archival/restoration projects.
GNU Gnash is already open source. What more do you want?
As is nouveau nvidia driver. Ready to ditch the blob ? How about exact specification for all of Flash's APIs and/or fully documented code, so 100% compliance of Gnash and Lightspark could be achieved instead of an exercise in guesswork ? Using Flash code directly would be dumb, it's most valuable as reference.
even if you had the full source code of the Flash player plugin open sourced it would be useless as all major browsers dropped support for plugins
even if you had the full source code of the Flash player plugin open sourced it would be useless as all major browsers dropped support for plugins
And yet I somehow have it enabled in my latest Firefox 77.0.1:
- https://build.opensuse.org/package/show/home:X0F:HSF/MozillaFirefox
- https://build.opensuse.org/package/show/home:X0F:HSF/freshplayerplugin
- https://build.opensuse.org/package/show/home:X0F:HSF/flash-player
- https://build.opensuse.org/package/show/home:X0F:HSF/lightspark
Also, all implementation of Flash, open and not, have stand-alone players.
by "all major browsers" you should have understood the "official distribution by the vendors" in other terms what people get by default on their OS and/or when they download a browser
but sure you can compile anything by yourself and have various results, but then it is just for you
a bit like maintaining your own chromium fork and dicking around with few dozens users while everyone else use Google Chrome
Also, all implementation of Flash, open and not, have stand-alone players.
a standalone player make it de facto something that run outside of the browser does it solve the problem of a plugin running inside the browser?
nope
so about being useless, what's worth a plugin you can only compile or install for yourself on your own compiled browser ?
not much
distribution, availability and reachability were the killer features of Flash as a plugin