Naming convention for APIs in the 64 bit world

We are having a little debate
internally on an issue around naming conventions for moving APIs to the 64bit
world. ns = "urn:schemas-microsoft-com:office:office" />

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; }

Thoughts, other
suggestions?