Hacker News Reader

Comment by thdrdt | Hacker News Reader

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.

View on HN

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.

This is a very interesting overview, thanks for sharing

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:

https://github.com/mozilla/shumway/issues

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

https://github.com/open-flash

and the shuobject api

https://github.com/mozilla/shumway/blob/16451d8836fa85f4b16e...

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.

Reply on news.ycombinator.com