Matevž Gačnik's Weblog

The PDC just started. I'm sitting at a pre conf session hosted by dbox, tewald and mgudgin.

In half a day I will be on a plane to Frankfurt, then off to LA.

It's gonna be a jolly week.

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.

Eric Maino writes about an obvious example of misleading writing on this Microsoft page.

I tend to agree. What should also be emphasized is that Web Services are not the only core feature of .NET. There's more meat behind the curtain.

After numerous unsuccessful attempts to contact the Microsoft UDDI team I emailed Karsten Januszewski directly and he managed to get it fixed in less than a day. Thanks Karsten!

We are now at level 2, so we can publish whatever we want. Currently we have seven services and this weblog registered.

What's interesting is that the UDDI categorization scheme seems to have changed. One can now do a successful search in InfoPath/VS.NET only if a service is assigned to wsdlSpec category.

Based on this and this, one can conclude that Avalon and Indigo are both based either on high level interfaces or Don/Chris have god-like memory.

I hope it's the former. It it is, it's going to be a jolly year. If it isn't and the memory statement is true, then Emacs support will drop.

My Inbox is drowning under Swen infected emails. It's getting serious, since I'm getting almost a mail per minute. It seems to me, that the intensity has doubled in the last few hours.

Virus/worm/trojan writers should be treated with <insert your punishment>.

We are unsuccessful with our emails to Microsoft UDDI team to upgrade our UDDI account to level 2 status. If anyone knows an appropriate contact or is able to help directly, please do so.

UDDI Provider name: Gama System
Current UDDI level: 1

The last post generated quite a stir, and I know why, but I deleted it anyway.

I'm actually not under Whidbey NDA, but to keep myself from disclosing something that is one month from being publicly available, and to keep everybody who has a hard time being silent about this happy, I'm shutting it down.

Thanks for reminding.

Since Jeff is having trouble finding a hotel for PDC, here's one I'm staying at. Reserved today.