Making sense of Windows code names

There's been much ado in the press about the recent branding of Windows code-named "Longhorn" to Windows Vista. Some people have jeered the new name, claiming Longhorn was somehow better. One has to understand that when you work on products, you are working with a bunch of ideas. Everything starts with vapor and you slowly flesh things out. The branding exercise comes toward the end. There are a lot of logistics involved in coining a name like Vista. Teams of people are often involved, scouring registered trademarks, looking at colloquial meanings, making sure the chosen word isn't offensive to customers' sensibilities, ensuring the name depicts the goals of the product and resonates with focus groups etc. The bar is just not high enough for internal codenames though.

I have a partial list of the progression of code names for Windows Client family products:

• Janus: Windows 3.1


• Chicago: Windows 95


• Memphis: Windows 98


• Millenium: Windows Me


• Daytona: Windows NT 3.5


• Cairo: Windows NT 4.0


• Whistler: Windows XP


• Longhorn: Windows Vista


• Blackcomb: the next big thing

The last three are interesting. Whistler was named after Whistler Mountain in British Columbia. Likewise Blackcomb was named after Blackcomb Mountain nearby. It's as if Whistler is where we were with XP and Blackcomb is where we want to be in the not too long term. I've heard that Longhorn was named after a bar on the way from Whistler to Blackcomb. And that makes sense. Metaphorically, it is a rest stop on our way to the destination.

Similar logic was probably used when the names Whidbey (Visual Studio 2005), Fidalgo (Visual Studio 2005 Extensions for WinFX) and Orcas (the next VS rev with tools support) were coined: all islands in the straits off the northwest of WA state.

For those who despair the renaming of Longhorn, I have this to say: just about nobody remembers Whistler (the codename) anymore. People are perfectly comfortable calling it XP. The same will happen to Longhorn. Besides, it isn't the name, rather what's in the product that makes the difference.

Tags: Microsoft

Email this | Bookmark this

RSS in everything and everything in RSS

I just installed the new MSN Screensaver Beta and gave it a whirl.



You can personalize it with your RSS feeds and photos. It supports MSN web search, tracks local weather and integrates with Hotmail and MSN Messenger presence. I like the slick, minimalist UI. Well, duh it's a screensaver.

Also noticed the folks behind Start.com have been working hard. The site has a much improved interface. Check out the search. Hmm, RSS? Ship it already!

Tags: Microsoft

Email this | Bookmark this

On writing

I've written previously about how a sound project plan lends to a successful project. The past 4 months have given me some good lessons on program management. In this post I'll talk in stream of consciousness mode about things I now know. The main focus here is on effective writing.

Projects live and die by their vision. You must know why and what you are building and for what customer. This ethic can be stretched to fit any part of your job function, especially your writing.

Prepare. I cannot overstate that. Read lots of books, articles and technical papers. Get a well rounded view; the big picture. Analyze things constantly. Ask questions. The effort you put into your research will show in the quality of your output.

Be open, humble and respectful. Use other peoples' experience. Trace ideas to sources. Respect people for their ideas. Engage them early and often. Keep them involved in your process. If not actively, at least keep them up-to-date on the status. For a smooth ride, get buy-in from important decision makers, preferably even before the spec is baked.

Whatever your role in a project, insist on getting the spec right before the code is written. The spec'ing process may take several iterations, so plan accordingly. It is easy to view a spec as an unnecessary intrusion of process. If you can make and solve your mistakes in the spec, you won't have to do them in your code. We all know the costs involved in refactoring later on in the cycle.

Write your thoughts. Writing offloads it from your brain and lends to further elaboration and clarification. Break things down. Ideas are often complex and need to be explained lucidly. You can write eloquent prose or you can make lists. It pays to make lists. Many good PMs I have seen in Microsoft use this approach. They love their bulleted lists!

Give your audience a clear understanding of things you are presenting. If you are talking work items, always specify the cost.

Keep it simple. Don't go for eloquent prose. Set a bar: don't use a word unless you know its exact meaning.

