ascend slowly, breathing normally

Windows 7 is coming on October 22, 2009. Pre-order Windows 7 today at the Microsoft Store. You'll get it for at least half off and be one of the first to get it. Pre-order a Windows 7 Home Premium Upgrade for $49 or a Windows 7 Professional Upgrade for $99 at Microsoft Store.   That's about half off the estimated retail prices.*

Hurry, quantities are limited. The offer begins on June 26, 2009 (links will go live on June 26) and will continue while supplies last, or until July 11, 2009, whichever comes first.  Go to the Windows team blog and find out all the details. 

* Special pricing is available in the following markets:  Canada, France, Germany, Japan, US, UK.

If you thought the VistaBridge was a cool idea, you're really going to love the next evolution.   Windows 7 has some great new features that will really shine in your managed application, and the Windows SDK team has been working on a way to help you do just that.  

The Windows API Code Pack is a source code library created to support targeting some new Windows 7 features and some other features existing in older versions of Windows from managed code. These features are not available via .NET Framework Class Library today. Using Windows API Code Pack you can target many of these useful Windows features without having to write interop code yourself.

The Code Pack includes a complete source code library, sample applications and API reference documents. You can build the included solution files to get the assemblies for use in your applications or to modify as you like.  Read all about it on the Windows SDK blog.

Below: This sample application shows the management of jump lists in an application, progress bar and usage of Taskbar overlay icons

The WSDAPI StockQuote and FileService samples that ship in the Windows SDK for Windows 7 may fail to build on the command line (using msbuild) if Visual Studio 2008 is installed. These samples include project files that reference WSDL and XSD files, and msbuild attempts to invoke sproxy.exe to process these files. Visual Studio 2008 does not include sproxy.exe, and compilation fails if the tool is not present. Compiling from inside the Visual Studio IDE is unaffected; the samples will compile without error.

A workaround is available.  It is not necessary to use sproxy to process these files.  WsdCodeGen, a WSDL/XSD compiler for WSDAPI, can be used to generate C++ code from these files. This generated code is already included in the sample.

If you encounter this error, you can remove the XSD and WSDL files from the affected project files and recompile with msbuild:

• StockQuote\StockQuoteContract\StockQuoteContract.vcproj: remove StockQuote.xsd, StockQuote.wsdl, and StockQuoteService.wsdl
• FileService\FileServiceContract\FileServiceContract.vcproj: remove FileService.wsdl

Installing the Windows 7 SDK (RC release) and Visual Studio 2008 RTM can disable the X64 and Itanium configuration platform choices in Visual Studio.

If the Windows 7 SDK (RC release) and Visual Studio 2008 RTM are installed on a machine running an x64 version of Windows the following issue may occur. The Itanium and x64 listings are missing from the New Platform drop-down lists of the New Project Platform and New Solution Platform dialogs of the Visual Studio IDE.  (This issue will be fixed in the RTM release of the Windows SDK for Windows 7.)

To determine if your directories are missing, launch the VS IDE and go to tool->options->projects and solutions->VC++ Directories.  If the entries in the drop down “Platform” box appear as "x86", "x64" and "Itanium", your directories are as expected and you do not have this issue.  If the platform entries appear as "x86", with no entry for "x64" and "Itanium", you do have this issue.

This issue will occur regardless of the order of installation – Windows 7 SDK (RC) and then Visual Studio 2008 RTM, or Visual Studio 2008 RTM and then the Windows 7 SDK (RC) unless Visual Studio 2008 SP1 is installed before the installation of the SDK.

The issue occurs because 64 bit versions of VCProjectAMD64Platform.dll and VCProjectIA64Platform.dll are installed instead of 32 bit versions. To prevent the issue install Visual Studio 2008 SP1 before installing the SDK.  If your Visual Studio installation has already been affected follow these steps to address this issue:

