MAME Running In Chrome

← Back to Stories (view on slashdot.org)

Posted by timothy on Saturday December 31, 2011 @10:58PM 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."

34 of 165 comments (clear)

Min score:

Reason:

Sort:

Is Google trying to fragment web? by SharkLaser · 2011-12-31 22:58 · 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 · 2011-12-31 23:07 · 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 · 2011-12-31 23:31 · Score: 3, Informative
  
  I'm talking about Native Client, not MAME per se.
3. Re:Is Google trying to fragment web? by JanneM · 2011-12-31 23:39 · 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 · 2012-01-01 00:07 · 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 supersat · 2012-01-01 00:11 · Score: 2
  
  I've thought about this a fair amount and have come to the conclusion that Native Client is not at all like ActiveX.
  First, ActiveX targeted the Win32 APIs, ensuring that it only works under Windows. Native Client now uses the new Pepper APIs (which is a replacement for the old Netscape Plugin APIs) and runs under Windows, OS X, and Linux.
  ActiveX relied on users to decide if a plugin is trustworthy. Native Client uses a sandbox to prevent code from doing anything that a regular web page couldn't do.
  Work is underway to make Native Client work across multiple architectures. While x86, x64, and ARM are all supported today, soon you'll be able to build LLVM binaries that can be run on any architecture.
  Microsoft's interest in ActiveX was tying web applications to Windows. Google's interest is in moving the web forward. After all, the more capable web applications can be, the better positioned they are to compete with traditional desktop software.
  Google has long experimented with non-standard APIs in order to stimulate progress. For example Google Gears added geolocation, local databases and storage, background workers, and more. Due to the success of Gears, all of these are now in the HTML 5 standard. I think Google will pursue standardization of Native Client when it's more mature. In the mean time, it's giving people a glimpse of what web apps can be.
  (And just to give Microsoft some credit, they sometimes move the web forward too. For example, they enabled AJAX with their XMLHTTP object in IE, which was later standardized as XMLHttpRequest.)
6. Re:Is Google trying to fragment web? by BasilBrush · 2012-01-01 00:23 · Score: 2
  
  MAME is one example of a complex C program hard to translate to Javascript but could be ported easily (4 days) to the Native Client platform.
  Just because it was done in 4 days doesn't mean it was easy. They said themselves it was relatively challenging. And reading through their description of how many things that MAME does are not supported in Native Client, it does indeed look challenging.
  This was done by a team of damn good engineers.
7. Re:Is Google trying to fragment web? by kangsterizer · 2012-01-01 00:31 · 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.
8. Re:Is Google trying to fragment web? by SharkLaser · 2012-01-01 00:36 · Score: 2
  
  That still doesn't change anything. Microsoft lets other browsers implement ActiveX too if they want to. But they don't. Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
9. Re:Is Google trying to fragment web? by icebraining · 2012-01-01 00:39 · Score: 2
  
  The source is not sufficient. A standard should be discussed and developed in partnership with the other parties, not just "here's a code dump, take it if you want".
  
  --
  Dilbert RSS feed
10. Re:Is Google trying to fragment web? by MichaelJ · 2012-01-01 00:55 · Score: 2
  
  it is highly secure as the code is analyzed before executing to make sure it won't do anything macilious.
  That's not highly secure. That's a challenge.
  
  --
  
  Michael J.
  Root, God, what is difference?
11. Re:Is Google trying to fragment web? by StripedCow · 2012-01-01 01:02 · 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.
12. Re:Is Google trying to fragment web? by raburton · 2012-01-01 01:04 · 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.
13. Re:Is Google trying to fragment web? by hairyfeet · 2012-01-01 01:17 · Score: 2
  
  Uhhh...because no matter how smart Google engineers THINK they are the malware writers are smarter? As the first poster said look at the history of ActiveX. When it first came out it was like a Godsend, an easy to use way to just host an app on your server and have ALL the branches instantly have access to it or to do the same for your customers. No rollout headaches or compatibility problems it all "just worked" but before you could say "Oh shit!" every malware writer and his cat and his cat's squeaky toy figured out how to get around the security and use it as a one stop malware drop. MSFT spent something like 4 years trying to plug the holes but it was like whack a mole.
  Personally I really really REALLY don't want native code running on my browser, thanks ever so. sandboxes can and have been broken out of and its just too risky a vector IMHO. While they've had a few sharp ideas (if anyone hasn't tried it chrome remote desktop makes taking control of a system for support work pretty damned simple) I really don't think this is the brightest idea they've had. I suppose we shall see but I wouldn't be surprised if the malware guys figure out how to jump out the sandbox just like they figured out how to get past FF's XSS protection and then this will be all kinds of nasty, especially on older systems that may not have all their patches up to date.
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
14. Re:Is Google trying to fragment web? by TeknoHog · 2012-01-01 01:24 · Score: 2
  
  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)
  AFAIK, the "native" in NaCl means that it is compiled for a given CPU architecture. It is probably independent of the OS, but you still couldn't run an x86 version on ARM, for example.
  
  --
  Escher was the first MC and Giger invented the HR department.
