How can I load the AIR runtime as a in-process shared library from a C program

Question

I'd like to build a special AIR launcher program in C along the lines of java.exe.

I've looked at running AIR programs with a process viewer and was able to locate the AIR runtime DLL that is being used. AIR programs are different than Java in that they are installed as platform-specific executables that bind the AIR runtime as an in-process shared library once they're launched (their icon is double-clicked by the user).

Well, I want to make an AIR launcher that is instead like the java.exe.

The java.exe is launched as a platform OS process that binds to the Java JVM runtime (JRE) as an in-process shared library. The java application that is to be executed is specified as a command-line argument to java.exe. Once java.exe is running and the JVM is fully functional, the specified java application class is loaded by the JVM class loader for execution. That specified Java application then takes over, in a sense "hijacking" the process of java.exe. Of course, the specified java application shows up in any process listing as the java.exe program that host it.

I want to make AIR app launching work like this. Why? So I can explore ways to hack AIR and perhaps overcome some of its many, many deficiencies. For instance, for starters I want to extend the AIR runtime experience with some new APIs that become available to the running AIR application.

My first order of business would be to:

• Implement a binding interface of ActionScript3 to C that is comparable to .NET PInvoke
• Add an API for process launching that is comparable to the APIs found in Java SE for doing this (Runtime.exec, ProcessBuilder, Process)
• Add support for an AIR application to be able to interact with stdin, stdout, stderr. Strangely, though Adobe added support for local file access in AIR, they have omitted interaction with these standard file pipes (yet they are found on any OS platform that AIR supports).
• Implement support of AMF over stdin, stdout, stderr - so AIR (or Java or any AMF capable language) apps can interprocess communication via exchanging AMF objects. This would add a touch of Microsoft's PowerShell to AIR.

Currently Merapi provides a AMF bridge with Java, so that demonstrates the efficacy of this. Alas, Merapi has to use a localhost port and socket for doing the interprocess communication - which is a clumsy way to go relative to using stdin/stdout/stderr interprocess pipes instead.

Answer 1

It sounds like you want to do some very hardcore AIR hacking. I don't think hosting the AIR runtime in your own process will be very easy. But you might consider embedding the Flash Player ActiveX Control. Since it is just a COM object, any COM application can CoCreateInstance() the Flash Player. The COM interface is not well documented, but here are some examples that might be helpful:

• F-IN-BOX is a developer's library to enhance Macromedia Flash Player ActiveX features. It does not use its own engine to display movies but provide a wrapper around official swflash.ocx/flash.ocx code instead.
• How to embed Flash Player ActiveX using BoxedApp SDK

If you want to get even lower level access, you could embed the open-source Tarmain AS3 VM. The code has an example command-line shell called "avmshell". If you build the Tamarin VM yourself, you can add new ActionScript classes implemented in native C++. Tamarin (and the Flash Player) implement many of their features using this "AVM Glue" between AS and C++.

Answer 2

What my question posed attempting to do turns out to be prohibited by Adobe (so far as any potential commercial use):

From the Adobe® AIR™ Runtime Distribution FAQ:

Distribute or use the Adobe AIR runtime, installer files, or extracted installer files in an undocumented manner or purpose. For example, you may not distribute, call directly, or write wrappers for any of the Adobe AIR libraries or runtime components within your software application. Runtime.dll, Runtime executables, template.exe, and template.app are examples of Runtime Components.