1. Open the Control Panel.
2. Select "Uninstall a program" from the Programs group.
3. Uninstall "Microsoft Visual C++ Compilers 2008 Standard Edition - enu - x64"
4. Uninstall "Microsoft Visual C++ Compilers 2008 Standard Edition - enu - x86"
5. Right-click on the main Visual Studio entry in the program list and select "Uninstall/Change"
6. When the Visual Studio setup dialog appears click the Next button and then click on the "Repair/Reinstall" option.
7. Install Visual Studio 2008 SP1 if it is not already installed on the machine.

Note: Running “Repair” on the Windows SDK will revert these fixes.

This article applies to 2 samples in the Windows SDK for Windows 7 and .NET Framework 3.5 SP1.  The WSDAPI StockQuote and FileService samples may fail to build on the command line (using msbuild) if Visual Studio 2008 is installed. These samples include project files which reference WSDL and XSD files, and msbuild attempts to invoke sproxy.exe to process these files. Visual Studio 2008 does not include sproxy.exe, and compilation fails if the tool is not present. Compiling from inside the Visual Studio IDE is unaffected.

It is not necessary to use sproxy to process these files. WsdCodeGen, a WSDL/XSD compiler for WSDAPI, can be used to generate C++ code from these files. This generated code is already included in the sample.

If you encounter this error, you can remove the XSD and WSDL files from the affected project files and recompile with msbuild:

· StockQuote\StockQuoteContract\StockQuoteContract.vcproj: remove StockQuote.xsd, StockQuote.wsdl, and StockQuoteService.wsdl

· FileService\FileServiceContract\FileServiceContract.vcproj: remove FileService.wsdl

Issue: Installing the Windows SDK for Windows Server 2008 after Visual Studio 2008 Standard on a computer with an X64 operating system corrupts VC directories, causing a double X64 entry.  This post applies to the Windows SDK for Server 2008 only.  This issue has been fixed in subsequent SDKs.

Scenario:

You probably have this issue if your computer setup matches the setup described below:

1. Visual Studio 2008 Standard is installed on an X64 OS.  To determine what version of Visual Studio you are using, launch Visual Studio, choose Help, About Visual Studio.

2. The Windows SDK for Server 2008 and .NET Framework 3.5 is installed (this is v6.1).

3. The VC++ Directories Platform Entries are corrupted.  To determine if your directories are corrupted, launch the VS IDE and go to tool->options->projects and solutions->VC++ Directories.  If the entries in the drop down “Platform” box appear as "x86", "x64" and "x64", your directories are corrupted.  If the platform entries appear as "x86", "x64" and "Itanium", you do not have this issue. 

4. It is not possible to create an X64 target.  Neither of the X64 directory entries work.

Cause:

The installation order of the compiler components that ship with the Windows SDK for Server 2008 creates the problem. Because Visual Studio Standard does not have ia64 support it does not install the file VCProjectIA64Platform.dll.  The Windows SDK does support IA64 development and does install this file.  However  Visual Studio VC++ is a 32-bit application and requires an X86 version of the file. The Windows SDK installs a 64-bit version of the VC compiler/CRT package on 64-bit operating systems.  This package includes the 64-bit version of VCProjectIA64Platform.dll, which causes the double directory entry. This issue has been fixed in later releases of the Windows SDK.

Workaround:

Pick one of the following workarounds:

1. If you do not need to build targeting IA64, you can simply delete IA64.VcPlatform.config from %ProgramFiles(x86)%\Microsoft Visual Studio 9.0\VC\vcpackages.

2. If you have the Windows Server 2008 SDK installed on an X86 computer, you can copy the x86 version of VCProjectIA64Platformd.dll and drop it to %ProgramFiles(x86)%\Microsoft Visual Studio 9.0\VC\vcpackages.

3. If the above workarounds don’t work for your situation, download the Windows SDK for Server 2008 ISO package.  Find the file named "\Setup\vc_stdx86.cab\FL_VCProjectIA64Platform_dll_76114_76114_x86_ln.3643236F_FC70_11D3_A536_0090278A1BB8".  Rename the file “VCprojectIA64Platform.dll”.  Copy it to %ProgramFiles(x86)%\Microsoft Visual Studio 9.0\VC\vcpackages.

