How to write Software... (part 4)
I should mention that I have a bias towards C# as a language. It is modern, OO, and has lots of language features that lend themselves to writing elegant programs. I also follow the progress of the Mono:: and DotGNU Portable.NET open source projects that allow C# to run on several platforms. The platforms I am most concerned about are (in order) Windows XP, Mac OS/X, and Linux (x86 & PPC).
What is NOT available is a cross platform UI for C#. There are candidates (wxNET, GTKSharp, TK#, SWF, SWT) but they are either incomplete, defunct, or just not ready yet for all my platforms.
Well, the obvious choice was to separate UI from functionality (always a good decision anyway) and write my imaging library first in C#. By then, surely, there would be a UI that I could use. If I put my UI behind a C# interface, then I could even load a different UI for each different platform. The same with hardware support. Everything behind an interface. I just need to do a little reflection discovery at load time to see what I have available.
I designed the project and called it Obsidian. Why not. I wrote the discovery code and the library. Lots of formal interfaces.
It was implemented in several assemblies. A real medium-to-large size C# app sans a UI.
A year passed. I kept up to date with all kinds of projects, both commercial and free. And guess what. I got burned. No UI materialized that was even a 1.0 release. I even tried starting interest in creating a project called CocoaSharp. It was supposed to bring Cocoa (the Mac's native Object framework) into the managed world. I worked a few weeks on it and released a version 0.1 that wrapped a few key Cocoa UI classes. Nobody was interested in contributing to the work and I was looking at wrapping by hand hundreds of classes (which were changing underneath me with new OS/X updates). I gave up and e-mailed the code so someone who asked for it and called it a life lesson. Note that my CocoaSharp project predated but was otherwise unrelated to the current CocoaSharp project underway, at least to my knowledge.
As it turns out, processing pixels (even in unsafe code) is not a performance demon under dotNET 1.0 or 1.1 so I got to thinking that C# might not be the full answer.
I had some experience with Interop (the method that managed code interfaced with native code) while writing managed camera classes that linked with some native libraries on the PC and the Mac. It even chose at runtime which native library to use through the same discovery mechanism I had written for the rest of Obsidian.
I decided it was time to bite the bullet. Write the lowest level functions in C. Plain C. K&R C. no modern conveniences C. portable C. Then, I could wrap them into ObjC objects on the Mac, C++ objects on Linux, and C# objects wherever a CLR was available. Damocles was born.
What is NOT available is a cross platform UI for C#. There are candidates (wxNET, GTKSharp, TK#, SWF, SWT) but they are either incomplete, defunct, or just not ready yet for all my platforms.
Well, the obvious choice was to separate UI from functionality (always a good decision anyway) and write my imaging library first in C#. By then, surely, there would be a UI that I could use. If I put my UI behind a C# interface, then I could even load a different UI for each different platform. The same with hardware support. Everything behind an interface. I just need to do a little reflection discovery at load time to see what I have available.
I designed the project and called it Obsidian. Why not. I wrote the discovery code and the library. Lots of formal interfaces.
It was implemented in several assemblies. A real medium-to-large size C# app sans a UI.
A year passed. I kept up to date with all kinds of projects, both commercial and free. And guess what. I got burned. No UI materialized that was even a 1.0 release. I even tried starting interest in creating a project called CocoaSharp. It was supposed to bring Cocoa (the Mac's native Object framework) into the managed world. I worked a few weeks on it and released a version 0.1 that wrapped a few key Cocoa UI classes. Nobody was interested in contributing to the work and I was looking at wrapping by hand hundreds of classes (which were changing underneath me with new OS/X updates). I gave up and e-mailed the code so someone who asked for it and called it a life lesson. Note that my CocoaSharp project predated but was otherwise unrelated to the current CocoaSharp project underway, at least to my knowledge.
As it turns out, processing pixels (even in unsafe code) is not a performance demon under dotNET 1.0 or 1.1 so I got to thinking that C# might not be the full answer.
I had some experience with Interop (the method that managed code interfaced with native code) while writing managed camera classes that linked with some native libraries on the PC and the Mac. It even chose at runtime which native library to use through the same discovery mechanism I had written for the rest of Obsidian.
I decided it was time to bite the bullet. Write the lowest level functions in C. Plain C. K&R C. no modern conveniences C. portable C. Then, I could wrap them into ObjC objects on the Mac, C++ objects on Linux, and C# objects wherever a CLR was available. Damocles was born.
posted by Oscar Papel at
4:09 PM
0 Comments:
Post a Comment
<< Home