Microsoft^® Windows^® SDK Readme for the February 2006 CTP

Welcome to the Microsoft^® Windows^® Software Development Kit (SDK) for the February 2006 Community Technology Preview (CTP). The Windows SDK contains documentation, samples, headers, libraries, and tools designed to help you develop Microsoft^® Windows applications. The documentation, samples, and tools provided in the Windows SDK support application programming interfaces (APIs) available in the Windows Vista™, Microsoft^® Windows^® XP Service Pack 2 (SP2), or Microsoft^® Windows^® Server 2003 Service Pack 1 (SP1) versions of Windows.

Important This version of the Windows SDK is available as both a DVD ISO image that must be burned to a DVD or mounted as a virtual drive and installed from that media, and as a web download.

• The DVD ISO image of the Windows SDK available from Download Center will not install the SDK directly on to your hard disk without the use of additional tools. See the installation instructions below for more information.
• The web download is also available from the Download Center. The web download will stream the SDK content to your local machine.

Important This version of the Windows SDK targets specific versions of Windows and has other restrictions. This version:

• Is supported on Windows Vista build 5308, which is available from the MSDN Universal Subscribers site on MSDN and from the Beta customer locations.
• Supports Microsoft Pre-Release Software WinFX Runtime Components - February Community Technology Preview (CTP) for Windows XP SP2 and Windows Server 2003 SP1, which is available publicly from the Download Center.

Note To use features for WinFX, the managed programming model for Windows, install the version of the WinFX Runtime Components compatible with this release.

Please note that this release is for preview purposes only. The APIs, documentation, samples, headers, libraries, and tools provided in this release are preliminary and subject to change.

• It is strongly recommended that you install this pre-release version of the Windows SDK in a test environment, not a production environment. There are several known issues with this release. Because this is a pre-release edition, many of the known issues are identified in this document. Please read the installation instructions and known issues before installing.
• To learn more about Known Issues and to find additional information about Windows Vista, see The MSDN Online Windows Vista Developer Center. The Developer Center is focused on keeping developers up-to-date on how they can take advantage of Windows Vista's rich new client features in their applications. Visit the Developer Center often to see new articles, read monthly columns, participate in the Windows Vista Beta Newsgroups, download sample code, and read the Editor's Web Log.

1. License Agreement

The contents included in the Windows SDK are licensed to you, the end user. Your use of the SDK is subject to the terms of an End User License Agreement ("EULA") accompanying the SDK and located in the \License subdirectory. You must read and accept the terms of the EULA before you access or use the SDK. If you do not agree to the terms of the EULA, you are not authorized to use the SDK.

2. Supported Compiler

3. Supported Platforms

• This pre-release of the Windows SDK supports x86 and x64 platforms for building and running samples.
• The IA64 platform is not supported in this release.

4. File System Layout

By default, the Windows SDK is installed to your hard disk in the locations described in the following table. This list is not complete, but covers the most common directories. 

Directory	Contents
\Bin	Windows SDK tools
\Help	Windows SDK documentation
\Include	Windows SDK headers
\Lib	Import libraries and TLB files
\License	Windows SDK license information
\Samples	Windows SDK samples

5. Installation Instructions

Please install on a clean machine or completely uninstall any pre-releases of the Microsoft^® WinFX^® Runtime Components 3.0, the WinFX SDK, the Platform SDK, the Windows SDK, the .NET Framework redistributable, Microsoft^® Visual Studio^®, and their dependencies before installing this release. These older components may interfere with this release, causing setup to fail or break functionality. We recommend installing this version on non-production machines (preferably in a test environment) without these previous releases to prevent incompatibilities.

To install on Microsoft Windows XP Service Pack 2 or Microsoft Windows 2003 Server Service Pack 1:

1. If you intend to install WinFX components available in the Windows SDK, install the Microsoft WinFX Runtime Components 3.0 for the February CTP from the Download Center.
2. Download the Windows SDK from Download Center. Note: If you download the DVD ISO image, burn the image to a DVD or mount as a virtual drive, and install the SDK on your local hard disk. The details page for the Windows SDK in the Download Center has additional information about tools you can use to create the setup image without burning the image to a DVD. You can also download the Windows SDK from the Download Center.
3. If you create a DVD ISO image or mount a virtual drive and launch setup.exe, choose the appropriate option to install the Windows SDK: Insert the SDK DVD into a DVD-ROM drive and click setup.exe, or after the virtual drive is mounted, launch the setup.exe from within that virtual drive.
4. Follow the instructions in the Windows SDK Setup wizard.
5. Optional Install Microsoft^® Visual Studio^® 2005 (this Windows SDK is compatible with the RTM version of Visual Studio).
6. Optional Install the Visual Studio 2005 Extensions for WinFX for February CTP from the Download Center.

To install on Windows Vista:

1. If you intend to install WinFX components available in the Windows SDK, install the Microsoft WinFX Runtime Components using one of the following methods:

   1. From a command prompt on a machine with Windows Vista February CTP installed, enter one of the following:
      %WINDIR%\SYSMSICache\WinFX\3.0\winfxrc.exe /q /qb /norestart for x86 machines
      %WINDIR%\SYSMSICache\WinFX\3.0\winfxrc_x64.exe /q /qb /norestart for x64 machines

   2. or install the Microsoft WinFX Runtime Components 3.0 for the February CTP from the Download Center.
2. Download the Windows SDK from Download Center. Note: If you download the DVD ISO image, burn the image to a DVD or mount as a virtual drive, and install the SDK on your local hard disk. If you mount a virtual drive and then launch the setup.exe from within that virtual drive, installation will begin. The details page for the Windows SDK in the Download Center has additional information about tools you can use to create the setup image without burning the image to a DVD. You can also download the Windows SDK from the Download Center.
3. If you create a DVD ISO image or mount a virtual drive and launch setup.exe, choose the appropriate option to install the Windows SDK: Insert the SDK DVD into a DVD-ROM drive and click setup.exe, or after the virtual drive is mounted, launch the setup.exe from within that virtual drive.
4. Follow the instructions in the Windows SDK Setup wizard.
5. Optional Install Microsoft^® Visual Studio^® 2005 (this Windows SDK is compatible with the RTM version of Visual Studio).
6. Optional  Install the Visual Studio 2005 Extensions for WinFX for the February CTP from the Download Center.

To install the WinFX Redistributable components for February CTP on the Windows Vista February CTP build:

1. If it is installed on your machine, uninstall the January CTP version of the WinFX Runtime Components.
2. Download the redistributable package for the WinFX Runtime Components 3.0.

Note If you intend to use Visual Studio to develop WinFX applications, you must install the Windows SDK before installing the Visual Studio 2005 Extensions for WinFX. It is essential that you use the version of Visual Studio identified in the Installation instructions in WinFX Runtime Components setup instructions.

Access the Windows SDK through the Start menu at Microsoft Windows SDK. This Start menu folder contains pointers to the documentation (which contains the samples for WinFX), tools, and debug and release build environments.

Note Documentation for the Windows SDK is also available on MSDN Online at:  http://windowssdk.msdn.microsoft.com/library.

6.1.1 The Windows SDK does not support UDDI development using .NET

The Windows SDK does not support UDDI development using .NET. As a result, three UDDI samples that require .NET will not compile in this version of the SDK. There is no known workaround for this issue.

6.1.2 Windows SDK disk space requirements

The complete DVD ISO installation of the Windows SDK requires 1.5 GB or more disk space to successfully install. Please verify that the machine you're installing to has at least the minimum required disk space before beginning setup. If the minimum required disk space is not available, setup will return a fatal error.

6.1.3 Known issues with Windows Workflow Foundation (WF)

There are several known issues with Windows Workflow Foundation (WF) in this SDK release. See the online Windows Workflow Foundation Readme for a complete list.

6.3.1    The J# Compiler is not available in this version of the Windows SDK

J# samples will not build using the Windows SDK because there is no appropriate build environment. There is no workaround. This edition of the Windows SDK does not support building J# applications.

6.3.2    Debugging Windows Presentation Foundation (WPF) applications with Kernel Debugger Active may result in an error

