The Professional Developers Conference (PDC) is the one event that all developers who use any Microsoft technologies must attend at least once in their professional careers. It’s the flagship event for developers, offering the most comprehensive, future-looking, technically deep, densely-packed set of sessions from Microsoft speakers you can find anywhere. This year’s PDC is no exception and you can expect it to be a very exciting event.

My first PDC was PDC08, held last November at the LA Convention Center. As one of the people at Microsoft who work on Windows 7, I was fortunate enough to be in the loop regarding Windows 7 @ PDC08, and was able to contribute (even if only in a small way) to one of the keynote. During the Day 2 keynote,

Steven Sinofsky presented Windows 7 to the world and for the first time people outside of Microsoft saw the new Taskbar, the Windows Ribbon, and witnessed a live multitouch demo. Attendees received a 160G hard drive (makes you wonder what they'll get this year…) with Windows 7 build 6800 (does anyone remember this build number?). The Windows team presented a lot of its technologies in a series of impressive sessions. And since then, through the different versions of Windows--Beta, RC, and RTM--we continued to push new content to help developers ramp up and get ready for Windows 7.

Windows 7 will become “Generally Available” (GA) to the public on October 22^nd, exactly two weeks from today, and this year’s PDC takes place right after Windows 7 GA. With the pre-release veil of secrecy lifted, during this year's PDC we can dive deep (very deep) into Windows 7 to extend our understanding of how Windows 7 works and, even more importantly, how developers can take advantage of all the great new improvements and features Windows 7 has to offer.

To start with, on the day before PDC09 starts, there is a FREE Windows 7 (seminar) Boot Camp led by top Microsoft Windows experts like Mark Russinovich, Landy Wang, and Arun Kishan. Then, during the PDC proper, we’ll have several deep-dive Windows 7 sessions.

So here is the first set of Windows 7 sessions that we are announcing:

This first one is probably my favorite topic (I am a geek, what can I say). What could be more important than performance, especially as it relates to Windows 7 and applications running on Windows 7? This has to be a MUST Attend session for any developer who writes any software (native or .NET) for Windows (and not just Windows 7) – this is truly a unique opportunity.

Optimizing for Performance with the Windows Performance Toolkit

The Windows team uses the Windows Performance Toolkit (WPT) to optimize the Windows OS. Come and see how the Windows Performance team used the WPT throughout the Windows 7 development cycle to optimize for customer scenarios and how you can leverage many of its features and capabilities to help you build faster applications on Windows. This session will present case studies that demonstrate how you can use the toolkit to pinpoint areas for improvement in your application and provide you with some best practices to follow in order to create applications with optimum performance.

The next two sessions are also personal favorites (you can’t blame me for loving Windows 7), as I think these technologies represent new levels of user interaction and adaptive user interfaces:

Building Sensor- and Location-aware Applications with Windows 7 and .NET

How many times have you thought to yourself, “My application would be so much better if it knew where the user was?” With Windows 7 and.NET Framework 4.0, you now have the tools at your fingertips to location-enable your applications. Based on the new Location platform for Windows 7, the location API in .NET Framework 4.0 provides a single, consistent API to get you your latitude and longitude regardless of the underlying technology that acquired it—allowing you to focus on creating exciting, differentiated location-aware applications.

Windows Touch Deep Dive

Windows provides applications with a default experience for gestures and touch interaction. This provides applications that you want to go beyond that basic experience with a powerful platform to build upon. This session is targeted at developers interested in building touch-optimized experiences. We’ll look closely at some of the more powerful portions of the Touch platform, like manipulation and inertia processors, as well as cover real-world problems that developers have encountered and overcome. Come help build the next generation of user experiences!

Another highly recommended session is the Windows Ribbon session. Before you dismiss the Ribbon, I suggest you take a second look and read between the lines of the Windows Ribbon native API. There is a lot of very interesting software architecture in the current API that provides a glimpse into tomorrow’s “commanding framework.”

Windows Ribbon Technical Deep Dive

This talk will cover some of the more subtle and complex aspects of ribbon implementation, like designing a great gallery (a critical task for any ribbon), adding an outspace MRU, etc. We will draw from specific experiences with Windows Live and other partners and spread the learning that those teams amassed as Windows Ribbon guinea pigs.

A lot has been said about the update to the Windows 7 graphics stack. This stack plays a major role in the performance improvements Windows 7 offers. You, as a developer, can tap into that user experience and start enjoying a rich and modern graphic framework that pushes GPUs to their limits.

Modern 3D Graphics Using Windows 7 & Direct3D 11 Hardware

Dig deep into the capabilities of Direct3D 11 and Windows 7to gain practical knowledge that will help you push graphics to the limit. Learn about the new tessellation stage in Direct3D 11, which enables an unprecedented level of rendering quality by dynamically generating geometry on the GPU. In addition, see how the multi-core improvements in the Direct3D 11 runtime can help you scale your application to take full advantage of all of the cores on a machine. Finally, take a peek at the power of DirectCompute (the hardware-accelerated general purpose computing technology) in a graphics application context.

Advanced Graphics Functionality Using DirectX

The number of PC configurations is exploding. With both netbooks and high-end desktop systems using the latest in graphics hardware, creating an application that can target all of these systems is getting harder every year. Join us as we explore the many options available in Windows 7 to facilitate graphics development across all kinds of hardware configurations, from low-end integrated GPUs to top of the line discrete GPUs. Learn about Direct3D 10 Level 9, which enables Direct3D 10 applications to run on pretty much every computer in the market today. Check out WARP, our new software rasterizer that lets your application use high-quality graphics even when there’s no graphics card. Finally, learn about Direct2D, DirectWrite, WIC, and the interoperability of Windows 7 technologies for making slick, high-quality graphics for your applications of the future.

The last session for today’s post, but most certainly not the least, is about the Windows API Code Pack for the Microsoft .NET framework. This is a framework that I have a personal interest in and I often blog about. With Visual Studio 2010 and .NET 4, .NET developers have an easier life. Nonetheless, there are still a great number of valuable Windows APIs that are NOT in the framework. This Open Source library provides a good intermediate solution.

Developing with the Windows API Code Pack for .NET Framework

The Windows API Code Pack for Microsoft .NET Framework provides a source code library that you can use to access some new Windows 7 features (and some existing features of older versions of the Windows operating system) from managed code. These Windows features are not available to developers today in the .NET Framework. This session will show you how to access features like taskbar integration, JumpLists, libraries, the sensor platform, Direct2D, and more.

Have you ever wondered how Windows 7 resumes from sleep in less than 2 seconds? Or how Windows 7 can scale up to 256 cores? Or maybe you just want to want to learn about any Kernel improvements that will make your application run faster with no extra effort from you?

Well, guess what? On Monday, November 16^th, the day before PDC 2009 starts, we are running a FREE Windows 7 Workshop – AKA Windows 7 Developer Boot Camp. That is  right, it's FREE for anyone who wants to attend. Windows 7 is one of the most exciting pivotal releases of the year. As part of the wave of activity surrounding the product launch, we're opening up this workshop to anyone who wants to attend - even if you're not able to join the rest of the conference. So, if you live LA, its surroundings, or even the Bay Area, you can attend this workshop for FREE!

Wait a minute! By now, you must be thinking to yourself, “If it is free, it can’t be that good.” Well it turns out that this Windows 7 Developers Boot Camp will include top Microsoft Windows experts like Mark Russinovich, Landy Wang, and Arun Kishan. These are the guys who are behind a large number of the amazing performance improvements in Windows 7, and this is your onetime chance to meet them in person for an intense, deep, and high-quality session. Mark, Landy, and Arun will start by talking about Kernel and architectural improvements, for example, the Kernel Dispatcher Lock, new and even more efficient Windows Memory Management, and Trigger Start Services, among many other topics.

Next, they’ll take a dive deep into the different APIs, paying special attention to the new shell integration points in Windows 7 such as the taskbar, libraries, and search. Right after that, they’ll give some tips for getting the most out of today’s hardware using the Sensor & Location platform, multitouch, and the new graphics libraries (Direct2D, DirectX 11) that take advantage of the GPU.

Regardless of whether you’re a C++, C#, or Visual Basic developer, if you're building a Windows application and you want your application to have the best possible performance, experience, and look-and-feel while running on Windows 7, this event is for you! I know I will be there; what about you?

Register for the PDC Workshop or read more info about the Windows 7 Boot Camp.

It has been a while since the last blog posting, Windows 7 RTM – Go Get It, and we have a lot of catching up to do.

The Windows 7 GA data is still October 22^nd, less than a month away, which means your application should be almost ready for Windows 7. As you prepare your applications for Window 7, be sure to verify that you don’t have any issues with version checking and UAC Data Redirection. This post topic, Session 0 Isolation, is another application compatibility topic that requires our special attention, especially if your applications include services. If your services are working on Windows Vista, most likely they will continue to work on Windows 7 (still you need to test your application fully on Windows 7). However, if you didn’t run the proper compatibility testing on Windows Vista, you might want to take few moments to read this post.

Let’s start with a better understanding of what services are.

What are services?

A service is an integral mechanism built into Microsoft Windows operating systems. You can think of services as “special applications” that run with no regard to the current user context. Services are different from “regular” user applications because you can configure a service to run from the time a system starts up (boots) until it shuts down, without requiring an active user to be present – that is, services can run without having any users logged on.

We like to think about services as running “tasks” for us in the background without interfering with user operations. Services on Windows are responsible for all kinds of background activity that do not involve the user, ranging from the Remote Procedure Call (RPC) service, through Printer Spoolers, to the Network Location Awareness service.

What’s the problem?

Some services may attempt to display user interface dialogs or communicate with user applications. Such functionality is “typical” of Windows XP services, mainly because it is easy to do so. If you happen to own a service that attempts to display some user interface objects, like a dialog box, or tries to communicate with applications you might run into trouble running on Windows 7.

When running a service that is trying to display a dialog box on Windows 7, instead of the desired dialog box, you will see an annoying flashing icon on the taskbar. And, if you press on that flashing icon, you will see a security dialog box. To be more specific, when running on Windows 7, your service may experiences one or more of the following symptoms. The service:

• Is running, but cannot do what it is supposed to do, and just eats CPU cycles and memory
• Is running, but other processes can't communicate with it and it cannot communicate with the user, or other applications / services
• Is trying to communicate with user applications through window messages, but the window messages are not reaching their destination
• Displays a flashing icon on the taskbar indicating the service wants to interact with the desktop

All the above symptoms point to the conclusion that your service is experiencing Session 0 Isolation of Windows 7 Services, that is, the “physical” separation between services and user applications, but more about that in just a bit. First, let’s define the two “buckets of issues” your services may experience when running on Windows 7:

• The service fails to display a UI or it displays a mitigation UI (or annoying flashing dialog box): When a service attempts to show any user interface element (even if it is allowed to interact with the desktop), a mitigation layer prompts the user with the Interactive services dialog detection dialog box, as shown in the next image. The user may opt in to see the service UI on the session 0 secure desktop, but the interruption in workflow makes this a serious application compatibility issue. Furthermore, some users may not react very well to a dialog that blocks your services / application from getting the user input and breaking the flow of the application.

• Objects shared by services and applications become invisible or inaccessible: When an object created by a service is accessed by a standard application (running with standard user privileges), the object cannot be found in the global namespace (that is, it is private to session 0). This means that other applications will not be able to access the so-called “shared object” from the global namespace, and most certainly, not directly from session 0. Additionally, security changes might warrant a situation where even if the object is visible, it is not accessible. This may affect other processes (such as standard user applications) from interacting with your service, again breaking the application flow.

Clearly, Session 0 Isolation has the potential of being a serious compatibility pain. Well, this post should provide you with enough information to identify if your service is at “risk” -- and how to solve the problem. However, I have to remind you that the main reason for isolating services from user application is making it harder for malicious software to run with elevated privileges, which enables them to do far more harm than running as standard user as explained in the following section, thus making Windows much more secure operating system. 

The Reason: Session 0 Isolation of Windows 7 Services

In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, services and applications run in the same session as the one started by the first user who logs onto the console. This session is called Session 0, and as shown in the following image, prior to Windows Vista, Session 0 included both services and standard user applications.

Image source: http://www.microsoft.com/whdc/system/vista/services.mspx

Running services and user applications together in Session 0 poses a security risk because services run with elevated privileges, while user applications run with user privileges (most of which are not admin).This makes the services targets for malicious agents that are looking for mechanisms to elevate their own privilege levels by “hijacking” the services.

Starting with Windows Vista, only services are hosted in Session 0. User applications are isolated from services, and run in subsequent sessions created when users log onto the system: Session 1 for the first logged on user, Session 2 for the second, and so on, as shown in the following image.

Image source: http://www.microsoft.com/whdc/system/vista/services.mspx

Entities (applications or services) running in different sessions cannot send each other messages, share UI elements, or share kernel objects without explicitly qualifying them to the global namespace and providing the appropriate access control settings. The following image illustrates this:

You can find additional valuable information about this in Impact of Session 0 Isolation on Services and Drivers in Windows Vista (http://www.microsoft.com/whdc/system/vista/services.mspx), an article that is equally applicable to Windows 7.

How can you detect whether your service might experience some of the above-mentioned problems?

So far, we have presented the symptoms associated with Session 0 isolation of Windows services, explained what service isolation is, and how it may affect your services and applications. Below are tests and other actions you can take in order to pinpoint your real problem and start resolving it.

Test #1 – Verifying service (or any other process) session assignment

1. Launch Process Explorer.
   1. To download or learn more about Process Explorer, see the Process Explorer Web site on Microsoft TechNet.
2. Ensure that Process Explorer displays all processes:
   1. Click File.
   2. Choose Show processes from all users.
3. Locate the first csrss.exe process, which is a service found under the System Idle Process (see next image), and inspect its properties:
   1. Right-click the process.
   2. Select Properties.
   3. Navigate to the Security tab.
   4. Note the session in which the service runs (typically Session 0) and its integrity level.
4. Locate the second csrss.exe process, found under the Wininit.exe (see next image), and inspect its properties as you did in step #3:

The following images show the process properties of both csrss.exe files - one runs under the medium integrity level (in Session 1) and the other runs under the system integrity level (in Session 0) – can you tell which one?:

The left image shows the process properties for the csrss.exe instance that runs at the high system integrity level (session 0), while the image on the right shows the process properties for the csrss.exe instance that runs with medium integrity level (session 1) of the current logged-in user (which is me).

If your service is running under Session 0 and under a high integrity level, it will be unable to display UI directly. It is also likely that you will experience problems when sharing kernel objects or files with the service.

Test #2 – Ensuring object accessibility

1. Launch Process Explorer.
2. Ensure that Process Explorer displays all processes:
   1. Click File.
   2. Choose Show processes from all users.
3. Locate the suspected service.
4. If the service contains objects that you know are shared with user applications, inspect their handles in the Handles lower pane (press CTRL+H to see it, or access it from the View menu).
   1. Right-click each suspected handle and select Properties.
   2. Switch to the Security tab to see the users and groups that are allowed to access the object referenced by this handle.

The following image shows an example of a shared object that everyone can access (for the “Synchronize” right) even though it is opened in a system service that runs in session 0

The following image displays an example of a shared object that only administrators and the SYSTEM group can access:

Now that you know what the problems could be, what about fixing them?

You've already done the hard part, knowing and understanding that you have a session 0 issue; solving these problems is easy.

Here are some ideas on how to solve the above mentioned problems:

• If a service needs to interact with the user by sending a message, use the WTSSendMessage function. It is almost identical in functionality to a MessageBox. This will provide an adequate and simple solution to services that do not require an elaborate UI, and is secure because the displayed message box cannot be used to take control of the underlying service.
• If your service requires a more elaborate UI, use the CreateProcessAsUser function to create a process in the requesting user’s desktop Note that you will still need to communicate between the newly created process and the original services, which is where the next bullet point kicks in.
• If two-way interaction is required, use Windows Communication Foundation (WCF), .NET remoting, named pipes, or any other interprocess communication (IPC) mechanism (excluding window messages) to communicate across sessions. The assumption is that because these technologies (most of them) integrate better security policies than the one used by basic Windows Messaging, they will provide the required elevation (if needed).
• Secure communication and other shared objects (for example, named pipe, file mapping), by using a Discretionary Access Control List (DACL) to tighten the set of users granted access to the mechanism. Use a System Access Control List (SACL) to ensure that medium- or low-integrity processes can access the mechanism even though a system- or high-integrity service created it.
• Ensure that kernel objects meant to be shared across sessions have names prefixed with the Global\ string, indicating that they belong in a session-global namespace.

Additional Resources

You can find more-detailed information about this topic in the Windows 7 Training Kit for Developers, including a detailed whitepaper and hands-on-lab. If you want, you can download just the Session 0 Isolation hands-on-lab directly.

Here is some basic information about the tools used in this post:

Process Explorer – a monitoring tool for Windows processes that is able to display process integrity levels and object security information.

• More information: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
• Download: http://download.sysinternals.com/Files/ProcessExplorer.zip

 

You can get much more information about this topic and others in Windows 7 topic page on channel 9.

For more Windows 7 Technical content and hands-on experience download the - Windows 7 Training Kit for Developers is also a great place to learn more about this topic

This is it people. Windows 7 RTM is available for download from MSDN & TechNet sites! If you have a MSDN subscription you can get Windows 7 RTM in English. On October 1st, the remaining languages will be released, for more information read - Windows 7 RTM Available Today for MSDN & TechNet Subscribers. You can also get the Windows 7 SDK  and the RTM version of the Windows API Code Pack for .NET Framework.

Make sure you get them all today to start testing your applications, and to make sure your applications are ready for Windows 7 RTM! Now is the time to work on your applications to make sure they are Windows 7 compatible. On top of that, you can use new Windows 7 features such as the Sensor and Location Platform, Taskbar, Libraries, Multi-Touch, the new Graphics APIs, the Windows Ribbon, and many other important and exciting Windows 7 technologies to make your application shine on Windows 7.

New Windows 7 Training Kit for Developers - Get it NOW!

To help you get your application on Windows 7 as soon as possible, we updated the Windows 7 Training Kit for Developers for the RTM version and gave it a new look and better functionality. You can still find all existing topics such as: Taskbar, Sensor and Location, Libraries and Shell, DirectX, Multi-touch, Ribbon, etc. No dev was left behind! The kit is built for both native Win32

C++ developers and .NET developers, so now most topics have multiple labs.We also added 6 new Application Compatibility labs: Version Checking, Data Redirection, UIPI, Installer Detection, Session 0 Isolation, and High DPI, to help you get over the most common application compatibility issues. All the topics in the training kit include additional information like whitepapers, links to MSDN, and links to videos from Channel 9.

 Updated Windows Topic Area on Channel 9

We also gave the Windows topic area on Channel 9 a brand new look and functionality to help you to better choose the right Windows 7 content you need. In the new Windows topic area for Channel 9, you can choose from three main topic areas:

• Using Windows 7 – Contains consumer- and user-related videos such as how to install Windows 7 and how to set up a home group network
• Programming Windows 7 – I don’t really need to explain what goes here, right?
• Last but not least, “Under the Hood” – Contains classics like the interview with Mark Russinovich on Windows 7 Internals.

While we hope you find all this helpful, this is only the start! We are working on more new and exciting content that will be shipped in the following weeks, so stay tuned.

In the meantime, here is some additional useful information:

• The Windows page on MSDN is the one-stop shop for Windows client developers
• At Develop for Windows 7, you can find all the information you need about specific technologies like Direct2D, Taskbar, Sensor and Location, Power Shell 2, Windows Ribbon, and many more
• Windows Application Compatibility is the one page you want to visit to make sure your application runs properly on Windows 7; it includes content and tools to test and fix many application compatibility issues. Directly accessible from that page, is the Windows 7 Application Quality Cookbook
• Also still very relevant, is the Windows Vista Application Compatibility Cookbook--most Windows 7 compatibility issues are the direct result of the changes introduced in the Windows Vista timeframe, and are included as topics in this Cookbook (UAC, Session 0 Service Isolation, IE Protected Mode, etc.), which is a great starting point for addressing these issues
• New Windows 7 videos on the Channel 9 Windows page explore specific features and technologies, and are great “windows” to the Windows engineering team
• As always, the E7 blog is an amazing source of the engineering back story behind Windows 7
• Last, but not least, for IT-Pro, we have our SPRINGBOARD SERIES, and edge on TechNet

And, of course, continue to watch for new posts.

Version checking is probably one of the most common Application Compatibility issues that both developers and users are facing. This is another post in a series of posts about Getting Ready for Windows 7.

As said, this is probably the most common application compatibility issue that users as well as developers face is when an application fails upon checking the operating system version. A lot can go wrong when version checking is misused. A user might experience a “silent fail” where the application simply fails to load and nothing happens. Or, a user might see a dialog box indicating something to the effect of “you must be running Microsoft Windows XP or later” when in fact, the computer is running Windows 7. Many other consequences to poor version checking can inconvenience users as well.

Applications fail due to version checking for two main reasons:

• A flaw (bug) in the version checking code, which fails if the minor version is decreased, even if the major version is increased, for example, changing versions from 5.1(Windows XP) to 6.0 (Windows Vista), or if the expected service pack (SP) is not installed, even if you're running a newer operating system (for example, changing versions from Windows XP SP 2 to Windows Vista SP 1). We recommend that you check functionality rather then checking version, as you can read in this post.
• An intentional blocking that prevents the application from running on operating system versions not tested by its developers. We recommend that you do not block applications from running on future operating systems.

When an application runs on an "incompatible" (due to poor version checking) version of Windows, it will generally display an error message, but it may also exit silently or behave erratically. Often, if we work around the version checking, the application will run well. End-users and IT professionals may apply a fix to let the application think it is running on an older version of Windows.

Working Around The Problem (not really solving the bug)

Compatibility mode: Designed for end users (not for developers to not fix their bugs), compatibility mode is an easy way to work around compatibility issues. When enabled, it applies a set of compatibility fixes that provide a runtime environment more compatible with applications written for older versions of Windows. One of those fixes is the "version lie," which makes the version query functions return the operating system version the user chose in the Compatibility tab of the Properties dialog box instead of the actual Windows version.

To enable compatibility mode:

• Right-click the executable or shortcut to the executable.
• Click Properties.
• Click the Compatibility tab.
• Enable Run this program in compatibility mode for: and select the operating system version you think the application should be able to run on.
  Some applications consist of several executables. You may need to apply this fix to each one.

• Click OK to close the dialog box.
• Run the application.

Checking for Features Rather Than Version

As mentioned previously, checking the operating system version is not the best way to confirm that a specific operating system feature is available. This is because the operating system may have had new features added in a redistributable DLL. Rather than using GetVersionEx to determine the operating system platform or version number, it is more effective to test for the presence of the feature itself. For example, we plan to make the Direct2D and DirectWrite APIs and the Ribbon API available in Windows Vista, so there is no need to block your application from using these APIs when running on Windows Vista. You just need to check if these features are available on the Operation System that you are running. If possible, your application should still run if the feature is unavailable, though with reduced functionality or performance.

You can use one of the following techniques to find out if a specific features is available on the given OS.

For Win32 developers:

• Use LoadLibrary() to load a library which is not yet loaded into your application. If you are interested in a new function of a DLL which is already loaded (for example, kernel32.dll), then call GetModuleHandle() to obtain the module handle. If either of these functions return NULL, then this indicates an error.
• Use GetProcAddress() to obtain a function pointer. If GetProcAddress() returns NULL, then the function may not exist. Cast the pointer to a function pointer of an appropriate prototype. Some functions, although they exist may actually be stubs that return a "not implemented" error. Be such to check for such errors.

Windows 7 introduces a new timer API - SetWaitableTimerEXProc, which adds one more input variable to the regular SetWaitableTimerProc. The TolerableDelay lets you specific a time tolerance window in which the timer can expire. This is a new in Windows 7, that we will use to demonstrate how to check for feature.

      // define function pointer type
    typedef BOOL (WINAPI *SetWaitableTimerExProc)(
      __in  HANDLE hTimer,
      __in  const LARGE_INTEGER *lpDueTime,
      __in  LONG lPeriod,
      __in  PTIMERAPCROUTINE pfnCompletionRoutine,
      __in  LPVOID lpArgToCompletionRoutine,
      __in  PREASON_CONTEXT WakeContext,
      __in  ULONG TolerableDelay
    );

    LARGE_INTEGER liDueTime;
    liDueTime.QuadPart = 0;
    nt period = 1000;
    unsigned int tolerance = 1000;
    HANDLE hTimer = // Get timer handle

    REASON_CONTEXT reasonContext = {0};
    reasonContext.Version = 0;
    reasonContext.Flags = POWER_REQUEST_CONTEXT_SIMPLE_STRING;
    reasonContext.Reason.SimpleReasonString = L"MyTimer";

    // Get module handle to a module which is already loaded
    HMODULE hKernel32Module = GetModuleHandle(_T("kernel32.dll"));
    if (hKernel32Module == NULL)
        return FALSE;

    // Get Address of function
    SetWaitableTimerExProc pFnSetWaitableTimerEx =
    (SetWaitableTimerExProc) ::GetProcAddress(hKernel32Module,     
        "SetWaitableTimerEx");

    // Check if the function exists    
    if (pFnSetWaitableTimerEx == NULL)
        return FALSE;

    // Call function
    if (!pFnSetWaitableTimerEx(hTimer, &liDueTime, period, NULL, NULL,
            &reasonContext, tolerance)
    { // handle error }

Alternatively, you may use DLL delayed loading and call functions in a __try...__except block. (For more information, see Linker Support for Delay-Loaded DLLs.)

For COM APIs, handle errors returned by CoCreateInstance and QueryInterface.NET framework applications that call Win32 APIs via P/Invoke should handle EntryPointNotFoundException and DllNotFoundException exceptions.

 

If You Must Check OS Version Number

Identifying the current operating system is not the best way to determine whether a particular operating system feature is present. However, if you can’t design your application to check for specific feature availability and the only way to ensure compatibility is through version checking, then please consider the following.

For native applications, you will need to ensure your application's logic will work with newer versions of Windows. Please DO NOT BLOCK on version change! The following is a Win32 code example that uses GetVersionEx. If the major version is greater than 5 (Windows Vista, Windows® Server 2008 R2 and Windows 7), the check passes. If it equals 5, then the minor version should be 1 or greater (Windows XP or Windows Server 2003).

#include <windows.h>
#include <stdio.h>

void main()
{
    OSVERSIONINFO osvi;
    BOOL bIsWindowsXPorLater;

    ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
    osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

    GetVersionEx(&osvi);

    bIsWindowsXPorLater = 
 ( (osvi.dwMajorVersion > 5) ||
       ( (osvi.dwMajorVersion == 5) && (osvi.dwMinorVersion >= 1) ));

    if(bIsWindowsXPorLater)
  printf("The system meets the requirements.\n");
    else printf("The system does not meet the requirements.\n");
}

However there is a better way to verify the minimum OS version required using VerifiyVersionInfo(). This function compares a set of operating system version requirements to the corresponding values for the currently running version of the system. The following code example uses VerifyVersionInfo to check the operating system version against minimal requirements (Windows XP SP2):

#include <windows.h>
BOOL Is_WinXP_SP2_or_Later () 
{
   OSVERSIONINFOEX osvi;
   DWORDLONG dwlConditionMask = 0;
   int op=VER_GREATER_EQUAL;

   // Initialize the OSVERSIONINFOEX structure.

   ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
   osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
   osvi.dwMajorVersion = 5;
   osvi.dwMinorVersion = 1;
   osvi.wServicePackMajor = 2;
   osvi.wServicePackMinor = 0;

   // Initialize the condition mask.

   VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, op );
   VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, op );
   VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMAJOR, op );
   VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMINOR, op );

   // Perform the test.

   return VerifyVersionInfo(
      &osvi, 
      VER_MAJORVERSION | VER_MINORVERSION | 
      VER_SERVICEPACKMAJOR | VER_SERVICEPACKMINOR,
      dwlConditionMask);
}

