Windows 7 Application Compatibility 

Overview 
Welcome to this session going over an overview of application compatibility in Windows 7. 

Windows 7 builds on Windows Vista 
When we look at the spectrum of changes in Windows 7 and the impact that it has, beginning with 
Windows Vista, if we go back a few years, we will note that we made some pretty deep changes. We had 
new models for security, new models for device drivers, new models for deployment, a new networking 
stack — a lot very significant changes that had a great impact on application compatibility. 

We had very few changes that we put in place for Windows Vista Service Pack 1. And so we noted that 
most software that worked on the RTM version of Windows Vista continued to work on the first service 
pack. Our goal was to take the very same approach for Windows 7 — to ensure that most software that 
will run on Windows Vista would continue to very well on Windows 7. 

Now, of course, we can never quite get to 100 percent. We will look at and explore why that is so as we 
get into the course here. One thing that I will note is that we will be covering the delta from Windows 
Vista to Windows 7 in this session. There are more training courses in this series that will outline the 
changes from Windows XP to Windows Vista. And yes, we are very well aware of the fact that most 
people who are migrating to Windows 7 early on will be coming from Windows XP and not from 
Windows Vista. 

So we're beginning with the changes to Windows 7 from Windows Vista not because we expect that 
that's where the majority of the work will be coming from. Rather, first of all, because most people are 
already familiar with the Windows Vista changes. And second of all, just so we make sure we understand 
the impact that it's going to have and emphasize that the skills that people may have built getting ready 
for Windows Vista will translate into those applications still working, hopefully, for Windows 7. 

Windows 7 goals 
2:02 

So our goal, as we stated earlier, was to make sure that any application that worked on Windows Vista 
would work on Windows 7, and that any application that worked on Windows Server 2008 would 
continue to work on Windows Server 2008 R2. 

When we don't have that happen, we also want to make sure that we have a broad ISV outreach well 
ahead of the deployment of the RTM version, so that we can rectify those issues beforehand, so when 
we have folks that have something that doesn't work. For example, Skype had an issue that didn't work 
with their version 3. Rather than shipping and having this very important application to a lot of people 
not working, we made sure that we had engineers that could work directly with them to get a version 
ready to go prior even to the release of the beta of Windows 7 — really making sure that we get in there 
early and we then don't go changing the operating system underneath them after they invest in making 
those changes. 

Strategies 
3:00 

So our strategies to get the goals that we wanted to for Windows 7 include:  

• Being able to scale our compatibility efforts. We've got a lot of automation; we've got a lot of 
daily tests that we run on applications to ensure that we understand the impact to the 
application ecosystem of all the changes that we make.  
 
But we added a feature in Windows 7 that we had turned on in the beta so we can collect some 
real data from what users are actually doing with their applications. We call this Telemetry. It 
lets us know which software you're actually running, how long are you running it, is it crashing, 
is it being fixed using shims? Because what we had been going on in the past has always been 
sales data. Sales data may or may not be an indicator of what you're actually using. 
 
By way of example, most people buy tax software. So, once a year, the sales data for that is 
really high. But you don't use tax software all year long, unless you happen to be an accountant. 
So we want to know about software that people are actually using all the time so we can make 
sure we get our priorities set correctly. 

4:11 

• We want to make sure that we prevent any problems by being aware of any problems that 
happen early on. We have a lot of tools that we have built that let us measure the impact of any 
changes that we make.  
• We want to make sure that we have quality gates, so that if we remove a public API, that action 
is detected right away.  
• We want a good, solid infrastructure so we can mitigate any compatibility issues, both now and 
into the future. We'll talk about that over the course of the session.  
• And we also want to make sure that we're really good partners with our ISVs, so that we can 
make sure that we understand the impacts, address them early, and provide them will all of the 
resources that they need to get their software working early and, if we can help it, to just never 
break it at all. 

The net result 
4:54 
The net result: We haven’t added any "special sauce" that will take something that didn't work on 
Windows Vista and have it magically start working on Windows 7. Yes, there are some one‐off fixes that 
we put in place. There are some new shims that we added to target specific application breakages that 
we've come across. But there are no systematic changes that were put in place to, say, take back some 
of the big security bets that we made for Windows Vista. So, all of those issues are still there.  

Fortunately, the ecosystem has had three years to catch up and to heal, so that should be a lot less 
damaging than for someone who is a very early adopter for Windows Vista. 

If you work on Windows Vista, you're probably going to work on Windows 7, unless you experience one 
of the following issues. 

Application compatibility issues 
5:41 

 So let's iterate what those issues might possible be.  

And the one that we hit every single time when we release a new operating system is that we change 
the version number for the new operating system. It is always a problem. In fact, one interesting bit of 
trivia: When we went through to do some analysis on the shims that were used to fix software that was 
assigned to the UAC team — they wanted to know which of these new fixes that we put in place to help 
make it run for a standard user that were not designed that way was the most common. 

