Suddenly, after having been worthless/dormant since its inception, the Feedster Windows Longhorn Buzz Feed has begun spouting useful information. Subscribed.

Richard Turner, a PM on the Indigo team, answers some of the Indigo questions that came up as a result of his recent Channel9 interview, including:

• Will .NET Remoting go away any time soon? (no)
• Will Indigo Services require IIS? (no)
• We need to support Windows 2000 and XP. Can Indigo Services be hosted on these OSs? (it’s not supported) Will applications running on these OSs be able to act as clients to Indigo Services? (absolutely)
• We expose some of our remoting assemblies via HTTP and host at least one in IIS.  Will Indigo Services offer interoperability with these configurations? (yes) Will we be able to write an Indigo wrapper around a remoting DLL? (yes)

I’ve just realized that Richard has turned into my most favorite Indigo blogger. He straddles the fence nicely between what is available today and what’s going to be available tomorrow. Thanks, Richard. We need you. : )

Ashvil DCosta, a software professional in Bangalore writing a book on outsourcing software product development, posts his ideas about how Longhorn, particularly WinFS, will change the way we think about and develop applications.

“The Longhorn speech API offers baked-in functionality for voice commands inside the operating system (OS). This is a giant leap forward in the functionality provided by an OS. With the addition of an alternate user interface, products in the future may have a much different mode of interaction than currently used. Through the course of this article, the basics of voice input and output will be shown, as well as the construction of grammar, and how to act on recognition.”

[via Paul Lamere]

Rob Chandler, a Microsoft Help MVP, has posted a look at where he sees User Assistance heading in Longhorn, both in the UI and in the new help system. I see Longhorn as an opportunity to crank user experience up a notch in every way and user assistance is an important part of that.

I’m a big cmd.exe user and was a big Korn Shell user before that, so command shells are an important part of my life and thus, I’m skeptical of new ones. However, I’ve been drooling over MSH (the Microsoft Shell — codename Monad) ever since I first saw it. In fact, when I saw Karsten’s post on getting the Monad bits for Windows XP and 2003, I was much excited. Then, I saw the Fundamentals Pillar topic on The .NET Show, which featured Jeffrey Snover (The Father of Monad) in the back half of the show and I was hooked. The way he told the Monad story motivated me to register for the public beta of Monad via Karsten’s instructions and wait impatiently over the weekend to be awarded permissions to download the bits.

Which I promptly installed on the WinHEC build of Longhorn (build 4074), even though it’s only supported for Windows XP and Windows 2003.

As it turns out, Longhorn comes with an earlier preview of Monad, but it’s much older than the latest Monad drop. So, I installed the latest Monad on the latest Longhorn, hoping that it would work and that I could follow along with my new hero Jeffrey.

And follow along I did, because not only did the latest Monad bits install and run just peachy under Longhorn, but the included Getting Started docs gave me hours of fun! With the functionality that Monad provides, I’m going to have a hard time going back to anything else.

If you’re a command-line person, I recommend getting on the Monad beta, taking it for a spin and letting those guys if there’s anything you don’t like (for example, I miss the “start” command, but I think I’ll go build it…).

There are two companies vying to be your XAML vendor today to help you get read for Longhorn tomorrow. Mobiform released an updated XAML viewer today that can convert from SVG to XAML and show XAML on your existing .NET machines. Xamlon has been on a hiring spree, today bringing on Ben Cantlon. I don't know Ben, but he's asking for suggestions on what his company can do today to move you to XAML that works on .NET today and Longhorn tomorrow.

The benefit of 3D support in Avalon is not the 3D support itself (we’ve had various ways to do 3D stuff in Windows apps for a while now, including both OpenGL and DirectX). The benefit is the tight integration we get between 3D and 2D elements in Avalon (and we’ll get even closer integration as we move closer to the Longhorn release).

For example, in his Avalon 3D Hit Testing Demo, Daniel Lehenbauer shows how hit testing can move into a ViewPort3D element (the representation of a 3D scene in an Avalon display) into the specific element being clicked. In other words, you can have a Button right next to a ViewPort3D showing a teapot and your app can easily tell which one was clicked. Handling a teapot click is slightly harder than handling a Button click simple because the Button does it’s own hit testing, but the Avalon 3D hit testing supports advanced features like clicking through the handle of the teapot w/o that being classified as a “hit,” all of which Daniel explains nicely in his sample.