Linked by David Adams on Fri 30th Nov 2007 19:18 UTC, submitted by pablo_marx
General Development ES is a fairly interesting looking open source research OS created by Nintendo. Runs natively on x86 (and qemu of course), kernel is written in C++, uses an ECMAScript interpreter for all of the userland, uses Cairo for graphics, and even has a port of Squeak.
Thread beginning with comment 287760
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Why?
by meianoite on Fri 30th Nov 2007 20:19 UTC in reply to "Why?"
Member since:

Why on earth? And why using such choice of technologies?
Squeak? Javascript? FAT as filesystem? this is horrible!

Simplicity and broad adoption.

(yeah, broad adoption; Squeak is *big* at Disney.)

Doesn't seem at all like a wise choice for a next-next-gen system.

What makes you think it's a next-gen system? It's a research system. And you know what my suspicion is? That's Nintendo answer for homebrew apps on the Wii.

FAT access for the SD card: check.
Interpreted languages to sandbox the development away from the "crown jewels" (i.e., the encryption keys), and to ensure portability between the development environment and the target environment: check.
Use of a graphics library that can make great use of hardware acceleration: check.

But of course I'd rather have Lua instead of Javascript; Lua is much, *much* bigger among the game development community, so it's definitely a wiser choice. Maybe in the near future, who knows?

Sony had already too much trouble forcing developers to use Linux as developer platform and only valid devkit, so most ended up using CodeWarrior.


I think you're mixing the facts here.

Apple had already too much trouble forcing users to ObjectiveC.

Uh... Noooo? The only Carbon apps you see nowadays on Mac OS X are those based on large existing codebases that started back on Mac OS 7, like those by Adobe and Microsoft, and apps ported over from Linux and use the eventual toolkit that doesn't bind to Cocoa (like Qt), but those are really few and far between (and to be honest I've never seen a single native Mac OS X app based on Qt).

Not a *single* interesting Mac OS X-exclusive app is written in Carbon.

Not going to work!

Careful, you're talking about Nintendo here. You know, that little company in Japan that simply prints money out of a little thing called Nintendo DS, as if the Wii wasn't enough? ;)

Edit: the obligatory Lua pimping ;)

Edited 2007-11-30 20:21

Reply Parent Score: 12

by mook on Sat 1st Dec 2007 08:15 in reply to "RE: Why?"
mook Member since:

I think their choice of JS bindings may be related to their other choice of using (WHATWG/HTML5) CanvasRenderingContext2D (from <canvas>, initially from WebKit IIRC). Not sure which influenced which, though.

With some small bootstrapping, you can actually write something that will run in a browser, then copy the code over to this thing - using whatever debugging utilities that already exist for browsers.

JS as a language is.. well, at least more widely available than <canvas>. (Think Acrobat, Flash, WSH, kjs...) I have no idea if they wrote their JS interpret from scratch, though; it sure looks like it.

Reply Parent Score: 1

RE[2]: Why?
by stew on Mon 3rd Dec 2007 13:49 in reply to "RE: Why?"
stew Member since:

> Not a *single* interesting Mac OS X-exclusive app is written in Carbon.

Finder? ;)

Reply Parent Score: 2

RE[3]: Why?
by meianoite on Mon 3rd Dec 2007 16:28 in reply to "RE[2]: Why?"
meianoite Member since:

>> Not a *single* interesting Mac OS X-exclusive app is written in Carbon.

>Finder? ;)

I thought we were discussing 3rd party apps? Because I assume Apple itself would have no problem with either languages. Or even Pascal, were it supported on OS X, for the matter.

Anyway, the point is not about Apple, it's about the marriage between language and functionality. For all I care Es could support a single language, and it could be BASIC, Forth, Lisp, Eiffel, Haskell, #!/bin/sh, C++, Dylan... All those languages by themselves amount to rigorously nothing, but the tools written around them to enable sane development, these do.

For a console-restrained OS with a focus on homebrew games (remember, a wild guess), I think something like Java makes a lot more sense than Smalltalk (and people that know me know I'm a strong proponent of Smalltalk, although I think polishing Squeak with more and better antialiasing wouldn't hurt, and neither would an improved dynarec), but not your average Java implementation, mind you. People would have to remember it's a constrained, embedded environment, and the current "best practices" in RAD that ignores tight memory management are simply non-starters there.

While we're going wild with suggestions and hypothesis here, I'd vote for porting Blender and its gaming engine, albeit with Lua instead of Python. That would be way cool.

Reply Parent Score: 2