Code Library

The Windows API has many new calls that expose new functionality available with Windows 7 and Windows Server 2008 R2; however, as of the .NET 4 release many of these calls are not available from the .NET Framework. The Windows API Code Pack helps here as it contains .NET classes that wrap native API calls to make them available from a .NET library. You can use this library within your .NET applications. You can download the Windows API Code Pack from http://code.msdn.microsoft.com/WindowsAPICodePack. This toolkit is used with most samples in this appendix. You can either use the libraries that come with this toolkit or copy the source code to your application. Typically, the classes from this toolkit are a thin wrapper around the Windows API.

Another toolkit you can use to target applications for the Windows platform is the Windows Software Logo Kit. On the Microsoft downloads page, you can find the Windows 7 Client Software Logo program documentation and toolkit that contains information about what’s necessary for an application to get the Windows 7 software logo. Even if you’re not interested in receiving a logo for your application, this documentation and toolkit is still interesting, as it explains what is required for an application to be considered well-behaved on the Windows operating system.

What are the requirements to receive a logo for an application? Here’s a short list of the requirements; you can get many more details in the Windows 7 Client Software Logo document. The application may not contain spyware or malware. Of course, that’s a requirement that should be fulfilled with every application. Interestingly, this is verified for logo compliance.

• Windows resource protected files may not be replaced.

• Errors must be reported with Windows Error Reporting (WER).

• The application must cleanly install and uninstall. The application should not force a reboot with the installation.

• The application should install to the correct folders. User data should not be written to the application folders.

• Files and drivers must be digitally signed.

• 64-bit systems must be supported. This means that 16-bit code is not allowed. It’s okay to run 32-bit applications on 64-bit. With .NET applications, you can set the platform configuration to Any CPU, x86, x64, or Itanium. Any CPU lets your application run with 32 bits on a 32-bit platform and with 64 bits on a 64-bit platform. When you set the configuration to Any CPU, you may not directly wrap native code with platform invoke in the assembly. Using native code restricts you to the nativecode native API calls that are used, and thus Any CPU will not work on both versions.

• Version check with the installation must be done to check if the operating system has a minimum version required, but it’s not allowed to check for a specific version.

• User account control guidelines must be followed.

• The applications may not block shutdown. You can use the Restart Manager to return the application to a working state after a reboot or failure.

• Multiuser sessions must be supported. Different users on one system should be able to use the application. This requirement is because of the fast user switching facility of Windows.

Source of Information : Wrox Professional C Sharp 4.0 and dot NET 4