Zac Bowling’s Blog

I can’t stop thinking and working on this XPCOM stuff. It’s getting pretty amazing. I’m learning some very core things to COM and various C++ compilers as well so I’m moving all the work I’ve been doing into a new library now called Mono.Interop to handle C++, COM, and XPCOM. I’m trying to make it possible to both early bind and late bind to XPCOM and soon COM. Late binding is very easy, but early binding is going take some time and its much more complicated in terms of trying to maintain some cross platform ability (and sometimes cross C++ compiler safety). Nothing looks impossible or unobtainable and in some cases, it looks like we can do some stuff that no body else can do in other langauges do (like Java and C++), when interoping with XPCOM and right into C++ for that matter.

I’ve got a 11 page document so far of how it works and the design architecture I’m plaining and using for accessing, invoking, reflecting, and exposing to XPCOM. I’m leaving room for COM at the same time so everything can dual purpose someday (even though for the moment, I personally have no interest into accessing COM since .NET does it right now and COM isn’t cross platform). There is a lot of work to be done to make it work for some aspects. Some parts are easier then others like early binding versus late binding and invoking into C++ (since all of XPCOM and most of Mozilla’s use of it is written in C++).

Its a massive undertaking. Not really in the total ammount of code but in the complicated nature of the code and the maintiance of it. From hosting Mono in a wrapper to expose objects back into XPCOM (which XPCOM has some emerging ideas for a new technique of mixing GC systems that I need to look at soon), to a semi-dynamic pinvoking library generated with Reflection.Emit to access xpcom components directly for early binding (which has to be done this way to handle the different name managlings of the various C++ compilers to keep it from being compiler specific). Some other issues that have to be worked on are handling versioning issues of XPCOM components, reflection into XPCOM to build wrapper assemblies (like tlbexp.exe in MS.NET), and a few other massive issues that I can even explain here without writting a full page document on the topic.

Anyways, after I get done researching and get my total vision down on paper of what I want it to do in the end someday, I’m going to get together a basic set of goals that need to be meet and at least some short term goals. I’ll commit my prototypes and post the design/architecture documents when I’m done. After that, I’ll get some feedback and get to work on making it real!! 

I wasn’t the first. Shaver (from Mozilla) had this idea as well and started a bit on it. I’m talking about XPCOM. I’ve done enough work to say that I’m working on it. I’ve taken Shaver’s orginial code, got it to work in Windows as well, extented it, re-did the makefiles, changed the coding conventions (sorry Shaver) and documented some of the code.

Anyone that doesn’t know, XPCOM is a product of the Mozilla project. All of Mozilla/Firefox is based on it so its crossplatform. Its very similar to COM in Windows. Making XPCOM work with Mono/.NET gives us access to many of the features in Mozilla natively and eventually to even write components that are expossable back into XPCOM. Not only does it give us access to Mozilla but XPCOM is capable of being self hosted so its possible to use it for its other benifits, such writting componets in Perl, Python, Javascript, Java, C and C++ and interop with them at a native object level (like writing a component in VB6 and consuming it in VB.NET with MS’s COM).

How does it work? Well XPCOM supports a method descriptor system, a sort of reflection, that tells you about a object dynamicly. We get this information at runtime when creating a new object and we create a virtual class object version of that using Reflection.Emit, that represents the object in XPCOM.

To access something in XPCOM, its very similar to way you can call the Activator object and create a new instance of a com object and it will run the com wrapping system for you. Also, in MS .NET, there is a tool called “tlbexp.exe” that creates a physical assembly for the COM wrapper, so you don’t have to call the methods on the COM object via reflection and you can build directly against something. I’m currently working on a facility to do this same exact concept with XPCOM and have a simiple tool wrapper that writes the assembly to file.

I’m also working on how we can expose back into XPCOM from Mono using a combination of the Mono embedding api and custom attributes to wire and map everything up.

Some aspects are pretty hard. There were a lot of design concepts I could of really used, however I felt it was best to mimic the way COM works with .NET in Windows.

Don’t get confused. XPCOM is not COM nor a drop in replacement. COM objects that run in Windows don’t work magicly under XPCOM. Its very very different in many ways and very very similar in others. However from the Mono/.NET, its not going to be much different to get used to from COM.

More info later!!!

Been going through the class libraries in 2.0 like crazy this weekend. Also manged to get Visual Studio 2005 and Sql Server 2005 installed in the process. I managed to tear it apart a bit.

Here are some random first impressions:

• Direct serial port access is a nice feature thanks to the new “SerialPort” class..
• Little bit thrown off from partial classes in C#. I can see how this was a nice feature for Microsoft to remove the designer generated code for VS 2005 to a different file but I couldn’t figure out why this would be useful anywhere else. That was until I went and looked in my source control and found 9 major instances where they come to be very nice. For example, when you have a private embedded class in some class or where your want to seperate the properties, methods, and everything else.
• Active Directory Application Mode (ADAM)? Thats neat. Look at that later.
• SqlBulkCopy is nice and well needed feature.
• System.Text.DecoderFallback and System.Text.EncoderFallback! I could of used this months ago. In our current model, this is going to be a little bit tough to make work for Mono.
• Visual Basic joins C# with support for variable paramaters in a function declaration using the “params” keyword or “ParamArray” in VB, but I’m not sure if this is new but if your langauge doesn’t support it then you get a nice little mapped class parameter called “ParamArrayAttribute”. By the looks of it, its not a really high preformance class and its not CLS compliant (so don’t expose them public).
• System Windows Forms has a BackgroundWorker. Something just like a async call wrapper or something. Figure that out later.
• Generics, Generics, Generics!
• Visual Studio has some nice features. Refractoring built-in, a quick code sniplet thingy, better InteliSense (show a ton more), Windows forns desinger is neater, less buttons…
• ASP.NET now ouputs XHTML by default and get this, its compliant out of the box. You can even switch it to a strict mode. Props to the ASP.NET team for that one.
• No more Server and Client versions of the GC. Its all one now.
• SQL Server 2005 now supports XML datatypes (not so bad, but its going to be hard convincing people that the database doesn’t store the data as text and parse it like that)
• SQL Server 2005 hosting the CLR is nice but it really doesn’t preform as fast as TSQL does for writing stored procs.
• TSQL stored procs now support try and catch blocks and you can expose stored procs as soap methods in line. (uuhhh.. wahoo?? I guess?)
• SQL Server 2005 supports a new multiple active recordset system. You maybe able to lower the number of needed open connections to MSSQL now. (more information)

I think that covers some of it. Time to code!!!