I was sad when "Indigo" and "Avalon" went away. It'd be great if we'd have a pool of cool legal-approved code-names for which we own the trademark rights and which we could stick to. Think Delphi or Safari. "Indigo" was cool insofar as it was very handy to refer to the technology set, but was removed far enough from the specifics that it doesn't create a sharply defined, product-like island within the larger managed-code landscape or has legacy connotations like "ADO.NET".  Also, my talks these days could be 10 minutes shorter if I could refer to Indigo instead of "Windows Communications Foundation". Likewise, my job title wouldn't have to have a line wrap on the business card of I ever spelled it out in full.

However, when I learned about the WinFX name going away (several weeks before the public announcement) and the new "Vista Wave" technologies (WPF/WF/WCF/WCS) being rolled up under the .NET Framework brand, I was quite happy. Ever since it became clear in 2004 that the grand plan to put a complete, covers-all-and-everything managed API on top (and on quite a bit of the bottom) of everything Windows would have to wait until siginificantly after Vista and that therefore the Win16>Win32>WinFX continuity would not tell the true story, that name made only limited sense to stick to. The .NET Framework is the #1 choice for business applications and a well established brand. People refer to themselves as being "dotnet" developers. But even though the .NET Framework covers a lot of ground and "Indigo", "Avalon", "InfoCard", and "Workflow" are overwhelmingly (or exclusively) managed-code based, there are still quite a few things in Windows Vista that still require using P/Invoke or COM/Interop from managed code or unmanaged code outright. That's not a problem. Something has to manage the managed code and there's no urgent need to rewrite entire subsystems to managed code if you only want to add or revise features. 

So now all the new stuff is now part of the .NET Framework. That is a good, good, good change. This says what it all is.

Admittedly confusing is the "3.0" bit. What we'll ship is a Framework 3.0 that rides on top of the 2.0 CLR and includes the 2.0 versions of the Base-Class Library, Windows Forms, and ASP.NET. It doesn't include the formerly-announced-as-to-be-part-of-3.0 technologies like VB9 (there you have the version number consistency flying out the window outright), C# 3.0, and LINQ. Personally, I think that it might be a tiny bit less confusing if the Framework had a version-number neutral name such as ".NET Framework 2006" which would allow doing what we do now with less potential for confusion, but only a tiny bit. Certainly not enough to stage a war over "2006" vs. "3.0".

It's a matter of project management reality and also one of platform predictability that the ASP.NET, or Windows Forms teams do not and should not ship a full major-version revision of their bits every year. They shipped Whidbey (2.0) in late 2005 and hence it's healthy for them to have boarded the scheduled-to-arrive-in-2007 boat heading to Orcas. We (the "WinFX" teams) subscribed to the Vista ship docking later this year and we bring great innovation which will be preinstalled on every copy of it. LINQ as well as VB9 and C# incorporating it on a language-level are very obviously Visual Studio bound and hence they are on the Orcas ferry as well. The .NET Framework is a steadily growing development platform that spans technologies from the Developer Division, Connected Systems, Windows Server, Windows Client, SQL Server, and other groups, and my gut feeling is that it will become the norm that it will be extended off-cycle from the Developer Division's Visual Studio and CLR releases. Whenever a big ship docks in the port, may it be Office, SQL, BizTalk, Windows Server, or Windows Client, and as more and more of the still-unmanaged Win32/Win64 surface area gets wrapped, augmented or replaced by managed-code APIs over time and entirely new things are added, there might be bits that fit into and update the Framework.  

So one sane way to think about the .NET Framework version number is that it merely labels the overall package and not the individual assemblies and components included within it. Up to 2.0 everything was pretty synchronized, but given the ever-increasing scale of the thing, it's good to think of that being a lucky (even if intended) coindicence of scheduling. This surely isn't the first time that packages were versioned independently of their components. There was and is no reason for the ASP.NET team to gratuitously recompile their existing bits with a new version number just to have the GAC look pretty and to create the illusion that everything is new - and to break Visual Studio compatibility in the process.

Of course, once we cover 100% of the Win32 surface area, we can rename it all into WinFX again ;-)  (just kidding)

[All the usual "personal opinion" disclaimers apply to this post]

Update: Removed reference to "Win64".

Categories: IT Strategy | Technology | ASP.NET | Avalon | CLR | Indigo | Longhorn | WCF | Windows

August 30, 2004
@ 09:55 PM

Ok, ok. I've said this over and over to Microsoft people over the past year and I can finally say it out loud. Ah, no, I won't. I'll just link.

Categories: Longhorn

January 12, 2004
@ 05:58 PM

So my new notebook is an Alienware Area-51m. It's really, really fast, and looks great, but as of now, it doesn't get past the boot screen when I try to install Longhorn. The Longhorn boot screen starts fading in and the machine locks up. Win03 and XP work just fine ("great!" I should say). So I am sitting here, fiddling around with the install options and I am suspecting that something in the BIOS isn't quite like Longhorn expects it to be. To be continued ...

I am using shared networking in my Longhorn VPC and I could browse the web and connect to the network. So to make working on the network a bit easier (and to try some more features) I thought it may make sense to add the Longhorn Virtual PC on my box to our domain. Setting this up worked.

Now, if I boot up Longhorn and my box is connected to the network, I get to see "Press Ctrl-Alt-Del to begin." and right after that, the VPC reboots. If I am quick enough to get to the logon screen, Longhorn reboots right after accepting the password. If I disconnect my machine from the network I can log into local LH accounts just fine.

Categories: Longhorn

Because most teams at Microsoft seem already a milestone or two ahead of what the Longhorn and Whidbey PDC builds reflect, how much is it worth to report bugs?

Hello? Redmond? Comments?

Categories: Longhorn

October 28, 2003
@ 07:55 PM

I’ve got the PDC build running on my box. Jim Allchin was right; it isn’t exactly screamingly fast – at least in Virtual PC. Here are a few notes:

·         Needless to say, but: Have a dedicated box for Longhorn or use Virtual PC. I’ll likely get a new box when I am back at home. Sounds like a machine brutally optimized for 3D gaming is a good bet – along with 2GB of memory.

·         If you can’t at least assign 256MB of memory to the VPC machine, forget it. If you can allocate more, go for it. Shut down all apps and services on the host you can and give Longhorn room to breathe.

·         The VPC2004 from the PDC disks will remove any previous Virtual PC builds from Connectix. The version from the PDC disks will expire February 28th, 2004. Which means that I just went from a licensed copy to a demo copy. I don’t like that, at all.

·         You will need to log on to the windowsbeta.microsoft.com server to acquire your product key. The userid and password is in the disk booklet.

·         Take your time. Installing into Virtual PC takes a very long time. Expect that your box will take about 2-3 hours and I wouldn’t do too much on it during that time. Expect the box to lock up, requiring a hard reset. It did that several times for me.

·         I’ve mounted one of the ISO images from Disk 2 into VPC, which seemed to be the most convenient option.

·         On my Dell Inspiron 8100, Longhorn comes up in 4-bit color mode and that’s the only mode available. You will have to install the VPC additions into Longhorn to get a graphics driver that works, reboot and then switch to that one.

·         Just right after install, with nothing done, the VPC disk size stands at 3GB. I think you should have some 6-10GB available if you want to do anything with it but looking.

Categories: Longhorn