When debugging WPF applications, the following error message may appear:

Debugging isn't possible because a kernel debugger is enabled on the system.

This message occurs while debugging managed code on a system running Windows^® NT, Windows^® 2000, or Windows XP that has been started in debug mode.  For details on debugging WPF applications in this situation, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vxgrferrordebuggingisntpossiblebecausekerneldebuggerisenabledonsystem.asp.

6.3.3    Linker tools sometimes throw errors at link time

The following error messages have been known to occur at link time:

             Linker Tools Error LNK2001
        'unresolved external symbol __security_cookie '
                               
        Linker Tools Error LNK2001
        'unresolved external symbol __security_check_cookie '

If one of these errors occurs, link your C/C++ application with bufferoverflowu.lib. To learn more, see KB article 894573.

6.4.1    Tb3x.exe has been deprecated and removed from the Windows SDK

Tb3x.exe has been deprecated and removed from the Windows SDK. There is no known workaround for this issue.

6.4.2    The Application Verifier tool is not available in the Windows SDK

The Application Verifier tool is not available in the Windows SDK. It ships as part of the Windows Application Compatibility Toolkit. To work around this issue, download the Windows Application Compatibility Toolkit.

6.4.3    UISpy.exe fails to run with a strong name validation error

UISpy sometimes fails to run and displays a strong name validation error.

This error occurs because UISpy.exe was delay signed and never resigned. By default, this causes the .NET runtime to fail the execution of UISpy.exe because the strong name signature in the executable is not valid. However, UISpy will run correctly if you configure the runtime to ignore the strong name signature for UiSpy.exe.

To work around this issue, register UISpy.exe for strong name verification skipping.

1. Open a Windows SDK command prompt.

2. Navigate to the /bin directory. By default, this is C:\Program Files\Microsoft SDKs\Windows\v1.0\bin.

3. Run the command SN -Vr UiSpy.exe. Example:

      C:\Program Files\Microsoft SDKs\Windows\v1.0\Bin>sn -Vr UiSpy.exe

The successfully run command will produce a message indicating that the verification entry was added for the UISpy assembly.

6.4.4 SvcConfigEditor.exe Does Not Activate Cross-process Activity Tracking When Activity Tracking Is Activated for a Source

Local traces will not be correlated to traces on another process or system, and multiple nodes (client/server) do not display in the TraceViewer’s Activity view.

Workaround

Manually activate this feature. In the SvcTraceViewer’s config file, add “propagateActivity=true” to the source of your choice using a text editor:

<sources>
<source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" propagateActivity="true" >
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>

6.4.5 WCF Message Logging Inoperative When Activated with the svcConfigEditor.exe Tool

When activating Message Logging using the Diagnostics screen in the WCF svcConfigEditor.exe tool, the tool adds the wrong source name— “System.ServiceModel.Channels.MessageLogging” instead of the correct source of “System.ServiceModel.MessageLogging.” As a result, message logging does not work, but no exception is thrown. This is a known issue that will be addressed in a future release.

Workaround

• Use the tool to open the Configuration you created.

• In the tool’s Configuration pane, click the “Diagnostics” item.

• In the Diagnostics pane, check the “Default message logging” checkbox.

• In the Configuration pane, expand the “Sources” item.

• Click on the source name.

• Rename the “System.ServiceModel.Channels.MessageLogging” source to “System.ServiceModel.MessageLogging” and save the file.

In addition, this version of the svcConfigEditor.exe tool does not, by default, activate either service-level or transport-level message logging. One of these two options must be enabled to cause WCF to log messages. This will also be addressed in a future release.

Workaround

• In the tool’s Configuration pane, expand the Diagnostics item if necessary.

• Click on the Message Logging item.

• In the Message Logging pane, set either LogMessagesAtServiceLevel or LogMessagesAtTransportLevel to True.

• Save the file.

6.4.6 Svcutil.exe Fails to Generate Configuration File for Queued Sessions and Queued Volatile Samples

When using queued sessions and queued volatile samples, running svcutil.exe generates the following warning:
 

