The Next Browser Scripting Language Is — C?

mad.frog writes to tell us that in a recent talk by Adobe's Scott Petersen he demonstrated a new toolchain that he has been working on (and soon to be open-sourced) that allows C code to be run by the Tamarin virtual machine. "The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there's some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM's "emulation" of memory to have only a minor overhead over the real thing. The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music."

Comments

Perl is Interpreted C

[Doc Ruby]

There's very little if any C code that can't be written basically the same for Perl to interpret it basically the same way. The exception is direct memory access, but there are ways. And besides, I'd rather access memory through an API that really manages it, like making it hard to unexpectedly overflow buffers or grant access to unauthorized other users.

I'd love a Perl interpreter embedded in my browser. I'd love to have a Perl API directly to the browser app and the browser documents' DOM. I'd love to have a "Perl commandline" that returns text like usual, or that works on remote data by URL, or that returns icons or other data displayable in the browser.

Javascript is a pain in the ass. I'd rather have a Perl engine, and all the Perl modules and scripts, to run against my browser the way I usually run against my terminal window.

Startup latency

[IamTheRealMike]

Being able to run Python or Quake inside a Flash VM sounds useful at first blush, but it seems you'd lose most of what makes webapps nice for both developers and users. In particular, C based apps are not designed to be streamed, whereas Flash or AJAX apps usually are (to some extent). Nobody wants to browse to a "web app" and then spend 5 minutes twiddling their thumbs whilst 20 megabyte of Python runtime or Quake is pulled down over the wire. Web apps just have a different DNA to desktop apps.

I can see this being used to accelerate computation-heavy subelements of a regular Flash app though. I wonder how much of this is being driven by a desire to run a Photoshop subset inside Flash?

Re:what?

[dgatwood]

I'd use C for everything if its string handling weren't so utterly broken. It makes sense from a pure performance, near-the-hardware perspective to handle strings the way it does, but what is desperately needed is POSIX standardization of stracat/stracpy. That one change would make it trivial to eliminate 99% of all buffer overflows in typical apps (and, ideally, kernel code)....

char *stracpy(char *src) Returns a copy of a string in a newly allocated buffer large enough to hold the result. char *stracat(char *string1, char *string2 ...) Returns a newly allocated string that contains the concatenation of two or more strings.

Sure, I could write my own, and pretty much everybody on the planet has done it at least once in their lives, but it seems ridiculous that such obvious operations require hand holding. Outside of embedded platforms where malloc is expensive, dynamically allocating a new buffer for concatenations should be the norm. For situations where performance takes a big hit because you can't afford to copy the source string every time, you could also add this API:

strbuf_t strbufalloc(char *src [, size_t size_hint]) Returns a copy of a string in a newly allocated buffer large enough to hold the result. The optional second parameter size_hint allows you to specify a suggested size for the buffer. strbuf *strbufcat(strbuf_t string1, strbuf_t string2 ...) Returns a newly allocated string that contains the concatenation of two or more strings. The value of string1 must be a string buffer (strbuf_t). The value of string2 may be either a strbuf_t or char **.

Wherein strbuf is opaquely defined as:

struct strbuf_private {
char *content; // null-terminated string
size_t length;
void *private_history_data;
};

struct strbuf;
typedef struct strbuf *strbuf_t;

and the routines automatically realloc the internal char * buffer as needed to grow the size to hold incoming content and likely future content based on historical data about prior operations on the structure, the algorithm for which would be an implementation detail outside the scope of the standard. That said, for the rare cases where a simple copy hurts performance badly enough for most folks to care, chances are your application knows its own growth policy better than the OS could guess anyway, so you probably should just roll your own buffer management code. The important bits to add to the standard are those first two functions (stracpy and stracat).

Easier way...

[Anonymous Coward]

chrome://browser/content/browser.xul

Firefox inside Firefox inside Firefox...