15. Re:Is Google trying to fragment web? by chrb · 2012-01-01 01:48 · Score: 2
  
  Microsoft never released the source code for free, though. The probability of uptake is higher if other browsers are given a free implementation.
16. Re:Is Google trying to fragment web? by Justin_Schuh · 2012-01-01 03:38 · 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.
17. Re:Is Google trying to fragment web? by ChunderDownunder · 2012-01-01 03:42 · Score: 2
  
  Well that's the strategy of ChromeOS. The browser is, effectively, the OS.
18. Re:Is Google trying to fragment web? by FrangoAssado · 2012-01-01 04:38 · 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.
19. Re:Is Google trying to fragment web? by FrangoAssado · 2012-01-01 06:48 · Score: 2
  
  There's a big difference between forcing everything to go through to committee, and having a strong leadership but with a "release early, release often" approach and seeking input.
  I don't understand your position. Are you suggesting no one should develop anything except in the open and accepting suggestions from anyone, or merely that it might be a good idea to be considered?
  Javascript surely would have benefited from input from other people. OR it would never have existed, because Netscape and others would be too busy deciding the features of the language to ship it with Netscape 2.0, and then someone else would do something else first. And maybe the CERN people, after receiving input from other parties, would think better and decide that a text-only protocol really was too simple to work for any serious data transfer, what were they thinking?
  In the end, it doesn't seem productive to try to dictate how innovation should happen. And we certainly shouldn't prevent people from doing new things a certain way because they *might* do it wrong.
The actual extension... by methamorph · 2011-12-31 23:15 · Score: 2

https://chrome.google.com/webstore/detail/kcfbijoldkenmemnbbkjnpdhnijgahck
Amazing! by Gaygirlie · 2011-12-31 23:19 · Score: 3, Informative

It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.
Summary by Anonymous Coward · 2011-12-31 23:51 · 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 · 2012-01-01 00:37 · 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.
party like its 1999 by Anonymous Coward · 2012-01-01 00:41 · 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
1. Re:party like its 1999 by YA_Python_dev · 2012-01-01 03:28 · Score: 2
  
  I get your point, but please note that WebGL is a web standard (implemented in Firefox, Chrome, Safari, Opera and Internet Explorer) and VP8 (I assume you mean VP8, the video codec used in WebM, and not literally VP6 that's obsolete) has multiple free/open source implementations and even its patents are available with very liberal conditions that make them compatible with free software licences.
  WebM unfortunately is not (yet?) part of the HTML standard due to strong opposition from Apple and Microsoft, but it's interoperably implemented in Firefox, Chrome, Opera, Safari and Internet Explorer (the latter two require the installation of the WebM codec in the OS, all other browsers just work out-of-the-box). It's also the thing that allowed me to not install a proprietary Flash plugin on my last two computers, so I kinda like it.
  Avoiding lock-in and proprietary techs on the intertubes is a very good thing, but neither WebGL nor WebM are a problem here, IMO.
  
  --
  There's a hidden treasure in Python 3.x: __prepare__()
ActiveX is non-free by tepples · 2012-01-01 01:44 · Score: 2

Why don't we all just run Windows and use ActiveX?
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.)
1. Re:ActiveX is non-free by aloniv · 2012-01-01 08:15 · 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
Because it's smaller than Windows by tepples · 2012-01-01 01:57 · 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.
Two BIG differences between NaCl and ActiveX by YA_Python_dev · 2012-01-01 02:47 · 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__()
Why is this important by YA_Python_dev · 2012-01-01 03:03 · Score: 2

It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.
It's not immediately obvious, but there are two advantages in having a program running in NaCl rather than directly on top of the OS:
1) portability: exactly the same code runs in any OS that has a browsers that supports NaCl (right now this means Linux, Mac OS X and Windows);
2) security: users can safely try running it even without knowing if MAME can be trusted (users often are not good at making security decisions); obviously this is not terribly important in this particular case since MAME is free software and is very unlikely to contain any malicious code, but even code written by the good guys can have security bugs that can be exploited if the thing is run directly on top of the OS. With NaCl you only need to keep a single program secure (the browser) to be protected.

--
There's a hidden treasure in Python 3.x: __prepare__()
1. Re:Why is this important by mounthood · 2012-01-01 06:39 · Score: 2
  
  You didn't mention the biggest benefit: no deployment hassles! Imagine taking a C/C++ app your company depends on and won't let go of, recompiling it to work with NaCl, and it's instantly distributed to all clients. Nighty changes would be easy for everyone. Caching is built-in. Troubleshooting an install is dead simple; clear the cache and click the link again.
  
  --
  tomorrow who's gonna fuss
Linux in Native Mode? by rossjudson · 2012-01-01 03:50 · 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.
MAME and ROMs by CanEHdian · 2012-01-01 05:35 · 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.