Note: Running “Repair” on the Windows SDK will revert these fixes.

Wondering how to use the new Windows 7 SDK with Visual Studio 2010 Beta1?   The Windows 7 SDK Beta version of the Windows headers, libraries and Win32 tools ships with Visual Studio 2010 Beta1, but you'd probably prefer to work with the RC release of the Windows SDK for Win 7, that was released after VS2010 Beta 1.

It's easy to do.  Just install the RC version of the Windows SDK for Windows 7 and .NET Framework 3.5 SP1 on your machine, and target the Windows 7 SDK RC release by following the steps outlined in this Visual C++ team blog post.

This post applies to the RC release of the Windows SDK for Windows 7 and .NET Framework 3.5 SP1.

Scenario: if VS2008 or another Windows SDK is installed, MSBuild and/or VCBuild may default to the headers, libs and tools of the older SDK.   Samples or applications built in the SDK build environment or in Visual Studio 2008 IDE will fail to find the Windows 7 content. 

Cause: a change was made to the way the Windows SDK writes to the registry keys that VS2008 uses to determine the "current" SDK.  The Windows SDK for Server 2008, and earlier pre-releases of the Windows 7 SDK set a registry key upon installation:

• On an X86 computer: HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows
• On an X64 or IA64 computer: HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows

This key is used by the VC++ toolset in both Visual Studio 2008 and in the Windows SDK build environment.  A decisions was made for the Windows 7 SDK to no longer set this key during installation in order to avoid unexpected changes to Visual Studio 2008.

Workaround: use the Windows SDK Configuration Tool to set the Windows 7 SDK as the “current” SDK for MSBuild and VCBuild. This will update the Windows 7 SDK build environment and the Visual Studio 2008 IDE build environment to use the Windows 7 SDK content.  You can also use this tool to switch it back again.

To run the Windows SDK Configuration Tool, go to Start, All Programs, Microsoft Windows SDK v7.0, Visual Studio Registration, Windows SDK Configuration Tool.

Send your thoughts to the Windows SDK Feedback alias.  Tell us how you use the SDK and what we can do to improve your development experience.

This post applies to the RC release of the Windows SDK for Windows 7 and .NET Framework 3.5 SP1.

Issue: When launching Windows SDK Documentation for the first time, you may see the Microsoft Document Explorer error message: The Application Data folder for Microsoft Document Explorer could not be created.

Cause: On first launch, Document Explorer needs to create one or more files in the Application Data folder. The application needs to run in elevated mode in order to write to this directory.

Workaround: Run the application as an administrator. Under Start Menu, go to All Programs and expand Microsoft Windows SDK v7.0. Right-click on Windows SDK Documentation and select Run As Administrator. Provide administrator credentials, if required. This only has to be done on first launch. Subsequent use of Microsoft Document Explorer can be accomplished by a standard user.

The Windows SDK for Win 7 & .NET Framework 3.5 SP1, RC version is available on the Microsoft Download Center in both ISO and Web Setup formats. 

You have two options when installing the SDK: the Web Setup or the ISO install. Running the Web setup allows you to install a smaller package on your computer, because you can deselect the components you don't want. The ISO image file can be used to burn your own DVD. The ISO files are big - around 1.3 GB. 

The contents of image files can be used as virtual discs using utilities such as ISObuster, Daemon Tools or Virtual CloneDrive for Vista. You can extract the files from an image file to a temporary folder on your hard drive, then run setup.

We've changed the ISO packaging with this release of the SDK. (You can learn more about ISO images and how to work with them in this blog post.)  There are three ISOs to choose from, based on the CPU (x86, x64, or Itanium) platform you are installing on.  Each ISO will allow you to build applications that target all the other CPU platforms.  If you install the x86 ISO on an x86 computer, you will be able to create applications targeting x86, x64, and Itanium.

