Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Google Emulation (Games) Games Technology

MAME Running In Chrome 165

An anonymous reader writes to point out this interesting outgrowth of Google's Native Client: a Google engineer has ported MAME 0.143 to the browser-based platform, and written about the process in detail, outlining the overall strategy employed as well as specific problems that MAME presented. An impressive postscript from the conclusion: "The port of MAME was relatively challenging; combined with figuring out how to port SDL-based games and load resources in Native Client, the overall effort took us about 4 days to complete."
This discussion has been archived. No new comments can be posted.

MAME Running In Chrome

Comments Filter:
  • by errandum ( 2014454 ) on Sunday January 01, 2012 @07:07AM (#38555142)

    I don't see your problem. It's not like they won't be supporting the standard, investing on their platform (that they even consider big enough to be your whole PC UI).

    I, for one, like the idea that I can have desktop quality applications running independent of platform on my browser - and wouldn't mind if this became the standard. By uniting all OS'es under this platform, I don't believe that there is fragmentation (what exists now IS fragmentation)

  • Amazing! (Score:4, Informative)

    by Gaygirlie ( 1657131 ) <> on Sunday January 01, 2012 @07:19AM (#38555178) Homepage

    It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.

  • by SharkLaser ( 2495316 ) on Sunday January 01, 2012 @07:31AM (#38555220) Journal
    I'm talking about Native Client, not MAME per se.
  • by kangsterizer ( 1698322 ) on Sunday January 01, 2012 @08:31AM (#38555392)

    It's not a plugin. It's integrated in chrome. It's called NaCl aka native client.
    the mame emulator is just ran from NaCl just like you load a java applet when you visit the web, except that the java part would be integrated into chrome.

    it doesn't work anywhere else. do you call java applets loaded from - the web - local programs?

    And there are tons of emulators that work on the web *without* NaCl and which are fully open. Heck there's even a Linux emulator.None of which uses NaCl.

    Finally please note that you can't currently run NaCl properly on tablet devices. Also that's *Android* tablet devices, and no, they don't actually ship with Chrome yet.

    So you're entire post is very uninformed.

  • by YA_Python_dev ( 885173 ) on Sunday January 01, 2012 @10:47AM (#38555852) Journal

    1) NaCl is free/open source software, both the SDK and the client implementation in Chromium; ActiveX was proprietary and every program required to be signed by Microsoft to run by default;

    2) NaCl is secure (see this IEEE article [], it's very interesting) and designed to be portable to different browsers and OSes; you can safely run untrusted code, just like you would do with JavaScript; ActiveX required not only to trust that the controls weren't malicious, but also to trust that they all were free of security bugs: if only a single signed ActiveX control somewhere had a security bug, it could be exploited to p0wn Windows PCs (that's why Microsoft had a growing list of signed controls and another growing list of signed-but-blacklisted controls).

    Native Client is certainly not perfect, but please don't compare it to ActiveX. Entirely different beast.

    Disclaimer: I speak only for myself and not anyone else. IANARE.

  • by Justin_Schuh ( 322319 ) on Sunday January 01, 2012 @11:38AM (#38556164)

    I can appreciate your confusion, but comparing NaCl to ActiveX doesn't really make sense. Once you instantiate an ActiveX control it runs arbitrary code at your full user privilege. Whereas NaCl is much more accurately compared to the restricted execution environment of a virtual machine, such as Java, .NET CLR, or even JITed JavaScript. It's just that NaCl virtualizes a well-defined subset of an existing hardware instruction set, rather than one developed specifically for it. That virtualization (and the associated instruction validation) is the primary security mechanism, and is typical of a VM environment. The process sandbox is just a defense-in-depth measure (and a very strong one) layered underneath an existing VM sandbox.

    However, there's no reason to take my word for it. If you research it a bit you should find that NaCl has a comparable or (in most cases) a more robust security model compared to the web-delivered execution environments most people are already running.

  • by FrangoAssado ( 561740 ) on Sunday January 01, 2012 @12:38PM (#38556590)

    A standard should be discussed and developed in partnership with the other parties [...]

    A lot of standards we have today (Ethernet, HTTP, Javascript, to name a few) were born out of small groups of individuals with no input from other parties, at first. In each case, the new technology became a standard only after it was implemented and proven really useful.

    Demanding that every new technology comes out of a committee is insane: it's a great way to stifle innovation.

    Now, there is a danger about non-standardized technology: it can be very bad if the creator tries to use it to prevent everyone else from competing in the same area, like was the case with ActiveX. However, I don't see how that would be the case with NaCl: anyone can see how it works, take the code, make it work in any browser (or anything else), and change it at will with no strings attached -- it has a BSD license. It could be a problem if Google refuses to participate in an effort to make a standard out of it, when (and if) it becomes widely used and has competing implementations. But it's way too early to be worried about it -- currently, NaCl is a mere curiosity.

"Remember, extremism in the nondefense of moderation is not a virtue." -- Peter Neumann, about usenet