First time I hear about this and it brought a smile to my face. I'm one of those "web assembly sounds great, but when am I actually supposed to use it"-guys, but this use case is so perfect and makes me really happy. We forget that flash games wasn't just a way to pass time, it's now also a part of internet culture that, without people like you, will go lost forever. HUGE props if you pull this off.

> Redistributing the Flash binary is not normally allowed, so we are going to directly download it over HTTP the first time our system is started.

How will this work when Adobe stops distributing the Flash installer?

Maybe get archive.org to handle it? My understanding is that they have some pretty good legal counsel, so that's something they might be cool with?

Security is another concern. Unless WebAssembly itself is immune

Since we wrote the post we started discussing with the appropriate parties to solve the licensing issues.

Is "the right way" in quotes because it's sarcasm? This is a really cool idea, but very impractical. I think most would agree that "the right way" would be to port the game to HTML5, either using straight JS or a technology like Haxe and OpenFL.

We believe this is "the right way" since it's the only possible way of _accurately_ preserve all Flash content.

It's certainly not the only way. It's just a more convenient alternative to running Flash player locally and downloading SWFs. The convenience is definitely a major improvement to the process, but it could potentially end up in a legal gray area after Adobe stops distributing their binaries.

Now that's impractical, because of cost. There's a wealth of SWF content that will never ever be ported.

An SWF runtime is feasible, it's actually not a very complicated format. The devil is in the details, but a lot of content does not use that many features.

This is a pipe dream, as Flash has capabilities you just don't get in HTML+JS without writing an entire VM, such as text metrics and weak references.

Reconciling those differences is part of the porting process. I do agree that it's a "pipe dream" to expect every single SWF out there will be ported, but it is definitely the right way to do it if you're trying to save a SWF.

Relying on old binaries of Adobe Flash Player is probably not a good idea from a legal perspective. I'm not a lawyer, and I haven't read the EULA, but I wouldn't be surprised if it didn't allow that type of redistribution.

Even if JS+HTML5 dies for some reason in the future, it's not a closed-source proprietary platform like Flash was, so preserving stuff will be much easier.

Hence WebAssembly + WebGL/WebGPU.

There is functionality that is just not available while in the browser sandbox, so some flash apps will never work. But I'm happy to see this happening.

WebAssembly not gonna give you access to syscall that are simply not there in the Web API

Text metrics, the graphics engine implemented on top of WebGL/WebGPU does it itself.

Weak references are coming, https://github.com/tc39/proposal-weakrefs

no, I'm talking about this

[0] does support for socket(udp and tcp)? [1] encountered with problem when Porting UDP socket communication c code using emscripten

one example among other, and so you can use WebAssembly all you want you will never be able to implement flash.net.DatagramSocket

[0]: https://github.com/WebAssembly/design/issues/1251 [1]: https://github.com/emscripten-core/emscripten/issues/5196

Yes you can, polyfill using WebSockets.

It would require a server component as gateway, so what.

Preaching to the choir my friend, this is the correct path.