We are having a little debate internally on an issue around naming conventions for moving APIs to the 64bit world.
We made a few design mistakes in V1 and exposed some properties that are really word sized as Int32’s rather than Int64s. I don’t think there are very many of these, but it seems we need a common pattern for any we do dig up…
Here is an example. On the Process class today we have:
public int VirtualMemorySize { get; }
public int WorkingSet { get; }
As you know we can’t just change these to return longs as that would break apps complied against V1 or V1.1 when run on Whidbey… We also can not add overloads that return longs as the properties must differ by more than return type (btw, this is a CLS rule not a runtime rule, the runtime is just fine with overloading on return type.. now the only problem is finding a language where that is valid 
). So we are left we having to make a name change…
We feel strongly we want a postfix so the properties sort correctly in initellisense. The two front runners are:
XxxLong
Xxx64
So that would be:
public long VirtualMemorySizeLong { get; }
public long WorkingSetLong { get; }
Or
public long VirtualMemorySize64 { get; }
public long WorkingSet64 { get; }
[Via: http://blogs.gotdotnet.com/BradA/permalink.aspx/28a2833b-0eba-43fa-9ce6-9a36d13c4f79]
Use the XxxLong suffix. Long will remain 64 bits long from now till the end of time. 128 bit address space is for science fiction writers. And this isn't "640 kb should be enough for everyone.".
Everyone should remember that 2^64 is 2^32 TIMES more that 2^32.
If for some strange, atom-splitting reason 2^64 would not be enough, it would surely not be called Long. And no, "we've been wrong before" does not stand here.