Share via

Windows SDK: Why do samples install to /Program Files, even on Windows Vista?

  • Article

One feature of Windows Vista that deeply affects setup is the tight control of files in the Program Files directory. For secuirty reasons, files in that directory tightly controlled in terms of how and when they may be modified. This caused a bit of a problem for the SDK, though, since we install all files to C:\Program Files\Microsoft SDKs\Windows\v6.0 by default, including samples. By nature of what they are, samples get modified. So what to do? Do we create problems for users by placing them in Program Files by default, or do we install the SDK to multiple directories, which causes other problems?

We had a pretty good amount of internal debate as to where samples should be installed for users by default. The feeling that we eventually came to was that it would seem strange for the SDK to be installed to two completely different locations by default. Users would expect all SDK content to be located at C:\Program Files\Microsoft SDKs\Windows\v6.0, and it might seem strange or awkward for everything but the samples to be at one location and only the samples at another location.

Of course, there is a significant loss of functionality for users on Windows Vista due to this, and that's why we introduced a second directory browse box in the Install Locations screen in setup. That way users could deliberately choose to override the default install locations and put the samples in a place in which they could modify them.

We talked about a whole range of other solutions to this problem, everything from putting a simple xcopy batch file in the user's /samples directory to building a full new samples browser to sidestep the issue. But, frankly, none of these really grabbed team members as viable ideas for our users.

In the end, we decided to simply add the second directory browse box, and it seems to be a solution that our users have found acceptable. Since this change went live in one of our CTP releases several months ago, over 250,000 installs of the SDK have happened according to webmetrix. We haven't received any user questions or complaints about this decision.

Moving forward, this really isn't on the table as something we're planning to change at this point. If we start getting user complaints, we'll definitely revisit it. We're also planning on adding a datapoint to our SQM data collection to see how many users choose to change their install directories.

What do you guys think? What's the best solution to this problem?

Comments

  • Anonymous
    December 14, 2006
    I think you chose a good approach. It makes more sense to me to have a master good copy of samples and then you copy the ones you want to play with or modify to a user-editable directory under your profile.

  • Anonymous
    December 14, 2006
    I think it is a fine solution, but to be honest, when I installed the SDK, I had no idea why it was prompting me for a second installation path, so I ended up using the default path, which IIRC is just the main install path.  I haven't used the SDK much yet, so I haven't run into the usability problem that you describe. On a semi-related note, what is up with the DDK installing to C:DDK by default?  I'm not sure whether it can be redirected into C:Program Files, but programs that install into the root really annoy me.  And I figure if they are suggesting C:DDK as the default install path, that they may not work correctly if installed into another location.

  • Anonymous
    December 14, 2006
    Correction: the DDK installs to C:WinDDK by default, not C:DDK as I had stated.

  • Anonymous
    December 15, 2006
    Why not put them on c:usersall usersdocumentsWindowsSDKSamples I don't have vista in front of me so the path might not bet exact. This is frequently a problem for software developers who ship samples or similar files. This also explains why developers have taken so long to adapt UAC. People will do what is easiest. If you guys can't come up with a good solution to these type of problems it's going to be a mess all over again.

  • Anonymous
    December 17, 2006
    Just follow Designed for Windows (Windows Logo) rules by default. The SDK must pass logo verification, because it's a tool to create logo-compatible applications.