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."
Summary (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.
party like its 1999 (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
Re:ActiveX is non-free (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 [libreplanet.org]