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.
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)
SPDY is shit. It's complicated with its own hacks like a hardcoded compression prefix that saves on order of a hundred bytes per connection (web pages are pushing 1 MiB and google are hacking out a few bytes). It doesn't proxy well, and on top of that in practice it's the same speed as pipelining.
NaCi hopes to fix the application part. ... Those guys got Quake 2 (was it?) running
Main problem with NaCl is that it secures the code but not the APIs. Every API in NaCl has to verify all its parameters just as well as an operating system call does, meaning with any large API set there will be security flaws. Another big problem is the code doesn't run on different architectures (even if they get the LLVM compiler integrated it won't run well). A probably problem is that it relies on hardware hacks that are unused in normal programs, and if some security research discovers flaws in how CPUs implement segments etc then those CPUs will need to emulate the code.
In other words it's possible for NaCL to be a net good, but unlikely.
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
Didn't Google work on something like this recently? It wasn't Go, something else I think.
You mean Dart.
Dilbert RSS feed
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.
SPDY is also non-standardized and Google keeps changing the details. Basically, the standard is however Google's implementations happen to behave, and only the client side of them is open. The Firefox developers are working on an implementation but kept running into issues because of this.
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.
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).
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.