Wednesday, May 5, 2010

Practical applications to reverse-engineering

I find myself spending a lot of time reverse-engineering other people’s work. That is, it’s rather typical that clients have existing systems and frameworks where the amount of documentation is tragically inadequate. The trick is to learn as much as you can about the author(s) and then emulate what they’ve done. And although it’s rather cliché to say this, you really can learn a lot about a person by sifting through their code.

I was working on a project last year which involved developing work specifically targeted for the Nintendo Wii browser. Even though it is powered by Opera, it doesn’t behave the same way as its desktop cousin. The issues are compounded by the fact that there is no official documentation from either Nintendo of America, Europe or Japan; thus it was necessary to break down the issues myself. The full list is a lot more explicit so I’ll simply fire off some of the most glaring facts:

  1. There lacks metrical data to gauge the user's environment. The following issues remain unresolved:
    • There are different Nintendo Wii browser versions and they’re linked to firmware patches.
    • There are different versions of Adobe Flash for the Wii browsers. While one version of Flash can handle video well, the other doesn't.
  2. During the initial launch of the console, the Wii browser costed $5. Someone found a hack to enable one of the apps –which then allowed for a modified version of the onboard browser to run: The legitimate $5 browser had a different resolution than the hacked. In 2009, the decision was made to offer the Wii browser at no charge, but the divide was already set.
  3. What are the dimensions one can work with on the Wii browser? 800x600? No. An obscure width to the likes of 813px. What’s even more strange is that when the <BODY> has a CSS width of 100%, any <DIV> set to “100%” will be locked at 813px.
  4. The Wii has a feature that allows users to zoom in and out of the page. This feature – coupled with the onscreen menu — throws Javascript haywire because the viewable screen height constantly changes.
  5. Anchor tags <A> as well as tags which can be clicked (ie. adding the Javascript function "location" to a div) will always have a visible border around it. I've yet to find a CSS or Javascript solution to this unsightly issue.

From this experience, I can only conclude that web development experts weren’t initially consulted by Nintendo before the browser was integrated onto their console. Since I don’t personally own a Wii, the likelihood that I'd develop personal work for such a platform is very slim. In any case, good luck to all those who have an interest in it!

No comments:

Post a Comment