Engineering in the white spaces
VB.Classic was always prone to taking a contrary view of the world, usually in order to make life simpler for its users. For instance, while most languages considered true to equate to 1, VB.Classic stated that true was actually -1.
So when moving VB forward to .NET, the language team faced a dilemma. Should they redefine true to be the value used by the CLR and the majority of other .NET languages, or should they keep the same value of true to maintain compatibility with the terabytes of VB.Classic code already in existence?
Executing the following code shows that they decided to have their cake and eat it too.
The true value of true is actually not fixed - it depends on which view you take. If you use VB.Classic functions such as CInt, then true = -1. On the other hand, .NET functions such as Convert will return true = 1. As long as you always set Option Strict On in your VB code so that implicit conversions aren't performed, and as long as you always compare to true and false rather than to -1 and 1, you shouldn't have any problem with this double-headed beast.
You do use Option Strict On, don't you...?