Erwyn van der Meer

After further exploring Windows Vista it turns out that are some more components than just ASP.NET 2.0 that use managed code. The visuals of the new Event Viewer looked a bit funny and the UI performed sluggishly. Here's a screenshot of the new Event Viewer:

This new Event Viewer has gained quite a bit of functionality:

"Improvements to the Windows event logging service make the Windows Vista desktop easier to manage and monitor and provide better information for troubleshooting. Strict standards ensure that events are meaningful, actionable, and well-documented. Many components that stored logging information in text files in previous versions of Windows now add events to the event log. With event forwarding, administrators can centrally manage events from computers anywhere on the network, making it easier to proactively identify problems and to correlate problems that affect multiple computers. Finally, the event viewer has been completely rewritten to allow users to filter and sort events, control which type of events are logged, discover events more easily, and perform basic diagnostic tasks. This input makes it much more practical for administrators to use the event log to troubleshoot users' problems."

After firing up Sysinternals' Process Explorer my suspicions were confirmed: the CLR was loaded. After a couple of minutes it was undeniable when the Event Viewer crashed with the following managed code stack trace. Also note the new UI for sending crash reports to Microsoft:

The stack trace shows that the sluggish UI might be caused by the strange UI model chosen for the Event Viewer. The unmanaged Management Console (mmc.exe) process hosts the managed Event Viewer plug-in. This managed plug-in generates HTML code that is shown by using the Windows Forms 2.0 WebBrowser control. This control uses the unmanaged rendering engine of Internet Explorer to display a list of events. I hope that the final version will use Avalon and it's powerful databinding techniques for displaying a list of events.

Microsoft retracted the faulty setup of the WinFX SDK and replaced it with a new version. This version installed without a glitch on Windows Vista Beta 1.

I also installed the just released beta 1 of the ATI drivers for Windows Vista to get the best possible graphics experience. The Aero Glass theme runs without problems on my ATI RADEON 9800 PRO video card with 128 MB of memory. Unfortunately I am missing sound as there are no drivers for the Soundblaster Audigy as of yet. 

So now I could finally try out Adam Nathan's Avalon Cards Sample after compiling it. You can see it in the following screen shot. Notice the translucency of the non-client areas of the windows with the Aero Glass theme.

I can't notice if it runs any smoother than it did with the WinFX Beta 1 RC1 on Windows XP on my machine. Moving the mouse over the cards still produces a high CPU usage (up to 80%), so it seems not all work is offloaded to the GPU.

After the install of the WinFX SDK failed I tried to install Visual Studio 2005 Beta 2 on Windows Vista. The first attempt was unsuccesful because the MSXML 6.0 Parser could not be installed.

I remembered seeing an msxml folder on the Windows Vista DVD. It also contains an installer for MSXML6. Its location on the DVD is support\winfx\wcu\msxml\msxml6.msi. That version installed just fine. After that the Visual Studio installer detected that MSXML6 was already installed and did not try to install it again.

With that fix Visual Studio 2005 Beta 2 installed with no further problems.

At the end of my previous post I mentioned that I needed to download and install the WinFX SDK to run an Avalon sample app. After the downloading and starting the setup I ran into this error message:

After checking the digital signature of this file, it turns out that this signature cannot be verified:

because there is a problem with validating all the certificates in the certification path

I found some Usenet postings that indicate the same problem. And that's where it ends right now, because there is no solution available as of yet.

After installing Windows Vista and revealing that it has no significant dependency on WinFX or the .NET Framework it is on to the fun stuff. This is the view of the Games folder:

As you can see the icons are scalable to large sizes and are vector based. After this eye candy be prepared for some devastation:

These are old-style bitmap graphics that don't scale ;( Check out Adam Nathan's blog post about XAML cards for what could have been if Avalon had been used.

Very revealing is his reply to a comment:

"Thanks! To be clear, this is just a demonstration for the sake of developer education. I don't currently know what the plans are for the card games shipping in future versions of Windows."

I can't run his sample app even with WinFX installed, because it is not distributed in executable format.

