Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Next Browser Scripting Language Is — C?

Posted by ScuttleMonkey on from the a-home-for-all-of-that-old-code dept.

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."

7 of 375 comments (clear)

  1. am I the only one bored with the software world? by Anonymous Coward · · Score: 5, Insightful

    Everything's being constantly reinvented but no actual progress is being made. Oh look, the 100th toolkit to do exactly the same thing! Oh look, a new way of layering something old on something old on something old to give something new! Oh look, another silver bullet framework!

    Can anyone here remember the web of 10 years ago, for example? Content = text for reading + graphics for illustration. No bullcrap, just Google/Wikipedia style web sites to give me a simple navbar + content.

  2. Re:Right... by Nyall · · Score: 5, Insightful

    primary? ummm... I thought the primary point of layers is so that you can do a lot with only a few simple function calls

    --
    http://en.wikipedia.org/wiki/Jury_nullification
  3. Ah, the Memories... by Tickenest · · Score: 5, Insightful
    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.

    So Flash can simulating computing as it was back in 1998? Super....

    --
    This is the NFL, which stands for "Not For Long" if you keep making those bulls*** calls.
  4. Re:Browser-based OS by Hatta · · Score: 5, Insightful

    Well this just underscores how silly the whole web-application thing is. An application running on a browser is a silly idea for the same reason an OS running on a browser is. We already have operating systems to run programs on. Give us native programs, not some horrid mishmash of technologies.

    --
    Give me Classic Slashdot or give me death!
  5. Re:But is it secure? by ergo98 · · Score: 5, Insightful

    If the "byte array mapped to RAM" installed in Tamarin allows the code to store anywhere in the interpreter's space, that's a huge security hole. It can do anything the user process can do. If you're going to allow that, you may as well just load executable machine code directly, as with Active-X.

    You should email them and tell them about this! Surely they haven't though of such a thing!

    Sarcasm aside (sorry, I couldn't help myself), I suspect the VM needs to actually hand you a block of memory, and on accesses it validates that it is within the VM allocated range. Anything less would be silly, however such a thing would provide a huge win (I've tried to do image editing in pure managed code, and then found a massive performance win switching it over to P/Invoke native code).

  6. Re:Browser-based OS by bestinshow · · Score: 5, Insightful

    Not really. I do agree that native applications are nicer than web applications, especially if you compare, e.g., Google Docs to Office, or even WordPad.

    However what we have discovered is that (1) web applications are easier to write, and (2) it's nice having a consistent platform to develop to, even if that platform is mildly ridiculous (HTML + CSS + JavaScript + Browser-Workarounds + JavaScript canvas thing). Getting stuff to display and layout on this platform is easy, and simple to prettify, far easier than most native platforms have been in the past. There are also a dozen different ways to write the server side of things, and I think for many developers it is nice to be forced to split up the client interface from the meat of the system.

    Of course, things are going too far. What should be happening is the simplification of native application programming, with a common platform, etc, without the overhead of having to run a Javascript or HTML rendering engine, and native full-speed canvases. I think that Apple is getting there, QT and KDE4 may be getting there but I haven't really looked into that platform. Java should have gotten there but early design mistakes (AWT, Swing) have killed that off, and SWT is a last-generation UI library. Maybe something like Fenggui on Java might help this platform, but I think Java's dead on the home desktop (and extremely alive and profitable on the server).

  7. Re:Browser-based OS by Yold · · Score: 5, Insightful

    #1, Yes, it is hard to push out an application to every University computer when you are at one w/ 50,000 students.

    #2, see #1

    #3, everything is done on the server-side, and prior to AJAX, it was redone in Javascript on the clientside for a more responsive user interface. Now, both the client and server use the server-side procedure.