“Warning: Unable to import wsdl:binding”
 

Svcutil.exe also fails to generate a configuration file in this case.

Workaround

None. This issue will be addressed in a future release.

 

6.4.7 Interface Generated by svcutil.exe Does Not Expose the Methods Required by the WCF COM Service Moniker

The WCF COM Service Moniker uses an interface definition that is typically created with the Service Model Metadata Utility Tool (svcutil.exe). In this release, the tool does not generate an appropriate interface definition.

This is a known issue that will be addressed in a future release.

6.4.8    Known issues with the Microsoft Command Shell (Monad)

Changes from Windows "Monad" Shell Beta 2

Although this release is essentially the ame code base as the previous Beta 2 release (except moved to the RTM versionof the .NET Framework 2.0), a few changes were made:

"Single Shell" Changes

This release incorporates the "Single Shell" changes to the Windows "Monad" Shell.

The user-visible operation of Monad at startup is the same, however Monad now groups cmdlets assemblies into "MshSnapins" and dynamically loads MshSnapins at startup based on registry settings. To learn more about the Monad MshSnapins simply type: get-help about_MshSnapins. This help topic also talks about how to create and save console files.

Monad added cmdlets to control MshSnapins:

add-mshsnapin [-Name] String[] [-PassThru]

get-mshsnapin [[-Name] String[]] [-Registered]

remove-mshsnapin [-Name] String[] [-PassThru]

export-Console [[-Name] String] [-Force]

More details are available by running get-help on each one of these cmdlets.

Note: the new MshSnapins cmdlets are not available in a custom shell.

To learn more about how to create a MshSnapin, refer to the GettingStarted.rtf documentation and look up: Appendix D - Creating a SnapIn.

Literal numbers Cmdlet parameters:

Cmdlet parameters that are literal numbers will now get treated as numbers, whereas previously they used to be treated as strings. This may affect a script if the type of the parameter can be converted from a string but not from an integer. The user fix is to enclose the literal number in quotes. This change was in the earlier Monad Beta 2 but was not well communicated before.

The remaining notes are unchanged from the ones included with the prior Windows "Monad" Shell Beta 2 (for .NET Framework 2.0 Beta 2) release.

MAML Cmdlet help schema

Cmdlet help now adhere to the Microsoft MAML schema. All Cmdlet help content are in the *help.xml files in the Monad application folder under the correct culture folder:

System.Management.Automation.Commands.Management.dll-Help.xml
System.Management.Automation.Commands.Utility.dll-Help.xml
System.Management.Automation.ConsoleHost.dll-Help.xml
System.Management.Automation.dll-Help.xml
System.Management.Automation.Security.dll-Help.xml

New add-member Cmdlet

We have introduced a new add-member cmdlet. To learn more about this Cmdlet, please check its usage by simply typing get-help add-member.

Monad assemblies are now NGEN'ed/GAC'ed

All Monad assemblies are installed using the Native Image Generator Ngen.exe and are installed in the Global Assembly Cash folder "GAC" by the Monad MSI installer. This allows the assemblies to load and execute faster, because it restores code and data structures from the native image cache rather than generating them dynamically.

Preference variables interaction changes

The effective settings which govern the behavior of ShouldProcess, ShouldContinue etc. emerges from the following:

- Command-line options: -WhatIf, -Confirm, -ErrorAction, -Debug, -Verbose
- Preference variables: $WhatIfPreference, $ConfirmPreference, $ErrorActionPreference, $DebugPreference, $VerbosePreference, $WarningPreference, $ProgressPreference

The following are the algorithms for determining the effective setting. In priority order:

WhatIf (true/false)

-WhatIf (or –WhatIf:$false)
$WhatIfPreference
default: false


Confirm (ActionPreference)

-Confirm:$true => Inquire
-Debug –Confirm:$false => Continue
-Debug => Inquire
-Confirm:$false => SilentlyContinue
$ConfirmPreference
default: SilentlyContinue


ErrorAction (ActionPreference) (note that –ErrorAction is of type ActionPreference)