Well I guess I have to try if the WinFX SDK and Visual Studio 2005 Beta 2 will install on top of Windows Vista. The WinFX SDK is not included on the Windows Vista DVD so I had to download it. Luckily the pesky Windows Genuine Validation tool thinks that my Windows Vista installation is genuine so I could start the setup. But then I ran into trouble. Check out my next blog post for more details.

After installing Windows Vista it's on to the R&D work. Note that this is done for LogicaCMG.

Microsoft Watch' Mary Jo Foley revealed in May 2005 the "dirty little secret" about Longhorn:

Developers say there's a dirty little secret about Longhorn that few Softies are discussing publicly: Longhorn won't be based on the .Net Framework. We're still expecting that the .Net Framework will ship with Longhorn–on the CD and/or "in the box" in some way. But the .Net Framework won't be at Longhorn's core, we hear.

And yep it is true. Windows Vista Beta 1 out-of-the box doesn't use the .NET Framework in any way! To prove it I took this screenshot of Sysinternals Process Explorer which highlights processes that have the CLR loaded in yellow:

Even worse "Avalon" and "Indigo" (or should I say "Windows Presentation Foundation" and "Windows Communication Foundation") and the rest of WinFX are not even installed! This is the "out-of-the-box" view of the .NET Framework directory. Note that the nice smooth big icons (in large icon view) for some files and folders were not produced using Avalon!

It seems the .NET Framework is only used for ASP.NET. Internet Information Server (IIS) is installed by default. The service is disabled by default but is easily enabled using the IIS management console plugin. It is not easy to determine the version number of IIS, but it seems to be a derivative of IIS 6.0 and not IIS 7.0. IIS is not configured to run ASP.NET by default and I found no other way to enable it than to run aspnet_regiis -i from the .NET Framework folder.

WinFX can be found on the Windows Vista installation DVD in the Support folder:

This is my first post from within Internet Explorer 7.0 running on Windows Vista. It is my account of the installation process of Windows Vista.

10:16 - Finished burning the 2.4 GB ISO image to DVD. Windows XP Autoplay offered to start the setup.exe on the new DVD.
10:17 - Started the installation from within Windows XP. I only had to answer three questions: 1) Where to install, 2) The product key and 3) The computer name.
10:18 - Windows Vista started installing from within Windows XP. No further user interaction was needed. I took this picture:

10:25 - First reboot. My Windows XP installation takes two minutes to shut down ;(
10:27 - First Windows Vista boot. The boot screen looks nasty:

10:28 - The installation continued. The following screen was shown for quite some time. Note that the progress bar didn't make any sense. It filled and cleared about once every minute.

10:48 - Second reboot. Same boot screen, but then followed by a black screen, followed by my monitor going into stand-by. Hmmm, not good I thought. Then I remembered something similar when installing an alpha build of Longhorn. I turned on my secondary monitor, and fortunately the installation was continuing over there:

10:51 - The installation is complete. Windows Vista is running interactively and I can switch the display back to my primary monitor.

So all in all a good setup experience. The process is much smoother than installing Windows XP for instance. Subtracting the two reboot time, installing Windows Vista took 32 minutes with only minor user interaction at the start required. On to my first explorations within Windows Vista in my next blog post...

The official names for Indigo and Avalon have been announced to be "Windows Communication Foundation" and "Windows Presentation Foundation".

I think I will have a hard time abandoning the Avalon and Indigo code names. Windows Vista is a better name than Longhorn, but these long names suck big time...

But the good news is that the WinFX name will stick! In fact officially it is WinFX™. Thankfully that won't become Windows Application Pack.

That blog post of JohnMont also lists the new features that Windows Vista will bring to the table. Note the absence of claims that WinFX™ as a managed API will cover everything that the Win32™ API offers.

Microsoft has released beta 1 of Windows Vista. You can download it if you have an MSDN Subscription from http://msdn.microsoft.com/subscriptions/. It's a hefty 2.42 GB DVD ISO download. I am downloading it right now but I guess I have to clean up my machine to make some room to install it. Hopefully the beta will feature the new OS installer which should get Longhorn installed in 15-30 minutes.

Mini-Microsoft is the blog of an anonymous Microsoft employee that from time to time spills his guts over how he feels about Microsoft and doesn't hold back. He is not too fond of managed code. Monday's post reveals that one of the high-ranking managers for the Office System product line is not too fond of the CLR either:

"It's interesting to see Mr. Steven Sinofsky's Technical Career Forum blog. Now, I don't know much about Mr. Sinofsky. But earlier in the year I was over in the absolute worst and poorly designed building on campus - #36, the home to just about all things Office - and the discussion about the current and previous releases of Office came up. Mostly around how Windows had screwed Office really really well over constantly slipping and cutting features that Office was trying to synchronize a release with. One thing related to me, that I have great respect for Mr. Sinofsky if true, is that Sinofsky more or less told anyone hawking a .NET CLR integration demand on Office to take that CLR and JIT it up where the sun don't shine. I have great respect for that."

So does this mean we should not have too high of an expectation for better CLR integration with Office 12?

Craig McMurthy has published an essay providing guidance on preparing for Indigo. As Craig mentions, he takes a different approach than two other guidance articles published by Juval Löwy and Richard Turner. Craig says:

"The approach that will be adopted in this document is somewhat different.  It begins not with isolated technical requirements, but with the larger context of a software development enterprise, and then goes on to identify some common application architectures, and to provide suggestions on how to implement those with technologies that are available now."

Craig's approach is interesting. He draws an analogy with a revolutionary new type of vehicle, that unifies the best of public transport, cars and private jets. This new transport will appear next year. It seems obvious to not invest in buying a vehicle that exists today, because that investment will be waisted. With that analogy it seems obvious to wait for Indigo and to not invest in today's technologies: Enterprise Services, Web Services and .NET Remoting.  Craig says:

"Asking which technology for communication among software entities one should adopt today anticipating the forthcoming release of Indigo next year, is about as absurd.  One should naturally begin using the prototypes of Indigo right now, and certainly forego any investment in existing technologies for the time being."

But what if you don't have any transport today and need to go somewhere tomorrow? You can't always wait for next year's promise. Even if you think Indigo Beta 1 RC is solid enough to use, you are not allowed to use it for production systems. It doesn't come with a "Go-Live" License.

I think the situation is not as bad as Craig portrays it to be. You can have your cake and eat it too. Microsoft is making sure Indigo will not completely alienate people using today's technologies. Would it be bad to invest in learning how to drive in next year's transport by driving a transport that has a similar interface? Next year you just swap the engine and chassis for a much more powerful one and you're done. The cockpit you are used to might remain quite similar. Yes, next year's transport provides a brand new and more powerful cockpit, but you are not forced to use it.

Read Juval Löwy's Preparing for Indigo-Choosing the Right Technology Today to decide if you should drive a train, a plane or a car if you haven't decided already. Of course test driving the beta of Indigo is highly recommended. But due to the uncertainty of the release date for Indigo you shouldn't stop thinking about today's technologies. I have been lobbying with Richard Turner to finally get the Proseware sample application created by Clemens Vasters et al released. It showcases a combination of Web Services (with WSE 2.0) and Enterprise Services for a Service Oriented system with a Contract First approach. Even though it was supposed to be released more than a year ago, I think it is still relevant guidance.

What do you think? Should we only focus on Indigo or are today's technologies just as relevant?

Microsoft's Matt Warren gives us a glimpse into the design process of C# 3.0 in a post titled XML Generics in C# 3.0. We're still left guessing (of course, it's not September yet ;) to what the syntax will be, but I have the feeling it's going to be something good.

Matt has a very nice writing style, with a good touch of irony, so check out some of his other posts. Especially his post on C# 4.0. A quote:

"Too soon, you say?  Are you kidding?  Of course not.  Look, the design staff here has to keep planning far in advance of the development juggernaut.  If we were not constantly leaping ahead into product plans n-versions out, the developers might start to think that the ship was drifting off course and that everyone was asleep at the helm. If that ever happened, the negative impact to employee morale would be devastating, sending productivity into the toilet, initiating a downward spiral of fear, uncertainty and drunken binge programming that we might never recover from. "

And Drug Induced Dreams. That one (from January 2004) contains the following hilarious segment:

"So Bill's updated his character sheet.  I'm not quite sure, does Knighthood count as an epic level paladin or a prestige class?  I was thinking about this last night while I sat playing a game at a friends house.  It's my once a week get-away from the family.  Not that I don't enjoy my wife and our son, but everyone needs to have at least one night off.  I encourage everyone new to parenthood to do the same.  It keeps me from burning out from too much stress.  Work can be stressful and so can kids."

I don't know much about parenthood, or if BillG reads his blog, but I instantly believed Matt.

Yep, the rumors were right. Windows Vista it is. I don't know yet if I like the name, but I like the C9Park comic on Channel 9 about it! Check it out.

This entry is a reply to the request from comments from Steve Main on "On the Utility of .svc files".

In my opinion the .svc file for an Indigo service hosted in IIS only has value if it contains substantial content and not just one line.

In ASP.NET 1.1 .aspx, .asmx and .ashx files can contain code that is just-in-time compiled when the corresponding URL is first requested. But when you have a complete code-behind model having that physical file serves almost no purpose and I would prefer the config approach to map URLs to classes that handle the HTTP request.

In my current ASP.NET project we use some .ashx files that have no code-behind (despite total lack of support in VS .NET 2003 for the non code-behind model). The reason for doing is that keeping everything in one file eases deployment and maintenance over several servers. But that said, these .ashx files have less than 100 lines of code and almost no dependencies. I wouldn't use this approach for anything bigger.

I dislike the strong coupling that IIS mandates between file extensions in physical file names and URLs to decide what ISAPI extension to use. Similarly I dislike how ASP.NET almost completely forces you to use the extension to decide which type of HTTP handler (factory) to invoke. Having this mapping in a configuration file instead of depending on extensions of physical files would be great. At my current project we go through great lengths to hide the .aspx and .ashx extensions from the URLs. I developed a custom HttpHandlerFactory to do this and I had to enable a wild card mapping in IIS to the ASP.NET ISAPI DLL. 

But please don't implement this config approach only for Indigo. Please make sure IIS, Indigo and ASP.NET will have a consistent model for mapping URLs to handlers. I don't know what IIS 7.0 will do in this respect, but I guess it's too late to enable this for ASP.NET 2.0. And of course Indigo goes beyond HTTP. I guess even when hosted in IIS, so it supports other types of URIs for service endpoints in the configuration file.

To conclude: I would say go for the config approach for mapping URLs to handlers (like Indigo services or ASP.NET pages) without relying on file extensions. But keep the possibility of optionally using a .svc file that contains code. So as to not alienate the quick-and-dirty coders that are used to how things work in ASP.NET.

Workflow will be a hot topic at the upcoming PDC. Already a whopping amount of nine sessions have workflow in the title or the description. Michael Herman has a listing of these sessions. He questions if there is one common workflow strategy behind this or if it is just a "technology fair". Michael says:

Is the PDC going to be one large Microsoft "technology fair" with no strategic intent other than giving each product group a venue to promote their own technology bits?

At PDC 2003 I was amazed at how Microsoft was able to present a coherent vision on the three pillars of Longhorn: Avalon, Indigo and WinFS. So Microsoft is likely able to present a coherent vision on workflow.

But of course that vision for one managed API, dubbed WinFX, that would replace Win32 fell apart after 2003. Longhorn will add several managed APIs with Avalon and Indigo. But internally Longhown will be primarily unmanaged code.

For example the Aero shell will not be written in managed code and will not use the managed Avalon API. But graphically Aero will be nothing like the current Explorer though. It doesn't use GDI32/GDI+. Instead it takes advantage of the Unified Composition Engine (DirectX based) through MIL (Media Integration Layer), which underlies Avalon.