3 ms·

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.

pjmlp 6y ago
Hence WebAssembly + WebGL/WebGPU.
- zwetan 6y ago
  WebAssembly not gonna give you access to syscall that are simply not there in the Web API
  - pjmlp 6y ago
    Text metrics, the graphics engine implemented on top of WebGL/WebGPU does it itself. Weak references are coming, https://github.com/tc39/proposal-weakrefs https://github.com/tc39/proposal-weakrefs
    - zwetan 6y ago
      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 https://github.com/WebAssembly/design/issues/1251 [1]: https://github.com/emscripten-core/emscripten/issues/5196 https://github.com/emscripten-core/emscripten/issues/5196
      - pjmlp 6y ago
        Yes you can, polyfill using WebSockets. It would require a server component as gateway, so what.
- coopsmgoops 6y ago
  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.
- Sophistifunk 6y ago
  Preaching to the choir my friend, this is the correct path.
bogwog 6y ago
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.

pjmlp 6y ago

Hence WebAssembly + WebGL/WebGPU.

zwetan 6y ago
WebAssembly not gonna give you access to syscall that are simply not there in the Web API
- pjmlp 6y ago
  Text metrics, the graphics engine implemented on top of WebGL/WebGPU does it itself. Weak references are coming, https://github.com/tc39/proposal-weakrefs https://github.com/tc39/proposal-weakrefs
  - zwetan 6y ago
    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 https://github.com/WebAssembly/design/issues/1251 [1]: https://github.com/emscripten-core/emscripten/issues/5196 https://github.com/emscripten-core/emscripten/issues/5196
    - pjmlp 6y ago
      Yes you can, polyfill using WebSockets. It would require a server component as gateway, so what.
coopsmgoops 6y ago
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.
Sophistifunk 6y ago
Preaching to the choir my friend, this is the correct path.

bogwog 6y ago

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.