In this code you can see how we use the VerifyVersion with a set of conditions to return TRUE incase we run on any OS grater than Windows XP Service Pack 2.

 

For .NET Framework developers, use the ==, !=, <=, <, >, >= operators of the Version object returned by Environment.OSVersion.Version:

// This code checks if the OS is at least Windows XP
  if (Environment.OSVersion.Version < new Version(5, 1))
  {
        MessageBox.Show("Windows XP or later required.",
         "Incompatible Operating System", MessageBoxButtons.OK,
                MessageBoxIcon.Error);
        return;
  }

It is highly recommended that you don’t check for version at all and try looking to work with features. It will prove valuable for the future…

Just incase you want to read more, here are some useful links

• Application Compatibility Cookbook: http://msdn.microsoft.com/en-us/library/bb963893.aspx
• Version Lie and Managed Applications: http://blogs.msdn.com/cjacks/archive/2007/09/10/version-lie-shims-and-managed-code-on-windows-vista.aspx

You can also download a HOL and code sample for this topic.

To making sure your application is ready (compatible) for Windows 7, I am going to start providing additional information about the few compatibility topics we introduced in the “Is Your Application Ready for Windows 7 RTM?” post. This post focuses UAC Virtualization or more known as Data Redirection.

What Are You Talking About?

