Creating Wii# (C# Homebrew Development) -- Possible?

So I've been looking to get into Wii homebrew for a while and I think now is the time. I'm very pleased with how far the community has come and I want to further it, in larger strides than just a single program if possible.

What I really want to do is make homebrew, using C#/.NET really easy. From what I can tell, Devkit seems to be the main way to go for homebrew, using C/C++. While that is fine, I'd like to use C#. From what I can tell, there are no real documented ways of getting it set up so I assume that it's not a common thing to do. Like I said, I'd like to change that.

Doing a little searching, I've come across ports for both ARM and PPC for Mono, as well as a straight Wii port. The last one gives me a lot of hope that much of the groundwork is already laid and its just a matter of piping everything up and writing wrapper classes to handle the underlying libraries, which I'd be more than happy to do.

I have also heard (and seen) that SDL is now working on the Wii, which is another great feat. I'd like to extend that to SDL.NET for the Wii (much like Tao has done) to create sort of an 'XNA' for the Wii.

I'm very familiar with C/C++ and C#, so I feel that even though it may be a large task for a single person to do, I'd be more than willing to do it in my downtime this semester.

I apologize if I am somewhat behind in the homebrew news and if some or all of this has already been accomplished, I'd be more than happy to know and try it out myself. If not, I'd like to make it a reality as I feel C# is an amazing language for robust, fast designs as well as SDL being a great library to boot.

I have subscribed to this topic but if any devs wish to be in direct contact with me, feel free to add me on MSN as I am on there quite often: ewrogers [at] gmail [dot] com. Just let me know you're from here so I can put you in the right group!

EDIT: Changed the title of this topic to better reflect my goals. I've done a little peeking around and it looks like starting with the Mono:PPC trunk might be the best bet.



Edited 2 time(s). Last edit at 09/03/2009 02:42AM by SiLo.

Quote
SiLo
What I really want to do is make homebrew, using C#/.NET really easy. From what I can tell, Devkit seems to be the main way to go for homebrew, using C/C++. While that is fine, I'd like to use C#. From what I can tell, there are no real documented ways of getting it set up so I assume that it's not a common thing to do. Like I said, I'd like to change that.

Do you know who OWNS .NET languages, we have had this convo before but with vb. C# is intergrated into the operating systems as of Windows 7, it would an inch from impossible to translate C# to c++ or c as many if not all functions in C# refer to the win32 api

Well one easy (and cheap) way to acheive that would be to map every base "System" classes of .NET to their equivalent in devkitpro in C++. Maybe "System.IO" as well... And then, when you wirte a user defined class in C# you convert it in C++ then you start the C++ compiler and you have your wii game......

The concept of a Framework like .NET is to have an abstract layer of what's happening in the OS to eg: read a file. If Microsoft implemented the framework with win32 API calls its because its the way it should be on computers, but if the wii dosen't required this to read a file, just do it the way the wii knows and you have done it in C#.



Edited 1 time(s). Last edit at 09/02/2009 04:02PM by holy_artefact.

Well,

Quote
Linked Site
To build Mono on the Wii, you will need a Mono 2.4 set of class libraries, and in addition to that, you will need to check out the Mono/Wii branch and the special wii support system (obtain this URL from Novell)

Bummer, every big open-source project is spoiled by a software giant... this time Novell...

Guess you should continue from the ppc-port, that "special wii support system" possibly licensed separately and costs money. and possibly it's specific to Nintendo's development kit.



Edited 1 time(s). Last edit at 09/02/2009 04:08PM by I.R.on.

From what I understood, no one 'owned' the C# language necessarily, it's a specification just like C/C++ is. Yes, some companies like MS and Novell have developed their frameworks for it and such, but why can't it exist on the Wii?

As holy_artefact said, the point of the .NET language was to abstract everything from the underlying system and be able to write code that "just worked." The System libraries would do all the JIT work to produce the correct machine code. It's similar to Java but with much better speed, efficiency, and in my opinion syntax. Naturally, the MS implementation of .NET pipes through a lot of Win32 API functions. However, if you use Mono under Ubuntu or another Linux distro, the same objects are there such as System.Net.Sockets and System.Threading and work the same way without Win32 API calls. If you're doing code with the registry, then yes those functions are not available through Mono, but that's fine. The point is, I want homebrew to be able to be written using C# under the Wii's PPC architecture.