Start paragraphs with the main points. This helps readers skim through your document and yet get the gist. Keep your document consistent. Be it in style or content. Stick to your core talking points.

Pay attention to language. Use fewer words. And fewer still if you are drafting a presentation slide deck. Be concise in your sentences. Don't use unnecessary phrases. Prune the redundant words. Use "although" instead of "regardless of the fact that" and "each" instead of "each and every" and "if" in place of "in the event that". Take my word; just omit the phrase "as a matter of fact". It means nothing.

Start your documents as a draft, maybe even a list of points. Then work your way up. Don't worry about spelling, grammar and formatting in your draft. Once your content is organized, edit mercilessly, improving with every iteration. One of the best investments I ever made was in buying "Elements of style", William Strunk's 1918 masterpiece. Things have improved now that I have Ashley: she's a great guide. But for a guy who spoke English only as a third language (after Tulu and Hindi), I needed all the help I could get!

Writing a summary at the top of the document is never a bad idea. By doing that you are being mindful of peoples' time. If the summary spurs their interest, they will read on. If not, oh well, at least you didn't waste their time. Also mention clearly what type of document this is: a Product Vision document or Functional Specification or Technical Specification or Design Document.

Use spellcheck, er, spell check.

Deal with ambiguity both in your job and in your writings. Refrain from making ambiguous statements. If, in your writings, you have to call something out but are uncertain how it pans out, flag it as such. For example, thanks to Henry, I use a style for 'Issues' in my documents. They serve as buckets for half-baked thoughts that wouldn't otherwise belong in the document. The revision process irons them out. They should never make it to the final version. If there are items in your 'Issues' or 'To do' list that will take less than 5 minutes to resolve, then resolve them now. Send that email asking for clarification. Call or walk to that person's office seeking an answer.

Once you have your document ready, distribute it for review. Seek feedback and when you get it, either incorporate it in your document or reply to your reviewer with the reasons you cannot. Using your best judgement on confidentiality of the documents, make it a point to post them to a site or forum or file share so your team and partner teams can readily access it.

Tags: Program Manager

Email this | Bookmark this

Having fun with OneNote

I'd never used OneNote before I started working at Microsoft. In my first 1:1 with Rich Clayton (my boss' boss), he suggested I give it a try. Excellent advice. Aside from the Eclipse IDE, I've never immersed myself so much in an application. OneNote and er, Outlook are now the applications I use the most, making "death by meeting" a not-so-unbearable experience. Besides letting you take notes efficiently, OneNote lets your organize and search notes as well. I'll talk about some of my favorite features.

Audio recording
A couple weeks ago, Rob told me about Audio notes capability in OneNote. Picture yourself in a requirements gathering meeting. First, get a new OneNote page and add a title "Requirements Gathering". Then start recording using the toolbar button with a microphone on it, or from the menu by clicking Tools -> Audio and Video Recording -> Record Audio Only. OneNote places a notice like so on your page:

"Audio recording started: 3:30 PM Saturday, July 16, 2005".