-ErrorAction <preferencesetting> => <preferencesetting>
-Debug => Inquire
$ErrorActionPreference
default: Continue


Debug (ActionPreference)

-Debug:$true => Inquire
-Debug:$false => SilentlyContinue
$DebugPreference
default: SilentlyContinue


Verbose (ActionPreference)

-Verbose:$true => Continue
-Verbose:$false => SilentlyContinue
-Debug => Inquire
$VerbosePreference
default: SilentlyContinue


Warning (ActionPreference) (note that there is no –Warning flag)

-Debug => Inquire
-Verbose => Continue
$WarningPreference
default: Continue


Progress (ActionPreference) (note that there is no –Progress flag)

$ProgressPreference
default: Continue

Monad refactoring work

In this release, the Cmdlet base class has been factored into two separate classes. If your cmdlets do not require any of the Monad engine core services (access to session state or providers) or use any of the engine intrinsic APIs, then you should continue to derive from Cmdlet. If you do require any of these services, then you should change your code to derive from MshCmdlet. In migrating to this new release, the best approach is to compile any existing cmdlets while still deriving from Cmdlet and only change the derivation for those cmdlets that have errors.

This change was made to reduce unnecessary dependencies on Monad core data structures for cmdlets that do not require those services. A positive consequence of this change is that if your cmdlets which derive only from Cmdlet can be directly invoked as standalone objects. For example, the get-process cmdlet only derives from Cmdlet and can therefore be used directly as shown in the following code:

 

using System;
using System.Collections;
using System.Diagnostics;
using System.Management.Automation;
using System.Management.Automation.Commands;

public class process

{
    public static void Main()
    {
        GetProcessCommand g = new GetProcessCommand();
        g.ProcessName = new string[] {"[a-t]*"};
        foreach (Process p in g.Invoke<Process>())
            {
                System.Console.WriteLine(p.ProcessName);
            }
    }
}

IMPORTANT NOTE: As always, our developer guidance is to develop your service as a proper API, then write cmdlets to surface that API to Monad. It is strongly recommended that little or no business logic be contained in the cmdlet code itself. Although this refactoring does allow cmdlets to be used directly as an API, it should not be construed as a replacement for proper API design.

Misc bug fixes

- Match-string: match-string -list used to write the match object before closing the file which used to cause an exception. This issue is now fixed. The following example should now work as expected:

ls -rec -filter *.cs | match-string "cmdlet" | foreach { (cat $_) -replace "cmdlet","MshCmdlet" > $_ }

- Constants expressions after a variable were not being handled properly. The following example describes the new fixed behavior:

MSH:\> $a = "this is a test"
MSH:\> 80 - 8 - $a.length
    58

- Credential parameter of remove-item is now correctly passed to the provider.

- write-progress now uses "ooo.." instead of "%%%"

Changes from Windows "Monad" Shell Beta 2 (for .NET Framework 2.0 Beta 2)

MSH execution policy changes

Monad's ExecutionPolicy is now configured to "Restricted" by default. This is a new value for ExecutionPolicy. In Restricted mode, scripts (.msh files) cannot be run and .mshxml files (types.mshxml and *.format.mshxml files) can only be run if they are signed by a trusted publisher (.mshxml files are treated the same as they are by the "AllSigned" policy). For msh.exe, this value is controlled via the registry setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSH\1\ShellIds\Microsoft.Management.Automation.msh\ExecutionPolicy". The earlier Beta 2 release defaulted to an ExecutionPolicy of "RemoteSigned".

For other shells, the ExecutionPolicy is controlled via the registry setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSH\1\ShellIds\<YourShellId>\ExecutionPolicy" where "<YourShellId>" can be obtained from the $shellid variable inside the shell.

When Monad first starts up it may ask a question "Do you want to run software from this untrusted publisher?" for the file "types.mshxml", published by Microsoft. You can choose to not load the file, but the file (and the *.format.mshxml files, which Monad will also prompt for if you do not select [A] for "Always run" for types.mshxml) controls the display and formatting of Monad and the experience in Monad will be degraded if it is not loaded. To avoid this prompt in the future, either select [A]for "Always run", or change the ExecutionPolicy from "Restricted" to "RemoteSigned".

