Windows 7 Battery Notification Messages

Over the past week we have seen a little bit of blogosphere activity regarding Windows 7 and batteries, specifically the new Windows 7 message “Considering replacing your battery”. Since this is related to the engineering of Windows 7 we’re going to use this blog to provide an update to people. As we have talked about many times, we have a relentless focus on the quality of Windows 7 and we take seriously any reports we receive that indicate a potential problem that could result in a significant failure of the OS. In a previous post we talked about the steps we take when we receive a bug report, in particular when we start to see several reports that appear to be the same. For the past week or so we have been diligently working through these steps and more to see if there is anything in Windows 7 we need to address regarding this issue. At this time we have no reason to believe there is any issue related to Windows 7 in this context.

Several press articles this past week have drawn attention to blog and forum postings by users claiming Windows 7 is warning them to “consider replacing your battery” in systems which appeared to be operating satisfactorily before upgrading to Windows 7.  These articles described posts in the support forums indicating that Windows 7 is not just warning users of failing batteries – as we designed Windows 7 to do this – but also implying Windows 7 is falsely reporting this situation or even worse, causing these batteries to fail.  To the very best of the collective ecosystem knowledge, Windows 7 is correctly warning batteries that are in fact failing and Windows 7 is neither incorrectly reporting on battery status nor in any way whatsoever causing batteries to reach this state. In every case we have been able to identify the battery being reported on was in fact in need of recommended replacement.

Using all the tools at our disposal including contacting customers reporting this issue on forums, customer service communications, partnerships with our PC makers, and of course the telemetry in Windows 7, we have been monitoring reports and discussions regarding this new feature, trying to separate reports of the designed behavior from those that might indicate an issue with Windows 7.  In the latter cases we are trying to understand the scope of applicability and obtain hardware on which to reproduce a faulty behavior.   To date all such steps indicate that we do have customers seeing reports of battery health issues and in all cases we have investigated Windows 7 has simply accurately detected a failing battery.   Before I go into our status on this particular issue, we should review the details behind this new feature.

One of the most obvious components of PC battery life (the runtime you get on battery power) is the battery itself. PC batteries inherently degrade in their ability to hold a charge and provide power (as is the case for all rechargeable batteries). The cause of this is complex and includes irreversible changes in battery chemistry, and increased internal resistance among other things and those in turn are dependent on the design and manufacturing of the battery. This degradation translates into less battery life for the user over the life of the battery in the PC.  Ultimately, batteries must be replaced to restore an acceptable battery life.  A quick check of mainstream laptops will show that batteries usually have a warranty of 12 months, which is about the length of time when statistically we expect to see noticeable degradation (meaning that you start to notice the need to charge more frequently). Those of us that have owned the same laptop (or mobile phone, or music player, or anything else with rechargeable batteries) for a couple of years and taken it through regular charge cycles have no doubt “felt” the decline in battery life though we might have attributed to any number of factors since we did not have any information available to us otherwise.

Windows 7 makes use of a feature of modern laptop batteries which have circuitry and  firmware that can report to Windows the overall health of the battery. This is reported in absolute terms as Watt-hours (W-hr) power capacity. Windows 7 then does a simple calculation to determine a percentage of degradation from the original design capacity. In Windows 7 we set a threshold of 60% degradation (that is the battery is performing at 40% of its designed capacity) and in reading this Windows 7 reports the status to you.  At this point, for example, a battery that originally delivered 5 hours of charge now delivers, on average, approximately 2 hours of charge.  The Windows 7 the notification is a battery meter icon and notification with a message “Consider replacing your battery”.  This notification is new to Windows 7 and not available in Windows Vista or Windows XP.

PC batteries expose information about battery capacity and health through the system firmware (or BIOS).  There is a detailed specification for the firmware interface (ACPI), but at the most basic level, the hardware platform and firmware provide a number of read-only fields that describe the battery and its status.  The firmware provides information on the battery including manufacturer, serial number, design capacity and last full charge capacity.  The last two pieces of information—design capacity and last full charge capacity—are the information Windows 7 uses to determine how much the battery has naturally degraded.   This information is read-only and there is no way for Windows 7 or any other OS to write, set or configure battery status information.  In fact all of the battery actions of charging and discharging are completely controlled by the battery hardware.  Windows only reports the battery information it reads from the system firmware. Some reports erroneously claimed Windows was modifying this information, which is definitely not possible.

As mentioned, every single indication we have regarding the reports we’ve seen are simply Windows 7 reporting the state of the battery using this new feature and we’re simply seeing batteries that are not performing above the designated threshold. Below we’ll talk about the data we have to support this point of view. It should stand to reason that some customers would be surprised to see this warning after upgrading a PC that was previously operating fine. Essentially the battery was degrading but it was not evident to the customer until Windows 7 made this information available. We recognize that this has the appearance of Windows 7 “causing” the change in performance, but in reality all Windows 7 did was report what was already the case.

The following data points contributed to our understanding of the reports we are seeing. Please keep in mind that all the telemetry we see is opt-in, anonymous, and respects our privacy policy.

• We have seen no reproducible reports of this notification on new hardware or newly purchased PCs. While we’ve seen the reports of new PCs receiving this notification, in all cases we have established that the battery was in a degraded state.


• Our OEM partners have utilized their telemetry (call center, support forums, etc.) and have let us know that they are seeing no activity beyond what they expect. It is worth noting that PC manufacturers work through battery issues with customers and have a clear view of what is to be expected both in general and with respect to specific models, timelines, and batteries.


• We’ve gone through all the major online support and self-help forums and when appropriate have worked to follow up with any reports of this notification being presented in error. Through this we have identified no reproducible cases where the battery or PC was new and have only learned of batteries that were degraded in capacity.


• In our telemetry from RTM code customers, only a very small percentage of users are receiving the “Consider replacing your battery” notification, and as expected, we are seeing systems older than ~1.5 years.  We’re seeing relatively fewer notifications compared to pre-release software as the average age of the system decreases.


• Microsoft has received 12 customer service incidents in addition to pulling 8 additional incidents from various forums. To date (for a total of 20 incidents), none of these have shown anything other than degraded batteries. 


• Microsoft has been using the technet community moderators to assist in further contacting customers reporting on this notification and we’ve assigned additional customer service personnel to be ready. However, of the 30 or so contacts we have received we have not learned of any new facts or conditions with respect to this notice.


• During pre-release testing of Windows 7 we saw almost precisely this same experience with customers in terms of the display of the notification. In fact, in looking at the hardware distribution of pre-release testing we saw an ever so slightly higher number of systems receiving this notice. This follows from the fact that a large set of customers are buying Windows 7 with new PCs or using the upgrade provided with a recent Windows Vista PC.


• When looking at the telemetry reports for the machines that have reported displaying this notification we have seen nothing in additional reliability data that indicates any other system anomalies.


• While the information regarding battery status is provided read-only to the operating system through ACPI, we performed a thorough code-review and verified that there exists no code that is capable of modifying battery status information.

This data would confirm our point of view that we are seeing nothing more than the normal course of battery degradation over time. The transparency provided in this new Windows 7 feature produced a notice that previously was not available to customers and did so shortly after upgrade. This is the root cause of the urgency with which we’ve seen postings, but does not change the reality of the condition of the battery. We have no confirmed cases of new machines with the as-purchased batteries.

As we always say with regards to any reports on the quality of Windows 7, we are going to continue to be diligent and use all the tools at our disposal to get to the bottom of a report that has the potential to require a code change we would distribute to customers. We are as certain as we can be that we have addressed the root cause and concerns of this report, but we will continue to monitor the situation. In particular, we will continue to have focused communication with our OEM partners as they monitor their customers and PCs over time.

Finally, if you believe you are receiving this error and your battery is new or believed to be in great shape we would encourage you to report this to us or your original PC maker. You are welcome to send me mail through the contact form on this page, use the TechNet forum, the Microsoft Answers forum, or visit support.microsoft.com where you can get additional information about how to contact Microsoft assisted support in your region.

Thanks,

Steven

What we do with a bug report?

This has been a busy couple of days for a few of us on the team as we had a report of a bug in Windows 7. The specifics of the issue are probably not as important as a discussion over how we will manage these types of situations down the road and so it seems like a good time to provide some context and illustrate our process, using this recent example.

This week a report on a blog described a crashing issue in Windows 7. The steps to reproduce the crash were pretty easy (1) run chkdsk /r on a non-system drive then crash after consuming system memory. Because it was easy to “reproduce”, the reports of this issue spread quickly. Subsequent posts and the comments across the posts indicated that the issue seemed to have been reproduced by others—that is the two characteristics of the report were seen (a) consumption of lots of memory and (b) crashing.

Pretty quickly, I started getting a lot of mail personally on the report. Like many of you, the first thing I did was try it out. And as you might imagine I did not reproduce both issues, though I did see the memory usage. I tried it on another machine and saw the same behavior. In both cases the machine functioned normally during and after the chkdsk. As I frequently do, I answered most of the mail I receive and started asking people for steps to reproduce the crash and to share system dump files. The memory usage did not worry me quite as much as the crash. I began having a number of interesting mail threads, but we didn’t have any leads on a repro case nor did we have a crash dump to work with.

Of course I was not the first Microsoft person to see this. The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). We cast the net further and continued looking for crash dumps and reports. As described below we have quite a few tools at our disposal.

While we continued to investigate, the mail I was getting was escalating in tone and more importantly one of the people I responded to mentioned our email exchange in a blog post. So in my effort to have a normal email dialog I ended up in the thick of the discussion. As I have done quite routinely during the development of Windows 7, I added a comment on the original blog (and the blog where this particular email friend was commenting) outlining the steps we are taking and the information we knew to date. Interestingly (though not unfortunately) just posting the comment drew even more attention to the issue being raised. I personally love being a member of the broader community and enjoy being a casual contributor even when it seems to cause a bit of a stir.

It is worth just describing the internal process that goes on when we receive a report of a crashing issue. Years ago we had one of two reactions. Either we would just throw up our arms and surrender as we had no hope of finding the bug, or we would drop everything and start putting people on airplanes with terminal debuggers in the hopes of finding a reproducible case. Neither of these is particularly effective and the latter, while very heroic sounding, does not yield results commensurate with effort. Most importantly while there might be a crash, we had no idea if that was the only instance or if lots more people were seeing or would see the crash. We were working without any data to inform our decisions.

With the internet and telemetry built into our products (not just Windows 7) we now have a much clearer view of the overall health of the software. So when we first hear a report of a crash we check to see if we’re seeing the crash happen on the millions of machines that are out there. This helps us in aggregate, but of course does not help us if a crash is one specific configuration. However, a crash that is one specific configuration will still show up if there is any statistically relevant sampling of machines and given the size of the user base this is almost certain to be the case. We’re able to, for example, query the call stacks of all crashes reported to see if a particular program is on the stack.

We have a number of tools at our disposal if we are seeing a crash in telemetry. You might have even seen these at work if you crash. We can increase (with consent) the amount of data asked for. We can put up a knowledge base article as a response to a crash (and you are notified in the Windows 7 Action Center). We can even say “hey call us”. As crazy as that one might sound, sometimes that is what can help. If a crashing issue in an already shipping product suddenly appears then something changed—a new hardware device, new device driver, or other software likely caused the crash to appear far more frequently. Often a simple confirmation of what changed helps us to diagnose the issue. I remember one of the first times we saw this was when one day unexpectedly Word started crashing for people. We hadn’t changed anything. It turned out a new version of a popular add-in released and the crash was happening in the add-in, but of course end-users only saw Word crashing. We quickly put up instructions to remove the add-in while in parallel working with the ISV to push out a fix. This ability to see the changing landscape, diagnose, and respond to a problem has radically changed how we think of issues in the product.

We are constantly investigating both new and frequently occurring issues (including crashes, hangs, device not found, setup failures, potential security issues, and so on). In fact we probably look into on the order of hundreds of issues in any given month as we work with our enterprise and OEM customers (and therefore hardware partners, ISVs, etc.). Often we find that issues are resolved by code changes outside core Windows code (such as with drivers, firmware, or ISV code). This isn’t about dodging responsibility but helping to fix things at the root cause. And we also make many code changes in Windows, which are seen as monthly updates, hotfixes, and then service pack rollups. The vast majority of things we fix are not applicable broadly and hence not released with immediate urgency—if something is ever broadly applicable we will make the call to release it broadly. It is very important for everyone to understand how seriously we take the responsibility of making sure there are no critical issues impacting a broad set of customers, while also balancing the volume of changes we push out broadly.

To be specific about the investigation around the chkdsk utility, let’s look at how we dove into this over the past couple of days. We first looked through our crash telemetry (both at the user level and “blue screen” level) and found no reported crashes of chkdsk. We of course look through our existing reports of issues that came up during the development of Windows 7, but we didn’t see anything at all there. We queried the call stacks of existing reported crashes (of all kinds, since this was reported) and we did not find any crashes with chkdsk.exe running while crashing. We then began automated test runs on a broad set of machines—these ran overnight and continued for 2 days. We also saw reports related to a specific hardware configuration, so we set up over 40 machines based on variants of that chipset, driver, and firmware and ran those tests. We were not hitting any crashes (as mentioned, the memory usage was already understood). Because some were saying the machines were non-responsive we also looked for that in manual tests and didn’t see anything. We also broadened this to request globally to Microsoft folks to try things out (we have quite a few unique configs when you think of all of our offices around the world) and so we had several hundred more test runs going. We also had reports of the crash happening when running without a pagefile—that could be the case, but that would not be an issue with this utility as any program that requests more memory than physically available would cause things to tip over and this configuration is not recommended for general purpose use (and this appears to be the common thread on the small number of non-reproducible crashes). Folks interested might read Mark’s blog on the topic of pagefiles in general. While we did not identify anything of note, that does not rule out the possibility of a problem but at this point the chances of any broad issue are extremely small. 

In the meantime, we continue to look through external blogs, forums and other reports of crashes to see if we can identify any reproducible cases of this. While we don’t contact everyone, we do contact people if the forum and report indicate this has a good chance of yield. In all fairness, it probably doesn’t help us when there’s a lot of “smoke” while we’re trying to find the fire. We had a lot of “showstopper” comments piling on but not a lot of additional data including a lack of a reproducible case or a crash dump.

This type of work will continue until we have satisfied ourselves that we have systematically ruled out a crash or defined the circumstances where a crash can happen. Because this is a hardware/software related issue we will also invite input from various IHVs on the topic. In this case, because it is disk related we can’t rule out the possibility that in fact the disk was either failing or about to fail and the excessive use of the disk during a /r repair would in fact generate a failure. And while the code is designed to handle these failures (as you can imagine) there is the possibility that the specific failure is itself not handled well. In fact, in our lab (running tests continuously for a few days) we had one failure in this regard and the crash was in the firmware of the controller for the disk. Obviously we’ll continue to investigate this particular issue.

I did want folks to know just how seriously we take these issues. Sometimes blogs and comments get very excited. When I see something like “showstopper” it gets my attention, but it also doesn’t help us to have a constructive and rational investigation. Large software projects are by nature extremely complex. They often have issues that are dependent on the environment and configuration. And as we know, often as deterministic as software is supposed to be sometimes issues don’t reproduce. We have a pretty clear process on how we investigate reports and we focus on making sure Windows remains healthy even in the face of a changing landscape. With this post, I wanted to offer a view into some specifics but also into the general issue of sounding alarms.

It is always cool to find a bug in software. Whether it is an ATM, movie ticket machine, or Windows we all feel a certain sense of pride in identifying something that doesn’t work like we think it should. Windows is a product of a lot of people, not just those of us at Microsoft. When something isn’t as it should be we work with a broad set of partners to make sure we can effectively work through the issue. I hope folks recognize how serious we take this responsibility as we all know we’re going to keep looking at issues and we will have issues in the future that will require us to change the code to maintain the level of quality we know everyone expects of Windows.

–Steven

Windows 7 Battery Notification Messages

Over the past week we have seen a little bit of blogosphere activity regarding Windows 7 and batteries, specifically the new Windows 7 message “Considering replacing your battery”. Since this is related to the engineering of Windows 7 we’re going to use this blog to provide an update to people. As we have talked about many times, we have a relentless focus on the quality of Windows 7 and we take seriously any reports we receive that indicate a potential problem that could result in a significant failure of the OS. In a previous post we talked about the steps we take when we receive a bug report, in particular when we start to see several reports that appear to be the same. For the past week or so we have been diligently working through these steps and more to see if there is anything in Windows 7 we need to address regarding this issue. At this time we have no reason to believe there is any issue related to Windows 7 in this context.

Several press articles this past week have drawn attention to blog and forum postings by users claiming Windows 7 is warning them to “consider replacing your battery” in systems which appeared to be operating satisfactorily before upgrading to Windows 7.  These articles described posts in the support forums indicating that Windows 7 is not just warning users of failing batteries – as we designed Windows 7 to do this – but also implying Windows 7 is falsely reporting this situation or even worse, causing these batteries to fail.  To the very best of the collective ecosystem knowledge, Windows 7 is correctly warning batteries that are in fact failing and Windows 7 is neither incorrectly reporting on battery status nor in any way whatsoever causing batteries to reach this state. In every case we have been able to identify the battery being reported on was in fact in need of recommended replacement.

Using all the tools at our disposal including contacting customers reporting this issue on forums, customer service communications, partnerships with our PC makers, and of course the telemetry in Windows 7, we have been monitoring reports and discussions regarding this new feature, trying to separate reports of the designed behavior from those that might indicate an issue with Windows 7.  In the latter cases we are trying to understand the scope of applicability and obtain hardware on which to reproduce a faulty behavior.   To date all such steps indicate that we do have customers seeing reports of battery health issues and in all cases we have investigated Windows 7 has simply accurately detected a failing battery.   Before I go into our status on this particular issue, we should review the details behind this new feature.

One of the most obvious components of PC battery life (the runtime you get on battery power) is the battery itself. PC batteries inherently degrade in their ability to hold a charge and provide power (as is the case for all rechargeable batteries). The cause of this is complex and includes irreversible changes in battery chemistry, and increased internal resistance among other things and those in turn are dependent on the design and manufacturing of the battery. This degradation translates into less battery life for the user over the life of the battery in the PC.  Ultimately, batteries must be replaced to restore an acceptable battery life.  A quick check of mainstream laptops will show that batteries usually have a warranty of 12 months, which is about the length of time when statistically we expect to see noticeable degradation (meaning that you start to notice the need to charge more frequently). Those of us that have owned the same laptop (or mobile phone, or music player, or anything else with rechargeable batteries) for a couple of years and taken it through regular charge cycles have no doubt “felt” the decline in battery life though we might have attributed to any number of factors since we did not have any information available to us otherwise.

Windows 7 makes use of a feature of modern laptop batteries which have circuitry and  firmware that can report to Windows the overall health of the battery. This is reported in absolute terms as Watt-hours (W-hr) power capacity. Windows 7 then does a simple calculation to determine a percentage of degradation from the original design capacity. In Windows 7 we set a threshold of 60% degradation (that is the battery is performing at 40% of its designed capacity) and in reading this Windows 7 reports the status to you.  At this point, for example, a battery that originally delivered 5 hours of charge now delivers, on average, approximately 2 hours of charge.  The Windows 7 the notification is a battery meter icon and notification with a message “Consider replacing your battery”.  This notification is new to Windows 7 and not available in Windows Vista or Windows XP.

PC batteries expose information about battery capacity and health through the system firmware (or BIOS).  There is a detailed specification for the firmware interface (ACPI), but at the most basic level, the hardware platform and firmware provide a number of read-only fields that describe the battery and its status.  The firmware provides information on the battery including manufacturer, serial number, design capacity and last full charge capacity.  The last two pieces of information—design capacity and last full charge capacity—are the information Windows 7 uses to determine how much the battery has naturally degraded.   This information is read-only and there is no way for Windows 7 or any other OS to write, set or configure battery status information.  In fact all of the battery actions of charging and discharging are completely controlled by the battery hardware.  Windows only reports the battery information it reads from the system firmware. Some reports erroneously claimed Windows was modifying this information, which is definitely not possible.

As mentioned, every single indication we have regarding the reports we’ve seen are simply Windows 7 reporting the state of the battery using this new feature and we’re simply seeing batteries that are not performing above the designated threshold. Below we’ll talk about the data we have to support this point of view. It should stand to reason that some customers would be surprised to see this warning after upgrading a PC that was previously operating fine. Essentially the battery was degrading but it was not evident to the customer until Windows 7 made this information available. We recognize that this has the appearance of Windows 7 “causing” the change in performance, but in reality all Windows 7 did was report what was already the case.

The following data points contributed to our understanding of the reports we are seeing. Please keep in mind that all the telemetry we see is opt-in, anonymous, and respects our privacy policy.

• We have seen no reproducible reports of this notification on new hardware or newly purchased PCs. While we’ve seen the reports of new PCs receiving this notification, in all cases we have established that the battery was in a degraded state.


• Our OEM partners have utilized their telemetry (call center, support forums, etc.) and have let us know that they are seeing no activity beyond what they expect. It is worth noting that PC manufacturers work through battery issues with customers and have a clear view of what is to be expected both in general and with respect to specific models, timelines, and batteries.


• We’ve gone through all the major online support and self-help forums and when appropriate have worked to follow up with any reports of this notification being presented in error. Through this we have identified no reproducible cases where the battery or PC was new and have only learned of batteries that were degraded in capacity.


• In our telemetry from RTM code customers, only a very small percentage of users are receiving the “Consider replacing your battery” notification, and as expected, we are seeing systems older than ~1.5 years.  We’re seeing relatively fewer notifications compared to pre-release software as the average age of the system decreases.


• Microsoft has received 12 customer service incidents in addition to pulling 8 additional incidents from various forums. To date (for a total of 20 incidents), none of these have shown anything other than degraded batteries. 


• Microsoft has been using the technet community moderators to assist in further contacting customers reporting on this notification and we’ve assigned additional customer service personnel to be ready. However, of the 30 or so contacts we have received we have not learned of any new facts or conditions with respect to this notice.


• During pre-release testing of Windows 7 we saw almost precisely this same experience with customers in terms of the display of the notification. In fact, in looking at the hardware distribution of pre-release testing we saw an ever so slightly higher number of systems receiving this notice. This follows from the fact that a large set of customers are buying Windows 7 with new PCs or using the upgrade provided with a recent Windows Vista PC.


• When looking at the telemetry reports for the machines that have reported displaying this notification we have seen nothing in additional reliability data that indicates any other system anomalies.


• While the information regarding battery status is provided read-only to the operating system through ACPI, we performed a thorough code-review and verified that there exists no code that is capable of modifying battery status information.

This data would confirm our point of view that we are seeing nothing more than the normal course of battery degradation over time. The transparency provided in this new Windows 7 feature produced a notice that previously was not available to customers and did so shortly after upgrade. This is the root cause of the urgency with which we’ve seen postings, but does not change the reality of the condition of the battery. We have no confirmed cases of new machines with the as-purchased batteries.

As we always say with regards to any reports on the quality of Windows 7, we are going to continue to be diligent and use all the tools at our disposal to get to the bottom of a report that has the potential to require a code change we would distribute to customers. We are as certain as we can be that we have addressed the root cause and concerns of this report, but we will continue to monitor the situation. In particular, we will continue to have focused communication with our OEM partners as they monitor their customers and PCs over time.

Finally, if you believe you are receiving this error and your battery is new or believed to be in great shape we would encourage you to report this to us or your original PC maker. You are welcome to send me mail through the contact form on this page, use the TechNet forum, the Microsoft Answers forum, or visit support.microsoft.com where you can get additional information about how to contact Microsoft assisted support in your region.

Thanks,

Steven

What we do with a bug report?

This has been a busy couple of days for a few of us on the team as we had a report of a bug in Windows 7. The specifics of the issue are probably not as important as a discussion over how we will manage these types of situations down the road and so it seems like a good time to provide some context and illustrate our process, using this recent example.

This week a report on a blog described a crashing issue in Windows 7. The steps to reproduce the crash were pretty easy (1) run chkdsk /r on a non-system drive then crash after consuming system memory. Because it was easy to “reproduce”, the reports of this issue spread quickly. Subsequent posts and the comments across the posts indicated that the issue seemed to have been reproduced by others—that is the two characteristics of the report were seen (a) consumption of lots of memory and (b) crashing.

Pretty quickly, I started getting a lot of mail personally on the report. Like many of you, the first thing I did was try it out. And as you might imagine I did not reproduce both issues, though I did see the memory usage. I tried it on another machine and saw the same behavior. In both cases the machine functioned normally during and after the chkdsk. As I frequently do, I answered most of the mail I receive and started asking people for steps to reproduce the crash and to share system dump files. The memory usage did not worry me quite as much as the crash. I began having a number of interesting mail threads, but we didn’t have any leads on a repro case nor did we have a crash dump to work with.

Of course I was not the first Microsoft person to see this. The file system team immediately began to look into the issue. They too were unable to reproduce the crash and from their perspective the memory usage was by design and was a specific Windows 7 change for this scenario (the /r flag grabs an exclusive lock and repairs a disk and so our assumption is you’d really like the disk to be fixed before you do more stuff on the machine, an assumption validated by several subsequent third party blog posts on this topic). We cast the net further and continued looking for crash dumps and reports. As described below we have quite a few tools at our disposal.

While we continued to investigate, the mail I was getting was escalating in tone and more importantly one of the people I responded to mentioned our email exchange in a blog post. So in my effort to have a normal email dialog I ended up in the thick of the discussion. As I have done quite routinely during the development of Windows 7, I added a comment on the original blog (and the blog where this particular email friend was commenting) outlining the steps we are taking and the information we knew to date. Interestingly (though not unfortunately) just posting the comment drew even more attention to the issue being raised. I personally love being a member of the broader community and enjoy being a casual contributor even when it seems to cause a bit of a stir.

It is worth just describing the internal process that goes on when we receive a report of a crashing issue. Years ago we had one of two reactions. Either we would just throw up our arms and surrender as we had no hope of finding the bug, or we would drop everything and start putting people on airplanes with terminal debuggers in the hopes of finding a reproducible case. Neither of these is particularly effective and the latter, while very heroic sounding, does not yield results commensurate with effort. Most importantly while there might be a crash, we had no idea if that was the only instance or if lots more people were seeing or would see the crash. We were working without any data to inform our decisions.

With the internet and telemetry built into our products (not just Windows 7) we now have a much clearer view of the overall health of the software. So when we first hear a report of a crash we check to see if we’re seeing the crash happen on the millions of machines that are out there. This helps us in aggregate, but of course does not help us if a crash is one specific configuration. However, a crash that is one specific configuration will still show up if there is any statistically relevant sampling of machines and given the size of the user base this is almost certain to be the case. We’re able to, for example, query the call stacks of all crashes reported to see if a particular program is on the stack.

We have a number of tools at our disposal if we are seeing a crash in telemetry. You might have even seen these at work if you crash. We can increase (with consent) the amount of data asked for. We can put up a knowledge base article as a response to a crash (and you are notified in the Windows 7 Action Center). We can even say “hey call us”. As crazy as that one might sound, sometimes that is what can help. If a crashing issue in an already shipping product suddenly appears then something changed—a new hardware device, new device driver, or other software likely caused the crash to appear far more frequently. Often a simple confirmation of what changed helps us to diagnose the issue. I remember one of the first times we saw this was when one day unexpectedly Word started crashing for people. We hadn’t changed anything. It turned out a new version of a popular add-in released and the crash was happening in the add-in, but of course end-users only saw Word crashing. We quickly put up instructions to remove the add-in while in parallel working with the ISV to push out a fix. This ability to see the changing landscape, diagnose, and respond to a problem has radically changed how we think of issues in the product.

We are constantly investigating both new and frequently occurring issues (including crashes, hangs, device not found, setup failures, potential security issues, and so on). In fact we probably look into on the order of hundreds of issues in any given month as we work with our enterprise and OEM customers (and therefore hardware partners, ISVs, etc.). Often we find that issues are resolved by code changes outside core Windows code (such as with drivers, firmware, or ISV code). This isn’t about dodging responsibility but helping to fix things at the root cause. And we also make many code changes in Windows, which are seen as monthly updates, hotfixes, and then service pack rollups. The vast majority of things we fix are not applicable broadly and hence not released with immediate urgency—if something is ever broadly applicable we will make the call to release it broadly. It is very important for everyone to understand how seriously we take the responsibility of making sure there are no critical issues impacting a broad set of customers, while also balancing the volume of changes we push out broadly.

To be specific about the investigation around the chkdsk utility, let’s look at how we dove into this over the past couple of days. We first looked through our crash telemetry (both at the user level and “blue screen” level) and found no reported crashes of chkdsk. We of course look through our existing reports of issues that came up during the development of Windows 7, but we didn’t see anything at all there. We queried the call stacks of existing reported crashes (of all kinds, since this was reported) and we did not find any crashes with chkdsk.exe running while crashing. We then began automated test runs on a broad set of machines—these ran overnight and continued for 2 days. We also saw reports related to a specific hardware configuration, so we set up over 40 machines based on variants of that chipset, driver, and firmware and ran those tests. We were not hitting any crashes (as mentioned, the memory usage was already understood). Because some were saying the machines were non-responsive we also looked for that in manual tests and didn’t see anything. We also broadened this to request globally to Microsoft folks to try things out (we have quite a few unique configs when you think of all of our offices around the world) and so we had several hundred more test runs going. We also had reports of the crash happening when running without a pagefile—that could be the case, but that would not be an issue with this utility as any program that requests more memory than physically available would cause things to tip over and this configuration is not recommended for general purpose use (and this appears to be the common thread on the small number of non-reproducible crashes). Folks interested might read Mark’s blog on the topic of pagefiles in general. While we did not identify anything of note, that does not rule out the possibility of a problem but at this point the chances of any broad issue are extremely small. 

In the meantime, we continue to look through external blogs, forums and other reports of crashes to see if we can identify any reproducible cases of this. While we don’t contact everyone, we do contact people if the forum and report indicate this has a good chance of yield. In all fairness, it probably doesn’t help us when there’s a lot of “smoke” while we’re trying to find the fire. We had a lot of “showstopper” comments piling on but not a lot of additional data including a lack of a reproducible case or a crash dump.

This type of work will continue until we have satisfied ourselves that we have systematically ruled out a crash or defined the circumstances where a crash can happen. Because this is a hardware/software related issue we will also invite input from various IHVs on the topic. In this case, because it is disk related we can’t rule out the possibility that in fact the disk was either failing or about to fail and the excessive use of the disk during a /r repair would in fact generate a failure. And while the code is designed to handle these failures (as you can imagine) there is the possibility that the specific failure is itself not handled well. In fact, in our lab (running tests continuously for a few days) we had one failure in this regard and the crash was in the firmware of the controller for the disk. Obviously we’ll continue to investigate this particular issue.

I did want folks to know just how seriously we take these issues. Sometimes blogs and comments get very excited. When I see something like “showstopper” it gets my attention, but it also doesn’t help us to have a constructive and rational investigation. Large software projects are by nature extremely complex. They often have issues that are dependent on the environment and configuration. And as we know, often as deterministic as software is supposed to be sometimes issues don’t reproduce. We have a pretty clear process on how we investigate reports and we focus on making sure Windows remains healthy even in the face of a changing landscape. With this post, I wanted to offer a view into some specifics but also into the general issue of sounding alarms.

It is always cool to find a bug in software. Whether it is an ATM, movie ticket machine, or Windows we all feel a certain sense of pride in identifying something that doesn’t work like we think it should. Windows is a product of a lot of people, not just those of us at Microsoft. When something isn’t as it should be we work with a broad set of partners to make sure we can effectively work through the issue. I hope folks recognize how serious we take this responsibility as we all know we’re going to keep looking at issues and we will have issues in the future that will require us to change the code to maintain the level of quality we know everyone expects of Windows.

–Steven

Our Next Engineering Milestone: RTM

Today marks an important milestone in the Windows 7 project. The Windows 7 team is proud to share with you that a short while ago we have started to release Windows 7 to PC OEM and manufacturing partners. This means our next major milestone will be the availability of PCs loaded with Windows 7 and store shelves stocked with Windows 7 on October 22, 2009.

This is a milestone we could not have achieved without the broad participation across the PC Ecosystem we have talked so much about on this blog. Windows 7 is a product not just of Microsoft, but of a whole industry of partners of all kinds. Throughout the development of Windows 7 we’ve seen an incredible engagement from so many people that have contributed to making the Windows 7 engineering project one we, collectively, feel good about. The feedback and collaboration throughout the development of Windows 7 has been outstanding and valuable beyond measure. This work has created the kind of experience so many of you have talked about in this blog—the ability to use a broad range of PC hardware and peripherals with a great setup and out of box experience. On behalf of the Windows team and all of the successful installations and device connections, please let me extend an incredible “thank you” to all of our hardware partners who have done such excellent work.

Windows 7 has also been one of the most broadly and deeply tested releases of software we have ever had. Starting with a pre-beta in October of 2008 with a few thousand developers using Windows 7 at the earliest stages, through the Beta, and then the Release Candidate in May when we have had millions of people successfully running the product (and many on multiple PCs). As we have discussed in this forum, the ongoing depth usage of Windows 7 along with the breadth and variety of hardware and software configurations has provided (and will continue to provide) the key tools to make sure we continue to deliver ever-improving Operating System quality.

In developing Windows 7 we also set out to have a great dialog with you, perhaps our strongest critics and our biggest supporters. We know you expect a lot from Windows 7 and you demand a lot from the team that builds your OS. This blog has helped to bring significant issues and important decisions to light and we have debated them—here and elsewhere. Along the way we have definitely learned a lot about working together and also about many specific issues that are important to you. We have worked hard to find the right balance across many diverse points of view and we hope you share our feeling that we’ve done a good job at being open, honest, and transparent in how we have approached engineering Windows 7. The conversations we had on this blog have been a memorable part of developing Windows 7 and in our hallways, in Redmond and around the world, we’ve spent collectively thousands of hours discussing and acting on the feedback you have provided here.

While we have reached our RTM Milestone, no software project is ever really “done”. We will continue to monitor and act on the real world experience with Windows 7—we’ve used the Beta and RC process to test out our servicing and we have every intent of doing a great job on this important aspect of the product. Hardware partners will continue to provide new devices and improve support for existing devices. PC makers no doubt have quite a bit in store for all of us as they begin to show off PCs specifically designed for Windows 7’s new APIs and features. Software developers will have lots of new software to show off as well. All of this is yet to come and is very exciting.

Software projects on the scale of Windows are pretty rare and our team has a lot of pride, and as we have said so many times, is humbled by the responsibility. We are going to continue to learn and continue to improve how we engineer our products, with the aim of being the very best engineers we can be and delivering the very best OS for the world’s varied customers. Being an engineer is about learning and that learning comes from the experience gained in designing and delivering each release. Together we’ve learned and together we’ve engineered a wonderful product.

We know there are lots of questions about how to get Windows 7 and when, and of course more questions to come about exploring and using the full set of Windows 7 features. Our Windows Team Blog today has posted a lot of new information and gathered up some important details that we hope will answer your questions. Please check our blog and stay in touch on the in-market developments of Windows 7 there.

The final few minutes before RTM are a sign-off process where each and every team that contributed to Windows formally commits to having successfully executed the work necessary for the product to be in the release process. We gather one last time (for Windows 7) in the “Ship Room” and a representative from each team signs (literally) and signifies their team’s readiness for manufacturing. We thought we’d share this moment with you here today.

On behalf of the Windows 7 engineering team we want to thank you very much for your contributions throughout development and your contributions yet to come to Windows 7. THANK YOU!

Next stop, October 22, 2009!

–The Windows 7 team

Engineering Windows 7 for a Global Market

Microsoft has been a global software company for a long time and has always put a lot of effort into engineering our products for a global customer base.  It is also an area where the engineering is complex—probably a lot more complex than many might think—and one where we are always trying to learn and improve.  Building global software is a responsibility for everyone on the team.  We also have feature teams dedicated to developing both global and market specific features—whether it is font handling or doing East Asian language input as two examples.  We of course have a significant engineering effort that goes into localizing (“translating” is not quite accurate) Windows into nearly 100 languages. Julie Bennett represents the global development and localization teams and she and John McConnell on her team collaborated across the team to author this post that provides an overview of engineering for a global market. –Steven

Many of the readers of the e7 blog are located outside of the United States or speak a language other than English, so we thought it would be useful to share the international and multi-lingual improvements in Windows 7. Our goal for Windows 7 is to deliver exciting features that benefit users worldwide as well as features that make Windows feel local to every user. Like Windows 7’s focus to improve the fundamental scenarios of performance and reliability, we improved our processes to allow us to deliver a great customer experience in every language and every country we serve, including delivery of Windows 7 as close to simultaneously as possible worldwide. This blog entry discusses some of the new features and improved processes that we believe make Windows 7 a great worldwide release.

Features

The international features of Windows 7 are pervasive across the system, from such low-level aspects as the supported characters in NTFS file names (now upgraded to match Unicode 5.1) to such high-level aspects as the selection of backgrounds and themes (now including locally-relevant photos). But there are certain features which are intrinsically critical for proper support of the world’s many languages and cultures, and we will describe some of those here.

Fonts

Language and writing are at the heart of any culture and thus support for fonts is essential to supporting international users. Windows 7 significantly increases both the range and quality of fonts. We have added fifty new fonts:

 

As you might guess from the font names in the above table, many of the new fonts are for non-Latin scripts. In fact, Windows 7 will be the first version of Windows to ship with more fonts for non-Latin scripts than for Latin-based scripts. One major area of improvement is for the languages of India. To the nine (9) fonts for Indian languages that shipped in Vista, Windows 7 adds forty (40) more. Windows 7 will now include multiple fonts (often in multiple weights) for each of the official languages of India.

Aparajita: A New Devanagari Font in Regular, Bold, Italic and Bold-Italic

 

 

Besides new fonts, we have also improved many of the existing fonts. For example, we have added over two thousand (2,000) glyphs to Consolas, Calibri, Cambria Bold, and Cambria Math. But the most dramatic improvements have been to some of the non-Latin scripts. For example, Windows 7 does a much better job rendering the common Lam-Alef ligature in Arabic (see the illustration below) and in the placement of vowel marks.

Left: Lam-Alef Ligture in Vista Right: Lam-Alef Ligature in Windows 7

Changes to fonts (even clear improvements) are always tricky because of backwards compatibility issues. For example, if a character changes width or position, it may cause existing documents to reflow (repaginate), which is unacceptable. Therefore, whenever we change a font, we must run extensive verification tests against the changes to ensure the font metrics and other tables are unchanged. In the case of the Lam-Alef fix shown above, we discovered that there were existing applications that relied on the (undocumented) order of the glyphs within the old font. These applications would break if we simply replaced the glyphs. The font team worked closely with the international application compatibility team to ensure that changes we made did not affect the order of glyphs within the font, thus providing backward compatibility.

Font Control Panel

With so many new and expanded fonts for Windows 7, we also wanted to help users manage their fonts more easily. For the first time in years, we have done a complete overhaul of the font control panel.

The first picture below shows the font control panel with the large icon view. The most obvious change is that the font icons now convey much more information about the appearance of the font. The content of the icon gives a hint as to the glyph repertoire of the font. The style of the icon matches the style of the font. Non-Latin fonts show typical glyphs from the script for the font to see how it is designed. A more subtle change is that some font icons are faded to indicate fonts that are installed, but hidden. Hidden fonts will not show by default in the ribbon and font dialogs. Users can now use the font control panel to tune the fonts that they regularly use. By hiding fonts they never use, users can simplify choosing the correct font within applications. By default, only fonts supporting languages that can be written with the users installed input locales (keyboard layout plus language) will be shown. For example, users with English and French input locales will see only the Latin fonts, whereas users with the Japanese input method installed will see only the Japanese fonts. Users can override these defaults by right-clicking on any of the fonts in the control panel. Hidden fonts are still installed so an existing application that uses a hidden font will behave identically.

Font Control Panel with Large Icon View

The next picture below shows the font control panel with the detailed view. Now users can see much more information about the font. For example, the user can sort fonts by style, whether they are hidden, and information about the creator of the font. Font files generally contain information only in the design language of the font (e.g. a Japanese font might contain only information in Japanese). In Windows 7, we needed a solution that would work for all languages and for all fonts, so we created a hybrid approach that combines information from the font itself with metadata (an XML file that provides the information about the fonts on the system).

 

Font Control Panel with Detail View

Local Packs

Windows 7 has increased opportunities for personalization. New themes, backgrounds, and sounds make it easy to customize Windows 7 to match your personality. To the extent that our preferences are influenced by our language and location, Windows 7 reflects this with the introduction of Local Packs. Local Packs provide customized Windows 7 visual themes for a specific region. These visual themes contain locally relevant wallpaper images, custom aero glass colors, and regional sound schemes. Windows® Internet Explorer® Favorites and RSS feeds may also be updated when the Local Pack is activated on an end user’s computer. For example, adding and enabling the Local Pack for France will add a market-customized theme for France to the end user’s Personalization control panel and a number of links to useful French Public Sector websites and RSS Feeds to the user’s profile.

Customized Themes in the Personalization control panel

The Local Pack content provides users with seamless local experiences right out of the box. Users are never exposed to Local Packs per se, they just select their Location as normal during Windows Welcome, and appropriate local content is exposed to them based on that setting.

Users looking for visual themes for other countries, or indeed any other areas of interest, can find them on the Windows Online Gallery, which is accessible via the “Get more themes online” link in the Personalization control panel.

Other Features

Other new features include five (5) new locales (bringing the total number of locales supported to two hundred and ten (210)), twelve (12) new input locales, and improvements to sorting for traditional Chinese characters. Also, we have generally updated our system databases to the latest version of the Unicode Standard (5.1). There are also interface improvements that should allow developers to create better globalized applications. Extended Linguistic Services (ELS) is a cool new feature we describe below in the International Timeliness and Quality section.

Perhaps one of the most important improvements outside the core international features has been in Search, which now recognizes more languages. For example, Windows 7 desktop search now recognizes Russian morphology (the rules for single and plural, tenses, and case). This means that searches for a particular word in Russian will now match not only that exact word, but also the common variations of the word, yielding significantly better results.

International Timeliness and Quality

In previous versions of Windows, final delivery of every language to every market took several months. For Windows 7, we changed how we worked on international releases to significantly shorten this delta so that all users worldwide can enjoy Windows as simultaneously as possible. This goal had far reaching implications on how we perform our work as engineers and on how we interact with partners and customers during our public testing phases.

To understand our approach, we should first explain two important concepts: localization and globalization.

Localization is the process of adapting the user experience into another language. Beyond the translation of strings, it can also include activities such as resizing dialogs and mirroring icons for right-to-left languages, such as Hebrew and Arabic. Localization bugs, such as the mistranslation of a menu item, are defects introduced during this process.

Globalization, on the other hand, is the process of producing a product that works well in every country no matter the user interface language setting. A globalization bug may be as simple as showing a UI element in the wrong language and as complex as not properly handling right-to-left scripts. Globalization bugs are inherently more serious than localization bugs as they usually affect many or all languages and often require re-thinking the technical design. In past Windows releases, repairing globalization bugs contributed to the necessity of the long release deltas. For Windows 7 we worked to prevent, find, and fix globalization bugs as early in the development process as possible.

Pseudo-Localization

To prevent common globalization bugs, pseudo-localized builds were created. Pseudo-localization is a process that creates a localized product in an artificial language. That language is identical to English except that each character is written with a different character that visually resembles the English character. Except for being entirely machine generated, we create the pseudo-localized builds exactly the same way as we create the localized builds. Because even monolingual US software developers can read pseudo-localized text, it has proven to be an excellent way to find globalization problems early in the development cycle. In the Windows 7 beta, some UI elements were still in their pseudo-localized form, causing some interesting theories about what the meaning might be. We hope we have solved the mystery with this blog post.

 

Control Panel Dialog in Pseudo-localized Windows 7

Pilot Languages

Beta is always an exciting time for us as it is our first real chance to hear from you about our efforts. We are thrilled that people from over one hundred and thirteen (113) countries downloaded the Windows 7 Beta. With such a large and diverse beta program, we must have highly scalable processes to gather and incorporate your feedback. In Windows 7, we are very excited about some new approaches we took here.

In the past, localization languages for Windows beta releases were selected for a mix of pragmatic reasons. While this ad hoc approach had benefits, too often we found that serious globalization defects were not reported because they did not manifest in the chosen languages. For the Windows 7 Beta, our priority was to find globalization bugs and therefore we have concentrated on four languages (plus English) that experience has shown are most likely to find specific types of defects:

• German - Because it contains some very long words, German can reveal dialog size and alignment defects better than other languages.


• Japanese - With tens of thousands of characters, multiple non-Latin scripts, alternative input method engines, and an especially complex orthography, Japanese is a great way to find defects that affect many East Asian languages.


• Arabic - Written right-to-left and with contextual shaping (character shape depends on adjacent characters), including this language in the Beta helped us test code paths not exercised by German and Japanese.


• Hindi - Windows 95 and Windows 98 never supported Hindi and support for this language relies entirely on Unicode. Testing Hindi helps find legacy (non-Unicode) defects that affect all such languages.

By concentrating on these four languages during Beta, we maximized our chances to find and fix the globalization bugs that affect many languages. This in turn gave us more time to improve the localization of all languages before we release the actual product. The pictures below show two bugs found during Beta that illustrate the advantages of focusing on these pilot languages.

Globalization Defects Found During Windows 7 Beta

In addition to our goal of finding globalization bugs via these languages, we also asked some of our OEM customers to provide feedback on the language aspects within their manufacturing processes. Since many of the OEMs are located in East Asia, we also localized Windows 7 Beta for Simplified Chinese, Traditional Chinese, and Korean.

RC Language Packs

In part because of the engineering process improvements described above, we were able to deliver more language packs for Windows 7 RC than we have ever been able to do in the past for Windows. For those of you running the Ultimate version of Windows 7 RC, you will have noticed the following thirty-two (32) Language Packs available for download on Windows Update:

32 Windows 7 RC Language Packs on Windows Update

One thing we will do differently in the future is to ensure that all languages available at Beta are also available at RC (e.g. not including Hindi for Windows 7 RC). We will correct this for future versions.

Understanding feedback from around the world

With Windows 7 beta localized into five languages and globally enabled for hundreds more, we received beta bugs from customers all over the world. We rely on these bug reports to help us improve Windows 7, so we devote much time to reading customer bug reports to determine product issues. Because bugs come from worldwide customers in many languages, we look for ways not only to understand their feedback, but also to address it as quickly as possible. The faster we can understand the issue, the better chance we have of addressing the feedback. As we receive bug reports in all the many languages that our customers speak, this has sometimes posed quite a challenge.

In the past, we have handled multilingual bug reports using manual processes, where individual bugs were examined and then manually translated one-by-one for appropriate follow-up by the feature team that owned the affected component. This is a time-consuming and error-prone exercise that scales poorly to a program as large and diverse as the Windows 7 beta. In the worst case, valuable international feedback has missed the window to affect the final product, and thus slipped to a Service Pack or subsequent release.

In Windows 7, by using the language detection API in the new Extended Linguistic Services (ELS), we have been able to automatically detect the language of customer bugs as they are reported. ELS functionality is new for Windows 7 and available to any developer who wants to leverage advanced linguistic functionality in the operating system. Beginning in Windows 7, developers may use ELS to provide language and script detection of any Unicode text, as well as transliteration to map text between writing systems. To use these Windows 7 services and all further services that we will add in subsequent releases, developers need only to learn one simple and unified interface. The ability to detect over one hundred (100) languages is available for all Windows 7 application developers, and we are happy to be able to apply this functionality to triage and handle beta feedback you send us from around the world. We use our own international developer functionality to improve our ability to respond to customer issues globally.

Once we have detected the language, we take the resulting text and use the machine translation support that is available online from Live Translator. This allows us to translate the text to English to get a sense of your feedback. Our engineers can then search our feedback database for specific features or areas of functionality. This also helps us in our efforts to ensure international application compatibility, as we can learn about potentially problematic international application experiences as soon as customers report them. Machine translation does not provide a perfect translation, but it does allow us to determine which issues might require further investigation. This in turn allows us to hear and respond to customer issues with a much faster turnaround time than we have had in previous releases, which means better quality in Windows 7 when we release it to the world.

By the end of Windows 7 Beta, we had used this process to translate 35,408 issues and comments submitted using the Feedback tool.

Putting it all together

The end result of the work to improve globalization and localization quality is reflected in the announcement that all fully localized releases of Windows 7 will be available within two weeks of the initial release wave with all languages available in October. We hope (and believe!) end users will find the overall quality of these releases to be the best ever.

36 Windows 7 language releases available in October 2009

In addition to the 36 languages that will be released in October, there will be additional languages available for download as Language Interface Packs (LIPs) onto any Windows 7 edition as part of the Local Language Program (LLP). The LLP is a partnership with governments, universities, and language experts from around the world. (You can find more information on the LLP at http://www.microsoft.com/unlimitedpotential/programs/llp.mspx.) Work on a LIP starts at RTM and continues for many months based on the schedules of our partners. Two (2) LIPs will be available for download when Windows 7 is available in October – Catalan and Hindi. Additional LIPs will become available for download over the following months based on the schedules of our partners. We are happy to have improved the delivery time of the first 38 languages (36 + 2 LIPs) and recognize that future releases are an opportunity to improve further. Creating a track record of dependable release schedules on our part will help everyone around the world plan better for a more unified release timeline.

More information about Extended Linguistic Services (ELS) and other cool new features of Windows 7 are available on-line on MSDN. In particular, you can download the Windows SDK for Windows 7 and read about what is new in the ‘International’ section. Also, the new Go Global Developer Center on MSDN has a wealth of information about international technologies.

If you want to send us feedback, please comment on this blog entry or use the Feedback button in Windows 7. We love to hear from you (in any language).

– Windows International Team

Engineering Changes to ClearType in Windows 7

One of the many passions held by Bill Gates is a passion for reading and so his desire to make reading on PCs a fantastic experience has been an effort ongoing for many years. In the 1998 COMDEX show, Bill Gates unveiled ClearType – hard to believe it was that long ago. Back when it was announced, very few of us had LCD monitors and those that did invested several thousand dollars in one that was 15” and 1024×768 (today one like that costs less than $100). The notions of smoothing and anti-aliasing have been around for many years and are common in the world of typography, animation, and games. ClearType took this to new levels by building on the properties of LCD panels. ClearType was subsequently included in Windows XP and continues in Vista and Windows 7—each release saw changes in the underlying technology, the fonts that support the technology, and the APIs available to developers. It is fair to say that over the years we have learned that there are a set of customers who simply find ClearType rendered screens less than appealing and wish to turn it off. We recognize this and want to make sure we provide the appropriate controls. ClearType is also part of the Windows platform and provides APIs callable and controllable by developers of applications. There is a conventional view that ClearType is a "visual preference" and through this post we want to show how there are elements that are such a preference but there are also elements that are APIs used by applications, just like applications can choose fonts, colors, and other attributes as required.  This post goes into the details of Windows 7’s implementation along with some history and background. Greg Hitchcock is the development lead on ClearType and has worked on it since the start. He’s also one of the most tenured members of the Windows 7 engineering team with only 6 folks having been at Microsoft longer — Larry is one of them !

–Steven

Based on feedback, we want to clarify how font rendering works in Windows 7 and give some background on how we chose ClearType font rendering to be the default in Windows. For those that dislike ClearType and want to change the system default setting to bi-level rendering, as were defaults in Windows Millennium, the quick answer is:

• Enter Appearance into the start menu search
• Select Adjust the appearance and performance of Windows from the Control Panel
• The setting that should be changed under the custom option is: Smooth edges of screen fonts, which should be turned off

The longer answer, as we will describe in this post, shows that changing the default setting is not as “black and white” as it may seem. As you have noticed, Windows 7 also includes a new ClearType tuner in the control panel which affords fine-grained control over rendering—we’ll talk about that some below as well.

ClearType

ClearType is a technology developed to improve both the appearance of font rendering and reading performance on computer displays. As most people spend over 80% of their time on computers reading on the screen, improvements in this area greatly improve the overall experience of Windows. The ClearType technology has continued to evolve and the latest improvements have been made in Windows 7, as discussed in this earlier E7 post.

In simple terms, ClearType works by using the underlying geometry of colored sub-pixels in the display as if they were full pixels—gaining extra resolution while at the same time using principles of human vision to remove the perception of color artifacts. Further details on the technology and how it uses human visual perception are described here. More specifically, the ClearType technology is optimized for LCD panels with red, green, and blue (RGB) striped sub-pixels that are oriented vertically, although it performs reasonably well on CRT displays (especially those that are aperture grille based) and even LCD panels with horizontally oriented RGB stripes. Although this might seem counterintuitive, through informal studies, we’ve found that about 70% of users prefer ClearType even on these non-optimal displays. Of the 30% who preferred other rendering techniques, their biggest concern with ClearType in these non-optimal cases was the loss of text contrast.

Other Types of Font Rendering in Windows

Given the complex world of many display types and a wide variety of users and their visual systems, how did we go about implementing ClearType into Microsoft Windows? Microsoft did not rush headlong into making ClearType the default rendering. The technology was first released in 2000 with the Windows CE product. The Windows CE environment is usually quite controlled in terms of the hardware used, so it was quite easy to verify that ClearType worked properly on each device, and either tune ClearType or adjust the hardware to optimize the onscreen reading experience. The first release of ClearType on the Windows platform was with Windows XP in 2001.

Bi-Level Rendering

Example of Bi-Level rendering.  Note if your browser scales this image the text will not be correctly represented.

Prior to Windows XP, two types of font rendering were supported in Windows. The first type of font rendering supported was bi-level rendering, more commonly referred to as “black and white” rendering, but sometimes also called aliased text. With bi-level rendering, two colors represent the font, the foreground color and the background color. This was the first type of rendering supported by TrueType when Windows 3.1 was released, and also the essential method of displaying fonts in bitmap form from Windows 1.0. Bi-level rendering, especially when generated from outline technologies like TrueType, is very difficult to optimize for low screen resolutions. Significant effort needs to be put into the font hinting for TrueType in order to get the best bi-level quality. It can reasonably take a skilled person 6 months to a year per font of hinting time to get this level of rendering detail. That would be multiplied by four for a four-member family. If the character sets are larger, as in some system fonts, it can take even longer.

Font Smoothing / Grayscale

 

The second form of rendering, known as font smoothing, became the default rendering in Windows 2000 and was first released as an option for Windows 95 in the Plus! Pack. Font smoothing is a hybrid grayscale anti-aliasing technique designed to improve the contrast of fonts over traditional anti-aliasing techniques. There are two factors that differentiate font smoothing from more traditional text anti-aliasing.

First, traditional anti-aliasing works by overscaling the font outline data and then downsampling. Font smoothing uses the same technique, except that it applies font hints prior to overscaling the outline data. Although we don’t have enough space here to fully describe font hinting, I can simplify it enough to say that it often uses a method called “grid fitting” to snap the vertical and horizontal edges of the font outlines so that they are aligned with the pixel grid. In this situation, most horizontal and vertical stems of a font, when overscaled, cover 100% of the underlying pixels, and when downsampled return the text foreground color, which is usually black. Diagonal and round features of the font will not have full coverage of the pixel and thus will return some shade of gray, reflecting the coverage of the underlying pixel. It should be noted that when text displays the “jaggies” (or more formally aliasing) this usually occurs on round or diagonal parts of the glyphs—exactly the areas receiving gray coverage with this method. This way of anti-aliasing is beneficial due to the higher contrast of the stems in the font at a slight cost of some spatial accuracy.

The second differentiating factor is that the fonts determine the exact size that the font smoothing turns on or off. Most fonts that provide this level of information turn on grayscale anti-aliasing below 9 pixels per em (PPEM.) That is the equivalent of 7 points on a 96 PPI screen. Above 9 PPEM, anti-aliasing is turned off until the main stems of the font are around two pixels wide, which is around 13 to 20 points, depending on the typeface. Once the main stems are two pixels wide, anti-aliasing remains on as the sizes increase. Two pixel wide stems are usually chosen because there is usually enough “backbone” of foreground colored pixels to keep the stem contrast high.  If the font does not have specific sizes for font smoothing, system defaults are used. There are independent defaults for both regular and bold typefaces. So although font smoothing was the default, most fonts, when displaying text at typical reading sizes, would render them bi-level.

Defaults for Font Rendering

With the addition of ClearType to Windows XP, there were now three types of font rendering available (Bi-level, Font Smoothing, ClearType). During the time period that Windows XP was being developed there was a clear transition underway from desktop systems with CRT monitors to laptops and desktops with LCD displays. Since this transition was far from complete, we felt that the default value for font rendering in Windows XP should be grayscale font smoothing, the same as Windows 2000. OEM’s who provide Windows XP on their systems could change this default, and in fact, by the time Windows XP SP 2 shipped, many of them had set the default to ClearType. It should be noted that OEMs can always change these settings as part of configuring a PC.

In Windows Vista, the system’s default font rendering was changed to ClearType. It is important to clearly understand what is meant by default font rendering. In Windows, the default font rendering is the rendering used when the application does not choose an explicit type of rendering. Some have confused this default value to mean that all applications must use this value. This view is inconsistent with the way text APIs worked when introduced in Windows 95’s font smoothing. In GDI, the API for choosing the current font has the rendering type explicitly as input. It is expected that there are situations where the application knows best what type of rendering should be used. For example, in displaying a print preview page with small text, traditional font smoothing might be the best choice for rendering. Likewise, if an application was targeting on-screen reading, it might be best to use ClearType as the rendering for that application. In some situations, like remote terminal services, the application might choose to use bi-level rendering to reduce the bandwidth of text information that needs to be sent to a remote client.

There are many examples where applications decide one way or another to use rendering other than the system default—just as applications that choose to use different fonts, colors, sizes, or other text attributes.  The most typical example is in applications that wish to have reproducible layout and flow of documents.  By being specific about which way to render text, the applications can be certain of how text will flow across different PCs.  Another common example, as mentioned above, is Print Preview where the ability to properly render representations of higher resolution output, particularly for small text sizes, is much improved.  We recognize that for some it is counter-intuitive that an aspect viewed as a “display” property is something that applications can choose to “over-ride”.  We’ve designed rendering so that the default case is to respect the setting, but applications, including Windows itself, might have elements that require explicit rendering techniques.

Although each application can make the choice on a per-font basis of which rendering to use, the majority of applications choose the default rendering. Therefore, making the decision to change the default for Windows Vista was not taken lightly. The trends in the hardware displays were strongly showing a rapid movement from CRTs to LCD-based displays as we have shown in earlier blog posts based on the Windows XP and Windows Vista real-world telemetry. Even though there were still CRTs in use, feedback from Windows XP customers was positive on the quality of ClearType rendering on CRTs. After we made the choice, the feedback on the decision to enable ClearType as the default for Windows Vista was overwhelmingly positive.

Even with the default rendering set to ClearType, there are some scenarios that can change the default. If an OEM is providing Windows on their hardware, they can change the default. In some situations, and this was more common with font smoothing in Windows 95, the hardware may not meet the minimum requirements for the rendering technology. In the case of both font smoothing and ClearType, a minimum of sixteen bits per pixel display resolution is required. (When rendering to an off-screen bitmap in GDI, it is important that it not be the default color depth of 1 bit per pixel if you desire to capture ClearType text.) In some cases, when optimizing for system performance, font smoothing (both ClearType and grayscale) can be disabled. In a similar fashion, using Remote Desktop to connect to another computer or session usually disables ClearType by default.

Changing the Default Rendering in Windows 7

Windows 7 maintains the same defaults as Windows Vista. There are several ways for the user to change the default values for font rendering in Windows 7. For those that want the default rendering to be bi-level, the user interface for this selection is in the performance section of the Control Panel. From the root of the control panel you can access it by selecting System and Security –> System –> Advanced System Settings –> Performance (Settings…). An easier way is to enter “Appearance” into the start menu search, and then select “Adjust the appearance and performance of Windows.” The setting that should be changed under the custom option is: Smooth edges of screen fonts, as shown in the figure.

The option of no font smoothing as the default value is considered to be an uncommon setting, so it is a little more difficult to find than other settings. If the user prefers to change the default font rendering selection to the Windows grayscaling anti-aliasing technique described earlier, in Windows 7 that is now done through the ClearType Tuner.

ClearType Tuner

The quality of the ClearType text can be optimized for you and your monitor. The ClearType Tuner is a new control panel component for Windows 7. Because there are differences in monitor characteristics and differences between readers’ eyes, there are font rendering options that can only be optimized by a reader looking at text on their monitor. The ClearType Tuner uses various samples of ClearType, presented in the form of an eye-test, to make fine grained adjustments to the ClearType algorithms. Each wizard page tunes a parameter such as monitor gamma (relationship between voltage and brightness), your sensitivity to color artifacts, and your preference for letter heaviness.

In order to switch between ClearType and grayscale, the setting “Turn on ClearType” on the opening page of the ClearType Tuner can be toggled.

Either way, the user is taken through the rest of the ClearType Tuning wizard for two reasons; if an application explicitly enables ClearType rendering, it is useful for that experience to be tuned, and some graphics platforms have more fine tuning of the rendering for both gray rendering and ClearType.

 

Font Design and Font Rendering

The availability of higher resolution font rendering techniques like ClearType has had a significant impact on the design of fonts for onscreen reading. From the early days of the printing press, as new technologies and printing styles were developed, typefaces were redesigned to take advantage of those technologies. For example, many typefaces still in use today incorporate “ink traps” into the design so that ink would not clog up key features of a glyph. This is an aspect of making specific design choices in the font in order to work the best with the technology. In traditional typeface design, the term font refers to a typeface at a given size. So a 10 point Times New Roman would be a different font from a 24 point Times New Roman. In the days of metal cast typography, each of these sizes were designed by a punch cutter to be optimized for the medium for which they were to be used, often with changes in stem contrast, x-height, or character spacing for a given size. The advent of photo typesetting in the mid-twentieth century was a step backwards in this regard, as it used one size as a type master, and then used optics to scale that master size to any other presentation size.

Microsoft Windows has taken the more traditional approach to digital outline fonts, and through a combination of font hinting and new typeface design we attempt to optimize each size for the medium for which they were intended. With Microsoft’s initial release of TrueType for Windows 3.1, the traditional typefaces Times New Roman, Arial, and Courier New were used as core fonts. In the creation of these fonts, one master size was chosen for the outline data, usually something around 10 or 12 point, and, similar to the technique used in photo-typesetting, the outlines could be scaled to any requested size for a given display resolution. But, going back to the more traditional ways, each size was carefully examined and changes were made to the basic design through font hinting—including changes to critical features like stem contrast, x-height, or glyph spacing. As earlier mentioned, hinting fonts to be tuned for a low-resolution medium like full pixels on a 96 PPI screen was very time consuming. To help in this process for Microsoft Windows, we commissioned or designed in-house new outline typefaces designs that were optimized for the world of 96 PPI bi-level rendering. These custom fonts include Tahoma, Verdana, Georgia, Trebuchet MS, and even Comic Sans MS. These fonts still needed to be hinted to tune the individual sizes, but because the typeface was designed with the medium in mind, it was a more straightforward process and less time consuming.

Even with typefaces tuned to the display medium, 96 PPI pixels on a screen are still larger than many of the features we’d like to show in a typeface—and that is where ClearType helps us. Therefore, with ClearType, it made sense to commission a new set of fonts that were optimized for this new medium. Now the existing fonts for Windows still work well with the technology, but this project was an attempt to get the very best design for onscreen reading using ClearType. This led to a new set of fonts that shipped and were tuned for Windows Vista. The ClearType Collection fonts of Calibri, Cambria, Consolas, Corbel, Candara, Constantia, the new user interface font Segoe UI, and the Japanese font Meiryo were designed for this medium. As part of the engineering work on these font projects along with the default setting of ClearType, we decided in the hinting process to do the fine, size-specific hinting only for ClearType, and not for bi-level rendering. This allowed us to focus our efforts on the fine levels of detail and quality for the vast majority of customers.

ClearType Fonts in Windows 7

A reasonable question for us to ask ourselves is what is the experience like in Windows 7 when bi-level or hybrid font smoothing is chosen as the default?

As mentioned earlier, not all applications will choose to render with the default settings. Microsoft Office and Internet Explorer will default in some cases to using ClearType rendering. Some applications that use fonts tuned for ClearType and not bi-level rendering may choose ClearType rendering to maintain the benefits of the font designs. Some applications need higher precision glyph widths like sub-pixel positioning or “natural width ClearType,” and would reflow if they were changed to bi-level or grayscale rendering. Other applications like Adobe Reader have their own built-in text rendering engine that is independent of the Windows graphics platforms. Likewise, platforms like Java on Windows also use their own rendering techniques.

In some situations with the Windows 7 Explorer, ClearType rendering will remain on so that Segoe UI will keep its optimal design. Changing the system font from Segoe UI to some other font could be problematic, leading to issues like reflowing dialog box entries, missing text due to wrapping, unlabeled buttons, etc. We know many would value global changes to the fonts used by Windows, but to maintain to reliably across resolutions, DPI, and languages to name a few issues means we cannot have total flexibility on the system font settings at this time.

Given the challenges of turning off ClearType, there are a few mitigations in the fonts to handle some scenarios where ClearType is not available. In the ClearType font Calibri, since it is the default font for Microsoft Office, an unusual technique was used to attempt to improve the quality of the font rendering when font smoothing grayscale was selected. In this case, as opposed to the normal situation where font smoothing was disabled at lower text sizes to remove the blur, at these lower sizes the font enabled grayscale in order to improve the character shape. Also, at a few key sizes, the Calibri font had some bitmap fonts embedded in the outline file. These bitmaps kick in when bi-level rendering is requested. These bitmaps were intended to handle the case where Calibri was being used in a Remote Terminal situation and the default for Remote Terminal was not set to ClearType for performance reasons.

ClearType Research on Performance

As mentioned earlier, one of the goals behind ClearType is to improve the performance of reading text on computer screens. We have supported several areas of research looking into measuring this work. The research is done at universities and published in peer-reviewed journals. We have another Microsoft blog, that among other things related to fonts, also describes some of the research work on reading performance. Since those blog entries give more detail and background, we’ll just describe some of the performance highlights.

• We’ve measured an improvement in word recognition accuracy of 17% using ClearType over bi-level rendering. 
• We’ve found a 5% speed improvement in reading speed and a 2% improvement in comprehension (this is remarkable) using ClearType over bi-level rendering. A 5% reading speed improvement may sound small, but the cumulative effects can be huge given the amount of time people spend reading.
• We’ve found the reading speed improvements of 5% continue over longer spans of text, and we’ve found that non-traditional reading tasks like document scanning are about 8% faster with ClearType over bi-level rendering.
• We’ve found that reading sub-optimal text causes eye fatigue by increasing squinting and decreasing the blink rate. (This may seem obvious, but prior to this work there was no understanding of the physiological mechanisms of eye fatigue.)

ClearType Research on Rendering Preferences

Another research question we’ve asked ourselves is why do some people prefer bi-level rendering over ClearType? Is it due to hardware issues or is there some other attribute that we don’t understand about visual systems that is playing a role. This is an issue that has piqued our curiosity for some time. Our first attempt at looking further into this involved doing an informal and small-scale preference study in a community center near Microsoft. This was done with two identical laptops, one with ClearType and one with bi-level rendering. They were placed side by side and participants were asked which version they preferred. This was done with three different samples. Here were the results:

Comments:

1. 35 participants.
2. Comments for bi-level rendering:
   Washed out; jiggly; sketchy; if this were a printer, I’d say it needed a new cartridge; fading out – esp. the numbers, I have to squint to read this, is it my glasses or it is me?; I can’t focus on this; broken up; have to strain to read; jointed.
3. Comments for ClearType:
   More defined, Looks bold (several times), looks darker, clearer (4 times), looks like it’s a better computer screen (user suggested he’d pay $500 more for the better screen on a $2000 laptop), sort of more blue, solid, much easier to read (3 times), clean, crisp, I like it, shows up better, and my favorite: from an elderly woman who was rather put out that the question wasn’t harder: this seems so obvious (said with a sneer.)

Two other additional preference tests were performed with 28 of 30 participants preferring ClearType to bi-level rendering in one study and another with 52 of 55 participants preferring ClearType. Combining these three tests, we get 113 of 120 participants preferring ClearType rendering over bi-level rendering. It is important to note that in a forced preference test like this, just because someone preferred ClearType, it does not mean that they also don’t like bi-level rendering. It is just a preference towards ClearType.

Further examination of those who prefer bi-level rendering is of great interest to us and we continue to research this topic and to work with university researchers as well. We expect to see published papers on this topic in the future.

Future Research

Going forward, much of our research is in finding ways to make the highest quality text rendering more accessible to everyone. Each visual system has its own characteristics, and just as the ClearType tuner allows us to tune the algorithm for display characteristics, it would also be nice to tune for visual system characteristics. For example, in the United States 7% of the male population is color blind. We believe that we can improve the ClearType algorithm so that text for a colorblind reader is even better than for a reader without colorblindedness. Researching ways to improve text rendering for those with high color sensitivity and lower visual acuity would be just as important for us.

Conclusion

Making the screen the best possible place to read is an exciting opportunity for us.  It blends the engineering challenges of working with many display technologies and human visual systems with the artistic challenge of creating a beautiful set of glyphs, where every subtle typographic nuance is important.  In doing this, we need to keep in mind how the science of reading must guide us in making the experience optimal for us—humans. Each rendering technology has advantages and disadvantages for different people; depending on the application in use there are tradeoffs involved. Many of these issues go beyond the ability for people to easily discern choices. Our job is to work hard to provide a great platform for developers as well as tools that people can use to make choices and control how they use their technology. Our goal should be that the out-of-box experience just works. We think that, most of the time, we’ve accomplished this and we also recognize this area is complex and there is a wide spectrum of feedback.

The team at Microsoft working on these problems has been together since 1990, developing fonts and font-rendering solutions, and working to get a better understanding of the science of reading. The team is made up of engineers, type designers/artists, and psychologists and we work with many other experts throughout Microsoft in attempting to tackle this tough, yet vitally important task. You spend over 80% of the time at the computer reading, so it should be as pleasant an experience as possible. The following article from IEEE Spectrum describes some of the issues we deal with related to the technology, art, and science of text.

–Greg

Improving Audio Glitch Resilience in Windows 7

Delivering excellent audio playback on a PC is one of those “much harder than it looks” technical challenges.  Unlike dedicated audio / video devices, PCs have a lot going on during playback of audio and the playback happens on an incredible array of hardware and software.  Many of you might be familiar with “glitches” that occasionally happen.  In this post, Kristin Carr, a program manager on our Devices and Media team, describes some of the engineering in Windows 7 to improve this area representing the work of a number of folks across the team.  One lesson I learned early in the product cycle is that we don’t say “glitch-free” but rather “glitch-resilient” and hopefully that will make sense as you read this.  –Steven

Have you ever used your PC to play an MP3 or a DVD? If you answered yes, you’re among the overwhelming majority of PC customers who use their computer for audio and video applications, encompassing everything from watching a movie to playing a game to viewing a YouTube clip. But you may have also had an experience where your audio or video wasn’t quite perfect – perhaps the video was a bit choppy or the audio stuttered. We call this a ‘glitch’ – a perceived discontinuity in your audio or video that interrupts the playback experience. In this blog post, we’ll be focusing on audio glitching: we’ll examine the ecosystem challenges that can cause glitches, and we’ll discuss the work we’ve been doing to improve the Windows 7 experience.

 

What Causes Glitching?

In previous posts, we’ve touched on a variety of ecosystem initiatives and challenges that we’ve undertaken for Windows 7, including application compatibility, accessibility, and system performance, among others. Tracing the root cause of audio glitching leads us to a similar place: because Windows runs on a huge variety of hardware configurations and multitasks between dozens of applications, it is challenging to ensure that all of the programs and drivers running on your computer will work together in exactly the way you expect.

Audio is especially sensitive. In order for you to hear music from your speakers, data needs to be delivered to your audio hardware approximately every 10 milliseconds, or 30 times in the blink of an eye! The challenge is that your PC is usually doing a lot of other things at the same time you’re listening to music, such as streaming that YouTube video or downloading that new song, and many of these other tasks have complex timing requirements as well. As you can imagine, it doesn’t take much – a slow network driver or a graphics driver that requires plenty of CPU time – to prevent your audio from reaching your ears in a continuous fashion.

So what are we doing to address this challenge? The answer is ‘lots!’ – and the remainder of this blog post will be devoted to discussing these things:

1. Gathering data in order to characterize the problem


2. Developing a systematic method to detect and analyze glitches


3. Getting these tests and tools widely deployed, both at Microsoft and by our Windows partners


4. Engaging with partners to detect, diagnose and fix glitching issues

Who Experiences Glitching?

In studying this during the Windows 7 development cycle, our first order of business was to gather data. We‘d heard reports of audio glitching, but we didn’t know the exact scope of the problem. How often do users hear their audio glitching? Are there certain machines that were worse than others? With these questions in mind, we set out to understand our problem space a bit better.

We gathered data by using the telemetry infrastructure built into Windows, which allows our users to report back to Microsoft with performance data and other statistics that help us improve the OS. For each machine that opted to contribute data to Microsoft, we measured the number of times that the underlying audio hardware was being starved for data (i.e., when the user might hear a glitch). This data was grouped into “sessions,” each of which represents the data collected on a single machine for a single day or the data collected between machine reboots, whichever is shorter.

Let’s dive into some of the results. First, let’s look at the overall rate of audio glitching:

Figure 1: Distribution of Glitch Counts per Session

The chart above shows data from external (non-Microsoft) RC users. Approximately 80% of sessions showed no glitching at all, but 4.3% showed 10 or more glitches, which indicates that audio glitching affects a significant number of users.

Once we figured out how often glitching occurs, we started looking into why it occurs. First, we broke the data down by laptop/desktop form factor:

Figure 2: Glitching Likelihood by Form Factor

From this data, we noticed that laptops were almost twice as likely to experience audio glitching. As a result, we’ve made sure to address and target mobile PCs as well as mobile scenarios (for example, playing music while running on battery) for better coverage in our glitching tests and diagnostic tools.

Next, we looked at glitching likelihood by PC manufacturer:

Figure 3: Glitching Likelihood by PC Manufacturer (Mfr)

This data showed that certain manufacturers were more likely to be susceptible to audio glitching than others. As a result, we made sure to spread our testing efforts across a wide spectrum of machines and manufacturers. In addition, we are using this data to work with manufacturers to see if we can identify components or specific causes that would result in higher glitch incidents.

Finally, we looked at glitching on a wide variety of PC models:

Figure 4: Breakdown of All Glitch Sessions by PC Model

In the chart above, we examined all of the sessions that had at least one glitch, and we looked for any correlation with the PC make and model as shown in the table above (actual machine names have been anonymized). The first thing to notice is that Machine A is responsible for more than three times as much audio glitching as any of the other machines on the list. This data confirmed earlier reports of audio glitching on this particular machine, which we traced to a graphics card that shipped in a faulty configuration. As a result, we were able to work with the manufacturer to improve the configuration.

This chart also helps to show how widespread the issue is. There were hundreds of PC models that showed evidence of glitching – in fact, it seemed difficult to find a single PC model for which audio glitching did not ever occur. On the other hand, most individual machines didn’t show any problems at all. The conclusion that we drew was that audio glitching was not caused by any one hardware configuration, but was dependent on all the different hardware and driver permutations a user could possibly encounter on their machine. It was clear that no machine was immune, and in order to improve the experience, we were going to need a far-reaching, system-wide solution to this problem.

Developing Tools to Diagnose Glitching

Once we had data on when and why glitching occurs, the Windows Devices & Media Performance team developed a comprehensive suite of tests that were centered around media playback scenarios and were designed to assess how well a PC performed at that scenario. During media playback, these tests recorded thousands of statistics about the system’s performance, including CPU load, the activity of all components on the system and their corresponding interactions, and whether glitching occurred, among other things. We intentionally covered a huge range of scenarios and configurations, including laptops running on battery power, hardware under stress, hundreds of media content types, and many more. The goal was to exercise each PC in a wide variety of user scenarios in order to uncover and isolate audio glitches.

In addition, the Devices & Media Performance team created a graphical tool to highlight glitches as well as the CPU activities that occurred before and during an audio glitch, which allows us to quickly diagnose any glitching problems that we uncover. For example, in the figure shown below, we can see a visual representation of when glitches occurred, and we can display related measurements that occurred at the time of the glitching in order to easily pinpoint any suspicious behavior.

Figure 5: Example Graphical View of Audio Glitch Troubleshooting

In this case, you can see four audio glitches (shown by red vertical lines in the top panel). Two panels down, we have displayed calls to the CPU that took longer than 3ms (called long ISRs/DPCs). In this example, you can see a direct correlation between audio glitches and long ISRs and DPCs, which are procedure calls executed by the operating system that have the potential to hog the CPU and produce audio glitches. From here, we can track down the components responsible for these calls in order to reduce or eliminate the glitching. This figure shows additional information than what we used to diagnose the particular problem discussed above; however, this information and the many other measurements are available to diagnose other glitches and media performance issues from across a wide range of sources.

Putting the Tools to Work

Armed with these tests and tools, our next step was to deploy them on as many systems as possible. As part of this effort, we are participating in a Windows-wide initiative to help OEMs test their PCs at or before ship time. Hundreds of OEM machines get shipped to Microsoft for use in our Windows lab where we run thousands of tests in order to validate and ensure the best user experience. What this means is that if we notice that a particular machine or configuration might be susceptible to glitching, we can work with the OEM to try to fix the problem before the consumer ever sees their new PC.

By running these tests and analyzing the results with our new tools, we’ve been able to find hundreds of potential issues that would result in audio glitches. In some cases, this analysis resulted in changes to the Windows code. In other cases, we have identified components developed by our partners that can lead to audio glitching.

Engaging with Windows Partners

Since the issues we identify with these tools often involve components from many different partners, an important aspect of this work is engaging with these partners. Until now, it has been almost impossible for manufacturers to know how their components will affect the system as a whole, but by making these tests and tools available, we are attempting enable these partners to see how their components interact and what the final impact on users will be.

As part of this effort, we have been working to ensure that our partners can take full advantage of these new tools and tests. We’ve talked with OEMs, ODMs (original design manufacturers, who traditionally assemble the PC for the OEM), hardware manufacturers, and software vendors. We’ve given presentations and tutorials, written whitepapers, and held video conference workshops. Our goal has been to make it as easy as possible to create glitch-resilient software and hardware.

In summary, this effort includes:

1. Sharing audio glitching telemetry data with our partners. Our partners have had very little concrete data on the prevalence of audio glitching. With the data we are now collecting, we can help them to diagnose problems and improve their products.


2. Running our suite of audio and video performance tests on the hundreds of machines that OEMs send us and communicating the results to our partners. By assessing as many systems as possible and providing these results, we begin to tackle the causes of audio glitching.


3. Providing the tools and support that enable our partners to understand how their components are interacting with everything else on a PC and enable them to more easily address the subtle issues that can result in audio glitching.

What’s Next

Ultimately, we and all of our Windows partners share a common customer (you!); by working with our partners, calling attention to these issues, and providing more insight into the root causes of audio glitching, we are continue to improve the audio experience for everyone.

Creating, Saving, Sharing Themes in Windows 7

When we posted the new “inbox” desktop backgrouns, the reactions showed just how personal, personalization can be.  Building on that theme of personalization (pun intended), we wanted to share some of the work we did on themes in Windows 7.  We’ve shared data about customization in previous releases of Windows and this post builds on that.  This is also an area where we know there is very broad spectrum of desires (needs) for personalization and we definitely had to balance the engineering and design efforts.  I’ve received mail from many folks wanting to personalize (tweak) nearly every pixel on the screen—from border width, to title bar transparency percentage, to height of taskbar, to color/size/location of the close button (I’ve received each of these in email more than once).  At the other end are customers who are enormously happy when they can easily change the background picture and color scheme, and many do.  With Windows 7 we picked a group of settings that we believe represent the most satisfying settings to broadly personalize, and would also provide the most robust platform that maintains application compatibility, and made those easy to change.  In addition we wanted to make it easy to package up those settings so you could save and share them.  We think of this as the start of bringing robust personalization (and customization) to a broader set of customers.  Katie Frigon, a program manager on the core user experience team, authored this post. 

–Steven

PS: Things are “slowing” down as we have talked about in how we will get to the RTM milestone.  You might have noticed the announcement we made today in Asia regarding Windows 7 release and availability. Thank you to everyone who has been using the RC and helping to reach the next milestone.

Creating and Sharing Windows 7 Themes

In early builds, you may have noticed that Windows 7 includes a variety of themes that change your desktop background, window color and sounds with a single click. These themes are located in the Personalization Control Panel which is easily accessed from the desktop context menu.

Personalization Control Panel

Desktop Context Menu

In the RC, you can see a number of new themes, for example the “Architecture” theme. This theme is comprised of six architectural photos which cycle on the desktop background, a complementary “Twilight” window color and the “Cityscape” sound scheme which was inspired by the sounds of an urban jazz club.

A theme is a coordinated set of Desktop Backgrounds, Window Colors and Sounds.

Windows provides a set of themes in box and if customers want more there is a prominent link in the Control Panel to get additional themes online. This link takes you to the Windows Online theme gallery where Microsoft provides additional content including a variety of international themes.

Personalization Control Panel: Get more theme online link

Creating a theme

While our customers enjoy the content we’ve provided both in the box and online we also know that they enjoy and desire the option to customize their PC’s even more than choosing a theme. Windows 7 continues to be about your PC reflecting you and what you do, as well as putting you in control of that experience. So, if you do want to go beyond the options in the box and on the web, it is easy to create and share your own themes. Creating your own theme can be as easy as just changing your desktop background image while keeping the rest of the settings the same or you can change all the settings one-by-one.

From our Beta Customer Experience Improvement Program data we see that customers are changing and creating themes. We also see many users changing the different settings, the most popular being desktop background:

Figure 1: Break out of theme type

Note: Only 15% of the beta users kept the default theme. 77% of the beta users created a custom theme by changing one or more elements of the inbox themes.

Figure 2: Percentage of Beta users selecting each theme component in a session

Note: 35% of beta users who opened the Personalization CPL clicked on “Desktop Background”.

Now let’s look at how you can change the different settings and save a custom theme. To start, you can change any of the theme settings by starting in the Personalization Control Panel.

Personalization Control Panel: Click on the items beneath the theme gallery to change your theme settings.

Let’s start with the desktop background control panel. This control panel has been enhanced for Windows 7 to support the pictures library and the new desktop background slideshow capabilities. If you choose the “Pictures Library”, we will show all of the pictures in that library including subfolders. All you need to do is select more than one photo to have them cycle as your desktop background slideshow. In this example, I have selected some of my favorite photos from a recent trip to Hawaii to use as my desktop background.

Desktop Background Control Panel: Windows 7 adds support for libraries and desktop
background slideshows. I’ve selected the pictures I want to use in my theme.

When personalizing your PC, you might want to go further than just changing your background. Changing your window color or sound scheme is simple, just click on the items beneath the themes gallery. We provide 16 window colors to choose from and the ability to pick a custom color as well. New to Windows 7, we include 14 sound schemes with the OS inspired by a variety of regional music traditions, so you have plenty to choose from. If that isn’t enough, you can include your own sounds if you want.

Window Color and Sound Control Panels: It is also easy to change your window color
or pick from 14 diverse sound schemes.

After you change the desktop background, window color or sound scheme, you will notice that we have created a new “unsaved theme” that contains your changes. Your unsaved settings will be preserved when trying other themes in the gallery so you can get back to your most recent customizations. If you are happy with your personalization settings, you can ensure that they are always available in the themes gallery by clicking “Save theme”.

Personalization Control Panel: I clicked “Save Theme” to ensure that my current
personalization settings will always be available in the themes gallery.

Sharing themes

After saving your personalization settings for your own use, you might want to share these settings with friends and family or bring the settings to another PC. Windows 7 allows you to share your themes by right-clicking on your current theme and selecting “Save theme for sharing”. After specifying a name and folder destination for your theme, Windows will collect all of your custom desktop background images, sounds, mouse pointers and icons into the new .themepack file format that can be applied on another computer running Windows 7.

Personalization Control Panel: When I’m ready to share my theme with Friends, Family and on the Web,
I right-click on my current theme and select “Save theme for sharing”.

Sometimes after I take a fun vacation I like to create a theme that reminds me of the trip. To do this I select the best photos from the trip to rotate as my desktop background and then pair those with a matching window color and Windows 7 sound scheme that best matches the mood of the trip. After I save as a new .themepack I can either share this file via Windows Live to friends and family or use it from another PC in my house via Homegroup.

Sharing with Windows Live

Since all of the personalization settings are now contained in a single file, it’s easy to upload the theme to Windows Live Skydrive and post a link to the theme on a Windows Live Spaces blog. Once my friends and family upgrade to Windows 7, they will be able to download themes from trips that we went on together so they can enjoy my photos on their desktop background.

Windows Live: I can also upload my theme to my Windows Live Skydrive
and add a link to the theme on my blog.

Sharing via Homegroup

In Explorer you can create a themes Library. Then from another computer in a Homegroup you just browse to the shared location and click on the desired theme to apply those settings with a single click.

Explorer: I created a themes library on one of my PC’s and shared it with my Homegroup.
From another PC in the home, I can click on any of these themes to apply them.

But wait…there’s more.

One additional way we’ve added value with Windows7 themes is by capitalizing on the growing popularity of RSS photo feeds to share photos. Enthusiasts can create a theme where the desktop background slide show points to an RSS photo feed. For example, my sister lives across the country and we only see each other about once a year. An easy way for me to keep her up to date on my family is to send her a Windows 7 theme which points to my RSS photo feed. When I upload new photos they will appear on her desktop automatically.

Because there are a few different ways to create an RSS photo feed, the process to include an RSS photo feed in a Windows 7 theme will only work if your RSS photo feed links to the high resolution photos using the “enclosures” method. The feed should only reference picture formats such as JPEG or PNG. Due to this limitation themes must be created manually when including an RSS photo feed.

So, to create one of these themes you can follow these steps:

1. Download the template from MSDN.


2. Open the template using Notepad.


3. Replace {themename} with the name you want to appear in the Personalization Control Panel themes gallery.


4. Replace {rssfeedurl} with the full path to your compatible RSS photo feed.


5. Save the changes as a file with the “.theme” extension.

It is ready for you to share! Send the file via email, etc. to your friends and family.

Photo sharing sites can also offer these Windows 7 RSS photo themes which provide more ways to connect their customers.

Looking ahead

Themes in Windows 7 make it possible for you to make the PC reflect you. Beyond my example of sharing personal photos as a theme, we hope that users will find new and creative ways to use themes in Windows 7. Wedding photographers can include Windows 7 themes in the packages they deliver to their clients, Artists can create themes that showcase their creative style and businesses can create themes that promote their brand. We look forward to seeing how you are using themes to Personalize these aspects Windows 7.

–Katie

PS: We’ve posted some additional themes you can download and use on http://windows.microsoft.com/en-US/Windows7/Personalize which is the US English link from the Themes control panel.

Safeguarding Windows 7 – Parental Controls

As you can imagine, our team is quite busy working through this next phase of Windows 7.  We definitely appreciate the millions of downloads and installs of the Windows 7 RC.  Things are going as we expect at this point.  On a personal note, I wanted to thank all the folks who have been sending me mail.  I’ve received a lot of kind words and support regarding the RC and quite a few people saying “hurry up and just release it”.  We outlined the steps we’re taking for this next milestone and aren’t going to rush things.  We’ve got a lot of work for sure!  Not that I’m counting, but I just crossed over 3,000 emails sent via the contact link in this blog.  While I haven’t answered all of them, I’ve done the best I can, and appreciate each and every exchange. 

Windows 7 includes a set of features for safeguarding your PC when used by children.  This post is by Vladimir Rovinsky, a program manager on our Safety Team, who details the features in Windows 7 specifically around Parental Controls.  This work is in addition to the safety of the OS itself and of course the features built into Internet Explorer to provide safety and security while browsing.  You might also want to check out Windows Live Family Safety which is part of Windows Live Essentials (http://download.live.com) which provides even more for safety and parental controls.  –Steven

Today, children are exposed to digital hazards more easily than any time in the past. Especially with the help of powerful search tools, convenient social networking applications, low cost tools and services for publishing videos and photographs, the web is awash with content that’s inappropriate for children, and full of people that parents want to bar from contacting their children.

These digital hazards are accessible to children through a variety of applications, including web browsers, instant messaging applications, media players, games, and email applications. Many of these applications have attempted to offer parental control features. However, they offer this functionality through variety of user interfaces, locations and include varied terminology. The duplication and inconsistency of parental control settings management can make it difficult for parents to maintain the correct settings across multiple applications.

Windows Vista Parental Controls provided a framework to solve these problems by offering:

• A single, central location in the Windows Control Panel to configure and manage parental control settings and activities;


• Built-in restrictions on web content and file downloads, time spent on the computer, application usage, game usage as well as the ability to log and view user activity.


• The Windows Parental Control platform public application programming interfaces (API) which expose in-box restriction settings and logging functionality to any application. For instance, Internet Explorer and Mozilla Firefox 3.0 are using these APIs to determine if file downloads should be blocked for a user.


• Integration with the User Account Control (UAC) to enforce standard user accounts for parentally controlled users; promotion of best practices for keeping kids safer on a Windows computer; for instance, encouraging the creation of separate standard accounts for managed children, password creation for parent accounts (administrators), etc.

To get a quick demo of Windows Vista Parental Controls in action, check out this video.

For more information about developing software for Windows Vista Parental Controls, see Using Parental Controls APIs.

Key Design Decisions for updates to Windows 7 Parental Controls

Responding to customer feedback and evolving nature of the web and challenges it poses to the parents, we strive to provide families with flexible and effective safety features. Our efforts for the Windows 7 release of Parental Controls were focused on the following objectives:

1. Further developing the extensibility of the Parental Controls platform to enable third-party developers to create richer Parental Control capabilities that integrate well with Windows 7 Parental Controls.

The Windows 7 Parental Controls platform was modified to allow multiple independent providers of Parental Controls functionality to be installed on the system and augment or fully replace the parental controls provided by Windows 7. Windows Vista allowed partial replacement of Windows Parental Controls; the web filter was replaceable. In Windows 7, in addition to the web filter components, the entire Windows 7 Parental Controls user interface can be replaced by third-party providers. The underlying enforcement of the offline restrictions will still be performed by Windows Parental Controls platform. Allowing a third party provider to replace the entire Windows Parental Controls user interface creates a consistent user experience that seamlessly combines existing Parental Controls functionality with the new ones introduced by the third-party provider.

The Windows Control Panel Parental Controls screen still remains the central location and launching point on Windows 7 for Parental Controls functionality regardless of whether it is provided by default (system) or by a third-party provider.

2. Removal of web content restrictions and activity viewing functionality from default (system) Parental controls provider and reliance on Windows Live or third-party providers for these capabilities.

The web is changing much faster than we can update the Windows operating system. For example, when Vista was released Social Networking was barely known. Now it has a thriving web presence. We need to keep web focused parental controls up with innovation. Because of this, we have moved them into Windows Live.

Web filtering and activity viewing capabilities can be more efficiently provided by Windows Live or a third-party solution that implement web based delivery of this functionality. For instance, Microsoft’s Windows Live Family Safety free application provides web content filtering, file downloads restrictions, and activity monitoring. It also provides online contact restrictions for children using Windows Live online applications (Windows Live Hotmail, Windows Live Messenger, etc).

You can learn more about Windows Live Family Safety solution here.

More information about Windows 7 changes to the Parental Controls platform can be found here.

Windows 7 Parental Controls User Interface Changes.

Elements new to Windows 7 Parental controls top-level screen can be seen on the following screen shot:

Figure 1 Windows 7 Parental Controls screen

1. The Additional controls section allows users to select a provider for additional controls such as web filtering, activity reporting, online contact management, etc. When a third-party controls provider’s installed on the computer, the screen displays the Select a provider drop down box that shows the currently selected (active) provider. A description of the provider’s functionality, as supplied by the provider, is shown below the drop down.


2. When the user account is selected by clicking user’s name or picture, the provider configuration for the user is launched. The provider can take over the default configuration UI for the in-box offline restrictions.  Optionally, provider generated status strings for user accounts are displayed under user account pictures.


3. An Icon supplied by provider is shown in the upper right corner of the screen.

Additional control providers can still rely on the default’s (system) provider UI for the configuration of in-box offline restrictions. If a provider chooses to do so, the User Controls screen can be presented to configure a user’s Parental Controls settings.

If an additional provider is selected and configured, the following new user interface elements are shown on the Windows 7 User Controls screen:

Figure 2 Windows 7 User Controls screen. Additional controls provider is installed and configured.

1. More Settings allows direct access to the currently selected provider’s functionality.


2. Web Restrictions allows access to the currently selected provider’s functionality.

Windows Parental Controls settings and Vista to Windows 7 upgrade

If a Windows Vista PC which has parentally managed user accounts with enabled web filtering restrictions is upgraded to Windows 7, parents (administrators) are warned during the upgrade as well as when opening the Windows 7 Parental Controls screen, that web filtering and activity reporting functionality is not part of Windows 7 Parental Controls.

 

Figure 3 Windows 7 Parental Controls screen. Some users have web filtering restrictions. No additional provider is installed.

Windows Vista Parental Controls settings (including web filtering and activity logs information) are preserved unchanged when upgrading from Windows Vista to Windows 7. Although web filtering settings and activity logs information are not used by Windows 7 Parental controls, their preservation allows third-party provider to honor these settings.

As you start using Windows 7, we hope these changes to Parental Controls capabilities will make you feel more confident and in control of how your family members are using computers and experiencing the web.

–Vladimir

Next Page »