Analysis of the Duqu Trojan worm by Kaspersky Labs

This summary is not available. Please click here to view the post.

Windows 7 ನಲ್ಲಿ ಕನ್ನಡ ಟೈಪ್ ಮಾಡೋದು ಹೇಗೆ? - ಒಂದು ಪಾಠ

ನಾನು ಆನ್-ಲೈನ್ ಮಾತಾಡುವಾಗ (ಚ್ಯಾಟ್ ಮಾಡುವಾಗ) ಆದಷ್ಟು ಕನ್ನಡದಲ್ಲೇ ಮಾತಾಡ್ತೀನಿ, ಅಂದರೆ ಕನ್ನಡದಲ್ಲೇ ಟೈಪ್ ಮಾಡ್ತೀನಿ. ಇದನ್ನ ನೋಡಿದ ಸುಮಾರು ಗೆಳೆಯರು ಹೇಗೆ ಮಾಡ್ತೀಯಾ, ನಾನು ಮಾಡಬಹುದಾ ಅಂತಾ ಕೇಳ್ತಾರೆ. ಅದಕ್ಕೆ ಉತ್ತರವೇ ಈ ಲೇಖನಿ.

Windows Vista ಇಂದ ಹಿಡಿದು ಕನ್ನಡ ಟೈಪ್ ಮಾಡೋದಕ್ಕೆ ಬೇಕಾಗಿದ್ದೆಲ್ಲಾ Windows ಅಲ್ಲೇ ಇದೆ. ಬೇರೆ ಏನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡೋದು ಬೇಕಾಗಿಲ್ಲಾ. ಕೇವಲ ಕನ್ನಡ ಕೀಬೋರ್ಡನ್ನ ಶುರು ಮಾಡಬೇಕು. ಅದನ್ನ ಹೇಗೆ ಮಾಡಬೇಕು ಅನ್ನೋದಕ್ಕೆ ಒಂದು ಚಿಕ್ಕ ವಿಡಿಯೋ ಮಾಡಿದೆ. ವಿಪರ್ಯಾಸ ಏನಂದ್ರೆ ಆ ವಿಡಿಯೋನಲ್ಲಿ ಧ್ವನಿ ಇಂಗ್ಲಿಷಲ್ಲಿದೆ. :( ಪರವಾಗಿಲ್ಲಾ ಜನರಿಗೆ ಗೊತ್ತಾಗಿ ಕನ್ನಡ ಟೈಪ್ ಮಾಡೋದಕ್ಕೆ ಶುರು ಮಾಡಿದ್ರೆ ಸಾಕು.

ವಿಡಿಯೋ ಬೇಡಾ ಅಥವಾ ವಿಡಿಯೋ ಸರಿ ಇಲ್ಲಾ ಅನ್ನೋರಿಗೆ ಕೆಳಗೆ ಸ್ಕ್ರೀನ್-ಶಾಟ್ ಗಳೂ (screenshots) ಇವೆ. ಅದನ್ನ ನೋಡಿ, ಅದರ ಜೊತೆ ಇರೋ ವಿವರಣೆಯನ್ನ ನೋಡಿ ಕನ್ನಡ ಕೀಬೋರ್ಡ್ ಶುರು ಮಾಡಬಹುದು. ಈ ವಿವರಣೆಯನ್ನು ವಿಡಿಯೋಗಾಗಿ ಇಂಗ್ಲಿಷಲ್ಲಿ ಬರದಿದ್ದೆ. ಆಲಸಿಯಾಗಿರೋ ನಾನು ಅದನ್ನ ಹಾಗೇ ಕಾಪಿ-ಪೇಸ್ಟ್ ಮಾಡಿದ್ದೇನೆ, ಸ್ವಲ್ಪ ಎಡ್ಜೆಸ್ಟ್ ಮಾಡ್ಕೋಳಿ :)

ಈ ವಿಡಿಯೋಯನ್ನ ನಾನು ಏನೂ ಶ್ರಮ ಹಾಗೂ ಖರ್ಚಿಲ್ಲದೆ Stupeflix (http://studio.stupeflix.com/) website ಅಲ್ಲಿ ಮಾಡಿದ್ದು.  ಅವರಿಗೆ ತುಂಬಾ ಧನ್ಯವಾದಗಳು.

ಸಿರಿಗನ್ನಡಂ ಗೆಲ್ಗೆ

ವಿಡಿಯೋ

ಸ್ಕ್ರೀನ್-ಶಾಟ್ ಗಳು

Open control panel and click on "Change Keyboard and Other input methods".
If you can't see it, make sure to set the view to "Category" in the right top.

A new dialog pops up. Click on the "Change keyboards" button in the new dialog box.

Another dialog pops up showing you the keyboards currently in use. Kannada keyboard will not be shown there yet. You will see it after adding it. Click the "Add" button.

A new dialog pops up with a list of all available keyboards. The keyboards are arranged in alphabetical order. You will find Kannada almost at halfway in the list. Scroll down, choose the "Kannada" under, "Kannada, India" entry, by checking the box.

Click "Ok" in this dialog box, and also in every other dialog that opened up in the previous steps.


Now you should see a small language bar in the right bottom of your screen. Clicking on it will allow you to change the language.

Alternately you can change the keyboard language by pressing "Alt + Shift" keys together.

You can start typing kannada whenever you want after changing the language.

Initially, use the "On Screen Keyboard", to understand how the keys are laid out.

To launch the "On Screen Keyboard", open the windows menu and type the letters "o s k".

The o s k dot e x e will be listed under "Programs". Click it, to launch the "On Screen Keyboard".

The "On Screen Keyboard" program launches. It starts as an English keyboard, by default.

Change the language using the language bar in the right bottom or by pressing "Alt + Shift" keys together.

Once you change the language, the "On Screen Keyboard" will show the "Kannada" letters.

Take a closer look at the keyboard layout.

To the left are the vowels or also known as "swaraa" and to the right are the consonants, also known as "vyanjanaa".

Observe the keyboard for a little while to understand the layout.

Open a notepad and start typing kannada in it with the "On Screen Keyboard". A letter is formed by the combination of a "vyanjanaa" and a "swaraa". Try out the various combinations.

Once you have little familiarity with the layout, minimize the "On Screen Keyboard" and type using the real keyboard.

Please be patient and practice regularly to be able to type easily. It will be difficult initially, but it will be a JOY later.

Good luck!

Transactions - both single node and distributed - are hardwired in Windows - since Win 95

Transactions or "Atomic Transactions" to be precise, are very well known to anyone who has worked with databases. With the recent advent of NoSQL databases and the CAP theorem being used/abused by anyone and everyone, words like "consistency" and "transactional model" have become run-of-the-mill jargon. But what is actually interesting is that the concept of transactions or transactional model goes beyond our typical RDBMS. Things get even more challenging when we try to achieve transactions in a distributed system. Because transactions inherently lock the resource(s)/data they are operating on until the transaction completes, those resources can become inaccessible altogether very easily in a distributed setup if one of the node fails or if there is some problem with the network or any such thing, there by increasing the complexity of implementing distributed transactions by many folds compared to transactions on a single node.

Today I was trying to figure out if there is a way to "simulate" (albeit it will be very crude) some sort of transactions in my application which uses MongoDB (which doesn't support transactions by design - to avoid the locking mentioned above, although ironically there is a global write lock..!!). Searching on the internet lead me to this blog of a Raven DB developer. The author there mentions that RavenDB supports both sharding and transactions, which means it has implemented distributed transaction support. At first read I was pretty impressed (this was the first time I had heard about RavenDB). Before I could ask the author about the implementation details I saw a comment in which the author had mentioned that they use DTC (which again was a new thing). Turns out DTC, Distributed Transaction Controller, is a service that is baked right in the Windows OS itself, that too dating back to the Windows 95 days (wow.. now I am impressed with Windows..!). Here is the MSDN article describing the service.

The MSDN article clearly explains the basics of distributed transactions and how it is modeled. What is worth noting is that, by abstracting out the code for carrying out distributed transactions as a service, multiple resource managers (like different databases, queue servers, file servers/managers, etc..) can all interact together in a single transaction. For example, lets say that you have web application where in a client request results in a job being picked up from a queue for processing and simultaneously you update the status of the job in a DB and also create a new file associated with the start of the job. Very evidently all the three resource managers and the web application itself can be (very likely will be) on different nodes. With something like DTC you can easily create a new transaction, send across a commit message and you will get a success notification only if all three actions were successful or else none of the actions go through. Of course, this is possible only if all the three resource managers involved here adhere to the Microsoft's DTC specification and provide the necessary interface to work with it.

The previous example might make DTC appear like this Jason Bourne kind of super dude who can take care of all the heavy lifting and also do it very efficiently. But remember even Bourne gets shot at and also loses his girl. So DTC is not fully immune to problems either. Here is one blog post titled "My beef with MSDTC and two phase commits". It is definitely worth reading. Note that my impression about DTC is purely based on reading the documentation. I have not written a single line of code using DTC.

Microsoft's Virtual Wifi adapter ( or virtual wifi card) -- cool technology

I wasn't aware of the very interesting research on Virtual Wifi Adapters that Microsoft guys have been carrying out. Apparently they have been doing it for quite some time now. What this research group is trying to do is basically allow us to have an unlimited number of "virtual" wireless cards on our computers, each connecting to a different wireless connection, and all of it using just a single physical card. That is some awesome stuff.. !

A couple of days ago I opened up the Dell Support Center tool on my laptop and it popped up a message saying a device on my system is in the disabled state. I was pretty startled to see that, as pretty much every device on my laptop is used by me daily. On clicking the message it told me that the disabled device is "Microsoft Viritual Wifi Miniport". That did not make any sense to me. I had absolutely no clue about this device.

Searching the internet led me to this Microsoft page (along with several others, of course) which gave me a fair idea of what this device might be, but nothing concrete. It was this fine article on istartedsomething.com that clearly explained what this is all about. In the same article the author tells us that Microsoft has been carrying out research in this regard for a few years now. But nothing was given to end users until Windows 7 baked in this wifi card virtualization natively. And not just that, all WiFi card providers are expected to add support for this virtualization in their drivers if they want their drivers to be properly signed digitally and recognized by Windows during installation. I say that is "Wicked cool".. :)

About the technology itself, it can be described as a way to make "software copies" of your Wireless card and use those copies to "connect to multiple networks simultaneously".  Although research prototypes can apparently create any number of virtual devices over the single actual hardware device, Windows 7 limits it to just one copy/virtual device.

This whole research is doubly fascinating.

First because the applications of this research work are very interesting. One such application is explained in the article mentioned above. It talks about being able to connect to an existing wireless access point with your laptop and at the same time making your laptop a wireless access point in itself. It means, if someone is far from the actual access point and your laptop happens to be closer, he/she can connect to your laptop instead and your laptop will forward their connections to the actual wireless access point. Of course, this can only happen when the two laptops involved are in the same security/trust group. I wouldn't go on and connect via some random stranger's laptop. It is like letting that person look at all the data coming in and going out of your computer over the internet (or network in general). Despite such caveats, this is very much a practical use case. May be you wouldn't use it to be a hop in the network (or more like a virtual signal booster), but you may use it to make P2P/direct connections with another laptop close by for sharing files instead of doing over the wireless LAN. Or, if access to wireless network is possible only after you authenticate via certificate (like in a corporate setup) and the certificates can be put only one of your laptops (the official company laptop), the connection sharing will indeed come in handy.

Secondly, and more importantly, the complexities associated with this are lot and that makes it all the more exciting. If we delve a little deeper into what this virtual adapter is and how it works, we will see that it is actually a piece of software sitting between the actual device driver and the rest of the network stack (i.e. all above the MAC layer in the OSI model). This little piece of software is supposed to appear as one or more "devices" to the OS and hence it invariably has to have its own device driver. That is the "Virtual WiFi Filter" driver or VWifi driver. This VWifi driver tells the OS that there are multiple wireless cards and the OS then allows the user to connect to different available wireless connections via these virtual cards. But note that all this time, there is only one physical card and hence at any given point in time that one physical card can be connected to (or can communicate with) only one wireless network. It is the job of the virtual adapter software to cycle over all the virtual wireless cards and service the network requests made through them using the one physical card, in a time shared manner all the while keeping it transparent to the user. Although it sounds very similar to the kernel's process scheduling which makes use of the single processor in a time shared manner, this is actually somewhat different because of the way wireless networks work.

Note that different wireless networks behave differently. They might be operating at different frequencies, they might be having different authentication/encryption schemes, the bandwidth might be different and probably many other factors that I can't think of right now. So every time the actual wireless card switches to a different connection, there can be a shift in all or some of the above mentioned attributes. The card might have to step up or down its operating frequency, change to a different encryption scheme and all of this on the fly. Now that is a lot of work to do and in fact all of this switching can just drag the network performance to the ground. This makes the design and implementation of the virtualization software pretty challenging. This and many other challenges/caveats are discussed in this Microsoft Research's FAQ page.

I have been very excited about this research work ever since I read it and have been meaning to try out writing some network code using the virtual adapter. Sadly I have zero experience in network programming in Windows and currently don't have enough time to read up all of that. I hope such a thing will come up in Linux some time soon, if it isn't already there.

Changing the start up directory of command prompt -- The safe and simple way

By default, the command prompt window (cmd.exe) starts in a particular directory which depends on quite a few factors. Specifically, the env varibales %HOMEDIR% and %HOMEPATH% matter the most or these are the ones which ultimately decide the location. There are some registry values also, but they are not in the game by default. This leads to the command window to start up in something like C:\Documents and Settings\<username>\ which is not particularly useful as this location is rarely used for anything useful. It can get worse. In a corporate environment it might so happen, more often than not, that your home directory is set to a shared network drive using a group policy and the command prompt starts in that remove drive location.. ! The pain can be aggravated if you are on VPN or something similar.

I personally feel that command prompt, which is mainly programmers tool, should not start in %HOMEDIR% as there are rarely (mostly never) any programming related files are kept. Anyways, there are many ways to solve this problem.

The first of them and the most dangerous is fiddling with the registry. It is mentioned here : http://windowsxp.mvps.org/autoruncmd.htm
The problem with this is that it will screw up make based build environments which spawn multiple child shells (aka command prompts), because the command prompt will start in this changed default location instead of the location where the make had to run.

The next is fairly simple and also elegant. You can create a shortcut to the main exe (C:\Windows\system32\cmd.exe) and in the properties of the shortcut you can provide the directory to start in. This good for mouse users. However for those (most programmers) who start command prompt from the run dialog (by typing cmd) this will fail.

The third solution is to deal with the previous solutions shortcoming. You can just create a batch fail in any of the locations where the run dialog looks into. I prefer C:\Windows\systme32\. Put the following line in the batch file: C:\Windows\system32\cmd.exe /K "cd <path-to-dir>" . Just replace the <path-to-dir> with the path where you want the command to start. I generally put it as C:\.
This will start a command window and execute cd <path-to-folder> and will stay for further inputs. I have named this batch file as sh.bat (obviously to get a linux feel :P ). So now when I press the Windows + R key and type sh, I get the command prompt started in C:\.
Done.
And yes, this is totally safe and will not affect any other application using cmd.exe. :)

Recursively rename files in windows

My friend Prasanna B P asked me to solve a bunch of problems that he was facing with his computer. One of them was fairly common and there was a very easy and straight forward brute force solution. But coming up with a "smart" was really interesting.

Essentially some malware had renamed all the movie files that he had to carry a .jpg extension. His initial solution was to associate those jpg files with a movie player like Mplayer123 or VLC and the file would be invariably played without any regard to the extension. But this made the genuined jpg pictures to be opened with the player.

The obvious solution was to rename all the files and change the extension. Manually doing it from the GUI is the brute force idea that I earlier mentioned. And it is a totally crappy one. Next I can rename all files in a directory from the command line. But here the movie files were in directories of their own and hence I would have to move to each directory manually and run the rename command. This makes it as good as the GUI approach. In fact the extra effort of typing the commands might make it worse.

The I searched the internet a little and got to know that the windows command shell supports a "FOR" statement which can be used to recursively traverse directories, amongst many other things it provides. Using that I found this command:

FOR /R %x IN (*.jpg) DO ren "%x" *.avi

from this website : http://stackoverflow.com/questions/210413/command-line-recursive-renamemove-in-windows

People used to Linux Shell scripting might think of this as a wierd syntax, but yeah thats the windows choice.

It was good to do some Windows Shell scripting too. :-)

Changing directory in which command window opens

For some reason my command prompt always opened up on my mapped network drive. That was probably because the network drive was set as my home or something. It was the sys-admins work about which I did not have any clue.

Every time I had to change to my local disk drive and then navigate to the directory I wanted. Also the network drive caused a lot of delay when it was not available, making my PC freeze at times and there by making me very irritated. So I finally decided to get rid of the network drive. But I couldn't and I had to settle for changing the default location in which the command window opens. The link below has all the details for doing the needful. As usual with windows its a registry value :-)

HKEY_CURRENT_USER \ Software \ Microsoft \ Command Processor
              |
              |
              |____ Autorun =

How to change the default startup directory for Command Prompt?

BTW, It mentions that this setting will render the "Open Command Window Here" XP PowerToy. Nothing like that happened to me, at least not yet. So you can be assured that both of these will work in harmony.

Happy Commanding. ;-)

Editing remote files smoothly in vim on windows

I have a laptop and a desktop. Desktop runs Ubuntu, by choice, and laptop has to run Windows, by force. But most of my work happens on the Linux desktop itself. So when I am away from the desktop I would login to my desktop via SSH using PuTTy. It works fine when I am still on the corporate LAN, but the problem starts when I go home and get on to VPN. The speed and the responsiveness simply demotivates me and I tend to waste a lot of time specially when I am editing files with vim, because every keystroke has to travel across the network to my desktop and the response is to be sent back to my laptop. Coding really becomes hell with this.

Recently I got to know that VIM has identified this problem quite some time back and has a solution in store. You can open a remote file over SCP, where in VIM would bring down that file to the local system and store in some temp location. You edit that temp file, with VIM running on your own machine. So do not have to wait for keystrokes to be processed by the remote machine. When you write the file, VIM updates the remote file using SCP.

[Note]: If the file is read only, w! will not work. The user account used for SCP must have write permisson for the file you are editing. Otherwise, obviously, remote write fails and VIM will promptly report it.

Look at this page for the syntax and more details.

This would be straight forward on a linux box as both vim and scp come packed with the OS and they are in the shell execution path and everything is set up by default. Things need some extra work on Windows.

First obvious thing is to install VIM. Then you would need a SCP program. And once again PuTTy comes to rescure. They have a PSCP.exe, which makes you feel at home even on Windows. Get it here.

To improve this a little more you can rename the PSCP.exe to scp.exe and place it in "C:\Windows\System32\" so that it will be picked up from everywhere at the command prompt. Also note that you can use your PuTTy saved sessions directly with PSCP.

Happy remote VIMming. :-)

Hari Om

How libffi actually works?

I came across this libffi when I thought of working on js-ctypes. Though my contribution remained very close to nil, I got to know about this fantastic new thing libffi. But I did not understand how it actually worked when I first read. I just got a high overview and assumed that the library abstracts out several things that I need not worry about when making calls across different programming languages. I just followed the usage instructions and started looking at the js-ctypes code. That was sufficient to understand the js-ctypes code. But today when I was once again going through the README, I actually came across one line that made things a little more clearer. The first paragraph in "What is libffi?" tells it all. Its the calling conventions that this library exploits. I had written a post about calling conventions some time back. As mentioned in the readme file, its the calling convention whcih is the guiding light for the compiler. So when generating the binary code, thecompiler will assume will that the arguments that are being passed to that function will be available in some place and also it knows about a place where the return value will be kept, so that the code from the calling function will know where to look for it.

Now we know that the ultimate binary code that we get after compilation is the machine code. So it is basically a set of machine supported instructions. These instructions are certainly not as sophisticated as those available in the C - like the functions. So what do these functions transalte to? Nothing but a jump of IP(instruction pointer) to an address where the binary code of that function is. Inside this code, the arguments passed are accessed by referencing some memory location. During compilation the compiler will not know the precise memory locations (obviously). But the compiler has to put in some address there when generating the code. How does it decides on the memory location? This is where the calling conventions come into picture. The compiler follows these standard steps. Since its the compiler who is generating the code for both calling a function, where arguments are sent, and the code of the called function, where those args are received, the compiler will be knowing where it has put the arguments and hence generate code to use the data in those locations. From this point of view, the main(or is it the only one) condition for the binary code of a function to work properly is to have its arguments in the memory locations it thinks they are in and and the end place back the return value in the right location. And from what I have understood till now, it is this point that libffi exploits.

When we are forwarding calls from an interpreted language, like JS, to some binary code generated from a compiled language, like C, there are two things to be done:

0. As discussed earlier, whatever arguments are passed from JS are to be placed in the right locations and later take the return value and give it back to JS.
1. Type conversions -- The types used by JS are not understood by C. So someone should rise up to the occasion and map these JS types to their C counterparts and vice-versa.

The first of these is taken care by libffi. But the second one is very context specific and totally depends on the interpreted language. It does not make sense to just have a catalog of type convertors for every interpreted language on this earth. So these two steps were separated and spread out as two interacting layers between the binary code and the interpreted language code. libffi now takes care of the calling convention part and making sure the binary code runs and gives back the results. And the job of type conversion is the job of another layer which is specific to the interpreted language which wants to call into the binary code. And hence we have these different type converting layers for different interpreted languages: ctypes for python, js-ctypes for JS (and probably some more exist). Well with this renewed and clearer understanding I hope to actually contribute to js-ctypes.

Happy calling (with conventions) ;-)

Getting bluetooth working on your Thinkpad

I recently started using a Thinkpad T60p and its been good till now. Today I wanted to transfer some files from my cellphone to my laptop via bluetooth. It took my quite sometime before I figured it out(of course with the help of people around me). So I sat down to write this blog post.

Technically the thing is very simple but not apparent. The problem is that the default Thinkpad driver called the enhanced data transfer does not provide any UI to use the device for any sort of communication. Hence Microsoft guys have come up with a driver which will give you a nice System Tray icon from where you can launch settings, send or receive files and all such Microsoft goodies. So to use that one visit this page to download the driver. (Download the one named Microsoft bluetooth support). Run that executable to have the contents extracted to some standard location like: C:\Windows\Drivers\.... . Now do to Device manager -> Bluetooth Devices and click on "Update Driver" and select the above mentioned location where the extracted files are kept. This will install the new driver. Ideally you should be ready to use your bluetooth now. Even now if you are unable to use then go to the bluetooth settings (using the system tray icon) and select the "Hardware" tab at the end. There make sure the "Microsoft Bluetooth Emulator" is selected. After this your Thinkpad bluetooth should work.

Happy toothing.

Special chars and Escape sequences in .NET strings

Having come from C/C++ programming, and that too mainly console programming, escape sequences were very dear to me as they were my sole friends when it came to formatting the output. Now at work I work with C# .NET and things are not the same. I wrote a XSLT processor, as part of my job, and I wanted to log every successful XSL trasnformation. Well the file I/O was a lot easier with .NET types, but introducing an newline at the end of every log entry was a big pain. As I used to do earlier I simple put a "\n" at the end of the log message. This resulted in a empty square box being placed there instead of a newline. This was totally wierd and I started to wonder whether I have been writing Japanese???!!!

Then a little bit googling told me that .NET has encapsulated these special chars and newlines in a type called "Environment". This makes sense. Newline can be differnet in different environment. And with this encapsulation we get the correct newline for any environment.

So in C# if you want to add a newline to your string use the "Environment.Newline" object. VB .NET developers are, as usual, lucky with a easier encapsulation. They have a type called "ControlChars" and this can be used like this: "ControlChars.crlf" which of course is more intutive that something like environment.

Calling Conventions

This is the outcome of today's presentation by Anand - our tech lead.
There are four calling conventions, and the Microsoft terminologies for them are:

1. __stdcall
2. __cdecl
3. __thiscall
4. __fastcall

As its known, the calling conventions will tell who, amongst the caller and callee, will clear the parameters from the top of the stack when the function call completes.

__cdecl is the old 'C' way where the stack is cleared by the calling function. Clearing the stack is nothing but having a statement to move the stack pointer up by some number (which is generally the number of arguments). So when a call is placed, immediately after instruction to call, there will be an instruction to move the stack pointer. This way we have an extra instruction associated with every function call instruction. This leads to the increased size of the executable, because of one extra instruction for every function call.

__stdcall is the new way where every function is responsible for clearing the stack allocations made for its parameters. As in, the callee is the one who will rewind the stack and move the stack pointer. In this approach before the return statement of the function a statement to move the stack pointer is introduced. This way the number of instructions will not increase with the number of the function calls.

__thiscall is the object-oriented way of calling functions. Here the first parameter passed is always the "this" pointer. So any instance function member of a class will follow this calling convention. Unlike other parameters, which go to the stack top, the "this" parameter which is also passed is stored in "ECX" register. Now this is how the "this" pointer is implicitly available to all the instance member functions. No function can be explicitly qualified with this calling convention. Any instance member function will get this implicitly, but it can be over-ridden with any other calling convention.

__fastcall is an approach where in the system will try to push the parameters on to Registers instead of the stack just to get a performance boost. But as with the variable qualifier "register" , if the registers are not available then again stack is used for the parameters.

There are a couple of other posts regarding the specifics of the calling conventions and comparison. If this post made any sense then check out those also.

Intellisense in VS2005 stops working

Its a very well known issue with VS2005. Intellisense is not all intelligent, though it is programmed to be like that. It is indeed helpful and helps us avoid a lot of dog work and remember the big long names and types and parameters a function takes and all that regular crap. But the bad thing is that, the intellisense works fine for the first few days until we get addicted to it and one fine day when you are close to your deadline it suddenly stops working crippling you like anything and your work almost comes to a halt.

Thank god for editors like Vim and build systems which use "Make" and other command line tools. These keep our mind fit enough to do some exercise in case of emergency. Nevertheless we still want that intellisense thing to work, because we have this "IDE" here and it must be better than any editor. So here is how you get it working again:

• Close the solution.
• Go to the directory of the solution and delete the .ncb file.
  
• Re-open the solution and build it once. The .ncb file must be regenerated now. This must wake up intellisense again and get it working.
• If not then delete the obj directory of the project also and then build it again.

If none of these work then there is some serious problem that you should not try solving and stop reading this blog and read something useful.

VS2005 has a feature (supposedly) called "Copy Local"

VS2005 and .NET users are pretty familiar with the way the IDE makes the job so easy and keeps us away from all the build related things like references, linking and all that stuff. But in many cases this might actually be far from desired behavior. One such that recently took away some of my time was the "Copy Local" attribute on the references. This is a boolean property on the references added to a project. If this is set to true, then when the project is built the assemblies added as references as copied to the 'bin" folder of that project. Depending on the build, its either the "Debug" or the "Release" folder. With this, in future whenever the project is built, the DLLs in the bin directory are used, unless you change your references. This will cause a problem when one of the referred assembly is updated and you expect the new behavior, but get the old one instead.

Example, You would have added an assembly, E:\assemblies\MyAssembly.dll as a reference. Now when you want to update the assembly you typically replace the old MyAssembly.dll with the new DLL in the above mentioned location. And then you expect your project to reflect the new assembly, but it does not do that because "Copy Local" being true would have lead to the old DLL being copied to the bin folder of the project and though you updated the DLL in its original location, the reference was pointing to the DLL copied to the bin directory.

So watch out for this Feature. From what I know, this feature can be serialized in the assembly itself. Though this might be a good feature for applications which will use the same DLLs for a long time, this is clearly a bad choice for people who are writing small test applications to test their DLLs. Because with every new build the DLL version changes and yet the references point to the old one.

.NET GAC --- CompileTime v/s Runtime synchronization

GAC - Global Assembly Cache is just a run-time thing.

People familiar with .NET will surely know about GAC. Its just a one stop for any application running on the .NET framework to look for the assemblies (DLLs). When ever we run any .NET application, the framework will look for the referenced assemblies in the GAC. Note that even the version number of the DLL must match. If the application was compiled with an assembly 'A' of version 1.0 and you currently have anything, but 1.0, the application will not run. It needs exactly what it was compiled with. And the best part is that multiple versions can co-exist in the GAC

But this GAC look up happens only at the run-time. In Visual Studio, we will add the required assemblies for a project under the project references. These references will be pointing to the locations where the assemblies are present on the file-system and may be remote locations in case of web references. When we build the project the compiler will look at these locations and not in the GAC. Now if you are referencing an older assembly but we have a newer version in the GAC, then the project will compile but not run. Because at run-time the framework will look for the older assembly but does not find it in the GAC. So be sure of updating your references when your assembly of a particular version in the GAC is updated or replaced by an assembly of a different version.

This problem becomes still more evident and a little tricky when we are using an assembly(say assembly 'A') which again depends on another assembly (say assembly 'B'). And in such a case the problem can become evident even before compilation itself(If the assembly 'B' is related to designer of the Visual Studio). Say assembly A-1.0 was built using assembly B-1.0. Now when we use assembly 'A' by adding it as a reference to our project we are using assembly 'A-1.0' that was built using assembly 'B-1.0'. 'B' does not come into picture during compilation at all. When we build our project and run it, the framework looks for 'A-1.0' and finds out that it needs 'B-1.0' and finds both in GAC and runs the application. Here as 'B' does not come into picture during compilation, it is sufficient if we have it GAC, where as 'A-1.0' has to be at some location on the file system (either local or remote).

Now if 'B' in the GAC is updated, i.e 'B-1.0' is replaced by something like 'B-1.1', and you try to run the previously built application, it fails. Though the assembly referred by you , 'A-1.0' has not changed, the assembly 'B' which is necessary for 'A' has changed. So at runtime the .NET framework will search GAC and the current-folder for 'B-1.0' and as it would not be found, the application fails.

There are a couple of other posts about GAC and references in VS2005. Look out for those.

Registering and UnRegistering a DLL - Two ways

There are 2 ways to register a DLL.
Any DLL registration happens through the windows tool Regsvr32.exe present in C:\Windows\System32\

• The HARD-way: Using the above tool directly from command line. This is the obvious geekish way. This actually turns out to be simple after some practice. The command would be as per the following specification:

Regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname
/s - Silent; display no message boxes
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline];
     when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must
     be used with /i

• The EASY-way: Right-click on the DLL you want to register and open it with the above tool. Again the tool resides in C:\Windows\System32\. Thats it. The DLL if proper would be registered and error messages if any would be shown in an alert box.

I do not yet know of a easy way for unregistering a DLL. So for that command line is the way.