Slashdot Mirror
MAME Running In Chrome
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."
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.
https://chrome.google.com/webstore/detail/kcfbijoldkenmemnbbkjnpdhnijgahck
It's now possible to make a native client of MAME...which...already was native... uhhh, hmm.
In light of the discussion here:
http://yro.slashdot.org/story/11/12/30/2159200/doctorow-the-coming-war-on-general-purpose-computing
Let me say: Finally, general purpose computing coming to the web!
Besides, if this trend continues, we can finally be relieved of the quirks of web-browsers and just send our applications as-is, without any compatibility problems, and continuous maintenance due to continuously changing browser specs. Apps will JUST WORK (tm). About time.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
- 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.
No. Google are trying to create a new standard that hopes to replace application delivery on the web.
HTML and JavaScript is STILL too slow for anything useful.
The DOM is 10 kinds of pain in the ass to work with, especially when it comes to different renderers. W3Cs terrible instructions that led to a whole bunch of different values for input handling, inconsistent handling of CSS and a billion other things. (not to mention the ability for websites to BLOCK your own keyboard because some tube thought it was a good idea to prevent key presses to bubble up beyond the browser process. Escape should have been the general pause-all key, or, you know, PAUSE KEY, WHY DOES NOBODY USE THIS KEY)
NaCi hopes to fix the application part. That doesn't outright deny applications in the browser.
Those guys got Quake 2 (was it?) running in the browser using only web stuffs and an experimental API. And with the new Mouselock API, the ability to lock the mouse to a position will allow first person games to be done the right way, instead of having to batter your mouse by lifting and dropping it constantly to keep you centered. (or virtually doubling the dimensions of the canvas so a full circle can be done in a smaller area)
But that was running in a Canvas. (and using another API for 3D that has been disabled for security reasons)
It didn't have to deal with the terrible DOM system and the fifty billion attributes and conditions it needs to check in order to exist where it does.
So we have the DOM, which is just plain terrible, nobody can deny that. It is too big and complicated for its own good. Most people don't need what the DOM offers. Ever.
Then we have CSS, annoying again due to it being so strict, no decent inheritance control or rules / pattern matching (well, very basic) and a bunch of other problems, especially some attribute names/values.
Then we have JavaScript... I like JavaScript, but god DAMN is it a pain in the ass sometimes. The abilities of the language are nice, but the way it is expressed isn't entirely ideal for the language itself. (and we have to deal with the horrible inconsistency between browsers that still exists today)
The web was a nice idea. But stop trying to make it fit everything else. It wasn't built for it. (which is also why they created the SPDY protocol to replace HTTP, which nobody seems to be using either despite it cutting things in around half compared to HTTP, HTTP is literally hacks upon hacks now)
We need something to replace Java now that Oracle owns it and will destroy it.
Java was obtuse, stupidly bloated and old.
Didn't Google work on something like this recently? It wasn't Go, something else I think. It had some fantastic features.
It says "Package is invalid: Could not unzip extensions" on the latest Chrome beta (16) for me
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
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.)
This page makes me think NaCl is part of chromium-browser as opposed to being one of the few non-free things bundled with chromium-browser to make Chrome.
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.
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__()
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__()
Now that will speed it up and maybe make running games that used 3d chips run at a good speed or some kind of on it's own X86 VM for the games that used X86 cpus where you need to emu the input / security boards in them + maybe a 3d card.
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.
This is probably a project that some team at Google cobbled together during their sanctioned free time, no?. The methods used to execute the port are geek-worthy (the hurdles that they faced and how they cleared them - who isn't interested in the solution to a challenging problem?) This seems more like 'let's see if we can do this, and maybe we'll learn something useful while we're at it' (which is definitely geek-worthy), and not as much an attempt or even glimpse into a direction that Google is leading its browser.
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.
> relatively challenging
> took us about 4 days to complete
mfw
ActiveX Applications Running IE.
This is bad. There is no "sandbox". Not really. Get it through your heads people. Without hardware supported Virtualization, there is actually no "sandbox", the whole OS is there on the beach right next to my code, and I will figure out a way to interact with it in ways that you do not like.
For what it's worth: At least this isn't another JIT SNAFU. When you compile JS to a "limited" set of machine code instructions, then flag that DATA as CODE, and run it, it just takes one buffer overflow for me to get my "unlimited" machine code running on the metal. One more Kernel level exploit from there gives me Root... JavaScript is SLOW because it's so damn dynamic that it's hard to make fast... This means more complex compiler code to make it run faster, this means larger attack surface for exploits.
IMHO, Lua or other interpreted languages could probably be called sandboxed (so long as all the inputs to native functions are checked for sanity), but even then, it's not a hardware VM, it's not really a sandbox. Once you've allowed external code to run on the bare metal, ALL BETS ARE OFF.
While this makes for an interesting "what if" project, my understanding is that Google mainly designed NaCl for two reasons: to allow for writing plugins that are inherently sandboxed and to allow for snippets of performance critical Javascript to be written in native code. I personally think I have a better idea: invert NaCl's and Chrome's relationship. It's quite obvious that one of the focuses Chrome has had is on sandboxing itself to obtain a level of security. At the same time, a large point of what Chrome is is a multiplatform browser. Hence, NaCl, an inherent sandbox, running as a much smaller code base to run on multiple platforms provides a much better base to situate the coding of a browser. Furthermore, it'd strongly encourage further optimization of NaCl to be a viable, generic platform for other programs (not unlike what .NET's CLR was supposed to be) and the creation of sandboxes for more CPUs (AFAIK, there's still no NaCl-ARM). Best of all, if done right, it'd finally upset a core point of why people don't choose Linux as a platform; if developers had NaCl as a viable platform, then games could inherently run on Linux, Mac OS X, and Windows.
This concludes my New Years fantasy.
Eurohacker European paranoia, gun rights, and h
NaCl is designed to be portable to different browsers and OSes
But it is *not* designed to be portable to different CPUs. Try running NaCl MAME on your ARM or MIPS phone or on your PowerPC game console's browser - it won't work. This by itself makes NaCl unsuitable for the web. Not only can't we run it on non-x86 hardware now, it would make life harder for new CPU archs in the future.
(Yes, there is a research project trying to make NaCl portable to different CPUs. It is too early to tell if it will succeed, and what tradeoffs it will have in terms of speed, portability, code size, etc.)
Just run linux in javascript, someone did that and it is online. You now only have to install Chrome on it to perfect the loop.
Hey don't blame me, IANAB
There's all this bickering in this thread along the usual lines of programming nuances and security blah blah blah which is fine and good but how about for the people who just want to see how this thing does with a few of their favorite ROMs?
Anybody actually have this installed (preferably on a GNU-Linux installation) and care to point out how they went about it?
emscripten can compile C code, or anything that can produce LLVM bitcode, directly into JavaScript, allowing heavyweight code like Ruby/Python/Lua, physics engines, raytracing, FreeType, text-to-speech, etc. to run in a browser. JSLinux emulates the 386 instruction set to the point it can boot a stock Linux kernel, start a terminal, and run ELF executables like the Busybox command-line utilities in a browser (JSLinux's Fabrice Bellard could probably do MAME in JavaScript in his sleep one-handed.) So despite the innovations in Native Client, targeting JavaScript in an HTML5 browser is the way forward. And until Google implements Portable Native Client, NaCl doesn't even give you the ability to run in any Chrome browser, you need an architecture-specific executable. But portable NaCl is just running LLVM bytecode, and emscripten is already turning that into plain JavaScript without requiring a new black box in each web page.
Does anyone know if any of the native apps in ChromeOS/ChromiumOS and Android are written in NaCL or PNaCl? That would make some sense.
=S
Uh, MAME isn't 15 years old yet according to http://mamedev.org/history.html ... On 2/5/2012, it will be. Or did I miss something? :(
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
The NaCl Port of Mame is playable from the chrome webstore here:
https://chrome.google.com/webstore/detail/kcfbijoldkenmemnbbkjnpdhnijgahck
There are also more polished NaCl based games such as Bastion:
https://chrome.google.com/webstore/detail/oohphhdkahjlioohbalmicpokoefkgid
99%+ of Android devices use ARM so the current form of NaCL can't work (and it still doesn't actually work on the rest).
The Chromebook hardware can't run their current killer-app Bastion (not enough VRAM). They also really mean it when they say ChromeOS doesn't come with any native Apps. The is a small command line shell and SSH (sandboxed but not plain NaCL) and the Browser, nothing else.
Currently emscripten's graphics output is too slow to usefully run Mame. A more interesting project would be to compile NaCL with emscripten.