The error text for certain execution errors references the "about_signing" help file. Simply type get-help about-signing to learn more about the new changes in Monad's ExecutionPolicy.

If you see an error at startup "The file "C:\Documents and Settings\All users\Documents\msh\profile.msh cannot be loaded. The execution of scripts is disabled on this machine" then either change the ExecutionPolicy from "Restricted" to "RemoteSigned", or sign the files using the set-authenticodesignature cmdlet (the error message is misleading; execution of .mshxml files is not entirely disabled when ExecutionPolicy is "Restricted", but they must be signed by a trusted publisher). The "about_signing" help file has more details. You can also delete the file; in the initial configuration, the profile.msh file does not add any functionality to Monad.

Profile.msh possible errors

If you load the profile.msh file, and you have previously installed an earlier version of Monad, then on startup you may see a series of errors like:
set-alias : The AllScope option cannot be removed from the alias 'cat'.
At C:\Documents and Settings\All Users\Documents\msh\profile.msh:9 char:10
+ set-alias <<<< cat get-content
 

To fix this, either delete the file named ("C:\Documents and Settings\All Users\Documents\msh\profile.msh" in this example), or remove all the "set-alias" lines from it. Aliases defined in profile.msh in earlier versions of Monad are now defined internally by Monad before the profile is run, therefore the definitions in profile.msh generate an error attempting to redefine the alias.

Known Issues with Monad Beta 2

MSH crashes while get-content –wait is running on a file that is updated frequently.

UTF7 file encoding is not supported.

Set-item on an existing alias returns an error instead of writing a new value if –option ReadOnly is specified. Set-alias should be used instead.

Regardless of the file extension, the following reserved device names should not be used as the name of a file. If used, unpredictable behavior and data loss may occur.

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9

Help content for write-warning and script-signing are missing.

Help content for new-object is incorrect.

Important Changes in Monad Beta 2

COM interop feature has been added in this release. Documentation on how to use this feature is included in the "Getting Started Guide."

The concept of separate shells has been introduced in this version of MSH. If you are developing Cmdlets, review the information about Shells in the "Getting Started Guide."

When you run setup, it will automatically register an MSHSIP.dll to support script signing. To learn how to sign a script type:

MSH> Set-AuthenticodeSignature -?

and follow the instructions.

The following cmdlets have been added:

compare-object, convert-HTML, export-clixml, import-clixml, start-transcript, stop-transcript, update-FormatData, update-typeData, write-warning

Script block delegates feature is enabled in this release. However, currently it only works when the delegates are called on the same thread.

Changes from the Beta 1 Release

A system-wide profile is installed at "All Users\Documents\MSH\profile.msh". User specific profile should go in at "users\My Document\MSH\profile.msh".

The registry entry for Monad now has shellId - HKLM:\SOFTWARE\Microsoft\msh\1\ShellIds

The format.mshxml file allows the user to define what properties will be displayed and in what format for any type. Setup will install a read only format.mshxml file. You can add additional format data in a separate file with .mshxml extension for your formatting requirements. Documentation on how to use this file is included in the "Getting Started Guide."

The types.mshxml file allows the static extension of types with added properties (which can be used by format.mshxml). Setup will install a read only types.mshxml file. You can add additional types data in a separate file with .mshxml extension for your formatting requirements. Documentation on how to use this file is included in the "Getting Started Guide."

Now there are three execution policy - AllSigned, RemoteSigned, Unrestricted. The default execution policy is RemoteSigned. For more details on execution policy, refer to "Getting Started Guide."

6.4.9    Some tools are built to run only on Windows Vista

The following tools are built to run only on the Windows Vista operating system. If you attempt to run them on Windows XP SP2 or Windows Server 2003, you will see an error message stating that the executable is not a valid Win32 application.

• CertMgr.exe

• Checkv4.exe

• MakeCat.exe

• MakeCert.exe

• MakeCtl.exe

• SetReg.exe

• SpOrder.exe

• Where.exe

Workaround

Use these tools on the Windows Vista operating system.