Dan Swearingen

Our small piece of Vista

“In addition to our summer and winter estate, he owned a valuable piece of land. True, it was a small piece, but he carried it with him wherever he went.”

From Woody Allen’s Love and Death.

So, what HAVE we been spending our time on? Our little piece of the Windows Vista operating system.

For the last 20 months we’ve been building the digital locker assistant (DLA), a dedicated download client that works with Microsoft’s online digital locker, which is in turn part of Microsoft’s Windows Marketplace.

Windows Marketplace supports direct browser based downloading. However, when the download is greater than 1-2 Gigabytes using the DLA is a much better way to go. The most popular use of the DLA so far has been buying and downloading entire copies of Windows Vista and Office 2007.

We were rather skeptical that users would want to download Vista or Office since they are really big downloads but earlier in the year the success of selling and downloading of super large games from Windows Marketplace convinced everyone that downloading Vista would be attractive to consumers.

You can get the digital locker assistant two ways: If you have Windows XP, go to the Windows Marketplace website, create an account and download and install the MSI. It’s only a 1 meg download.

Or, it’s built into every copy of Windows Vista (except Server versions).

Actually building a part of Windows Vista was a huge effort but it’s really neat to install Vista and see our little piece in there.

I was the dev lead for the DLA for XP and Vista. Two very senior Windows developers with me at Vertigo, Chris Idzerda and Ralph Arvesen, rounded out the dev team (that is, they actually did most of the work). Initially, I was dev lead and PM but soon we needed more help with the process and got a full-time program manager, Anne Warren, who was also PM for the Windows Marketplace (WMP) website. The website dev team was some 15 developers and we had a build team of one (that should have been three). Our test team was in India so the dev/test cycle was almost 24/7, something like 24/6 – we’d hand off work in the afternoon and it would be tested all (our) night with a nice bug list waiting for us in the morning.

And then there’s the rest of the Vista team at Microsoft: really a cast of thousands. I think they ALL emailed me at least once. The High DPI functionality team. The Localization team (“do you know your UI looks really bad in Arabic?”), the Group Policy team, Remote Desktop team… you get the picture.

Let’s look at the app

In Vista there are two ways the digital locker assistant (DLA) may be invoked. The primary way is when you buy something at Windows Marketplace and it’s in your digital locker and you click “download.”

You may also browse to the DLA by finding it under the Vista Control Panel.

Then look under Programs or Programs and Features (using Classic view) and find “Manage programs you buy on line.” If you open this link you will invoke the DLA and if you have never sync’d up with your online digital locker you will see this:

If you have software in your online digital locker you can see it listed here by clicking on “Sign in if you already have a digital locker account.” Digital locker accounts are Windows LiveID (a.k.a. Passport) accounts mapped to a Windows Marketplace account. You’ll get a login prompt:

and after synchronizing with your online digital locker you’ll see all your purchased, free, and trial items listed. In my case (below) I clearly have a bunch of games in my locker. These were just to test downloading large items. Right.

Technology under the covers

The DLA is built in Win32/C++ as an ATL Windows application but we get some goodies from WTL as well. For those going “huh?” look at my post ATL and WTL resources.

At this point most people are asking me: why C++? Why not .NET and/or WPF? Or, if you’re using C++, why not MFC?

The DLA started (and is still available) as a downloadable application for XP. Our target users are what Alan Cooper would call “permanent beginners” (like that relative that always calls you for tech support…) — with a modem.

This means making the download as small as possible. Vertigo is a premier .NET shop but we could not use .NET because the 22 MB .NET runtime install kills us (that .NET never made it into the XP Service Packs… argh). Fortunately, we happen to have a few developers around (i.e., old geezers) who can do C++. We used ATL again to keep the size of the executable small.

In hindsight, it was just as well that the XP effort started in C++. Once we expanded the project to include being built into Vista we found that, in Windows System programming and the Vista source tree, C++ is expected and still king (See my post Has Microsoft flipped the Bozo bit on .NET? for a full discussion).

