A few weeks ago, I was talking to an older gentleman at a golf course, and I mentioned my 40th birthday was coming up.

He smiled and asked "It went by quick, didn't it?"

Yes, it did.

De Re Atari

People sometimes ask me where I learned programming. I learned long before going to college. Most of my formative years were spent reading books that are now available at atariarchives.org.

It's a lot of fun looking through those books now. I remember holding the paper versions in my hands, and typing the programs into my Atari 800.

My favorite among the books is De Re Atari: A Guide to Effective Programming by Chris Crawford, Lane Winner, Jim Cox, Amy Chen, Jim Dunion, Kathleen Pitta, Bob Fraser, and Gus Makrea. I spent a lot of time studying this book, learning all the ways to do cool stuff with the Atari 8-bit hardware. It also contains a lot of advice about how to design software, and most of that advice is still applicable today.

Those were the good old days, when developing software for personal computers required knowledge of hardware registers, assembly language, memory layouts, and so on. Today, we hide the details of the hardware as much as possible, but I think having experience with such low-level stuff is beneficial. If you're a young whippersnapper who has only used high-level APIs like DirectX, OpenGL, and Windows GDI to do graphics, I'd recommend paging though some of these old books to see how programmers used to do things.

One last thing: Atari rules, Commodore sucks.


I celebrated my 39th birthday this week, if the term "celebrate" can mean "sit alone at home and watch TV just like every other night." Because my birthday is in January, I do Birthday Resolutions instead of New Year's Resolutions. After all, that gives me a couple more weeks to figure out what it is I want to do with the coming year.

I've got one year to do all the things I want to do before I turn 40. But there's nothing I want to do. Yeah, I'd like to get into better shape, be smarter with my money, clean out my closets, find a better job, and the other typical stuff, but I know that none of these wants are engaging enough to hold my attention for a year.

So, I really don't have anything to write about, but I wanted to record this so that I can look at it next year and be comforted that I didn't fail to accomplish any of my goals.

I know some people will probably wish me a Happy Birthday, let me wish you all a Happy Birthday as well, whenever it is.


Kris, the production system isn't working since we installed the newest release. Can you tell us how to fix it?

Can you send me the log files?

No. They are too big.

Will you let me access the system myself to see what's going wrong?

No. Developers can't touch the production system.

OK, can I access the test system to see if it exhibits the same behavior as the production system?

No. The test system has been dismantled.

Did you test the new release before putting it into production?

No. There wasn't time.

Did you install the server-side updates?

No. The IT manager won't allow installation of any server updates.

Other than installing the new version, did you keep everything else the same?

No, we changed a few other things too. Can't remember exactly what.

Are you sure this "new" problem never occurred with the previous release?

No. Maybe.

Can you roll back to the previous release?

No. We blew away the old data after converting it to the new format.

Well, Kris, can you tell us how to fix it?


[Note: The Remoting.Corba project is "dead", and has not been active for several years. If you need .NET-CORBA interoperability, I recommend checking out IIOP.NET. Archived Remoting.Corba documentation is still available via The Wayback Machine.]

Remoting.Corba is an open-source .NET library that provides interoperability between the .NET Framework and CORBA servers/clients, using the .NET Remoting architecture.

I started this project to learn more about .NET Remoting and to apply my knowledge of CORBA. My basic goal was to be able to write .NET programs that interacted with CORBA-based applications using typical .NET Remoting code. For example, if a CORBA server supported this IDL:

interface Adder {
    long add_longs(in long arg1, in long arg2);
    double add_doubles(in double arg1, in double arg2);

then one could write a C# program that invoked the server, without need for an ORB, using code something like this:

// standard .NET Remoting stuff
using System;
using System.IO;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Messaging;

// Remoting.Corba
using Remoting.Corba.Channels.Iiop;

namespace MyExample
    // define .NET interface mapping for IDL interface
    interface Adder {
        int add_longs(int arg1, int arg2);
        double add_doubles(double arg1, double arg2);

    class App {
        // entry point
        static void Main(string[] args)
                // register IIOP channel with Remoting
                ChannelServices.RegisterChannel(new IiopClientChannel());

                // Use a standard CORBA stringified object reference for the server
                string ior = "corbaloc:iiop:localhost:9999/Adder";

                // create the proxy to the server object
                Adder server = (Adder) Activator.GetObject(typeof(Adder), ior);

                // execute some methods on the remote object
                Console.Out.WriteLine("1 + 2 = {0}", server.add_longs(1, 2));
                Console.Out.WriteLine("1.0 + 2.0 = {0}", server.add_doubles(1.0, 2.0));
            catch (Exception ex)
                Console.Error.WriteLine("Exception: " + ex.ToString());

The IiopClientChannel class from the R.C library takes care of generating and interpreting the CORBA IIOP (Internet Inter-ORB Protocol) messages and pumping them through the .NET runtime. There is also an IiopServerChannel class that can be used to implement CORBA servers using .NET Remoting.

It was pretty cool when it worked. The .NET Framework's Remoting architecture is very open, allowing programmers to plug in their own network protocols and messaging formats. I used some custom attributes to provide information needed by the CORBA engine that could not be gleaned via data types and reflection mechanisms.

Unfortunately, while the .NET Remoting architecture is open, it is not well documented. If all you want to do is send a SOAP message via some protocol other than HTTP (for example, via UDP, via message queues, via e-mail, etc.), then it is pretty easy to plug your own stuff in. But if you are doing anything more complicated, then you will quickly discover that the only way to figure out what's going on inside .NET is to look at the Rotor source code.

The project was valuable to me in that I learned a lot about .NET and C#. It was also gratifying to see other people using it and expressing interest in it. I was especially excited when it was mentioned in Don Box's Spoutlet, and when Miguel Icaza started playing around with it in Mono. It even got a few pages devoted to it in a Microsoft Press book!

I wrote this code during a period when I was not working any paying jobs, so I was always hoping I would find somebody willing to pay me to add features. There were a few nibbles, but users were generally able to add features themselves instead of hiring me to do so. I talked to some people at Microsoft and Inprise about potential deals, but nothing came of it.

I have put a few projects on SourceForge, but this was the first one where I got any significant contributions from other developers. Michael Sawczyn created an IDL compiler. Other developers did some bug fixing, refactoring, and feature additions. It never reached the "critical mass" needed to keep it going after I lost interest, but I think it was close.

I worked on R.C for a few months. I lost interest in it due to several factors:

  • No paying customers.
  • No real need to use it myself.
  • All the low-hanging fruit was gone; further development would have involved a lot of very technical work with little tangible benefit.
  • The appearance of commercial CORBA ORBs for .NET from Borland and others.
  • Limitations of the .NET framework

We hit limitations of the .NET framework when trying to figure out how to map remote object references back to objects in the same process. The only way to do it was to use reflection to invoke private methods of internal .NET classes. That prospect triggered enough of an "Ewww!" response that I decided further work was only going to make me feel worse.

I used a wiki to distribute the "documentation" for the project. I liked how the wiki turned out, but there were few contributions to it from anyone except myself.

So what did I get out of Remoting.Corba? Obviously, I learned about .NET Remoting and some more about the internals of CORBA. I got practice writing C# networking code. I made some contacts in the industry. I wish I could have used R.C on a real project, but that might have taken the fun out of it.

Syndicate content