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.

Sensible policeman --- An excellent showcase of presence of mind

India ranks pretty good in corruption ratings, and I am sure which "good" I am talking about. Things can get really over-whelming sometimes in some places of the country. And one of the departments thats deeply into competition is probably the one that should protect the people -- "The Police Department". Or at the least that is what the public (including me) thinks so, and we might as well be partially wrong. But whatever it may be one thing is sure that Bangalore Traffic police is really doing a good job. Now do not blame them for the bad traffic and long jams. Thats the work of the infrastructure people, which the police are not. Police manage the traffic in the currently available infrastructure.

Now what makes me write this specific blog is a set of two incidents that I recently came across and here they are:

We have a very small but extremely busy junction in Malleshwaram near Nataraja theatre. We pass through this junction almost everyday. Very recently when I was travelling with my one of my colleagues a little late in the night, we got stuck at that junction. The reason was that there was no policeman manning this junction and hence everyone was trying to find a way for himself wthout considering anyone around them, except for the ones who might hit them. The result, an obvious chaos with all vehicles being stand still because of a dead-lock. Afer waiting for a few minutes my colleague said, in a totally frustrated way, "Couldn't that police be here at this time??! If he was here we could be in our homes by this time. Damn it!!". So it was clear that the presence of a policeman would have brought in a lot of discipline.All of us might blame them, curse them or say anything, but its ultimately true that 80 - 90% of discipline on the roads is because of policemen.

Now the second incident:

Again, another day on my way back home from office, I was on a bike with my colleauge, waiting at the signal in front of Chinnaswamy Stadium. We were in the right half on the road and there were two lanes of traffic to our left. The traffic was all piled up and I suddenly saw the policeman, who was manning the signal, let go the two lanes of traffic to our left.I was like: "What the hell is this man doing??!!!". It was only a few seconds I realized the motive, when I heard the Ambulence siren. The ambulance was stuck in the traffic and was in the lane to our left. So the policeman moved the traffic to make way for the ambulance. And of course after the ambulance passed the signal, those two lanes were again stopped. See, policemen do a lot of good and necessary jobs.

So all tax payers, don't think that ALL the tax paid is going waste. In fact a large amount is being used very well. More about our government and the reality about the government workers in another post very soon.

Till then, just respect the traffic police, you can respect the others later after my further posts. :-)

Regards
Brahmana

.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.