This meant that we could develop one source code base and, with some care, make it build in the Windows OS build system for Vista and VS2005 for XP.

Single source is nice but why not make a single binary that runs on Vista and XP? Sigh. We do — sort of, but it’s complicated.  From a programmer’s perspective, Vista makes one dramatic change from traditional Win32 applications and that’s in how localized resources are loaded.

To handle localization traditional Windows practice is to create an RC file for all resources (dialogs, images, sounds, strings, keyboard shortcuts, etc.) which are compiled into the resource DLL. Localization teams produce localized RC files based on your master RC file and these are all built into a suite of resource DLLs. At run time the application loads the appropriate resource DLL based on logic you have to write which looks at the calling thread’s locale settings.

Internal to the application is a language-neutral block of resources (typically English-US based) and if an appropriate external resource DLL cannot be found for the current locale settings, this internal block is used instead. This is known as “fallback” behavior.

Here’s the new twist in Vista: in Vista the OS loader (not the app) picks the resource DLL and locates it in memory where the app thinks its internal fallback resources are. This is expected behavior and currently only appears to work for a native Vista-built application so our “legacy” resource loading technique as used in XP was not acceptable to those who guard the Windows Source tree. Did I mention all the code reviews? Making Vista-style resource loading work in XP, while theoretically possible, was a task we did not choose to take on. So we ended up with one set of source code feeding two build processes; one for XP and one for Vista. Through careful coding there are remarkably few “if Vista do this, if XP do that” points in the code. 

While we currently block running the XP installer on Vista (in theory blocking installation of the XP DLA on Vista), it turns out that the XP DLA runs fine on Vista. I should not be suprised by this becuase we did quite a bit of casual sanity testing on this but it was not initially part of the test matrix. We found out by somewhat by accident as users were upgrading their XP machines (where the user had added the XP DLA) to Vista and then running the XP DLA.

For our downloading mechanism we hand off all download jobs to Microsoft BITS (Background Intelligent Transfer Service). While BITS works well for us I still think Micorsoft is tempting the gods by including “Intelligent” in their product name. BITS is the guts behind hwo Microsoft Updates are downloaded. I’ve also discovered that Google Updater uses BITS as well. What we gained by using BITS was automatic download management including background downloads, downloads that persist when our application is not running, downloads that seamlessly restart when the machine is rebooted, and lots of error handling algorthms that we did not have to write or maintain. I’d use BITS again if needed. We did have to build a simple HTTP download as well because some modem-based accelerators do not play nice with BITS.

Overall it was a great experience. While it is a chaotic, exhausting process it was a lot of fun too. 

I’d do it again.

Really.

After I’ve had a couple years to rest.

Using a UDL file to generate and test database connection strings

One of the most common gotchas to getting any data driven application working is the database connection string. How many times in your development life have you heard “I can’t connect to the database” and the problem ends up a minor detail in the connection string?

When I was working on a project with IdeaBlade one of the developers showed me a neat trick: keep a UDL file on your desktop.

While there are whole websites devoted to connection string details, a simple UDL file on a Windows system gives you a really easy way to configure and test a connection string directly against the database you want to use.

In Windows the extension “.udl” is registered as a “Microsoft Data Link” and the default program is OLE DB Core Services. Not very intuitive so let me walk through the basics.