Which ISO download is right for you?

• If your computer is X86, download GRC1SDK_EN_DVD.iso
• If your computer is X64, download GRC1SDKX_EN_DVD.iso
• If your computer is IA64, download GRC1SDKIAI_EN_DVD.iso

Read the Release Notes for a description of known issues before you install the SDK.  New steps are required when using the SDK build environment or the Visual Studio build environment. 

Platform Compatibility:

The RC release is compatible with Windows 7 Release Candidate,  Windows Server 2008 R2 Candidate,  Windows Server 2008, .NET Framework 3.5 Service Pack 1 , Windows Vista, and Windows XP.

Visual Studio Compatibility:

The RC release is compatible with Visual Studio 2008; including Visual Studio Express Editions.

What’s New:

• Documentation – Approximately 80% of the SDK documentation set has been refreshed
• Headers/Libraries – numerous new and updated (see What’s New in the Windows API under the top-level Getting Started section in the documentation)
• Samples – Over 200 new and/or updated samples
• Tools – Several new tools added
• Visual Studio 2008 SP1 C++ command line compiler toolset and matching CRT

Watch the the Windows SDK blog and the Windows SDK MSDN Developer Center  for more information about the Windows SDK.  Send your thoughts to the Windows SDK Feedback alias.  Tell us how you use the SDK and what we can do to improve your development experience.

Win 7 SDK with VC++ 2005: Failure to compile in Debug mode

If you are getting weird Linking errors when using the Windows SDK for Windows 7 with Visual Studio 2005, you may need to install a patch.  If your usage scenario matches the one listed below, you will be unable to debug in the Windows SDK command line build environment or Visual Studio 2005 SP1.

Symptom: You have an .lib file or an .obj file that exposes C interfaces that was built by using Microsoft Visual C++ 2008 or for Windows 7. You add this file to a project as a link dependency. When you build the project in Microsoft Visual Studio 2005 Service Pack 1 (SP1) to generate an .exe file or a .dll file, you may receive the following link error:

Fatal error LNK1103: debugging information corrupt

Cause: This problem occurs because of a compatibility issue between Visual Studio 2005 and Visual Studio 2008 versions. For more information, see the Microsoft Support page for the patch: http://support.microsoft.com/kb/949009/.

Fix: Install the patch for Visual Studio 2005 SP1 available from: http://support.microsoft.com/kb/949009/.

It can be a bit tricky to use the DirectX SDK, the Windows SDK, and Visual Studio 2008.  If you're building an application in the Windows SDK command line build environment or in Visual Studio2008 IDE, you should ensure that the DirectX SDK include, library, and executables directories are set correctly in Visual Studio 2008. The order in which Visual Studio 2008 looks for executable directories and library files is important. The Windows SDK directories should appear above the DirectX SDK directories if you wish to build with Windows SDK headers, libraries and tools.

Here's how to make that work:

1. Launch Visual Studio 2008.

2. Open the Tools menu and select Options…. The Options dialog box appears.

3. In the left pane of the Options dialog box, expand the Projects and Solutions node.

4. Under Project and Solutions, select VC++ Directories.

5. In the right pane, set the "Platform" drop-down list box to Win32® and the "Show directories for" drop-down list box to Executable files.

6. At the bottom of the list of executable file directories, create a new entry for the DirectX SDK: 

<drive>:\Program Files\Microsoft DirectX SDK <version>\Utilities\bin\x86

(If there is already such an entry, move it to the bottom of the list.)

7. Set the "Show directories for" drop-down list box to "Include" files.

8. At the bottom of the list of directories, create a new entry for the DirectX SDK:

<drive>:\Program Files\Microsoft DirectX SDK <version>\Include

(If there is already such an entry, move it to the bottom of the list.)

9. Set the "Show directories for" drop-down list box to "Library" files.

10. At the bottom of the list of directories, create a new entry for the DirectX SDK:

<drive>:\Program Files\Microsoft DirectX SDK <version>\Lib