And the UAC team, fixing problems that are breaking when running as a standard user, reported that the 
most common fix they used was a version lie. Now, clearly a version lie doesn't cause you a problem 
running as a standard user. It just so happens to be that if you have a problem running as a standard 
user, you coincidentally also tend to have a problem where you need to have a version lie applied to 
keep you working. 

6:39 

What we like to see happen is to have people not check for the version number but instead check for 
the features. I do understand that's hard, and I'm fighting to have that made a little easier. If you are 
checking for a version, we like to encourage you to find the greater‐than key (>) on your keyboard. In 
that way, you can say, Hey, if the version is greater than or equal to this version of the operating system 
that has what I expect in it, then go ahead and run. 

If none of those work, we have the ability to come behind later and apply version lies to pretend to be 
an earlier version of the operating system. 

Why version 6.1? 
7:15  
Now some people ask — well, the first thing they ask is why Windows 7 is not version 7.0. One reason is 
that we can catch issues where something is running and checking for the major version only. If they're 
checking for dwMajorVersion = 6, then we won't break those. If we follow that logic to its logical 
conclusion, what would the next version of Windows have to be? It would have to be 6.1.1, because to 
check for version 7, you now have to check for 6 and a minorVersion of 1, so 6.1 would still be the same, 
and you'd have to look for 6.1.1.  

The version of Windows after that? 6.1.1.1. And, clearly, that begins to become a little silly when you 
think that people are only checking the majorVersion. Yes it does happen. 

8:03 

The major thing that we're trying to accomplish, beyond that, is that anyone who is testing for Windows 
XP is using some flawed logic. And we have some of that flawed logic here on the screen. 

