Wednesday, September 29, 2004

Ensuring all applications run on latest CLR

If you want to ensure that all applications run on the latest CLR installed on your system, you just need to change some registry settings or set a flag in VS.NET 2005 (Beta 1). There is a switch in VS.NET 2005 (Beta 1) which does this.

Doing it with registry:

To turn on the switch
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\.NETFramework\OnlyUseLatestCLR=dword:00000001

To turn off the swtich
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\.NETFramework\OnlyUseLatestCLR=dword:00000000

Monday, September 27, 2004

Reverse

Try this game- Reverse. Its awesome . Got it from Eric's Blog. I'm done with it...and still moving the mouse in opposite direction. :P

Thursday, September 23, 2004

Monad September 2004 release available

Monad September 2004 (Partner Drop 3) release is available for download at MS Beta Site with some new features in it :)

Friday, September 17, 2004

More on HashCode...

Continuing to my previous post, I was wondering how this HashCode is calculated. On what basis this hashcode is returned.
Here are my conclusions::
Object.GetHashCode returns an index to an internal SyncBlock table that CLR maintains for object synchronization. Each element of this internal table is reference of the SyncBlock for an object.
Also I gave some logical reasons why we get a duplicate HashCode. After knowing how the HashCode is calculated, I deduced that when the object is alive in memory, HashCode functions returns the index of the internal table where the SyncBlock reference is stored. Now when the object is dead or is not in memory any more, this table entry gets empty or null. When new object is created, its SyncBlock reference is also needed to be stored in this table. System might use the same table entry to store the SyncBlock reference for this new object. This is the reason why we get duplicate HashCode for different objects.

Saturday, September 11, 2004

Object.GetHashCode()

Object.GetHashCode () gives us the hash code for an object. But as the documentation says, we should not use it for uniqueness. Because every object will give a hashcode and it will be same till the object lives. There can be cases where two different objects have same hashcode. This is very much possible. This is because Object.GetHashCode () returns an integer which contains a 32 bit value. And if there are more than 2^32 objects living in memory, then the hash code tends to repeat thought they are different objects if checked using Object.Equals() method. I’m not saying that only after 2^32 objects in memory, the hash code will repeat, but this is one case where the hash code can repeat. Also hashcode is an integer and it can have at the most 2^32 values. So, the hashcode can repeat. I tried to make the hashcode repeat on my system. Here is the code for it.

Hashtable hsTable = new Hashtable ();
while (true)
{
object obj1 = new object ();
int _hashCode = obj1.GetHashCode ();
if (hsTable.ContainsKey(_hashCode))
{
Debug.Write("Duplicate Hashcode: " + _hashCode);
break;
}
hsTable.Add(_hashCode, null);
}

Result:
Duplicate Hashcode: 65193

So, we do get same hashcode for different objects. MSDN says: “The default implementation of GetHashCode does not guarantee uniqueness or consistency; therefore, it must not be used as a unique object identifier for hashing purposes”. Hence proved :)

There are more things to talk about Object.GetHashCode(), but I’m still working on them!

Thursday, September 09, 2004

What is WOW64?

I was searching some information when i came across Josh's blog.
What is WOW64 and what does it mean to managed applications that run on 64 bit machine?

um...pretty interesting :)