(If there is already such an entry, move it to the bottom of the list.)

11. If you are developing an application to run on AMD64, you should repeat these steps to set the AMD64 paths by setting the "Platform" drop-down list box to AMD64 and providing the appropriate paths.

12. Click OK.

Check this page for the latest information about what's new in DirectX and known issues with the DirectX SDK.

The Microsoft DirectX SDK Developer Center provides links to the resources needed to build cutting-edge, media-rich, interactive applications. It includes runtimes, headers and libraries, samples, documentation, utilities, and support for C++ development.

This workaround applies to the Windows SDK for Windows 7 (currently released as a beta). 

If your usage scenario matches the one listed below, you will be unable to debug in the Windows SDK command line build environment or Visual Studio 2005 SP1.

Symptom: You have an .lib file or an .obj file that exposes C interfaces that was built by using Microsoft Visual C++ 2008 or for Windows 7. You add this file to a project as a link dependency. When you build the project in Microsoft Visual Studio 2005 Service Pack 1 (SP1) to generate an .exe file or a .dll file, you may receive the following link error:

Fatal error LNK1103: debugging information corrupt

Cause: This problem occurs because of a compatibility issue between Visual Studio 2005 and Visual Studio 2008 versions. For more information, see the Microsoft Support page for the patch: http://support.microsoft.com/kb/949009/.

Fix: Install the patch for Visual Studio 2005 SP1 available from: http://support.microsoft.com/kb/949009/.

This issue applies to the version of mt.exe that ships in the newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: BETA.  

Issue:

The use of mt.exe to add a manifest resource to a PE image file (.EXE, .DLL, etc.) that does not already contain a resource (.rsrc) section in it may fail on Windows 7 Beta.  The problem does not occur on Windows XP, Windows Vista, and Windows Server 2008, nor does it occur on Windows 7 Beta when manipulating PE image files that already contain a resource section. 

Workarounds:

1.    Use mt.exe on Windows XP, Windows Vista or Windows Server 2008 instead of Windows 7 Beta, or

2.    If using Windows 7 Beta, use an external manifest file or ensure the PE image has a non-zero length resource section. 

a.    External Manifest File:
For .EXE files, the manifest need not be embedded as a resource.  Rather, it may simply be placed next to the .EXE.  I.e., for ‘hello.exe’, the manifest ‘hello.exe.manifest’, when placed next to it, has the same effect as if the manifest were embedded as a resource.  This is true only for .EXE files.

b.    Create a Non-Zero-Length Empty Resource Section:
If it is imperative that mt.exe later be used to embed a manifest, and the PE image file in question cannot otherwise be guaranteed to have a resource section, then an empty resource script may be used.  Despite that the script is empty, the resultant resource section will not be zero-length, and mt.exe can then be used.  For example:

                                          i.    cl.exe /c hello.c

                                         ii.    echo. > hello.rc

                                        iii.    rc.exe /r hello.rc

                                       iv.    link.exe /out:hello.exe hello.obj hello.res

                                        v.    mt.exe -outputresource:hello.exe;1 -manifest: hello.exe.manifest

                                       vi.    (the file hello.exe now exists with hello.exe.manifest embedded)

The newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1: BETA is available on the Microsoft Download Center with several new tools. The following tools have been added since the M3 release of the Windows SDK. Over the next couple of weeks I’ll write a short summary of what each tool can be used for.

Windows Troubleshooting Toolkit (TSPBuilder.exe)

New to Windows 7 is the Windows Troubleshooting platform. This platform allows software developers to develop Troubleshooting Packs that automate the troubleshooting and resolution of problems without having to resort to painful technical support queues or documentation runs. In a nut shell, a software developer writes a bunch of PowerShell scripts to identify and resolve problems then packages them up and distributes the pack to end-users. Rafael Rivera has written a good step-by-step guide for how to author a Win7 Troubleshooting Pack HERE.

To learn about other tools new to the Windows SDK for Windows 7, see New Tools in the Windows 7 SDK.