If the majorVersion is greater than 5, and if the minorVersion is greater than 1. So people can say, well, 
is it greater than or equal to 5.1 (this doesn't have equal signs on it), then go ahead and work. 

Well, what's Windows Vista? It's greater than 5, but it's not greater than 1, because it's 6.0. So it failed 
that check for something that was designed for Windows XP.  

xxxVersionLie 
8:43 

So, when we fail a check, what do we do? We could apply version lies to it. This is something that the IT 
Pro can do to pretend to be a previous version of the operating system and get past those checks to see 
if you have a supported version of the OS. 

Version lie shims 
8:58 

There are a bunch of version lie shims; here they are enumerated. We look at everything from Windows 
95 up to, and including, Windows Vista Service Pack 2. We can pretend to be all of those to a particular 
application. 

Version lie layers 
9:12 

Similarly, we have layers that apply to all of those. 

Compatibility tab 
9:18 

And the layers are what we will display to the end user on the Compatibility tab when you go into the 
properties of a shortcut or an executable.  
Shims and layers 
9:29 

So, the question is: What are shims, and what are layers?  

Well, a shim is a way to intercept a call between the application and Windows and provide some 
different behavior. We're going to talk in more detail about how shims work in a later module that's part 
of this training. 

The application, if it spawns a child application, will find that its child application is not calling into the 
shim. It's calling into Windows itself. If, however, I apply a layer, both the application and any of its 
children are going to have that layer applied to it. 

Layers: more than version lies 
10:11 

Beyond just the difference in behavior for child applications, a layer also includes a number of other 
fixes. So the version lie is just one small part of that. So we can see the list in the VistaRTM layer includes 
the version lie plus a number of other fixes that we're going to apply to software that requires that 
layer. 

One thing that is interesting to note that is different, if you are familiar with the operating system layers 
or modes with Windows Vista, is that all of the layers, all of the modes, that you apply that are earlier 
than Windows Vista — so that's your XP Service Pack 3, Service Pack 2, Service Pack 1, Windows 2000, 
98, 95, all of them — now include an additional shim, which is called AdditiveRunAsHighest. What that 
means is I'm going to try to run with the highest level of privileges available.  

From a user experience standpoint, it means that if I'm running as a standard user, the behavior will be 
unchanged. If, however, I am running as a local administrator with UAC turned on, applying an XP layer 
or earlier will cause that application to begin prompting for administrator rights. 

So that is one significant change in the layers from Windows Vista into Windows 7. 

Windows version number (demo) 
11:31 

So we'll take a quick demo now to take a look at how that version number works and how you can get 
past that using version lies. 

 Let's take a look now at the impact of the version number on application compatibility in Windows 7. 

So the first thing, if you aren't already aware, is that we can see the version number is actually 6.1.7100. 
That's the build number for the release candidate. It is not 7.0; it is 6.1, and this is one way that we 
could see that. Just changing the version number alone is enough to cause some applications to have a 
challenge.  
For example, here is an application. If I double‐click it, it immediately says that the application itself 
requires Windows XP. Clearly, they're doing some type of version check; they're saying that it's not 
supported, and then it's going away.  

Now one way to fix it very quickly is to go into the properties of the shortcut or the binary and set the 
compatibility mode. And since I'm currently running XP SP2, I will set that compatibility mode. You will 
notice that straightaway I have put a UAC shield on here. Now, I am going to be prompting for elevation 
when I attempt to run this application.  

Fortunately, it does allow the application to run successfully. But I don't want my users to have to be 
prompted every time. So another option is instead of applying the entire Windows XP layer, which 
includes AdditiveRunAsHighest, we can use the Compatibility Administrator to go ahead and select this 
program, select the path to that program, not select a compatibility mode, but instead go in and select 
WinXPSP2VersionLie and the version lie alone. And then, once I finish making up that shim, I can save it, 
install that custom database. And now, when I go to run that application, I can lie about being Windows 
XP without having to have the elevation prompt and get my software working. And thank goodness, 
because I really enjoy seeing that star. 

13:46 

IE version 
Another potential source of issues is the fact that Internet Explorer is also being incrementally changed 
to now be Internet Explorer 8, from Internet Explorer 7, which shipped with Vista. 

Obviously there are a number of issues with Internet Explorer 8 in Standards Mode, the default mode 
for all of your Internet sites. So we also provided a Compatibility Mode that comes along with it, so that 
we can pretend to be IE 7. 

Now there is no Compatibility Mode to become IE 6. Yes, we are aware that that is probably somewhat 
more problematic for someone who is still running IE 6 on Windows XP. But we do provide the fallback 
to Windows 7 – in fact, fallback by default if you are in the Local Intranet zone. 

We also lie about the version number, and what we'll do is just go straight into a demo of that later, 
where we can see what you can do to get past this. Right? We mentioned that we are able to emulate 
the Internet Explorer 7 browser, right, but it's as the … All right, scratch this; start over. 

We'll next look at Internet Explorer, which is now … scratch. 

15:37 

We'll next look at the impact of having Internet Explorer 8 now packaged as part of Windows 7, as 
opposed to Internet Explorer 7, which was packaged with Windows Vista. 
First of all, some Web applications will check the version number of the browser and behave differently. 
We have revised the version of the browser, as well. Fortunately, fixing that with Internet Explorer 8 is 
much, much easier than it was for Internet Explorer 7, and we'll take a look at that a little bit later.  

It's also possible for someone to, you know, choose a particular site that's having a problem and go back 
to using the previous IE 7 renderer, not only from the IT Pro or end‐user perspective, but from the 
developer perspective. If you have an Internet‐facing Web site that you need to pretend to be IE 7, 
you're able to do that by either setting something in the headers of what's sent back on the HTTP 
request or as a metatag that is part of the page. 

Internet Explorer version (demo) 
16:45 

So let's take a look at how all of these behaviors affect compatibility in Internet Explorer with regards to 
the version number and the Compatibility Mode. 

17:01 

Next, let's take a look at Internet Explorer 8 and how it is able to handle issues with the User Agent 
string, or the version of the browser, that is being rendered. Let's take a look using this Web site, 
What'sMyUserAgent.com. It simply reports back the User Agent string that I am passing to this Web site.  

You can see that it is passing that I am running IE 8. You can also see how easy it is to switch the Web 
site into Compatibility View. Once you switch it into Compatibility View, it will report back to me that 
the browser that I am running is reporting a User Agent string of IE 7.0. So it's actually lying about the 
version in addition to providing the renderer from IE 7. 

So it's very possible for the end user to click Compatibility Mode on and off. It is also easy for the 
Enterprise to go through and have a list of Web sites that are pushed down to all of their users, if there 
are known applications that break. Also, by default, all Intranet sites are going to run in Compatibility 
View.  

For anything that's publically facing, it's very easy for the Web developer to go in and declare that their 
Web application should be run using IE 7 Compatibility Mode, simply by adding a metatag or by adding a 
value to the headers. 

18:37 

Windows Mail deprecated 
One thing that we did for Windows 7 was that we removed the Windows Gallery applications – things 
like the Photo Gallery, the MovieMaker application, the Windows Mail application. Those have all been 
deprecated.  You can still get the functionality. They've simply been moved over to Windows Live. 

However, in the case of Windows Mail, there's actual, documented APIs out there for how you can use 
Windows Mail as part of your applications. The publically documented APIs, for the most part, will 
continue to work. However, if you have an API that is designed to display a user interface, this will 
silently fail; it will never show a user interface. Any protocol handlers, any file extensions, the .eml file 
extension: Those are no longer going to be registered and are not going to have a handler. So if you 
need to have that, you'll need to install some mail application as part of the install.  

CoStartOutlookExpress 
19:32 

Now I went through, took a look at this, and realized that we have this publically documented API called 
CoStartOutlookExpress that is a prime example of the API that would display UI. I observe that even 
down level, even on Windows Vista, I couldn't get it to work. And I was curious why, because there were 
some applications that could, because we've had to fix three of them so far. 

I was curious because breaking three applications when you remove something that has a publically 
documented UI is a remarkably small number. So although I don't expect most people to be fluent in 
reading Assembly Language, I just wanted to display exactly what I found when I was investigating why 
this happened. 

As I was tracing through and seeing what the APIs were doing, I noticed that we did a call to get the 
name of the current file. That's the first line that you see, the call into GetModuleFileNameW. I do some 
work, and then we come down to the second Call instruction, where we're doing a call to 
PathFindFileNameW, which is pulling just the file name and removing the path from what we found in 
that earlier Call.  

So the module file name — what's the name of the file that is currently running, the code that is 
executing right now. We get down to see, OK, what's the file name and not the path off of that. We go a 
little ways down, and then we see the Push instruction that says "WinMail.exe." Another Push 
instruction, and then call into wcsicmp, which is a string compare. 

I realized that what, in fact, we're trying to do here is make sure that we only ever work if the name of 
the executable is WinMail.exe, which pretty much limits this API to being used by the WinMail 
executable itself, unless you go so far as to rename your executable to be WinMail.exe. And if you're 
going so far as to rename your own executable just to get this API to work, well, that kind of explains to 
me why we only found three applications that broke on the removal of this API. Not that there aren't 
more out there, but my expectation is that it's probably very rare. 

How to write apps that break 
21:45 

After I went through that exercise, I figured I'd go ahead and write a quick how‐to guide on how to write 
applications that break. 

Step 1: Ignore all the published APIs. Rather than calling into WinMail.exe yourself, you know, and 
expecting that to work; rather than accepting the failure as maybe a sign that it's not something that's 
meant to be. 
Reverse engineer what you find in Windows to figure out what you need to do to get it working. In this 
case, I would need to rename my own binary to WinMail.exe. 

Write code depending on what I reversed, assuming that we'll never, ever change Windows. And then 
simply sit around and wait for us to change Windows. That's how you can guarantee that something's 
going to break. 

22:26 

Obviously, we don't need that. But these are the kinds of things we're finding that is causing the most 
breakage in Windows 7 — when someone is reversing Windows, taking dependencies on things we 
never promised, and ending up breaking as a result of that. 

Not that they're bad developers for doing that, but simply that it's hard for us to uphold a contract that 
we never made. So we try to work with the Partner ecosystem to explain what we're providing and 
provide that out of the box. 

Windows Movie Maker deprecated 
22:55 

Similar to Windows Mail, we've removed Windows Movie Maker, another of the Windows Gallery 
applications that doesn't have the level of documented APIs that Windows Mail, or formerly Outlook 
Express, would have. However, there are some people who are developing plug‐ins, which are used by 
the application. Because you don't have the application, obviously your plug‐ins aren't going to be very 
useful anymore. 

NLS sorting changes 
23:20 

Another change that we made was to the sorting system, the NLS system, which is a sorting library that 
is revised for most of the major Windows versions that we released. The NLS version — right, we do 
have an API that you can use to check that it has been changed, and you can compare to see if we did a 
major version change. Then you're going to have to anticipate redoing your index. 

If you do a minor version change, your existing indexes should be OK, and you shouldn't have a 
compatibility issue between them. 

23:57 

So I usually begin this talk, and a lot of times I'm talking to people who only speak English. Their first 
question is "I have absolutely no idea what you're talking about, because our 26‐character alphabet has 
a pretty well‐known sort order that hasn't changed in a really, really long time." 

I'll give you a couple of examples of what might happen.  
 • The ligature æ typically would be sorted, if you're doing an alphabetical sort, as being equivalent 
to the letters a and e if they were two separate letters. However, in Icelandic, that would sort 
after the letter Z. 
• The A Ring (Å) would typically sort as a simple diacritic difference from A. But in Swedish it 
would sort after the Z. 

And think about the sorting that would happen in, say, a Far Eastern language, where you have 10s of 
thousands of characters that are being used, rather than simply 26. What are the chanced that people 
might change their mind on how to sort things? What are the chances that there's a bug when you 
sorted things? 

The issue that we come into is with those applications that have an existing index of sorting, because if 
we say that something should have come after the A, as in æ, and suddenly it's coming after Z,if I'm 
looking at a tree trying to do a search for something in an index, on the first branch I'm going to be 
looking at the first half of the alphabet and not the second half, and I'm not going to find my entry there, 
because it would be in the second half; it would be sorted after Z now. 

And so we end up with things not being returned from searches  on any existing indexes. 

25:39 

So that's potentially an issue, and it's something that comes up from time to time. We're looking to build 
some tools around that; although I'm not aware of those having shipped yet, the goal is to have those 
ready by RTM. 

Removal of Registry Reflection 
25:53 

Another significant change that we made, if you are heavily into COM, is the removal of Registry 
Reflection. For x64 versions of Windows, we added that Registry Reflection in as a feature, which was 
used primarily for COM. 

These are the keys that we will do the reflection on. 

As an example of what this Registry Reflection means, say for example you put in a value from a 64‐bit 
binary. We would copy that value over to the 32‐bit key, so both would have the same value. If you then 
modified it from a 32‐bit application, we would copy the value over to the 64‐bit key, and again they 
would have the same value. 

Why did we remove this? Well, for one, it didn't really have that many people who were using it. COM is 
the only known consumer, and since we own COM we can go in and change it. The reason why we 
wanted to change it? Well, it's because when you're copying things over, there's an inconsistent state. 
There will be a period of time when the 32‐bit key and the 64‐bit key are not going to be equal. That 
inconsistency can cause you a number of problems that were hard to resolve. The cure was worse than 
the disease, shall we say. 
27:09 

If you find yourself in this problem, we want to make sure that we're using non‐redirected registry keys, 
that we're explicitly using whichever bit key that we're looking for, we're reading things from a know, 
correct location at all times and not simply expecting, if I'm a 64‐bit app, to find a value there that would 
have been automatically ported from a 32‐bit key. 

Windows portable devices 
27:34 

Another change — and you'll noticed that we're starting to get a little arcane now — is with Windows 
portable devices, another example of reverse‐engineering Windows and taking a dependency on what 
you find other than what was promised. 

We move the functionality that used to be in the Windows portable devices driver (wpdusb.sys) and 
moved it into winusb.sys. OK, so far so good. For anyone who's using the device APIs, the APIs are 
always updated to pull from the right place. 

But if you reverse‐engineered our private, undocumented IOCTL codes, and tried just passing those 
codes in, you'll find that they're now breaking because there's no wpdusb.sys listening for them 
anymore. The remediation is simply to rewrite to leverage Windows portable devices APIs, instead of 
expecting a particular detailed implementation. 

New low­level binaries 
28:30 

We moved some binaries around. You'll notice if you start browsing around System32 that, in addition 
to kernel32 we have kernelbase.dll. We've actually moved functionality from kernel32 and advapi32 into 
this new kernelbase, and that's all part of an initiative called MinWin. If you want some details on that, 
Mark Russinovich gives a fantastic talk on that called "Kernel changes for Windows 7 and Windows 
Server 2008 R2." He's given it at various tech conferences; he's got articles coming out in TechNet 
Magazine, where you can review that in great detail. 

We've done some forwarding, but if you have some applications depending on offsets, or depending on 
undocumented APIs, that could potentially cause you a problem. We'll take a look at that in this brief 
demo. 

New low­level binaries (demo) 
29:20 

Let's now take a quick peek at how the refactoring of binaries manifests itself and how it can potentially 
be an issue for some applications.  

Let's just go ahead and open up kernel32.dll. Look for a function that we expect to find in there. We 
were talking a little bit earlier about the version number, so let's look for the export for GetVersion. 
Here's the GetVersionExA function. We find that in kernel32, which is where we expect to find it. But if 
we go through and disassemble this item — and no, we're not doing a test on how to read Assembly 
Language code — we just wanted to basically show you. We're doing a jump backwards, and from the 
jump backwards we're doing a jump out to a completely different DLL. In this case, the DLL happens to 
be called API‐MS‐WIN‐CORE‐SYSINFO‐L1‐1‐0.dll, and boy what a name. 

If you go and look for that DLL, you won't even find it. It's not on the system. That's what's known as a 
virtual DLL, and Mark Russinovich covers that in some of his talks at various conferences, as well as in his 
forthcoming article in TechNet Magazine that talks about these virtual DLLs.  

What ends up happening is that the loader resolves that virtual DLL location to the physical DLL that it's 
located in. 

30:53 

So, potential problem No. 1: If I have software that's checking to see if the function is actually still living 
in kernel32, it's not! I actually jump out of it within a few Assembly Language instructions, so I'm no 
longer between the start and end of kernel32. Some apps will check for that. 

Another potential issue? Well, some applications will try to chase through and figure out where we're 
jumping to. They won't find this DLL because it doesn't necessarily exist. Instead, the actual function is 
implemented in kernelbase.dll; and if I chase that down, I will find the same ExportVersionExW — and 
this is where the actual implementation of the function lives. 

So those applications that have a specific dependency on a detail of implementation can find that their 
assumptions can be invalidated with Windows 7 and find that, yes, indeed, that can cause compatibility 
problems. 

IE DEP enabled by default 
32:02 

Another change that has the potential to cause you challenges in a migration from Windows Vista to 
Windows 7 or from Windows XP to Windows 7 is the fact that, in Internet Explorer, we have enabled 
Data Execution Prevention by default. We had the feature in Internet Explorer 7 on Windows Vista, but 
if you poke around in Windows Vista, you'll notice that when you go and look at it you actually can't 
change that key, because it turns out that the settings, in the UI, you have to be running as 
Administrator in order to modify that value. 

And most people don't run their browsers as Administrator, unless they happen to run as Admin and 
disable UAC. So most people would never go in and change that setting. 

Now that it's enabled by default, we find that all the plug‐ins will suddenly have to start playing by the 
rules of Data Execution Prevention, or NX. If we have a plug‐in that does not behave well, we will need 
to look for an updated version of that component. If you are a developer, there is some guidance 
around how to do that as well. 
File libraries 
33:16 

Another feature that we've been talking about and have demos of is something called file library. It is a 
way to organize multiple file libraries under a single consistent view from multiple locations. So if you 
have public documents and your own personal documents, you can get a merged view with the two of 
them. You can add some additional folders into there to get a single, merged view of all these locations 
– maybe a server at work, maybe a server at home. You can bring them all together. 

The fact that we've done this, we now have this abstraction that says, Hey, I'm going to look at a view of 
these two different locations. That library has to be something. It turns out that the library itself, that 
something, is the file. There are some APIs that you can use to get the folder and get the file name, and 
the folder happens to be a library and not a directory, GetFolder will return the library, which is going to 
be a file name. 

So, if you were to, instead of calling iFileDialog‐>GetResult, which would give you the fully qualified path 
to wherever it is you're looking for, but instead call GetFolder+GetFilename, you would be appending 
GetFolder (a file) to GetFilename (a file) and constructing something that makes no sense at all. 

How we help you express your intentions more clearly: Switchback 
34:37 

Now, one significant feature that we've put in place to invest in the future is called Switchback. 

Now what this feature does is it allows you to tell us which version of the operating system you're 
designing software for. This is something that we're really trying to evangelize with developers. Anyone 
who is writing code – whether you're writing commercial software, whether you're developing line‐of‐
business software – you now have the ability to include in your Compatibility section which version of 
the operating system you have designed for. 

Switchback switch points. 
35:14 

There are a few ways that helps you in the moment. It turns on these certain switch points. There aren't 
too many of them.  

So if we look at the Remote Procedure Calls, we might move it to a different thread pool, a private 
thread pool is the default one.  

For DirectDraw, we actually take away the ability to lock the primary video buffer, which has the 
unfortunate side‐effect from the perspective of the user of disabling the Desktop Window Manager. 

Similarly, we turn off some of the abilities of the DirectDraw Bit Block Transfer that can cause some 
challenges working with the Desktop Windows Manager. 
But we also fix a bug. GetOverlappedResult? That API has a race condition. If we think that you're 
designed for Windows 7, then we can fix the race condition, because if we just fix the bug, we break 
apps. So by manifesting as Windows 7, we can give you the fixed behavior without breaking any legacy 
apps that are out there. 

And a final benefit is that the Program Compatibility Assistant, which monitors your application to see if 
there are any potential issues that it can spot and offer to fix for you, is disabled, because you're saying, 
"I'm designed for the OS I'm running on, and so I don't really need your help." 

Switchback manifest 
36:27 

Here's what the manifest would look like. It's the XML that you include, either as a resource or side‐by‐
side with the application (the resource has precedence), to tell us, "I'm designed for this OS." 

Then, in future versions of Windows, we can look at this and say, "Oh, you were designed for Windows 
7. I can put in place some lightweight virtualization to ensure that I keep you working as best I can." 

Switchback supported Oss 
36:54 

Which operating systems should you choose? Well, you noticed — then we'll go back to this slide — that 
we're supplying GUIDs, and since we obviously can't do a greater‐than or less‐than on a GUID, what you 
should do is supply the GUIDs of every operating system that you are tested on. 

So if you are running Windows 8, for example, if you just put a Windows 8 GUID, Windows 7 would not 
know that you are aware of something beyond it because it doesn't know what the Windows 8 GUID is. 
It hasn't even been generated yet. 

So if you depend on some of these switch points to be turned on for Windows 7, on Windows 8, with 
the Windows 8 GUID, you would get the Windows 7 plus the Windows 8 switch points. On Windows 7, 
you wouldn't even get the Windows 7 switch points, because it doesn't know that GUID at all. It just 
ignores it. 

So if you work on 7 and 8, make sure you supply supported OSes, including 7 and 8. 

Switchback operating system modes (demo) 
37:54 

Let's take a quick look at how the operating system context can be viewed on the system using these 
manifests.  

Let's now take a look at how we can see the operating system mode that has been set using the 
switchback manifest portion. Here we are in Task Manager, and we're on the Performance tab. From 
here, we can very easily link to the Resource Monitor, which lets us go in and look at some details for 
the processes that are on the system. In addition to having all of these listed off, we can add an 
additional column for Operating System Context. By default, it's not there. You have to add it on. Once 
you've done that, you can see which context has been set for this application, whether it's the Windows 
Vista context or the Windows 7 context. 

So you can see the operating system binaries that are saying, "Oh, I'm part of Windows 7, and I should 
be treated as a Windows 7 app" versus some older apps that don't have this manifest portion, which are 
saying, "I'm Windows Vista." The difference today being yeah, they're going to get a few switch points 
and bug fixes, and maybe that's good. But it also means that in the future, we'll know which operating 
system you were designed for. If we can build in some lightweight virtualization, we know to try to get 
you working as if you were designed for this OS, since, indeed, you actually were. 

What we made look a little nicer 
39:39 

We'll next take a brief tour of some of the visual changes that we put in place. 

We've updated some of the dialog boxes, and this is one that has gotten us some pretty good press from 
people who are crazy about fonts. We actually organized our Font dialog box to actually group fonts 
together appropriately in a way that is more typographically accurate than what we've done in the past. 
We kind of cleaned it up, freshened it up, made it look a little bit nicer. 

Probably more significantly, here are some of the changes that we made to User Account Control. We'll 
go into the details of this and take a look at what the changes are in terms of the UI that you're seeing, 
as well as in terms of configuration. 

UAC changes (demo) 
40:25 

So let's take a quick look at a demo of that. Now we'll take a look at the changes that we've put in place 
for User Account Control, or at least the more visible ones that you'll find.  

If I go into the Action Center, I can click on this item to change my User Account Control settings, and I'll 
find that instead of an On‐Off button (and that being all I get), I now have a slider. And the default is 
slightly different than what we had in the past. If I push it all the way to the top, I go back to Windows 
Vista mode, which is, in essence, prompt whenever I want to run anything elevated.  

The new default mode is one that's one notch down. It says, "Prompt me for applications that are trying 
to run with Administrator rights; but if it is a Windows binary or specifically a Windows binary on a 
whitelist of approved binaries, then please go ahead and automatically elevate those." 

I can take it an additional notch down and not switch to the secure desktop when I do that prompting. 
Or, finally, I can go all the way down to "turn UAC off." So I have a couple of in‐between notches.  
We'll go ahead and set it at the middle notch here so we can see the UAC prompts on our screen, 
because the next thing I want to show is the difference in the prompts themselves. 

41:44 

It used to be that we had three different styles of prompts.  

We had the prompts for anything that is a Windows binary; they were a nice, colorful blue. We'll go 
ahead and use the command prompt and see that here. Right, colorful blue. It says, "Hey, you know, it's 
your old buddy Windows. Would you like to go ahead and elevate? Everything's OK, so why don't you go 
ahead and say Yes." 

If you were an application that was digitally signed but by somebody other than Windows, on Windows 
Vista, you would see a grey prompt. But on Windows 7, now all signed applications get the exact same 
blue prompt. 

Finally, if were to try to run something that's not signed at all as an Administrator, on Windows Vista you 
would get a UAC prompt that looked qualitatively different from any other UAC prompt. Rather than the 
two buttons, it would have two Task dialog boxes. It was a completely different experience. On 
Windows 7, it is no longer a different experience. It is now the same experience. Yes, it's still yellow, 
showing you that this is something that's somewhat more dangerous than the other things, but at least 
it looks like the same thing.  

Tools and tips 
43:02 

Finally, let's go through a quick tour of the various tools that are available to help you through this 
process. 

ACT 5.5 
43:12 

First of all, we always release a version of the Application Compatibility Toolkit when we release a new 
version of the operating system. And we made sure that, even in time for the Release Candidate, we had 
a full version of ACT available that would support the new operating system, learning from previous 
experience that if we come along three months later, we run into some challenges for people who were 
trying to be early adopters but need to have production‐ready tools ready for their use. 

There are a bunch of new features available in ACT 5.5. We have a whole session coming up where 
we're going to be talking about all of the details about what happens in there and the internals of ACT, 
as well as focusing on some of those new features. 

Some of the interesting ones, which we'll gloss over here:  
 • Things like DCP Tagging, the ability to have the data collection package you send out have a tag 
associated with it. So, all of the applications, all of the issues that come back, will come back 
with that tag attached to them. 
• The support for Application Verifier 4.0 and Standard User Analyzer, which became a problem 
when we got rid of the 3.x version from the Web, and people could no longer use the old 
version of Standard User Analyzer. Well, we fixed that now.  
• We've done a lot of additional documentation on the fixes that you have, in terms of shims. 
• We've added some deprecation checks for Windows 7. 
• And we've added some great report‐filtering capability using auditing and the ability to really 
get into details of what you will or will not be able to synchronize. And with the community: 
We've added a lot of community enhancements. 

We will go over all of that in a session a little bit later on in this training. 

Problem Steps Recorder 
44:51 

Another great tool that I'm not entirely sure the developers intended to be such a publically visible tool 
— though I can't imagine they'd be sad about it — is the Problem Steps Recorder, a way to very quickly 
and easily record all of the steps necessary to reproduce a bug, package up those steps with 
screenshots, and send them off for someone to review. 

We designed it to integrate with our internal error‐reporting system during the pre‐release versions of 
the product. It was there in the beta. As well as with the Watson system, which is the online bug‐
reporting and crash‐analysis tool that we have. 

Problem Steps Recorder (demo) 
45:32 

Next, we'll take a look at how the Problem Steps Recorder works and how it could be incorporated into 
your workflows. 

Now, let's take a look at a tool called the Problem Steps Recorder. This is a tool that I can get from the 
Action Center. Once again, if I go into the Action Center, I can go into Troubleshooting, and from the 
Troubleshooting menu I have the option to say that I would like to Get help from a friend. 

46:00 

Now the friend may not be available right now, so that's why I can link from here to the Problem Steps 
Recorder, which lets me record what I'm doing when I find the problem.  

If I click on Start Recording, then I run the application that's giving me a problem — it's going to have an 
error message. If I would like to add a comment, I can say, "I prefer not to be an administrator." I can 
put in the comment as I'm passing this off to someone to investigate it, whether they are indeed my 
friend, or a Helpdesk, or perhaps I'm just a tester trying to escalate something to someone on the 
development team to get it fixed.  

When I'm all done, I select Stop Recording, and I can place this recording somewhere else. I'll just put 
this on my Desktop. I'll call this the StockViewerProblem. It will place this into a ZIP file that lives on the 
Desktop. 

If I open this ZIP file, it's simply compressing a single file (in this case an MHT file document) that if I 
open, I will find gives me a list of all of the actions that I took. Here I clicked the Start button; it'll show 
me a screenshot. What did I do next? I clicked the Start menu; it will show me a screenshot. It shows 
where this problem came up, it shows the comment that I made, and here is what was happening on the 
screen when I made that comment. 

47:30 

I clicked OK, here's a screenshot and some additional details on what was happening, in case I need that 
for debugging. 

So I capture all of that information in a way that is very easy to redistribute and send off to someone – 
and also reasonably compact. The sum size of this thing is 184 KB to package up all the steps to 
reproduce that issue. That could be the difference between the issue getting fixed and the issue not 
getting fixed. 

Windows troubleshooting 
48:05 

And finally we have Windows troubleshooting, which is the way to build up some common 
troubleshooting steps into a unified UI. In essence, you can use XML to define the user interface and 
PowerShell scripts to go through and define the functionality for the checking and remediation of 
configuration issues, so you can package up a solution to a problem that may be hard to fix otherwise. 

So if you have a common configuration problem somewhere in an organization, and it typically requires 
a number of steps to rule out what's not wrong so you can determine what is wrong, we can now begin 
to automate that without everyone having to invest in their own UI framework. 

So let's take a look at how this works, as well as the tools that you would use to build up your own 
custom troubleshooting packs. 

Windows troubleshooting (demo) 
49:02 

Let's take a look now at a feature called the Windows Troubleshooting Platform and how that's 
leveraged both in the operating system as well as ostensibly by anyone in the Enterprise, at an OEM, or 
pretty much anyone else. 
So again we can access this from the Action Center. We click on Troubleshooting, and let's say I'm 
having trouble with my favorite new feature in Windows 7, DirectAccess. 

If I click on Network and Internet, I will see that there is a troubleshooting pack for troubleshooting 
issues with connecting to my workplace. When I click on a troubleshooting pack, I get a consistent‐
looking UI that I can simply click Next through, that will be behind the scenes, running a set of 
PowerShell scripts to try to understand what could be going wrong. 

Because I am able to encode all of things that could possibly be a problem, I can automate the process. 
The design philosophy behind a troubleshooting pack should be "One click and it's fixed." Rather than 
having you follow step‐by‐step and do it yourself, or asking you a number of questions, the idea is, to 
the extent that you can, click it, find the problems that you can possibly have, and if you can fix it, go 
ahead and fix it. 

50:21 

In this case, I'm going to run through. It's detecting some problems, it's fixing them. DirectAccess 
happens to be down for me for me, so it's telling me the problem: The DNS server isn't responding. This 
is something I can escalate to the Helpdesk. 

The platform itself is extensible. If I install the Windows SDK — and this is from the Release Candidate 
version — I'll find in the Tools directory the Windows Troubleshooting Pack Designer. The 
Troubleshooting Pack Designer will let me build my own. 

So, with a little bit of XML coding, I can build some scenarios. But even without the ability to write XML, I 
can build some – you know, most of the typical scenarios that you would build. You would create the UI, 
and simply write some PowerShell scripts behind it to go through and fix the problem that I am able to 
detect, using PowerShell with all the powers that it provides. 

51:23 

So that is the end of this presentation. We hope it was useful. We'll next be drilling into a lot of the 
issues that are going to be problematic for anyone making the migration from Windows XP to Windows 
7. So we'll see you there.