A UDL file is actually a text file so start by creating a text file on your desktop. Right-click on the desktop and select New and Text Document. Note: I did this on Windows Vista but this works the same way on any modern version of Windows (I've checked as far back as NT 4.0).

Name your new file Connection.udl – or, whatever but you need the “.udl” extension. Ignore the “If you change a filename extension…” warning . The file will take on an icon appearance that is not a text file. Here’s how it looks on Vista

And XP

Now double click on (or right-click Open) the file. You should see a familiar database connection configuration dialog.

To connect to your local SQLExpress database go to the Provider tab and select Microsoft OLE DB Provider for SQL Server.

Now go to the Connection tab and select the database to connect to. You may just browse through the list but SQLExpress instances do not always show up. You may also type the server name into the listbox. For SQLExpress it will usually be [machine name]\SQLEXPRESS if you have a full SQL 2005 instance installed it will just be the machine name. In this case I’m connecting to my local SQLExpress database on my machine HAVOCVISTA.

Select the authentication you want to use. If using a username and password choose whether you would like to embed the password in the connection string.

Now select the particular database. If the dropdown is populated when you click on it you already have a good connection. If not, then the problem is going to be the name and/or the authentication provided. Assuming all’s well, select the database and click the Test Connection button.

Now close by clicking the OK button.

Here’s the "Ah Ha" step.

Now open the file in notepad – remember, the .udl file is simply a text file. You should see something like this:

In the file is the connection string you just tested. Copy and paste where needed in your application and you should be good to go.

ATL and WTL resources

The story of ATL and WTL (fit for a cocktail napkin):

In the beginning, (at least in *this* beginning) there was COM. As developers embraced COM programming for Windows applications Microsoft created the Active Template Library (ATL) as a framework to simplify and envelop the routine tasks in the creation of COM components.

Using ATL developers were happy with the ease with which small fast components could be created. They were unhappy with all the code wrappers they had to write to use any Windows controls. And, of course, everyone wrote their wrappers differently so this became an entropy generator on projects. While ATL does provide “Window” classes, they really don’t help much outside of COM. They’re mainly intended for COM control property pages.

In response, developers within Microsoft developed (in an unsupported way) the Windows Template Library (WTL). WTL extends ATL and provides a framework of light wrappers to use with Windows controls. Developers competent with ATL find WTL a great framework to quickly build small (in terms of KB EXE size) applications. Versions 7.0-7.5 are available from Microsoft but WTL has been released in the public domain and is maintained at SourceForge (see links below).

On a recent project I found these resources useful in catching up on how to work with ATL/WTL:

ATL resources:

Code:

ATL is part of the Windows SDK.

Web:

New MFC and ATL Features - MSDN
ATL Samples - MSDN
ATL Server Samples - MSDN

Code Project: Active Template Library (ATL)

Books:

ATL Internals: Working with ATL 8, 2nd Edition (New! July, 2006) (Amazon), by Christopher Tavares, Kirk Fertitta, Brent Rector, Chris Sells. Very good but does not have any material on ways to build ATL Window apps without WTL (Note: I stand corrected, see Chris's post below). Chris Sells’ web page for this book

Beginning ATL 3 COM Programming (1999)(Amazon), by Julian Templeman, Richard Grimes, Alex Stockton, Karli Watson, George V. Reilly. This is “beginning” as in “beginning cliff diving” – has an ATL Windows app section.

Professional ATL Com Programming (1998) (Amazon), by Richard Grimes.

Developer's Workshop to COM and ATL 3.0 (2000) (Amazon), by Andrew Troelsen.

WTL resources:

Code:

Windows Template Library (WTL) 7.0 4/2/2002
Windows Template Library (WTL) 7.1 12/9/2003
Windows Template Library (WTL) 7.5 6/13/2006
WTL open source at SourceForge. V 7.5 is released, 8.0 in development.

Web:

Chris Sells: Whitepapers, sample code and walkthroughs. Based on an old version of WTL but still the best starting point. WTL Makes UI Programming a Joy, part 1 and part 2, 6/2000

Yahoo! Tech Group: WTL -- online group discussion and help.

Code Project: Windows Template Library (WTL)
Code Project: Michael Dunn’s series on WTL for MFC Programmers is outstanding. Something like ten parts. Starts with WTL for MFC Programmers, Part I - ATL GUI Classes

Books:

None as far as I know.

How Bill Gates works

I thought this was an interesting look at how someone who is a very busy technical manager goes about their work. CNNMoney: How I Work.

So, can I have a third monitor now?