Sunday, March 2, 2008

.NET BCL source code

Source code for .NET Base Class Library has been made available for debugging sessions in VS2008. It would download one file at a time as they are needed. Since then John Robbins and Karem Kusmezer have create a tool to download all the source files without hassle, great work! The tool is NetMassDownloader.

Use it whilst it is still working :). Download, unpack, and run:

NetMassDownloader.exe -output bcl
    -d C:\Windows\Microsoft.NET\Framework\v2.0.50727

I executed in in Windows XP as a limited user and have seen numerous failure messages printed out. Nevertheless, 120MB of data was downloaded and I had all the files I wanted. The authors advise though to run it as a privileged process (at least on Vista).

The most interesting parts are bcl/redbits/ndp/clr/src/BCL/System and bcl/redbits/ndp/fx/src where bcl is the name of the directory you provided after -output switch. Together they are about 75MB.

It was pretty interesting to read the implementation of the classes I had been using for so long: String, Hashtable, Arraylist. They are easy to understand, with lots of comments, and of course in C#.

The classes I have read are all pretty basic and no wonder there are lots of pointers and calls into unmanaged code, but it is still readable.

One surprising thing, but obvious after knowing it, is that " s ".Trim() will not create a new string "s", but return a slice, an object that holds a reference to the original string and knows where are the beginning and the end. This is possible thanks to the immutability of strings. I bet the substring method is implemented like this too.

There are also some monster methods to be seen. One example is internal HttpListener.HandleAuthenticate spanning more than half a thousand lines.

BTW source code for mono is available at mono-project.com/AnonSVN. Source for mono's BCL is under mcs/class/corlib. It might be interesting to compare the two.

Saturday, March 1, 2008

Why Vim's modes frustrate newbies

Some people say they hate the Vim's modes. Puzzling, because I consider the modes as the killer feature of Vim, something that makes it superior to Emacs.

Why modes rock

I spend most of the time in the normal mode. In this mode, undo is just u, delete line dd and move one word forward w. In Emacs these commands would all include ctrl, shift, alt or whatever. Inserting text is not what I spend most of the time in an editor on. Most of the time I need to quickly navigate around and make small modification to an already existing text. It is false economy to have the keys on the keyboard be bound to less often used functionality all the time.

When I reach the exact place where I need to enter some text, I press i to enter insert mode, type it, and immediately get back to normal mode (I get to normal mode by pressing ctrl-[ rather than ESC).

Why modes frustrate newbies

While pairing with people new to Vim I noticed that they leave it in whatever mode. So if they were inserting, they live it in insert mode. When they come back to Vim window (after inspecting results of a test run for example), they think they are typing normal-mode commands, but are actually in the insert mode typing text. Or the opposite situation: start typing and instead of inserting text they are rapidly killing one chunk of the file after another.

Experienced Vimers follow a convention. After doing something briefly in other mode, immediately go back to the normal mode. I never live Vim in the insert mode or any other mode than normal; when I get back to the Vim window I can always assume Vim is in the normal mode.