Today, many applications are still designed to write files to the Program Files, Windows directories, or system root (typically the C drive) folders. Some applications are designed to update Microsoft® Windows registry values, specifically values in HKLM/Software. But there is one problem: the files or registry values are not created or updated. You may ask, “What’s going on? My application goes through the code and does not report an error. So where are my files?”

To be specific, you may experience one or more of the following symptoms:

• Your application writes to Program Files, Windows directories, or the system root (typically the C drive) folders, but you can't find your files in these locations
• Your application writes to the Windows registry, specifically to HKLM/Software, but you can't see the registry updates
• You switch to another user account, and your application is unable to find files that were written to Program Files, Windows directories, or the system root (typically the C drive) folders, or it finds older versions of these files
• After turning User Account Control (UAC) on or off, your application is unable to find files in the Program Files or Windows directories

If this happens to your application, it is experiencing UAC Virtualization (AKA Data Redirection). The following information provides you with everything you need to know in order to detect this application compatibility problem, offers some solutions, and provides additional information about the specific nature of the compatibility problem.

The Real Issue: UAC Virtualization

Prior to Windows Vista, administrators typically ran applications. As a result, applications could freely read and write system files and registry keys. If standard users ran these applications, they would fail due to insufficient access. Windows Vista improved application compatibility for standard users by redirecting writes (and subsequent file or registry operations) to a per-user location within the user’s profile.

