Newgrounds has done a lot of work on preserving old Flash content. Some standouts are their own Flash player and an SWF to MP4 converter, but what I find most interesting is Ruffle.
Ruffle is a Flash emulator written in Rust that can be used as a browser extension, a desktop client, or a website polyfill. It's still a work in progress, but eventually websites with heavy use of Flash content (like many late-2000s webcomics, or even Newgrounds itself) could use the polyfill to replace Flash content with WASM blobs.
The roadmap was updated recently, and provides a good overview of Ruffle's current capabilities. There's also a demo instance that can run arbitary SWFs, with a few examples available.
> The Flash plugin itself includes a JIT compiler that
> converts AS3 code to x86 code on the fly, which is then JIT
> compiled by CheerpX into WebAssembly.
And of course, the WebAssembly is then JIT compiled right back to x86, so it's actually three levels of JIT compilation. It's a wonder this runs with any acceptable performance at all.
I'm looking forward to seeing this as a dependency of any future Electron app too; Moore's law must be brought to use.
After all, it continues to put some tiny pixels on a screen, emit some light and gets interpreted by some huge neural networks that took decades to train and finally releases a small shot of endorphins.
To be clear, I think this is an amazing project and I very much appreciate this effort to preserve legacy software. When I say it is a wonder that this runs with acceptable performance, that's also to be taken as a compliment to the developers. :)
This is honestly one of the coolest things I've seen, and given the amount of Flex/Spark software for enterprise out there, it could drastically change the legacy software landscape.
It really sounds awesome, but I can't just download it and play with it.
I hope they release something usable that I can just download and play around with. I'm not a huge company which will create something really amazing and can pay royalties to them, I guess I am not interesting
I don't really understand why this isn't the migration path for any legacy tech... Just containerize and emulate it. If there is a security problem, it's only inside your container. No big deal.
It's not always possible to get that to work, depending on the tech. In the case of Flash one of the most annoying and difficult parts is that it requires access to the rest of the world on the internet to function properly a lot of the time. It's because of that lack of security that it was so useful and made a lot of good things possible back then (and also a lot of bad things too).
Is that a function of flash, or how the creator using Flash implements with it?
It's easy to make a mess in many things, and it's true Flash has it's share due to it's sheer ability to create beginners in the realm of digital experiences.
There are a few features of Flash that require either filesystem access or TCP/UDP sockets, which we are never going to be able to support while interoperating with native Flash Player. We can at least hypothetically emulate RTMP and some peer-to-peer functionality by wrapping it in WebSockets or WebRTC, but that only allows communication with Ruffle-aware servers and Ruffle peers (or a patched version of Lightspark). Local Shared Objects can be emulated with cookies but we cannot share LSOs with Flash Player, which stored everything in a separate Flash-specific cookie jar. Flash also had it's own cross-domain policy mechanism, which we could technically support with the extension, but for security reasons we're probably going to just use standard CORS fetches and hope any websites that need it are updated or proxied to support it.
We obviously also cannot support any of Flash Player's DRM features, not for any particular technical reason, but because we (and likely Adobe) are legally restricted from shipping a pure-web decoder for that DRM. We probably could proxy to an Adobe-provided EME plugin, but that would require cooperation with Adobe and major browser vendors for a 0.01%er preservation use case. We also cannot proxy early Flash video as no browser appears to expose native/hardware H.263 or VP6 decoding, so we'll have to ship software codecs that will probably perform like hot garbage on HD video. Fortunately, I don't think there's a lot of SWFs or FLVs with HD video in those codecs anyway.
Flash also allows you to enumerate device fonts, which used to be possible on the Web but isn't anymore. I don't think anyone will miss it.
However, the web sandbox is so large and all-encompassing nowadays that all of the above seems like small caveats. The vast majority of Flash content that people actually want to use is either standalone movies (Newgrounds, Albino Blacksheep, other portals) or static websites (e.g. Homestar Runner, Homestuck). The big hurdles for that are AVM2, dynamic text & inputs, and Stage3D. All of those are almost-perfectly enclosed within the web sandbox. Most of the sandbox-prohibited stuff is necessitated by websites which likely either have executed a transition plan to web standards (and thus won't be using Ruffle) or are willing to put up with whatever extra wrappers or steps we require to make these old APIs work.
In flash lingo aren't games just interactive movies? I remember being quite confused when I discovered I could play pirated flash games on my video player software.
I mean, to the extent that Tetris, Pacman, or Super Mario is an interactive movie, sure? I guess technically they're a series of animations which change (very quickly) when you press a button. But most people would call those games.
I mean that they are movies in terms of what Flash call movies. Flash covers a huge number of features (networking, interactivity, animation, etc.) I believe that Flash games are implemented with the functionalities intended for interactive movies.
That's included in the phrase "standalone movies". I'm so used to working with SWFs that I call all of them "movies" even if they're entirely a single frame with everything handled in ActionScript.
If we are talking about preservation, we would most likely want to be able to preserve everything made using Flash, rather than pick people who used Flash "correctly" and preserve only their work.
I have a hard time understanding why network access would be so annoying and difficult. It should be easy for an emulator to implement user-adjustable restrictions on that.
Flash used some unusual methods of authorizing network access (like crossdomain.xml [1]) which are significantly different from standardized HTTP cross-domain policies, and which can authorize some forms of network activity which are never otherwise permitted to web content (like connecting to arbitrary ports and transmitting arbitrary data, or sending HTTP requests with forged headers).
Worst case, you can use a helper server... The flash content tries to do an HTTP request, the container intercepts that, sends it to a proxy somewhere on the web, which does the request and pipes the response back.
Sure, someone has to run that proxy, but I'm sure flash games sites wouldn't have trouble doing so.
Flash sockets don't transport HTTP requests. You might be able to tunnel them through WebSockets, but that'd turn the "helper server" into what would amount to an open network proxy -- it'd be trivial to abuse.
It's kind of a moot point, though; I doubt that the networking servers that these games depended on are still online. That's a whole separate preservation problem.
No need to make it an open server. For applications that require a limited number of resources, you can implement a whitelist--only allow connections to certain IPs or addresses. Inspect the connections if you have to. For everything else? Make the user run it locally, have your runtime try to connect to a local instance before connecting to a remote instance.
Alternatively, figure out a way to ship remote dependencies alongside the swf file, and define a patch format that allows replacing network requests.
All of this is more work to do, but all of it is also workable solutions.
The worst part of that preservation problem is, that as a DRM measure, some games will "phone home" to download a swf component that implements some critical path of the game. If the server goes down, those games are dead in the water unless you can reimplement the missing pieces.
because the web sucked in terms of functionality then, especially as an application delivery medium.
There is a parallel universe somewhere where Javascript was designed as a Turing incomplete basic interactivity template and now node runs ECMAFlash2019
I'm sure there's a more scientific explanation involving cognitive bias and rationality and so on, but all I know is that few phrases send more chills down more spines of experienced developers than "it should be easy, why don't you just..." It's up there with "ship it now, we'll fix it later" and "if we can't agree which way to go, let's just make it an option in the prefs" on the Mount Rushmore of famous last words in software development. I've been burned by it so many times, I literally have to catch myself when I hear those words coming out of my mouth (or anyone's mouth, but I can only be responsible for myself), which they still do sometimes, because I'm just as subject to human nature and cognitive bias as anyone.
Hey now, the preferences panels of yore were glorious outposts of customization and power-user-centric software. Computing was way more fun back then. Don't lump anti-option sentiment in with those other, far more worrisome things.
That approach to preferences tends to cause combinatorial explosions in your QA department. You can do it if you're careful, but being careful is the opposite of the "then just make it a preference" approach.
I'm not against preferences and lots of options in general when appropriate, I just don't think they're zero-cost. It's like the surprisingly huge difference between a service being "free" vs. "almost free". But anecdotally (I know...) when fundamental differences between developers are resolved as, "let's just do both and make it an option", it's either people assuming that allowing both behaviors either has no cost, or it's a failure to resolve differences that inflicts one of the thousand tiny cuts that will someday overwhelm the code base.
At the same time, I don't want to be dogmatic about anything, those are just general tendencies. Emacs for example is a beautiful example of an almost opposite design. The software is like a computing instrument that the user has to first learn how to play, but the more effort they put in to it, (up to a point at least, and depending on what they want to do) the more they get out of it. Ultimately it depends on what you're trying to accomplish and who your users are.
My /favorite/ is "ship it now, we'll fix it later" or "do it this way now and we will come back and do the better way later" and then never going back.
I've watched a few products "grow" using this method then project managers be surprised when down the line it's all held together with duct tape and chewing gum and a "simple" change is a week of work. There have been a number of times in my past where I have purposefully not suggested or the team decided not to bring up an "option" because we knew it would be abused.
Well, "why not just..." is only bad if it's rhetorical; sometimes it's a genuine question: "why not just?"; there usually is a reason, and it's important to find out what that reason is, rather than repeat someone else's mistakes.
But this is right question. It should be easy to replace part of the binary, it should be easy to run several programs at the same time, it should be easy to type on keyboard so computer executes commands.
These are insanely hard problems yet they are solved because someone asked and someone tried.
Oh, it is easy - just bundle server together with application. The same way we bundle static dependencies (resource files).
For that you need server snapshot, that should be easy - just require it (maybe with source) to be provided with each application that use network. But some servers aggregate data from several users.
That's easy too - require it to be possible to deploy by user on some generalized network architecture.
So technically it is easy, but as society we select other priorities. Personal gain, time to deploy versus stable platform and culture preservation. It is not impossible - early internet was non profit only.
We have same conversation again and again - The Right to Repair, Internet Archive, Open Source. Flash was part of that rhetoric too - that's why it is so polarized. Brilliant tool, so much creativity and yet closed source, poorly supported, bug ridden. It was a public stance - if Flash become standard it would be new IE once again.
Because re-implementing Flash is an enormous amount of work. Back when Flash was popular there were numerous attempts to reimplement it for use on Linux. None of them really got beyond the proof of concept stage.
Based on that I'm pretty skeptical that Ruffle will succeed, although I guess it does have the huge advantage that Flash is no longer a moving target and they really only have to get it to work with existing Flash movies - nobody is creating new ones.
As far as I remember it was difficult to re-implement because the Flash player was backwards compatible with all Flash versions. And this was also why there were so many security issues.
I believe it was mainly legal issues that the community, with their obsession with the purity of open-source, didn't want to accept contributions from those who had done any RE'ing of the official implementation.
The SWF format itself is tiny in comparison to the web standards like HTML, JS, or CSS.
I spent a bit of time trying to figure out why previous reimplementation efforts didn't get anywhere. Here's where they get stuck
swf format: 100% implemented
Tamarind AS3 VM: Open sourced by adobe.
AS1, AS2, AS3: Not technically 100% but effectively so
Flash platform API: Enormous and bug ridden, like mapping the coastline of finland. you can get 90% through this and have 90% to go, over and over again for however many decades you care to work on it. It's not like the stuff here is hard, it's just the sheer quantity of stuff, like, for instance, the precise way that XML whitespace gets parsed by the XML parser into a DOM matters. The gamma interpretation of RGBA colours. And so on.
Flash rendering pipeline: No one has succeeded in figuring out how this works, at all. You can get far enough for strongbad, but for 100% compatibility, the CheerpX approach is the only one that I think has any chance of success.
Your reply to this comment is dead for some reason. As a response: I really, really wish Mozilla hadn't abandoned Shumway. I also wish they'd written it as a standalone translator instead of making it depends on Firefox. The worst part is that I've got several flash sites I used to visit that are still around, but now can't be used because even though they worked with Shumway, Shumway itself no longer works with Firefox.
I was shadowbanned by dang for expressing disappointment in some HN commenter's defense of coronavirus conspiracy videos. I really wish there were a way to delete my account and all my posts, but this is apparently the best they can do.
also, you may be interested in the openflash project
Open-Flash author here. Open-Flash was originally intended to be a fork of Shumway, but it ultimately became a fully separate project intended to provided modular libraries to handle SWF files. I had less time to push the project forward in the last few months.
It currently provides one of the strongest models for parsed SWF files and AVM1 bytecode, and the corresponding parsers and emitters. These libraries are in use to process SWF files automatically (remap identifiers, edit tags, compress files).
The end goal was to provide a player, but Ruffle already has relatively good support, so the goal is shifting to automatically convert SWF files to other languages and help with migrations. The current focus is on AVM1 (Actionscript 2) decompilation.
I forgot to mention the myriad ways that flash would interact with the browser and the operating system, with swfs often designed to interact with browser javascript in particular, in platform and browser specific ways. the various network protocols, RTMP streaming, prioprietary video codecs, ALPHA MASKED video, the CSS parser and styling engine! the API has everything but the kitchen sink. You can have a look at the sorts of challenges you're in for by looking at Shumway's issues register here:
Because everyone wanted flash gone. If it was possible to just run it as a wasm blob at the time we would end up with a bunch of websites still using flash for menus and video. Now that it has been dead for years we can bring it back for the stuff that can't be ported like games.
Ruffle is great! I just used it the other day to convert a flash website with a service manual for my outboard engine into a nice pdf. Each page was a swf file, so I only had to wget them all, convert them with ruffle, and at last convert the images into a complete pdf.
I hope this gets to whoever was in the room when Charlie Rose's show [1] switched thousands of hours of content over to Flash back when it probably seemed like a good idea - a window of perhaps a year or two as Real player faded out and video streaming over the top was finally a little stable if your link was over 2-300kbps.
I was pissed when they switched to Flash but whatever you think of the tech, or Charlie for that matter, it would be a crying shame to loose so much content. He interviewed everyone who was anyone during some eventful times. That site is part of the rough first draft of history.
Poki is also doing something similar together with Nitrome. They use technology from the guys of Away (the ones that initially brought 3D to flash). The product is called AwayFL.
Ruffle is a Flash emulator written in Rust that can be used as a browser extension, a desktop client, or a website polyfill. It's still a work in progress, but eventually websites with heavy use of Flash content (like many late-2000s webcomics, or even Newgrounds itself) could use the polyfill to replace Flash content with WASM blobs.
The roadmap was updated recently, and provides a good overview of Ruffle's current capabilities. There's also a demo instance that can run arbitary SWFs, with a few examples available.
https://www.newgrounds.com/flash/player
https://github.com/Herschel/Swivel
https://github.com/ruffle-rs/ruffle
Roadmap: https://github.com/ruffle-rs/ruffle/wiki/Roadmap
Demo: http://ruffle-rs.s3-website-us-west-1.amazonaws.com/builds/w...