Pat's Application Compatibility blog

Questions from the Developer Booth at TechEd Europe 2009

I had the opportunity to go to Berlin for TechEd Europe 2009.  I delivered a presentation on Application Compatibility and the rest of the time I hung out in the “Test your app on Win 7” and “Win 7 Developer drop in center”. I got some great questions from attendees.  I thought I’d blog some of the general Q&A. Thank you to all that stopped by the booth. I loved Berlin.  I hope I get to go back soon.

Q: Do I need to worry about anything in Windows 7 for web apps?

A: There are some IE8 changes that may affect web applications. The Internet Explorer 8 Readiness Toolkit is a very good reference.  The developer checklist is a good place to start.

Q: What do I need to worry about for existing installers on Windows 7?

A: The common problems that are encountered with existing installers are the same issues encountered in Vista:

• Version check criteria
• MSI custom actions

Ideally, you should not check for version if possible. Version checking tends to block applications that may install and run just fine on a newer OS.  If you need to check version, you should display a warning rather than exiting the installation. Version checking can also cause issues after an upgrade with uninstall. If you check version, the user may not be able to uninstall your application after an upgrade to the new OS.

MSI custom actions can run in a standard user context or the administrator. Sometimes the custom action is running in the wrong context.  Chris Jackson has a great post on the common issue with deferred custom actions.

Q: Where can I find info on developing on Windows 7?

A: The Windows 7 Developer Guide gives a good overview of new developer functionality.  If you are looking for presentations and code samples to get you started, check out the Windows 7 Developer Jumpstart Kit.

Q: I’m a .NET Developer. What’s the guidance for developing on Windows 7? Should I use the Code Pack or wait for .NET 4.0?

A: The short answer is: Use the Code Pack today but think of it as free code to include in your application that wraps the native Windows 7 API’s. In .NET 4.0, you will see some of the new Windows developer features available in WPF.  Yochay Kiriaty has recently outlined guidance on this topic.

Q: .NET 1.1 SP1 support for Windows 7?

A: As with all older products, be sure to check the support lifecycle for the product first. There isn’t an official statement of .NET 1.1 SP1 compatibility for Windows 7. However, because compatibility was a key goal between Vista and Windows 7, efforts were made to ensure .NET 1.1 SP1 works on Windows 7.

Q: Does <insert app name here> work on Windows 7?

A: The Compatibility Center is the best reference to get information on what applications have been reported to be compatible with Windows 7.

Windows 7 Application Compatibility Testing Guidance document

If you have an existing application, you may be wondering if it’s going to work on Windows 7.  If it works on Vista, you have a good shot at it working on Windows 7.

As a developer or a tester, you may be wondering if you have tested your application to uncover potential issues on the new OS. We’ve worked with a lot of ISV’s over the past few years and we’ve come up with a document that focuses on the common issue areas of application compatibility with testing scenarios.  The Windows 7 Application Compatibility Testing Guidance document can be downloaded from MSDN Code Gallery.

Displaying the UAC consent dialog on the desktop

I had written a draft of this post a while ago (last year).  I use Live Writer as my blog editor.  Between Live Writer and Intellimirror,this draft has survived multiple reloads of interim builds of Windows 7.  So, I think in some ways, it deserves to be resurrected and posted. :-)  Here’s the post with a Windows 7 update:

Frequently, we need to give presentations over Live Meeting.  When we demonstrate UAC, the consent dialog is displayed on the secured desktop.  Therefore, the Live Meeting participants don't see the UAC consent dialog.  To solve this, we use a policy setting to allow the dialog to be displayed on the user desktop. 

The reason I bring this up is that this same trick can be used if you have an automated functionality test that needs to click the consent dialog.

You can adjust this with a policy.  The local security policy (Run secpol.msc) is Local Policies | Security Options | User Account Control: Switch to the secure desktop when prompting for elevation.  Set this policy to "disabled" to allow the consent dialog to be presented on the user desktop.

On Windows 7, this setting is exposed through the UAC slider bar UI.  Just slide the knob to the next notch down from the default:

Chris talks all about the slider in his post.

Of course, running with this policy disabled opens up some risks and isn't recommended for normal operation.  For more information on the secure desktop and UAC consent can be found in the UACBlog in the User Account Control Prompts on the Secure Desktop post.

Developing Compatible Applications for Windows 7 webcast

I know I could talk all day about application compatibility topics and not cover everything that can be discussed.  Here’s a one hour webcast  I did that focuses on the top issues and most confusing topics for Application Compatibility.  I do some of my favorite demos showing UAC architecture, data redirection, services isolation, and mandatory integrity control.  The target audience is for developers and testers.

Here’s the webcast: Developing Compatible Applications for Windows 7

My main goal in this presentation is to talk about moving application from XP or Vista to Windows 7 and demystify some of common problems.  I also wanted to “plug” the Application Compatibility Cookbooks.  These documents are some of the best resources for understanding what breaking changes have occurred and how to mitigate them.

Make sure to reference both cookbooks. Most of the breaking changes are in the original XP to Vista cookbook.

Moving from XP-> Vista/2008 –> Win7: “Application Compatibility Cookbook”

Moving from Vista -> Win 7: “Windows 7 Application Quality Cookbook”

OEM Ready Test Case 1 Incorrectly Fails with a UTF-8 manifest

I haven't posted in a while.  I've been helping out with a couple other programs we have going on in the labs these days.  OEM Ready is a subset of Certified for Windows Vista targeted at applications that ship on new PC's.

If you are using the automation in the OEM Ready Certification Test Tool, you can get a false failure if your application has a UTF-8 embedded manifest that has the byte order mark (BOM) included.  Visual Studio 2008 includes the BOM if you use it to embed the manifest. 

The error in the log looks something like this:

Sigcheck is used by the test tool to dump the manifest.  Sigcheck outputs the BOM as garbage characters ().  This throws off the test tool and it gives an incorrect result.  This is a known bug with the tools and will be fixed.  For now, if you run into this problem, you can submit this test case as a pass.

Pat

Registering ATL Performance Counters on Vista and Server 2008

If you use the ATL Server performance counter libraries, you may run into a problem on Vista and WS08.  The ATL libraries don't play well with the updates to Windows Resource Protection.  WRP enforces restrictions on the registry to prevent corruption of performance counters.  ATL breaks these rules and tries to update the registry directly.

There is a workaround to the issue that is outlined in Q933241.

To avoid this problem, the recommended way to add counters is through the lodctr tool or the API LoadPerfCounterTextStrings.  See Adding Performance Counters.

If you are really ambitious, ATL Server code has been released as shared source.   I haven't looked at the code or the project but there may be an opportunity to change the way ATL loads perf counters in the future:  http://blogs.msdn.com/vcblog/archive/2007/01/19/atl-server-visual-c-shared-source-software.aspx

Pat

Windows Server 2008 Application Compatibility presentation

In the compatibility labs, we always give an big overview presentation about Windows application compatibility.  There's a lot of overlap between Vista and WS08 AppCompat but we call out some specific areas that mostly affect WS08.  We've recorded the WS08 specific section of the presentation and posted it to Channel 9.  I hope you find this useful in preparing your applications for WS08.

Detecting what Server Roles are installed on Windows Server 2008

I think there is always a nugget of information that inspires a blog.  This is the idea that inspired my blog.

By default, Windows Server 2008 has no server roles installed.  This isn't intended to make you do more work (it's a feature).  The goal is to be secure by default.  After the OS installed, you add the roles and features that that are needed.

So, from an application compatibility point of view, your application may require a role that isn't installed by default.  There are two ways to programmatically query what roles and features are installed.

Using ServerManagerCmd

UPDATE: ServerManagerCmd is being deprecated.  It is recommended to use PowerShell cmdlets for Server Manager starting with R2 forward.

There's a cool command line utility that has been added to Window Server 2008 called ServerManagerCmd.  ServerManagerCmd allows you to add, remove, and query roles and features. 

If you execute the following command:

> servermanagercmd.exe -query roles.xml

An XML file of all the roles and features installed will be created.  You could then parse that file to determine what roles and features are installed.  I was hoping to find something in the scripting repository to do this but couldn't find anything.  Powershell would be a good option but remember... no features are installed by default.  Powershell and .NET 3.0 would need to be installed.  You could do that with servermanagercmd as well.

For example:

> servermanagercmd.exe -install Powershell

ServerManagerCmd is great for scripting but what if you want to do determine installed roles in your application's installer? ...or avoid lots of parsing in a script? ..or needing to install .NET and Powershell?  WMI is probably a better choice.

Using WMI

With Windows Server 2008, there is a new class in the WMI namespace \Root\cimv2 called Win32_ServerFeature.  This will allow you to use WMI to iterate through what roles and features are installed.  WMI is a very good option for determining in your installer if a prerequisite role is installed.

Where do I start?

When you work on a given subject for a while, you tend to jump right in and forget to start at the beginning.   In the Application Compatibility lab, we kick off the week with an overview presentation and cover the basics of common compatibility issues.  Those topics are probably a good place to start with this blog.

The first thing to mention is the Application Compatibility Cookbook.  This is the primer of Application Compatibility.  I was going to call it the K&R of of Application Compatibility but I don't want to date myself ;-).  I highly recommend reading the cookbook or at least keep it handy for a reference.

Now that you've looked at the cookbook (Go look at it now if you haven't), you are probably saying, "Whew, that's a lot of stuff.  Can you just tell me the top issues with Application Compatibility?"  So, let's start with a list of the top areas of issues:

User Account Control (UAC):

UAC is intended to run applications as standard user by default.  Even if you are a member of the administrators group, applications that are not marked to run with administrator privileges will run with reduced "standard user" rights.  Applications may not be designed to run as a standard user and may not have rights or privileges to certain resources.

Next steps if you have an issue:

• UAC in the Cookbook
• Windows Vista Application Development Requirements for User Account Control (UAC)

Installation

Installation issues usually revolve around UAC.  Almost all installers need to run with admin rights because they usually write to Program Files or HKLM in the registry.  MSI issues usually revolve around custom actions being run in the wrong context (user or admin).

Next steps if you have an issue:

• MSI Installer issues - See rflaming's blog
• Custom installer issues with UAC - See installer topics under UAC in the Cookbook

Service Isolation

On Vista and Windows Server 2008, only services run in session 0.  Desktop applications run in sessions 1+n.  This blocks Windows messages between services and desktop apps.  This also blocks services from displaying UI on the desktop.

Next steps if you have and issue:

• Session 0 Isolation in the cookbook

Internet Explorer Protected Mode

IE in protected mode is sometimes called "Low Rights IE".  When protected mode is on, IE runs at a low integrity level.  This isolates IE from the rest of the processes and resources on the system.  ActiveX controls and browser objects may not have appropriate rights running in protected mode.

Next steps if you have an issue:

• IE protected mode in the cookbook
• Understanding and Working in Protected Mode Internet Explorer

That's it for now.  One final note, the area for all things regarding Application Compatibility can be found on Technet.

Pat

Welcome to my blog

I'm Pat Altimore an Application Developer Consultant who spends most of my time working in the Application Compatibility Labs at Microsoft. I'm planning on posting stuff of interest that we find in the lab. I hope the posts here will be helpful to developers that are getting their apps ready for Vista or Windows Server 2008 (and beyond).

There are a lot of great blogs by other AppCompat consultants out there. Please check out: MaartenB, CJacks, and Aaron_Margosis.