For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.

The following figure illustrates the two components of the Windows Virtualization process: file virtualization and registry virtualization:

To learn more about UAC virtualization and new UAC technologies, see “New UAC Technologies for Windows Vista” at http://msdn.microsoft.com/en-us/library/bb756960.aspx.

Solution

Virtualization is intended only to assist in application compatibility with existing programs. New applications designed for Microsoft Windows 7 should NOT perform write operations to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. Always develop applications for use with standard user privileges and don’t count on the application running under administrator privileges. Test your application with standard user privileges and not administrator privileges.

If you are experiencing UAC virtualization with applications developed prior to Windows 7, re-design your applications to write files to the appropriate locations. When updating existing code to run on Windows 7, you should:

• Ensure that during run-time, applications store data only in per-user locations or in computer locations within %alluserprofile% that have properly set access control list (ACL) settings. For more information about ACLs, see Access Control Lists.
• Determine the known folder to which you want to write the data files. Generic data used by all users should be written to a global public location that is shared by all users. All other data should be written to a per-user location.
  • Generic data files can include, but are not limited to log files, settings files (INI/XML), saved state applications such as saved games, and so on
  • User documents are different; they should be saved to the Documents folder (or to a location the user specifies)
• Ensure that you do not hard-code paths once you have determined the appropriate locations. Instead, use one of the following programming models and APIs to retrieve the correct paths of specific Windows known folders:
  • C/C++ native applications: Use the SHGetKnownFolderPath function that retrieves the full path of a known folder identified by the folder's KNOWNFOLDERID, a GUID parameter indicating the known location you would like to obtain:
    • FOLDERID_ProgramData – Shared program data directory for all users
    • FOLDERID_LocalAppData – Per-user program data directory (non-roaming)
    • FOLDERID_RoamingAppData – Per-user program data directory (roaming)
  • Managed Code: Use the System.Environment.GetFolderPath function. GetFolderPath takes a parameter indicating the Known Location you would like to obtain
    • Environment.SpecialFolder.CommonApplicationData – Shared program data directory for all users
    • Environment.SpecialFolder.LocalApplicationData – Per-user program data directory (non-roaming)
    • Environment.SpecialFolder.ApplicationData – Per-user program data directory (roaming)
  • If none of the above-mentioned options are available, use the environment variable:
    • %ALLUSERSPROFILE% – Shared program data directory for all users
    • %LOCALAPPDATA% – Per-user program data directory (non-roaming) - Windows Vista or later
    • %APPDATA% – Per-user program data directory (roaming) - Windows Vista or later

