Slashdot Mirror

← Back to Stories (view on slashdot.org)

MAME Running In Chrome

Posted by timothy on from the ok-now-iterate-and-1-and-2-and-switch dept.

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

19 of 165 comments (clear)

  1. Is Google trying to fragment web? by SharkLaser · · Score: 5, Insightful

    We had that shit before with ActiveX. We need standards, not some stuff that only works in Chrome. However, I guess it's better for Google - now they have something that only works with Chrome. So when new users go to some web site it will say that they need to download and install Chrome to use it. Old users will also be locked to Chrome.

    Don't do that. Only use standards like HTML5 that work in every browser.

    1. Re:Is Google trying to fragment web? by errandum · · Score: 5, Informative

      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)

    2. Re:Is Google trying to fragment web? by SharkLaser · · Score: 3, Informative

      I'm talking about Native Client, not MAME per se.

    3. Re:Is Google trying to fragment web? by JanneM · · Score: 4, Insightful

      "write once, run everywhere"

      Write once, run in Chrome.

      You really want to return to the days when sites required a specific browser to let you in?

      --
      Trust the Computer. The Computer is your friend.
    4. Re:Is Google trying to fragment web? by deniable · · Score: 3, Insightful

      Java programs = JVM programs Java support in the browser creates incentive to write Java applets: write once, run everywhere. Been there, done that. Didn't get a t-shirt.

    5. Re:Is Google trying to fragment web? by kangsterizer · · Score: 4, Informative

      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.

    6. Re:Is Google trying to fragment web? by StripedCow · · Score: 4, Insightful

      Java is much more high-level, because it integrates a garbage collector in the VM. This is what makes it a sluggish memory hog.

      NaCl does not do that. It allows lean-and-mean code. It is basically like a lightweight version of VMWare/VirtualBox sitting in your browser.

      --
      If Pandora's box is destined to be opened, *I* want to be the one to open it.
    7. Re:Is Google trying to fragment web? by raburton · · Score: 5, Insightful

      > 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

      The browser is your platform, that's the whole concept behind moving everything to web based. That's a good thing if you take the traditional view that the OS is the platform - now you can run any old OS you like (with a standards compliant browser) and you'll be able to run the apps.

      This doesn't make you platform independent though, it makes you OS independent - all you've done is just redefined 'platform'. While apps only use standards you maintain independence. As soon as they use non-standard extensions you are no longer independent and now you are limited again. In this case you are limited to Chrome.

      In this respect it's really no different to ActiveX. Just because google have published the workings of this doesn't make it a standard and there is really no reason for all other browsers to implement it. And if it isn't a standard and isn't available in all browsers people working with it will be forcing their choice of platform on their users and we're back to where we started. Why don't we all just run Windows and use ActiveX?

      Richard.

    8. Re:Is Google trying to fragment web? by Justin_Schuh · · Score: 5, Informative

      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.

    9. Re:Is Google trying to fragment web? by FrangoAssado · · Score: 3, Informative

      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.

  2. Amazing! by Gaygirlie · · Score: 3, Informative

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

  3. Summary by Anonymous Coward · · Score: 5, Interesting

    - They had to adapt the makefiles because they didn't support cross-compilation. However they did that by using ad-hoc hacks specific to Native Client rather than doing it the right way: they still compile stuff that should be compiled for the host for the target, and then run it on the host with an emulator. They also chose to remove use of makedep entirely, meaning their "port" is not something that anyone can keep or that could be integrated upstream. It's something you can throw away once finished, and that you'll need to redo whenever a new version gets released.

    - Native Client runs applications in a minimal virtualized operating system for sandboxing, that only has partial POSIX support and doesn't even have support for the libc fopen/fclose functions (at least this is what the authors claim -- googling about Native Client says it supports POSIX file I/O just fine, and C I/O should be the obvious thing to come with it). The provided libc implements many things as macros, which is a cause for several conflicts. The sandbox also disallows certain classes of instructions because they are "unsafe", and in particular most uses of inline assembly are likely to not work (again, this is what the authors claim, googling says native client supports hand-coded assembly code just fine).
    Again, the modifications they did to the code was very ad-hoc and is not proper support for an extra operating system in the MAME codebase, and is therefore not suitable for inclusion upstream.

    So finally, they claim something was "relatively challenging" and they did it "in 4 days". This is quite contradictory, if it was challenging it would have taken significantly more time. In particular, for most software, it is not uncommon to take several months to port to another platform, and typically takes much more work than what they've done.
    What they did is adapt a piece of cross-platform software to work on an extra platform that is very similar to one other platform it already supports. The process in doing so was fairly straightforward and accessible to any software engineer. They did it quickly and badly, preferring ad-hoc hacks over good software architecture. They didn't fully port it and disabled significant parts of the software and reduced its performance.
    Not really a great achievement.

    1. Re:Summary by BasilBrush · · Score: 3, Insightful

      I'd tend to go with what "the authors claim" rather than your Googling, since this port was done by Google engineers working on Native Client. If they don't know what it does and doesn't do, no one does.

      Resume of the person who posted the method of porting:
      http://muth.org/Robert/resume.html

      You're probably right that they went for a quick and dirty approach rather than future maintainable port. But why not, if that is what met their objective? They obviously want to test/prove/demonstrate the capabilities of Native Client. They can do that by just getting MAME running and pointing to it. It isn't their job to take much longer (several months in your estimation) to make it fully maintainable.

  4. party like its 1999 by Anonymous Coward · · Score: 4, Interesting

    Sorry, this comment requires Google Chrome 11.56258772331 with WebGL and VP6 installed
    Click here to go back
    Click here to visit webring

    The internet, 1 step forward, 2 steps back, feet together

  5. Because it's smaller than Windows by tepples · · Score: 3, Insightful

    Microsoft lets other browsers implement ActiveX too if they want to. But they don't.

    Because they'd have to reimplement the entirety of Windows.

    Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?

    Because the Pepper API is a much more achievable target than the entirety of Win32.

  6. Two BIG differences between NaCl and ActiveX by YA_Python_dev · · Score: 5, Informative

    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.

    --
    There's a hidden treasure in Python 3.x: __prepare__()
  7. Linux in Native Mode? by rossjudson · · Score: 3, Funny

    I wonder who will construct the crazy mobius loop of running Linux in Chrome's native mode? It'll be google-colored turtles all the way down.

  8. MAME and ROMs by CanEHdian · · Score: 3

    I love MAME and have been using it (on and off) since the very early MS-DOS days. The problem with MAME is that most of the needed ROM dumps are still copyrighted, and will remain under copyright for a very, very, very long time and it remains to be seen when they will enter the Public Domain, if at all.

    The MAME community should be on the forefront of the Copyright Term Reduction struggle; freeing up ROMs should be a major goal. Some ROMs, with Exidy being the Shiny Example, have been made available to us, but everything that is not listed here should be treated as suspious if not downloaded from a trusted source.

    --
    When the copyright term is "forever minus a day", live every day like it's the last.
  9. Re:ActiveX is non-free by aloniv · · Score: 3, Interesting

    The difference is that Windows is non-free and chromium-browser is free software. (Google Chrome is chromium-browser plus Flash and a couple other minor non-free bits.)

    Actually chromium-browser isn't entirely free software:
    http://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser