Web protocol handler in FF3

This is one awesome thing to happen. Haven't you crunched your face in disappointment and frustration whenever you clicked a "mailto" link on a webpage and unnecessarily have your desktop mail application (mostly unused and not configured one) popping up, hogging quite a bit of resources? The worst case scenario would be, the above described things happening even when you are logged into one of your web based mail services and thats where you wanted to send an email from.

Now all that go away. You Gmail might just give you a new mail compose page when you click on a mailto link. And this is not just for the "mailto" link. There can be web based protocol handlers to any sort of protocol. So all in all FF3 will rock like anything along with making web applications rock harder. So folks be ready to dance for the beat, for the beat will be pretty high paced. :-)

More details here: mfinkle's blog.

JS-CTYPES Status

Mark Finkles Weblog » JS-CTYPES Status

This was what mfinkle recently talked about js-ctypes. As he said because of the hectic FF3 schedule the devs at mozilla were pretty busy and hence nothing could be done. I being a lazy bot, also did not do anything. In the blog post above, Mark talks about the struct support (which I told that I would be doing). Now I exhibited my initial enthusiasm by writing up a doc, which was not really useful (its here ). After that nothing much happened except for a small bug fix.

Now that mfinkle has rekindled the interest I will also try and contribute. The struct support is still pending and I will start getting XPCOM code exchanging struct information with libffi. After that we can look at the other interface of JS exchanging structs with XPCOM to finally complete the loop. In the mean time I am also looking at embedding mozilla. Will put up a post about that very soon.


Again, Get ready to use deadly binaries in your JS code. JS-ctypes is soon going to be here.. ;-)

#pragma comment(lib, "libfilename") -- A cool way to indicate dependency.

.NET programmers are well aware of the References section of a .NET project using which we specify the dependencies. Things are pretty straight forward in the managed world and with an IDE like Visual Studio it can't be easier. You are using a type from a particular assembly, then just add that assembly to the references of the project. The rest is taken care of by the IDE and framework. When we move to the native/unmanaged world, we get slightly more powers with of course increased responsibility.

Any external symbol that we are using must be approved by two tools/stages: The compiler and the linker. The compiler can be tackled by having the appropriate header file (.h file) which just has the declaration and no definition/implementation. Using this is simple. #include the header file in whichever source file you are using the symbol. But just make sure that the compiler knows where to find that header file, that is maintain an includes directory and tell the compiler about that directory.

The linker is a less tamed beast or rather a more difficult a beast to tame. One simple reason being that since it handles the object code, its error messages cannot be traced back to a line in the source code. Another reason being that we have two versions of library: Static and Dynamic.

Now to use this we will have to provide each of these libs, containing the symbols that we use, as input to the linker. On the VS IDE, we have to list all the required libs in the project settings and also specify the the library containing the libs. I say this is not as simple as the references thing .NET because, to change anything you will have to visit the Project Settings page. And if you are developing without an IDE, your compiler invocation command line will be really really long. (though you can shorten it with some gmake variables and system variables). But apart from these geeky build methods there is yet another simple way to tell the linker which all .lib files it has to look into for symbols when linking the current code and thats where this #pragma directive comes into picture.

#pragma comment(lib, "requiredLibrary.lib") --- This line of code will make the linker look for the library file requiredLibrary.lib. Isn't that cool? Don't you get a feeling that you, kind of, tamed the linker using your C/C++ code?

All you need to do is to put this line of code in one of your code files and the compiler will know what to do. When this code is encountered, the compiler adds a "search directive" to the object file (.obj file) that it generates. When the linker reads that search record it will know what lib file it has to look for to find any external symbol that is present in the current object file that it is linking.

So, suppose you are providing a library and you want to enforce this above method on anyone who consumes your lib, you can provide a header file that they must include to use your symbols. And in that header file you can specify this above pre-processor directive. This way all your anyone who is using your lib will implicitly tell the linker which lib file to look for.

This #pragma comment on a broader sense is used to inject extra information to the object code generated by the compiler. This information can be used by the linker. Here is the msdn article on what all this #pragma comment can do: This page.

.NET metadata available in 2 ways - Reflection and TypeDescriptor

Ever since I was introduced to Java during my internship at IBM, I have been fascinated about the concept of Reflection. The only way something like that was possible in C/C++ was to put a function in a DLL and use GetProcAddress(), which we all know can get real dirty. But with Reflection things are real smooth and way more powerful. Without that you think the IDEs would have been this awesome?

Anyways this fascination continued at my first work place, National Instruments, where I started working with .NET. But it was not until today that I was aware of a competitor to this Reflection in .NET. That is the TypeDescriptor. Things can just keep getting more and more awesome with these managed frameworks. First they came up with Reflection, which just exposed any type from any assembly. This probably made the Type designer think that their types were lying around bare in front of their users. They saw the types struggling to cover themselves, hiding and crying. The scene was like the regime of an evil master/demon. But God protects the weak and the prayers of the Type and Type designers were answered. The framework developers finally decided to shield these poor and shy Types from their consumers and that is when they came up with this "TypeDescriptor" funda.


With this TypeDescriptor leading the troops from the front, Type and Type designers could combat the evil. If Reflection was like the nuclear energy in the hands of the evil, TypeDescriptor was like the lead container used to put the nuclear radiations under control. I mean, with TypeDescriptor we can decide what the type will look like to other people when looked through the TypeDescriptor. So if we have to protect our types we have to con the users into looking through this Descriptor and not the old weapon.

If TypeDescriptor is under use with a type, it expects that particular type to throw open some methods which the TypeDescriptor can use to give some information about the type. Later on this information is passed on to our users. And the obvious way of providing this methods is through interface and an example is ICustomTypeDescriptor. And if I remember correctly, just like assigning a TypeConverter to a type we can probably assign a TypeDescriptor also which takes care of presenting the type to the outside world.

But you know what, if your type does not have a custom type descriptor, or has a very lazy one - meaning one that just forwards the calls to the default one, then the shield no longer works. Because if the TypeDescriptor does see any openings to get information about the type, it goes for the inevitable --- Reflection.

So go protect your types, and don't forget the conning part.

In another post I will be more technical and less a story teller and write about the implementation of this TypeDescriptor.

--- Hari Om.