Steps to Determine the Most Appropriate Solution

So far, we have presented the symptoms associated with UAC virtualization, explained why redirection is taking place, and suggested a solution. This section contains tests and procedures you should perform in order to pinpoint the real problem and plot a way to resolve it.

Test #1:

• Launch the application with standard user privileges
• Run through the scenario that results in a write operation to any given protected folder such as the Program Files or system root (C:\) directories
• Expected results: The application “succeeds” in writing the file to the protected folder; however, you can't find the file in the expected location
• Conclusion: This suggests that UAC data virtualization is redirecting the file to a different location

Test #2:

• Using Windows Explorer, search for your files in the VirtualStore folder
  • The VirtualStore folder is a folder in your profile which stores redirected files
  • The VirtualStore folder’s name and location are subject to change in later versions of Windows
• First, attempt to find it under %localappdata%\VirtualStore
• If you are unable to find it there, try issuing dir %userprofile%\yourfile.dat /s /a at a command line (usually found C:\Users\<user name>\AppData\Local\VirtualStore)
• Expected results: You should find your file at the virtual store folder or sub folders
• Conclusion: This is proof that UAC virtualization is taking place

Test #3

• Log in as an administrator and launch your application with administrator privileges.
  • To launch the application with administrator privileges, right-click the file executable and select Run as Administrator
  • When an application runs with administrator privileges, virtualization is turned off, and the application now has sufficient privileges to write to the protected folders
