Harman + Plugin Flash Player

:slight_smile:
https://services.harman.com/partners/adobe
https://vimeo.com/440710761

6 Likes

I don’t want to be a killjoy but this tech

  • is not for the general developers
  • is quite a few many complicated steps to install for the end-user
  • it is slow, to the point where you really notice it
  • it has limitations, it does not support everything

so I get it, they made a product, and they try to promote it blah blah blah
but still they are claiming stuff that are not true

this part in particular

This means 100% compatibility with Flash.

I believe it is just “one more option”, whoever is willing to pay will certainly have their reasons for investing in this technology.

1 Like

Again, not trying to be a killjoy but I’m allergic to bullshit

so first, why are you associating https://services.harman.com/partners/adobe
to Cheerpx and/or Cheerpx Flash ?

unless I misread something, those are 2 different thing and Harman is not directly involved

there https://medium.com/leaningtech/announcing-cheerpx-for-flash-a-solution-to-extend-the-life-of-flash-applications-post-2020-8fd35483ee35

under Licensing there is only this mention about Harman

For organisations interested in self-hosting CheerpX for Flash, a redistribution licence for the Flash Player also needs to be procured from Harman. Leaning Technologies can make the right introductions and facilitate the conversation with Harman.


OK, so let be very clear

  • Harman, as part of their services to support Flex and Flash-based applications by enterprises
    propose different solutions

    • migrating their Flash-based application to HTML/JavaScript solutions
    • “Packaged Browser" solution
    • AIR SDK
  • Leaning Technologies, in their different products propose

    • CheerpX (in general)
    • CheerpX for Flash (in particular)

That’s two different companies with totally different products.

Because Harman continue to support the Flash and AIR runtimes, an enterprise that need to redistribute the Flash player have to license the rights to do so with them.

Those different products target the enterprises, it is not for the general public or end user.


You should read more in details Announcing CheerpX for Flash, a solution to extend the life of Flash applications post-2020

The complexity is not on the flash developer integration work, it is about the deployment, see the part " Deployment of CheerpX for Flash".

A server need to deploy those 7MB for each users, either on the cloud or self-hosting
so this part

We have been using this deployment method for our Java to HTML5 tool CheerpJ for several years, having currently an average of ~600,000 unique users per month, with no downtime ever recorded to date.

it’s cute, but if you look around all those flash developers who know how to deploy a SWF on a server, they don’t necessarily know or want to serve 7MB of “webassembly runtime” when self-hosting

so yeah there is the cloud hosting too, but this I doubt it will be free

but anyway not everything seems ready yet, we’ll see

the main problem is that Leaning Technologies think they can solve all the problems with their tech CheerpX.

When I mentioned “it has limitations, it does not support everything”
I’m talking about the webassembly tech itself

so

yep, but it can not be achieved

I gonna take an older publication about CheerpX to illustrate
Porting a C++ multiplayer game to the Web with Cheerp, WebRTC and Firebase

so trying to explain steps by steps

for deeper references look at MDN WebAssembly

first, webassembly is just some kind of special code format that the browsers can execute particularly fast

see under WebAssembly Concepts

WebAssembly is a new type of code that can be run in modern web browsers and provides new features and major gains in performance. It is not primarily intended to be written by hand, rather it is designed to be an effective compilation target for source languages like C, C++, Rust, etc.

but webassembly is not magic, it does not give access to system calls that you can not access from the web browser in the first place

even if you use webassembly you still depends on the Web API
and so if those API do not give you access to UDP sockets then you can not use UDP sockets

so what CheerpX is doing?
they emulate those system calls and/or re-implement them with Web API

the “Porting a C++ multiplayer game to the Web with Cheerp” code
depends on libraries to emulate the game, one of them is cheerpnet
and you can find the sources there leaningtech/cheerpnet

in cheerpnet.cpp
you can see how they re-implement/emulate different calls like socket(), bind(), sendto(), recvfrom(), etc.

I simplify a lot, but in short CheerpX

  • is a x86 to WebAssembly virtualization technology
  • can virtualize native executables or full operating systems
  • can run any x86 application, fully client side

they use the same principle to emulate many system calls that are not available to webassembly, to the point where they created a “virtual machine” that can execute a x86 executable

the Flash Player plugin is a binary that depends on those system calls too
and so CheerpX for Flash
is basically a x86 VM that host a webassembly version of the Flash Player plugin (another VM)

and that’s why it is slow, it is a VM emulating a VM that is emulating yet another VM … yeah that’s 3 VM chained to each other

So yeah, it looks like it will support everything the Flash Player can do, they did not re-implement it, they run it in emulation, so it should support everything right?

on their page they do say

supports networking, file access and many other Flash APIs

so when a flash dev will use flash.net.DatagramSocket (not possible in the Flash Player but let assume it is for the sake of the example)

this DatagramSocket class depends on native class implemented in C++, let’s call it DatagramSocket.cpp, and this C++ class depends on system call to be able to work
the same ones: socket(), bind(), sendto(), recvfrom(), etc.

the flash user code use DatagramSocket (the SWF file),
which then call some native class in the Flash Player plugin (x86 executable, CheerpX for Flash)
which then call system calls like socket(), bind(), sendto(), recvfrom(), etc. (CheerpX)
which then call the webassembly emulation layer that under the hood re-use the Web API WebSocket.