There are only a few "libraries" that you'd need to implement ideally:

System -- provides primitive types and arrays. Basic memory and variable functionality.
System.IO -- provides methods to access the file system, controllers, and SD card. Input/output for everything non-network.
System.Net -- provides network functionality, namely sockets and address endpoints. Networking for TCP/IP and UDP.
System.Drawing -- provides graphics library for rendering content to the video buffer. SDL integration?
System.Audio -- provides sound functionality for playing music or sound effects.

Extras could be:
System.Runtime -- provides IPC methods.
System.Diagnostics -- debug library for helping developers.

If DevKitPro is compiling down to PPC, why not start with the Mono:PPC and go from there (as another has suggested)?

To me, it seems like everything from all the libraries, like libogc, libdi, libfat, libmodplay, lwbt, lwip, and many others could be ported and integrated into the "Wii# Framework".

EDIT: Interestingly enough, there was a third-party (not homebrew) game released at the beginning of this year that used C# heavily along with Unity3D: My Animal Centre. While not the most enticing of games, I wonder what can be learned from looking at the code from the game itself.



Edited 3 time(s). Last edit at 09/03/2009 03:09AM by SiLo.

Quote
http://en.wikipedia.org/wiki/C_Sharp_(programming_language)#Criticism
In a note posted on the Free Software Foundation's news website in June 2009, Richard Stallman warned that he believes "Microsoft is probably planning to force all free C# implementations underground some day using software patents" and recommended that developers avoid taking what he described as the "gratuitous risk" associated with "depend[ing] on the free C# implementations".[22]. The Free Software Foundation later reiterated its warnings[23], claiming that the extension of Microsoft Community Promise to the C# and the CLI ECMA specifications[24] would not prevent Microsoft from harming Open-Source implementations of C#, because many specific Windows libraries included with .NET or Mono were not covered by this promise.

Do you really want to spend your time on this?

If you succeed to do that, you will be my god :)

Even if Microsoft did have the power to oust all other C# implementations underground, it would not be in their best interest now, nor later from what I can see.

First off, Microsoft holds a huge market share in both the OS and IDE market. Windows 7 is restoring a lot of damage that Vista did, and Visual Studio has always been great, especially since 2005. When developing for Windows, many developers, especially those in large companies will stick with Visual Studio, especially if they're going to be working with the .NET languages. At both my current and previous jobs, we use(d) Visual Studio for C/C++, ASP.NET, and C#. Once place used SVN and the plugin for VS, the other used Visual Source Safe.

Second, Microsoft has to make the C# language look appealing as a new language on the market. The first way they do that is the immediate benefits over C/C++, which is the RAD prototyping, reflection, GC, and other issues that can make working with C/C++ a chore at times. Second, the IDE and debugger, which provide a lot of helpful tools and not to mention the near-same performance of the language in most cases.

One aspect that many people had argued was hurting C# was no cross-platform. Then Mono came around. After that, a lot of people on the fence began to take the C# initiative more seriously and more Linux devs became interested in the .NET platform. Being able to port an application from Windows to Linux and vice versa is a boon to both OS's since developers only have to write the application once (or change very little between versions). Many people will say that C/C++ can do this easily too, but if you've ever written network or multithreaded applications, that's definitely not the case.

Third, as much as C# may not be only Microsoft anymore, it's still 'Microsoft's brainchild.' Not to mention, Microsoft can pride itself in having the most 'advanced' C# specifications implemented and being the authority on writing the specifications for it. That is, until Mono catches up but I'd say this is a case of 'competition' working in favor of the consumer. Not to mention, I think Microsoft might get in trouble with anti-trust if they tried to pull C# out from under everyone else. Even if they did, it would hurt them both developer-wise (Linux gurus regressing back) and PR-wise, imagine the backlash they'd get.

The possible 'loss' that Microsoft would have from open-source C# is negligible compared to the push its given to the language as well as the existing infastructure in the computing world that's doubtful to change. Think about all the Windows Servers, MSSQL Servers, MS Office Users, VS Users, and not to mention Windows itself. None of that is going to go upside down overnight just because of all this.

Look at Silverlight, it runs on Windows and Mac OS X. Just like Flash, there are crossplatform versions of this, Moonlight for Mono. Why would MS want to shoot themselves in the foot?

By the way, WBFS Manager is written in WPF! As great and useful as the program may be, there are some UI design elements I would definitely want to change, heh.



Edited 1 time(s). Last edit at 09/03/2009 11:03AM by SiLo.

Quote
SiLo
Look at Silverlight, it runs on Windows and Mac OS X. Just like Flash, there are crossplatform versions of this, Moonlight for Mono. Why would MS want to shoot themselves in the foot?

They have been doing it for years, they own the patents for FAT yet they have only sued one company over using it and it was TomTom (satnav makers)

While this may be in true in other cases, I believe the community promise is more than just a guise to open source development of C# and the CLR.
Microsoft issues patent promise, dispels Mono legal concerns.

At this point, I'd rather worry about the technical implications rather than the legal ones, namely since the legal ones seem to be defined already. While I understand there is a slight risk, I'm willing to take it for the better of the homebrew community.

While Mono says they have ARM and PPC ports, I have yet to be able to get my hands on them from the official site. While I know how to build from source and such, I admit I'm not as much of a Linux guru as I'd like to be. I get the impression that the 'official PPC port' (namely for the Wii) requires some kind of permission or request from Novell/Mono devs. I find that kind of weird, but I guess I'll ask for the 'general PPC port source' as I believe only official Nintendo devs can get the Wii port. I'm sure the latter has more legal implications than if we make the general PPC one work.

Once the PPC Mono port runs on the Wii, it'll be easy to port the rest of the libraries through it. I've been reading a lot trying to absorb how everything works when it comes to Wii homebrew, IOS, and the other subsystems.

I do have some questions.

How would I 'install' or 'build' Mono on the Wii? Normally, I'd SSH into a Linux box, use SCP for the files and then just make/configure. I suppose I could try using DevkitPro to build the PPC Mono binaries. Even if I do build them, how would I install them on the Wii as runtime libraries?

I know the project is feasible in some sense because we have homebrew working, third-party companies have used Mono in official Wii games, and that there are PPC/ARM ports for Mono. The amount of effort of getting it to work, well I'm up for doing that or at least trying my best. I'm familiar with this on other platforms but not the Wii as it doesn't have the same 'OS' scheme. Any ideas?



Edited 1 time(s). Last edit at 09/03/2009 10:54PM by SiLo.

I'm not an homebrew expert, but I guess you must link your .dol (wii executable) statically with the libraries you compiled.

I thought the same. I assume this is what the existing toolchain (DevkitPro) is doing.

From what I gather, everything on the Wii seems to be very singleton. One IOS running, one DOL/ELF running.

So the task is, take a C# program and compile it fully static into a single executable, removing the need of a JIT engine, in a PPC friendly form.

Judging from Mono:Runtime, this is entirely possible and PPC is stated as a supported platform.

Now the issue becomes how to set up a proper development environment. Luckily, MonoDevelop has come to most platforms and offers a great deal of functionality. It matches DevkitPro for the most part, the debugger has always been kind of odd but I think its at worst the same as we have now.

Perhaps I'm a bit pampered by Visual Studio, but is there a better way to debug for the Wii rather than code dumps and DSI exceptions? Reminds me of the days where C applications would just crash without any notification why leaving it up to you to rumage through the code and dump a bunch of printf(), TRACE and ASSERT commands. Meh.



Edited 2 time(s). Last edit at 09/04/2009 04:15AM by SiLo.

Just search something like wifi debug or something similiar in this forum, someone did a patch for libogc for debugging via wifi using GDB iirc.