• Do not rely on permanently marking your application to require administrator privileges as a way to bypass virtualization, as doing so will leave the system more vulnerable to attack, will prevent the application from running with limited or standard user privileges, and will needlessly annoy users with a UAC prompt
• Expected results: The application succeeds in writing the file to the protected folder, and you can find the file at the expected location
• Conclusion: Running the application with administrator privileges turns off virtualization and grants privileges

Test #4

• Launch Process Monitor (ProcMon)
  • To learn more about Process Monitor, visit the Windows Sysinternals Process Monitor Web site on Microsoft TechNet
  • During the hands-on lab, we will walk you through a detailed step-by-step process to use Process Monitor
• Configure filtering to show only file operations and only those operations performed by your process
  • When you launch Process Monitor, the Process Monitor Filter dialog box appears
    
• Add the following entry to the filter: "Column=Process Name, Relation=is, Value=YourApp.exe, Action=Include"
• To invoke the Process Monitor Filter dialog box again, click this toolbar button
• After clicking OK, configure Process Monitor to log only file events by enabling the following toolbar buttons as shown:
• Press CTRL-X to clear the log; press CTRL-E to toggle logging on/off
• Expected results: You will see file operations whose results are REPARSE; the next line (with result SUCCESS) will usually be the redirected operation:

 

 

• Double-click the line representing the operation with REPARSE as the result and click the Stack tab to show the call stack at the time of the operation:

• The pink K and blue U letters on the left of each stack frame show whether the stack frame is in kernel mode (K) or in user mode (U);in this case, we are interested only in user-mode stack frames
• In this example, the SaveFile function (at frame 21) in BrokenAppNative.exe is the one performing the operation which will be redirected
• You should configure symbols for a more meaningful display' for more information about configuring symbols, refer to the Debugging Tools for Windows Web site
• Conclusion: This test proves that UAC Virtualization did take place and shows you what operations in your application need to be corrected

Task #5

• Add a manifest to your application which contains a UAC directive
  • This will mark your application as UAC-aware and will disable UAC virtualization
  • A manifest is an XML document that developers embed as a resource in a DLL or .exe file, but can be a standalone file named YourApp.exe.manifest or YourDLL.dll.manifest
  • Manifests can contain a variety of information that usually pertains to application compatibility, such as the exact version of Visual C++ runtime to load, the version of Common Controls Library to load, as well as UAC settings
  • Read more about UAC settings in the manifest in the Windows Vista Developer Story: Create and Embed an Application Manifest (UAC)
• Expected results: The application now fails to write to any of the protected folders, returning an “access denied” error
  • This is a GOOD result, because the UAC data virtualization didn’t kick into action
  • As the developer, you should be able to recognize this (because you marked the application as UAC-aware in the manifest) and avoid writing to any of the protected areas
