Blog: Wii homebrew developer discusses (/rant) the Wii SDK/OS-Architecture of the Wii

[Farid]

http://hackmii.com/2009/02/why-the-wii-will-never-get-any-better/#more-463

Nothing really new here, if you followed the technical talks about the Wii (or GC) SDK and software stack. But it might be interesting to those who are less au fait with the way the Wii "OS" work and yet wanted some X360/PS3-like OS features on the Wii.

The posts provides some examples, as well. Examples wich can be corroborated or refuted, if someone feels like greeing/disagreeing with the author on a point-per-point basis.

Excerpt:

This isn’t a coincidence [Lack of OS feature updates]. As it turns out, Nintendo chose not to have any operating system or common code at all running on the Broadway CPU. When you run a game, everything that shows up on your screen, ever, is being loaded from that spinning polycarbonate disc. And there are no mechanisms for anything else to run on that CPU: no update infrastructure, no Home Menu updates, nothing. If they ever want to have a “hypervisor” run above games, they’ll need to get a new CPU with full-blown virtualization capability (or an emulator), because games assume they have direct access to the CPU and most of the hardware.

[..]

As a specific example, let’s look at the much-discussed future ability to load Virtual Console and WiiWare titles from an SD card (seriously, what the hell were they thinking with 512MB of internal storage and no sane infrastructure to ever expand it externally?) There are three possible solutions to get this to work:

• Add FAT filesystem code to IOS retroactively, disabling any SD access for titles that launch from SD
• Add FAT filesystem code to IOS retroactively and push title updates for everything that uses SD, to remove the in-title FAT code and replace it with a new interface to IOS
• Just fake it and transparently copy titles to the Wii system memory when you want to launch them, causing more Flash wear and tear and longer launching times

Chances are they’re going to go for number 3. And the only reason 1. and 2. exist is because downloadable content access is implemented through a unified “application security” subsystem, which forced them to define a sort-of-standard interface for it. They wouldn’t have done it otherwise.