the bytecode of the SWF is interpreted by the Flash Player VM which is then interpreted by the x86 emulation of CheerpX which is then webassembly interpreted by the browser

And that’s where I call bullshit

Sure, CheerpX tech in itself is quite a feature but it is still the same problem,
those guys bet so much on the web that they do think that the web can do and run anything

except that the web is limited, you can use JS or webassembly or whatever you want
the code will only have access to the Web API that the browser implements

you can not use real UDP sockets (or TCP sockets for that matter)
but you can emulate (kind of) with the WebSockets

my guess is that “CheerpX for Flash” is a specialised version of “CheerpX”
so they can hook to specific API, maybe they can replace “SharedObjects” API with the Storage API at a higher level than the system calls

but no matter what, for some API they will hit a wall because they will not be available at all

and funnily enough, when browsing those MDN links I saw this


MDN-Browser-Compatibility-Report-2020.pdf

webassembly will not magically solve those problems

so yeah

“A solution to run 100% of Flash post 2020.”

kind of misleading


I was not trying to be negative, but I call a cat a cat

I don’t have a lot of time so I might be a bit blunt (or don’t take the time to sugar coat it)
but it does not come from a bad place

  • is not for the general developers
  • is quite a few many complicated steps to install for the end-user
  • it is slow, to the point where you really notice it
  • it has limitations, it does not support everything

so I get it, they made a product, and they try to promote it blah blah blah
but still they are claiming stuff that are not true

unless I misread something, those are 2 different thing and Harman is not directly involved

That’s two different companies with totally different products.

Those different products target the enterprises, it is not for the general public or end user.

so yeah there is the cloud hosting too, but this I doubt it will be free

When I mentioned “it has limitations, it does not support everything”

yep, but it can not be achieved

but webassembly is not magic, it does not give access to system calls that you can not access from the web browser in the first place

those guys bet so much on the web that they do think that the web can do and run anything

but no matter what, for some API they will hit a wall because they will not be available at all

webassembly will not magically solve those problems

kind of misleading

I was not trying to be negative, but I call a cat a cat

:slightly_smiling_face:
Ok… now I understand.
Thank you so much again.

PS: I edited the post to prevent the information from confusing other users.

Sep 25, 2020 :+1:

2 Likes

I spoke to the CheerpX guys about a year ago, they said they would offer solutions to route low level Flash API calls to suitable alternatives or simulations. The appeared pretty confident, I am not sure whether this will be true or not. There was also talking of workers, sockets, encoders, etc.
I really have no idea, but being optimistic I like to believe it might be true, or at least partially true :slight_smile:

1 Like

This also makes me think. Is it very different from the WebGL Unity target? Also Unity exports a WebAssembly version (with a little bit of javascript initialization). Couldn’t this be a conversion of the Unity player to run in WebAssembly just similarly to CheerpX virtualization? Just guessing…

Whatever , It probably took another 5 years to make WASM as a thing.

WASM’s performance today is just like Flash in circa 90s, read: WASM is CPU intensive.
While Flash uses less resources at least from FP 10+.

Web App is dead, it is buggy by default.
Glad we have AIR for mobile target because thats where the end users are looking for apps more often than web apps.

1 Like

see MDN Browser Compatibility Report 2020

I would not say it is dead but it is not the ideal rosy path that some people promote
in the report you can see people complaining about SPA :joy:

the main problem with web app and WASM is some people do think it can replace absolutely everything

those are interesting times because around 2010 it was “look!!! HTML5/JS can do everything that Flash does”, except 10 years later the results are not really there

don’t forget the desktop, it still has tremendous value even if less high in view

personally I did bet long time ago on the server-side with Redtamarin, I still believe in that bet
if there is one thing that most dev team underestimate is that: server-side, backend, etc.

today you have ~80% PHP and ~10% ASP.NET and few others
see: Usage statistics of server-side programming languages for websites

2 Likes

yet, lots of people also said that PHP is dead :laughing:
whats wrong with people today, when new tech arrives they mostly said old tech dead/obsolete etc…
I’m surprised that Ruby is also used alot

1 Like

It’s part of the Kali Yuga.
It used to be grandparents teaching grandsons, now it is grandsons making grandparents feel obsolete because they can’t and couldn’t care less about using TikTok.
The dictatorship of 20 something know all :smiley:

Whoa… It seems this pattern has already been with us in our life.
The “…making grandparents feel obsolete…” -part is an enlightenment for me that I’ve never realize before

1 Like

It used to be grandpa teaching us how to hunt, read, think…
Now it’s little grandson teaching grandpa how to use an Ipad…
I find this sad :slight_smile: especially comparing the importance of the things grandpa would teach us, with the ephemeral knowledge of technology.

COBOL is another case. It feels obsolete but the fact remains shocking that many banking institution still using it today.
Business doesn’t care what is exciting , they care what is useful :laughing:

1 Like

I wish they would do it more :slight_smile: hopefully one day AS3 will benefit from the same treatement.
Hopefully there are already grandpas out there teaching COBOL to their grandsons :smiley:

1 Like