• Conclusion: Windows enables virtualization because the application isn’t marked as UAC-aware. Marking your application as UAC-aware disables virtualization. If your app tries to write to protected store while marked as UAC-aware, you will get an access denied exception

Hands On Labs and Additional Material

you can download this doc, a presentation describing UAC Virtualization, and two full hands on labs on this topic, one for managed code and one for native, from here.

Tools

In order to detect UAC virtualization we use the following tools:

• Process Monitor, a free and advanced Microsoft tool that monitors and logs file system, registry, network, and process activity
  • To learn more about Process Monitor, see the Process Monitor page at the Windows Sysinternals Web site
  • Download Process Monitor from Microsoft TechNet
• Standard User Analyzer, part of the Microsoft Application Compatibility Toolkit, is a free tool that monitors resource (file, registry, and others) usage of a given application and reports activity that is responsible for Standard User problems
  • To learn more about Standard User Analyzer see “Standard User Analyzer” at Microsoft TechNet
  • To obtain Standard User Analyzer, download the Microsoft Application Compatibility Toolkit

Additional Resources

• Windows Vista Application Compatibility: UAC: Standard User Changes – http://msdn.microsoft.com/en-us/library/bb963893.aspx
• Common file and registry virtualization issues in Windows Vista – http://support.microsoft.com/kb/927387
• New UAC Technologies for Windows Vista – http://msdn.microsoft.com/en-us/library/bb756960.aspx
• Inside Windows Vista User Account Control – http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx