I have seen this bug in many blog posts: http://atifsiddiqui.blogspot.com/2010/11/windows-calculator-bug.html
Is this bug a code bug or a mathematical imprecision ?
I am wondering if its really a bug, How it got undetected for years ?
What should I take care to make sure that it doesn't happen in my custom caculator program.
Yes, it's a bug. The fact that it has a technical explanation (which is hardly acceptable to the layperson) does not absolve it from being a bug. If it's not a bug then you are either arguing that - as we all do on occasion - "it's a feature", or that it is a limitation of the system.
To resolve it I'd suggest you round every result to an acceptable precision level to remove the very small error. As the other answers suggest, the problem is that in your calculator the square root of '4' is not '2', but rather a number very close to 2. To resolve this round the result to 10, 20, 30 decimal places or whatever you can afford.
I'd argue that any calculator engine should have an underlying level of precision that exceeds the accessible level of precision by a large enough margin so that the user is not able to access the limits of float point arithmetic. You'll lose one form of 'accuracy' if you take this path, but you simply state that your calculator is accurate to n decimal places. That's more than acceptable especially if it resolves this issue.
However it's not really a big deal, is it?
As an aside, I once worked on a financial application where a vendor provided some software which was supposed to compute some compounding interest rates. Their calculations were always off. They argued that it was 'due to floating point arithmetic' and tried to educate me on the issue; but their algorithm was way off. When compounding interest rates on dollar amounts, we always round the total after each iteration (day, week, month, year or whatever). Depending on the situation it may round to the nearest dollar, nearest cent, or nearest 100th of a cent - but it is a quantifiable amount, and we never compound millionths of a cent from year to year. This is the approach that you should take if you want to avoid what is essentially a computation rounding error.