Now, ask a meeting attendee (if you don't have one, pretend to be one yourself) your first question: "What are the goals of this project?". After you ask, type "Goals" on the note page. You are labelling or annotating the audio track so you can reach this point later. Let the person answer. You can take more little notes if you like but since the audio is capturing all the details for you, you can keep the notes brief. Ask another few questions and continue this way. Now stop the recording.

Move your mouse (or pen if you use a Tablet PC) over one of the notes you took. You'll see an icon appear to the left of your text. Click that icon. You should now hear the audio start playing back from the point in the interview when you took that note. You can listen for a bit, and click the icon again to hear it again. Likewise you can click icons accompanying other text tracked by OneNote. The audio jumps immediately to the right spot, backwards or forwards, as you click. Of course, the OneNote team has done one smarter: to account for the brief reaction time before you type your note, they've designed the feature such that the audio jumps to a moment in time a few seconds before the moment you started taking that note. The delay is also configurable.

Note flags
The Note flags is a nifty feature. Instead of annotating a line with the much overused todo marker, OneNote lets you add a flag, in this case using the Ctrl-1 keyboard shortcut or the Format -> Note Flags menu. Try it out. You'll see a checkbox to the left of your text. You have the ability to check it once the line item is done. You can choose from a variety of symbols, font and highlight colors to create your own custom note flags. Neat eh? That's not the end though. You can search and list your notes by flag using the Note Flags Summary pane (View -> Note Flags Summary)

Inserting Outlook meeting details
This is another feature I use often. If you're starting to take meeting notes, it pays to provide some context to the discussion at hand. OneNote makes this a breeze. Just hit Alt-I-M if you have your meeting registered in your Outlook calendar. OneNote will pop up a list of meetings for the day and let you select the right one. If you click OK here, OneNote will insert the meeting date and location, attendee names, subject and description of the meeting extracted from the invite: all formatted neatly.

Screen clippings
Ah, screen clippings are useful when you want to get screenshots and doodle your review comments on them. If you have OneNote running, just navigate to any window and hit WindowsKey-S or right-click the OneNote icon on your system tray and select 'Create Screen Clipping'. You can then use your mouse pointer to drag and drop over the area you want captured. OneNote will copy this over to a new note under My Notebook.

There are other really cool features that enhance your productivity but I'll leave that for you to investigate. If the application grows on you as it did on me, I'd be interested in any tricks you pick up. If you don't have OneNote on your computer, the OneNote website offers a free trial.

Tags: Microsoft

Email this | Bookmark this

Building an Avalon application: Part 2

We've previously looked at MSBuild and how it relates to Avalon's build process. Now let us delve deeper into the Avalon build pipeline. The image here provides an overview.

The goal of Avalon Build is to provide a command line and tool-based (Visual Studio or other) build experience that exploits the same project file (.*proj). There is currently support for compiling and building WinFX applications written in XAML with C# and/or VB. Resources can be packaged in satellite assemblies or as loose content files. Avalon has full localization commenting and attribute setting support. Consequently, there is built-in support for localization in the build. Avalon follows the assembly model of Multi-lingual User Interfaces (MUI) where an application can contain language-neutral resources in the main assembly and locale-specific satellite assemblies.

The build process involves pre-build cleanup and initializations: getting the framework path, initializing properties etc. Then all types of references in the project are resolved to ensure they are up-to-date. Pass 1 of markup compile then takes XAML and generates a code-behind file (.g.cs or .g.vb depending on your language setting) and BAML for Application definitions, Pages and MarkupResources. At this point if you're swelling with questions, I'd advise you to read Rob's excellent treatise on markup compilation. Following that, the file classifier looks at items in ItemGroup and properties, and culture (or locale) settings decides what files have to be embedded into main assembly or in the satellite assembly and which ones need to be loose content. The resources file is then generated. If any custom-defined types exist, a second pass of the markup compile process creates BAML for those XAML. Code is then compiled (using CSC or VBC, as the case may be) and the main assembly is created. Based on your project's culture settings, the satellite assembly is generated. At this stage, the time is right to generate manifests for the application. As we had seen in the post on Avalon's deployment story, your project file settings dictate whether the application will be browser-hosted or standalone installed. All build artifacts are then copied to the output directory.

You've just seen how the Avalon Build pipeline compiles and builds a WinFX application. In order to save you this work, we have codified this logic into the Microsoft.WinFX.targets file that accompanies your WinFX install. Moreover Visual Studio 2005 uses this same infrastructure to build your Avalon apps. Do give it a shot and leave a comment for me if you have questions or issues.

Tags: WinFX

Email this | Bookmark this

There is no Application Model

There isn't a bigger authority than Lauren on the Avalon Application Model. And she spills our team's secret in this post. Justifiably so.

Tags: WinFX

Email this | Bookmark this

Mike Swanson's Adobe Illustrator to Avalon/XAML Export Plug-In

Mike Swanson, one of our platform technical evangelists, has made his Adobe Illustrator to Avalon/XAML Export Plug In publicly available as a free download. The current rev works with Adobe Illustrator CS and CS2 running on Windows. As the eye candy here will show you, the results of his after-hours work are amazing!

Savage Night in Adobe Illustrator	Savage Night in Avalon SDK's XAMLPad

He also did a Channel 9 interview with Scoble where he talks about how Avalon creates a separation and smooth transition of work between graphics designers and application developers. Way to go, Mike!

Tags: WinFX

Email this | Bookmark this

Building an Avalon application: Part 1

After our look at Avalon's Deployment story, let's look at it's Build mechanism. Avalon relies on the Microsoft Build engine (MSBuild) at the core of it's build infrastructure. Before we jump into looking at Avalon Build, it would be worthwhile to get a refresher on MSBuild.

MSBuild is the new build platform for Microsoft and Visual Studio. It is completely transparent with regards to how it processes and builds software, enabling developers to orchestrate and build products in build lab environments where Visual Studio is not installed. The MSBuild engine synchronously executes a project file i.e. an XML file composed of a series of targets with pre-defined execution order, each target consisting of zero or more tasks.

Those familiar with Ant and its .NET clone NAnt, probably see the similarities. For others, the following couple paragraphs should serve to illustrate how targets and tasks help build applications.

For example, here's a simple project file with one target BuildMyApp that compiles HelloWorld.cs using the task CSC into the assembly HelloWorld.exe.

<Project DefaultTargets="BuildMyApp" 
 xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   <ItemGroup 
      <Compile Include="HelloWorld.cs" />  
   </ItemGroup> 

   <Target Name="BuildMyApp">
      <CSC Sources="@(Compile)"
              OutputAssembly="HelloWorld.exe"
      />
   </Target>
</Project>

If the project file were named MyFirstApp.csprojyou may run this by specifying this on the command line:

msbuild MyFirstApp.csproj

MSBuild ships with the .NET runtime. This means if you have the .NET Framework, you can compile a typical application. Let us look at the important constituents of MSBuild as relevant to building Avalon applications:

MSBuild.exe	The console application that consumes project files. Any C# or VB project you create in VS can be passed to MSBuild.exe to be built from the command-line.
Microsoft.Build.Engine.dll	Is the common build engine responsible for reading in and executing build scripts.
Microsoft.Build.Tasks.dll	contains MSBuild tasks which are discrete, reusable build components. For example, there’s a CSC task for invoking the C# compiler.
PresentationBuildTasks.dll	Contains Avalon's MSBuild tasks. These include MarkupCompilerPass1, MarkupCompilerPass1, FileClassifier, ResourcesGenerator etc.
Microsoft.Build.Utilities.dll	Offers a set of utilities classes that you would use if you were to write your own custom tasks.
Microsoft.Build.Framework.dll	Contains a set of interfaces that define the way the engine talks with tasks and loggers.
Microsoft.Build.Conversion.dll	Contains classes that help convert legacy VS .NET 2003 project formats to VS 2005 (Whidbey) MSBuild formats.

Microsoft ships a bunch of .targets files that you may enlist in building your project. For example:

• Microsoft.Common.targets: A repository of common targets, the bulk of the build work is done in this file.


• Microsoft.CSharp.targets: This contains C# build logic


• Microsoft.VisualBasic.targets: This contains VB build logic


• Microsoft.WinFX.targets: Here's where all of the Avalon Build logic resides. This targets file does not ship with the .NET Framework runtime, instead gets installed on WinFX setup.

The Avalon Build pipeline employs a number of these targets and tasks to build Express or Installed applications. The pipeline looks something like this:

MarkupCompilerPass1 -> FileClassifier -> ResourcesGenerator (for Main assembly) -> CSC -> MarkupCompilerPass2 -> ResourcesGenerator (for Satellite assembly) -> AL -> CopyToOutput.

If you don't have a clue what this is, don't sweat. We will look at the Avalon Build process in more detail in future posts.

Tags: WinFX

Email this | Bookmark this