Microsoft



Windows 10 Compatibility Cookbook: March 23, 2016AbstractThis Cookbook provides info for developers about platform changes to the Windows 10 operating systems (OS). We also provide guidelines for you to verify the compatibility of your existing and planned apps with the latest version of the OS. We assume that you are familiar with previous versions of Windows.The content applies to: Windows 10The Cookbook is for third party developers of apps and devices that are designed to be used in the Microsoft Windows environment. Disclaimer: This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet website references, may change without notice. Some information relates to pre-released product which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. You bear the risk of using it.This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. ? 2016 Microsoft. All rights reserved.Contents TOC \o "1-3" \h \z \u Introduction PAGEREF _Toc446498902 \h 3What is Windows as a Service? PAGEREF _Toc446498903 \h 4Windows 10 release types & cadences PAGEREF _Toc446498904 \h 5Supporting apps in WaaS PAGEREF _Toc446498905 \h 6Key changes since Windows 7 to ensure compatibility PAGEREF _Toc446498906 \h 8Microsoft is using data to make Windows better PAGEREF _Toc446498907 \h 9How we can ensure compatibility of the combined ecosystem PAGEREF _Toc446498908 \h 10Windows version check PAGEREF _Toc446498909 \h 11Undocumented APIs PAGEREF _Toc446498910 \h 14Develop UWP & Centennial apps PAGEREF _Toc446498911 \h 15Modern Desktop App functionality is impacted if not run in Windowed Mode PAGEREF _Toc446498912 \h 16Availability of applicable graphics drivers on Windows Update PAGEREF _Toc446498913 \h 17Graphics driver migration to Windows 10 PAGEREF _Toc446498914 \h 18Bluetooth drivers PAGEREF _Toc446498915 \h 20Optimized test strategies & flighting PAGEREF _Toc446498916 \h 21Step 1: become a Windows Insider & participate in flighting PAGEREF _Toc446498917 \h 22Step 2: test your scenarios PAGEREF _Toc446498918 \h 23Step 3: Provide feedback PAGEREF _Toc446498919 \h 24Step 4: Register for Ready for 10 PAGEREF _Toc446498920 \h 25Summary PAGEREF _Toc446498921 \h 26IntroductionWindows 10 introduces the latest OS technology and software development platforms for use by app and driver developers and enterprises worldwide. To further enhance the security, reliability, performance, and user experience of Windows, Microsoft has introduced many new features, improved existing features, and removed others. While the goal of Windows 10 is to maintain compatibility with apps written for previously released versions of the Windows OS, some compatibility breaks are inevitable due to innovations, tightened security, and increased reliability. Overall, the compatibility of the latest version of the Windows OS with existing apps and devices is high. This document shows you how to verify that your apps and devices are compatible with the latest version of the OS and provides an overview of known app incompatibility issues. We invite you to check out these topics to learn how to optimize your apps and take advantage of what this newest release of Windows has to offer. The Windows Compatibility Cookbook editions that address Windows 8 and Windows Server 2012, as well as Windows 8.1 and Windows Server 2012 R2 are also available for reference. What is Windows as a Service?In today’s environment, where user expectations frequently are set by device-centric experiences, complete product cycles need to be measured in months, not years. Additionally, new releases must be made available on a continual basis, and must be deployable with minimal impact on users. Microsoft designed Windows?10 to meet these requirements by implementing a new approach to innovation, development, and delivery called Windows as a Service (WaaS). The key to enabling significantly shorter product cycles while maintaining high quality levels is an innovative community-centric approach to testing that Microsoft has implemented for Windows?10. The community, known as Windows Insiders, is comprised of millions of users around the world. When Windows Insiders opt in to the community, they test many builds over the course of a product cycle and provide feedback to Microsoft through an iterative methodology called flighting.Builds distributed as flights provide the Windows engineering team with significant data regarding how well builds are performing in actual use. Flighting with Windows Insiders also enables Microsoft to test builds in much more diverse hardware, application, and networking environments than in the past, and to identify issues far more quickly. As a result, Microsoft believes that community-focused flighting will enable both a faster pace of innovation delivery and better public release quality than ever.Windows 10 release types & cadencesAlthough Microsoft releases flight builds to Windows Insiders, Microsoft will publish two types of Windows 10 releases broadly to the public on an ongoing basis: Feature updates install the latest new features, experiences, and capabilities on devices that are already running Windows 10. Because feature updates contain an entire copy of Windows, they are also what customers use to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed. Microsoft expects to publish an average of one to two new feature updates per year.Quality updates deliver security issue resolutions and other important bug fixes. Quality updates will be provided to improve each feature currently in support, on a cadence of one or more times per month. Microsoft will continue publishing quality updates on Update Tuesday (sometimes referred to as Patch Tuesday). Additionally, Microsoft may publish additional quality updates for Windows 10 outside the Update Tuesday process when required to address customer needs. During Windows 10 development, Microsoft streamlined the Windows product engineering and release cycle so that we can deliver the features, experiences, and functionality customers want, more quickly than ever. We also created new ways to deliver and install feature updates and quality updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership. Hence we have implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.The below table describes the various servicing branches and their key attributes.Servicing optionAvailability of new feature updates for installationKey benefitsSupported editionsCurrent Branch (CB)Immediately after first published by MicrosoftMakes new features available to users as soon as possibleHome, Pro, Education, Enterprise, Mobile, IoT Core, Windows?10 IoT Core Pro (IoT Core Pro)Current Branch for Business (CBB)Approximately 4 months after first published by MicrosoftProvides additional time to test new feature updates before deploymentPro, Education, Enterprise, Mobile Enterprise, IoT Core ProLong-Term Servicing Branch (LTSB)Immediately after published by MicrosoftEnables long-term deployment of selected Windows?10 releases in low-change configurationsEnterprise LTSBFor a more detailed description of the Windows as a Service model please read the TechNet article published here.Supporting apps in WaaSThe traditional approach for supporting apps has been to release a new app version in response to a Windows release. This assumes that there are breaking changes in the underlying OS that could potentially cause a regression with the application. This model involves a dedicated development and validation cycle that requires our ISV partners to align with the Windows release cadence. In the WaaS model, Microsoft is making a commitment to maintaining the compatibility of the underlying OS. This means Microsoft will make a concerted effort to ensure that there are no breaking changes that impact the app ecosystem negatively. In this scenario when there is a release of a Windows build, most apps (those with no kernel dependencies) will continue to work.In view of this change, Microsoft recommends that our ISV partners decouple their app release and support from specific Windows builds. Our mutual customers are better served by an application lifecycle approach. This mean when an application version is released it will be supported for a certain period of time (e.g. 3-5 years) irrespective of however many Windows builds are released in the interim. The ISV makes a commitment to provide support for that specific version of the app as long as it is supported in the lifecycle. Microsoft follows a similar lifecycle approach for Windows that can be referenced here. The above approach will reduce the burden of maintaining an app schedule that aligns with Windows releases. ISV partners should be free to release features or updates at their own cadence. We feel that our partners can keep their customer base updated with the latest app updates independent of a Windows release. In addition, our customers do not have to seek an explicit support statement whenever a Windows build is released. Here is an example of a support statement that covers how an app may be supported across different versions of the OS:The application lifecycleContoso is a software development company and is the owner of the popular Mojave app which has a major share in the enterprise space. Contoso releases its next major release Mojave 14.0 and declares mainstream support for a period of three years from the release date. During mainstream support all updates and support are complimentary for the licensed product. Contoso also declares an additional two years of extended support where customers can purchase updates and support for a grace period. Beyond the extended support end date this product version is no longer supported. During the period of mainstream support Contoso will support Mojave 14.0 on all released builds of Windows. Contoso will also release updates to Mojave as necessary and independent of the Windows product releases.In the following sections you will find additional information about the steps Microsoft takes to maintain the compatibility of the underlying OS. You will also find guidance on steps you can take to help maintain the compatibility of the combined OS and app ecosystem. There is a section on how to leverage Windows flighting builds to detect app regressions before a Windows build is released. Lastly, we describe how we use an instrumentation and telemetry-driven approach to increasing the quality of Windows builds. We recommend ISVs adopt a similar approach with their app portfolio.Key changes since Windows 7 to ensure compatibilityWe understand that compatibility matters to developers. ISVs and developers want to ensure their apps will run as expected on all supported versions of the Windows OS. Consumers and businesses have a key investment here—they want to ensure that the apps they have paid for will continue to work. We know that compatibility is the primary criteria for purchase decisions. Apps that are well written based on best practices will lead to much less code churn when a new Windows version is released, and will reduce fragmentation—these apps have a reduced engineering investment to maintain, and a faster time to market.In the Windows 7 timeframe, compatibility was very much a reactive approach. In Windows 8, we started looking at this differently, working within Windows to ensure that compatibility was by design rather than an afterthought. Windows 10 is the most compatible-by-design version of the OS to date. Here are some key ways we accomplished this:App telemetry: this helps us understand app popularity in the Windows ecosystem to inform compatibility testing.ISV partnerships: work directly with external partners to provide them with data and help fix issues that our users experience.Design reviews, upstream detection: partner with feature teams to reduce the number of breaking changes in Windows. Compatibility review is a gate that our feature teams must pass.Tighter control over API changes & improved communicationFlighting and feedback loop: The Windows Insider population receives flighted builds that help improve our ability to find compatibility issues before a final build is released to customers. This feedback process not only exposes bugs, but ensures we are shipping features our users want.Microsoft is using data to make Windows betterWindows uses diagnostic and usage data to identify and troubleshoot problems, improve our products and services, and provide our users with personalized experiences. The usage data we collect also extends to the apps that PCs in the Windows ecosystem are running. Based on what our customers use, we build our list to test these apps, devices, and drivers against new versions of the Windows OS. Windows 10 has been the most compatible version of Windows to-date, with over 90% compatibility against thousands of popular apps (across Windows Phone, Win32 and Windows Store apps). The Windows Compatibility team commonly reaches out to our ISV partners to provide feedback if issues are discovered, so that we can partner together on solutions. Ideally, we’d like our common customers to be able to update Windows seamlessly and without losing functionality in either their OS or the apps they depend on for their productivity or entertainment.How we can ensure compatibility of the combined ecosystemFollowing are some best practices Microsoft recommends so you can ensure your apps are compatible with Windows 10. Windows version checkThe OS version has been incremented with the Windows 10 OS release. This means that the internal version number for Windows 10 has also been changed to 10.0. As in the past, we go to great lengths to maintain application and device compatibility after an OS version change. For most app categories (without any kernel dependencies) the change will not negatively impact app functionality, and existing apps will continue to work fine on Windows 10.The manifestation of this change is app-specific. This means any app that specifically checks for the OS version will get a higher version number, which can lead to one or more of the following situations:App installers might not be able to install the app, and apps might not be able to start.Apps might become unstable or crashApps might generate error messages, but continue to function properlySome apps perform a version check and simply pass a warning to users. However, there are apps that are bound very tightly to a version check (in the drivers, or in kernel mode to avoid detection). In these cases, the app will fail if an incorrect version is found. Rather than a version check, we recommend one of the following approaches:If the app is dependent on specific API functionality, ensure you target the correct API version.NTDDI (NT device driver interface) version number will increment only if target functionality in the API changes. Ensure you detect the change via APISet or other exposed API as created by the feature team, and do not use the version as a proxy for some feature or fix. If there are breaking changes and a proper check is not exposed, then that is a bug. Ensure the app does NOT check for version in odd ways, such as via the registry, file versions, offsets, kernel mode, drivers or other means. If the app absolutely needs to check the version, use the GetVersion APIs, which should return the major, minor and build number.If you are using the GetVersion API, remember that the behavior of this API has changed since Windows 8.1. Please refer to this article for more details. If you own apps such as antimalware or firewall, you should work through your usual feedback channels and via the Windows Insider program.This is what the app manifest would look like: XML<exe>.manifest<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3"> <assemblyIdentity type="win32" name=SXS_ASSEMBLY_NAME version=SXS_ASSEMBLY_VERSION processorArchitecture=SXS_PROCESSOR_ARCHITECTURE /> <description> my app exe </description> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false" /> </requestedPrivileges> </security> </trustInfo> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> * <!-- Windows 10 --> * <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> </application> </compatibility></assembly>And then, add this to your sources:SXS_MANIFEST_RESOURCE_ID=1 SXS_MANIFEST=foo.manifest SXS_ASSEMBLY_NAME=Microsoft.Windows.Foo SXS_ASSEMBLY_VERSION=1.0 SXS_ASSEMBLY_LANGUAGE_INDEPENDENT=1 SXS_MANIFEST_IN_RESOURCES=1 For Windows?10, the two lines in the XML manifest sample marked with an asterisk (*) show how to accurately target your application for the Windows?10 version of the OS. Manifesting the .exe for Windows?10 will not have any impact when run on previous versions of the Windows OS. You can also add this to your .rc file if you already have it defined.Adding the trustInfo isn’t essential, but it is highly recommended. This will allow your .exe to always get the correct version, no matter whether the OS is Windows 10 or Windows 8.1.ResourcesApplication Compatibility Toolkit Download: Download the Windows ADK for Windows 10Known Compatibility Fixes, Compatibility Modes, and AppHelp Messages: Version Helpers API: APIsYour apps should not call undocumented Windows APIs, or take dependency on specific Windows file exports or registry keys. This can lead to broken functionality, data loss and potential security issues. If there is functionality your app requires that is not available, this is an opportunity to provide feedback through your usual feedback channels and via the Windows Insider program.Develop UWP & Centennial appsWe encourage all Win32 app ISVs to develop Universal Windows Platform (UWP) and, specifically, Centennial apps moving forward. There are great benefits to developing these app packages rather than using traditional Win32 installers. UWP apps are also supported in the Windows Store, so it’s easier for you to update your users to a consistent version automatically, lowering your support costs.If your Win32 app types do not work with the Centennial model, we highly recommend that you use the right installer and ensure this is fully tested. An installer is your user or customer’s first experience with your app, so ensure that this works well. All too often, this doesn’t work well or it hasn’t been fully tested for all scenarios. The Windows App Certification Kit can help you test install and uninstall of your Win32 app and help you identify use of undocumented APIs, as well as other basic performance-related best-practice issues before your users do.Best practices:Use installers that work for both 32-bit and 64-bit versions of Windows.Design your installers to run on multiple scenarios (user or machine level).Keep all Windows redistributables in the original packaging – if you repackage these, it’s possible that this will break the installer.Schedule development time for your installers—these are often overlooked as a deliverable during the software development lifecycle.Modern Desktop App functionality is impacted if not run in Windowed ModeIn Windows 10, modern apps are no longer full-screen by default – instead, they are windowed and operations like minimizing, restoring, maximizing, resizing (and any other operation that you’ve always been able to do to any other classic app window) is now possible.The most noticeable change now is that you can get sized to arbitrary sizes that are not just the size of the screen/height of the screen. A user can continuously resize the app window to their liking (down to the app’s minimal window size). This is different from Windows 8.0 or Windows 8.1, where the act of resizing a window was a discrete action (users resized a thumbnail of the window, which then caused the window to resize once the user committed the action). Today instead when the user drags the window by the bottom corner (or other border location) it is a continuous resize, and the app receives resize messages in a row, rather than size change.To mitigate this for Windows 8.0 and 8.1 apps:If the expected feature within the app functionality is broken, then the user mitigation is to place the app into full screen mode (by using the “go full screen button” in the upper right corner of the title bar). If app start-up is impacted that it does not open as expected, then the user should still be able to switch to Tablet Mode to force the app to start in full-screen mode without user intervention.The best way to handle this is to change the app to be aware of the fact that it can be sized to non-monitor sized places/heights (i.e. don’t have a hardcoded table of height/widths and only expect those, or expect hardcoded ratios as well). App developers should expect that as the app is being resized, that another resizing message can happen right after the current resize message gets delivered – as a result, if the app starts animations during resize, it’s possible that the app may receive another resize message right after (so it’s important to ensure that this type of situation doesn’t lead to the app crashing).Availability of applicable graphics drivers on Windows UpdateThe availability of these drivers on Windows Update (WU) will determine whether a user is automatically offered an upgrade from Windows 7, Windows 8 or Windows 8.1 to Windows 10. If hardware scans showed that there was no graphics driver available on Windows Update for the graphics adapter in the PC, users were not offered the updated Windows 10 OS. However, users can still obtain Windows 10 through other sources and manually perform the upgrade.Some users were unsure of why they were not offered the upgrade when other people were, even though the Upgrade Advisor explained that there was no graphics driver available for their hardware.Additionally, some users forced an upgrade and then found that their graphics functionality and performance suffered due to the lack of a hardware driver.MitigationsTo mitigate this, users can manually install an older driver, i.e. from Windows 7, Windows 8 or Windows 8.1, by going to the IHV or OEM web site and downloading a driver explicitly. This must be done after the upgrade and is not guaranteed to work. There is no supported solution if a suitable graphics driver is not available on WU. The user must decide whether to:Remain on the previous OS;Accept the limitations of the software driver, Microsoft Basic Display Adapter (MSBDA); orBuy a new graphics card that has a supported Windows 10 driver.SolutionsIt’s critical that IHVs and OEMs upload their Windows 10 graphics drivers to WU for any hardware that they intend to support. Note that hardware that has reached End-Of-Live (EOL) might not have drivers on WU. There is no solution in this case – the user must choose one of the options under Mitigations above.Graphics driver migration to Windows 10Graphics drivers are not included ‘in box’ or in other words, these drivers are not included in the Windows 10 Media and Windows 10, like its predecessor, Windows 8.1, does not have any 3rd party graphics drivers in the Windows media kit or “In Box”. Instead, the graphics drivers for a broad range of devices are provisioned on WU, which allows hardware vendors to update drivers without requiring a change to the operating system image. Also, existing drivers are not migrated to Windows 10 during an OS upgrade to Windows 10 from Windows 7, Windows 8 or Windows 8.1. This also impacts upgrades from Windows Server 2012.For upgrades and new installations, the graphics drivers must be obtained from Windows Update (WU) or the IHV/OEM web site for the relevant hardware. This requires an Internet connection. The drivers on WU are injected into the OS setup by Dynamic Update (DU) when a user upgrades their Windows 7 or Windows 8.x system to Windows 10.NOTE: This does not apply to systems which come with Windows pre-installed, e.g. off-the-shelf computers purchased in a retail store. These systems already have the graphics drivers installed by the OEM. The OEM might also supply a DVD (for re-installing the OS) which includes the drivers.After upgrading to Windows 10, users might find that there are no graphics drivers installed on their PC. This can happen for a few reasons:The user elected to do a clean install, i.e. not an upgrade.The user de-selected the option to check for updates during the upgrade, i.e. effectively disabled Dynamic Update (DU).The Internet connection was not working during the upgrade.The driver installation failed.After a clean install of the OS, there will not be any graphics drivers on the PC until the WU client runs automatically and downloads the applicable drivers. In the interim the PC will be running the Microsoft Basic Display Adapter (MSBDA), which has limited capabilities, e.g. no support for multiple monitors, and the user might also experience poor performance compared to a hardware driver, e.g. slow frame rate or tearing on video playback.For older PCs (typically built prior to Windows 7), it is possible that there are no drivers for Windows 10 on WU because the graphics adapters have reached End-Of-Life (EOL) and are no longer supported by the hardware vendors. Even systems currently running Windows 7 or 8.x might have been upgraded from a previous OS and could have EOL graphics adapters.Newer PCs might not have drivers available because the graphics adapter was transferred from an older computer, e.g. during a hardware upgrade. This most often happens for computers with multiple graphics adapters where the user kept an old graphics card when purchasing a new machine in order to use multiple displays.Another possibility for a small percentage of machines is that Windows Update only has “coverage” drivers. These are generic drivers that lack OEM customizations. A user who is delivered one of these drivers after upgrading to Windows 10 might see that some functionality is missing, e.g. function keys for controlling screen brightness no longer work.MitigationsSuitable graphics drivers should be delivered either by DU during the upgrade process or by WU soon after the upgrade completes. OEMs must ensure that the appropriate graphics drivers are included in the system images used for factory installation of Windows 10 on their computers.After an upgrade, the user can explicitly check Settings \ Windows Update for drivers although this should not be necessary. Users who force a check while a driver is being automatically installed in the background might see a driver installation failure if the automatic installation completes first. This can be ignored.Users who intend to do a clean install of Windows 10 should obtain the relevant drivers before installing or rely on Windows Update to supply the drivers later, in which case they must ensure that their Internet connection is working.For computers that receive a coverage driver there is no mitigation for missing functionality. However, this should only happen in cases where the hardware supplier no longer maintains the drivers, i.e. computers that are several years old.NOTE: For systems with a single display, e.g. a laptop, many users find that MSBDA is acceptable and do not notice the lack of a hardware driver. No mitigation is required in this case.SolutionsIt is critical that IHVs and OEMs upload their Windows 10 graphics drivers to WU for any hardware that they intend to support. Users should leave “Check for Updates” selected (the default setting) when upgrading. Depending on the speed of the network connection and the load on the WU servers, this can mean that the drivers do not get installed until after OOBE has completed and the user has logged in for the first time. In the meantime, the user might notice some limited functionality or poor performance.Users must ensure that their Internet connection is working before starting an upgrade even if they are upgrading using media (DVD or Flash Drive). If the PC is connected to the Internet, the appropriate drivers should be downloaded and installed automatically. The user is not required to take any action. If the PC is not connected to the Internet, the drivers must be downloaded from the IHV or OEM web site using an Internet-connected computer; transferred to the target machine using a Flash Drive or CD/DVD; and then installed manually.Bluetooth drivers IHVs and Enterprise customers should be aware that Bluetooth drivers and third party profile packs will not be migrated to Windows 10 as part of upgrade from Windows 7, Windows 8 or Windows 8.1. Please refer to this article for more information about Bluetooth changes for Windows 10.Optimized test strategies & flightingWindows OS ‘flighting’ refers to the interim builds available to Windows Insiders before a final build is released to the general population. The more Insiders that flight these interim builds, the more feedback we receive on the build quality, compatibility, etc, and this helps improve quality of the final builds. You can participate in this flighting program to ensure that your apps work as expected on iterative builds of the OS. We would also encourage you to provide feedback on how these flighted builds are working for you, issues you run into etc.If your app is in the Store, you can flight your app via the Store, which means that your app will be available for our Windows Insider population to install. Users can install your app and you can receive preliminary feedback on your app before you release it to the general population.Following are some steps for testing your apps against Windows flighted builds.Step 1: become a Windows Insider & participate in flightingAs a Windows Insider, you can help shape the future of Windows—your feedback will help us improve features and functionality in the platform. This is a vibrant community where you can connect with other enthusiasts, join forums, trade advice and learn about upcoming Insider-only events.Since you’ll have access to all Windows 10 preview builds, Windows 10 Mobile Insider Preview, and latest Windows SDK and Emulator, you’ll have all the tools at your disposal to develop great apps and explore what's new in the Universal Windows Platform and the Windows Store. This is also a great opportunity to build great hardware, with preview builds of the hardware development kits so you can develop universal drivers for Windows. The Windows IoT Core Insider Preview is also available on supported IoT development boards, so you can build amazing connected solutions using the Universal Windows Platform.Before you become a Windows Insider, please note that participation is intended for users who:Want to try out software that’s still in developmentWant to share feedback about the software and the platform.Don’t mind lots of updates or a UI design that might change significantly over time. Really know their way around a PC and feel comfortable troubleshooting problems, backing up data, formatting a hard drive, installing an operating system from scratch, or restoring an old one if necessary. Know what an ISO file is and how to use it.Aren't installing it on their everyday PC or device.Step 2: test your scenariosOnce you have updated to a flighted build, following are some sample test cases to help you get started on testing and gathering feedback. For most of these tests, ensure you cover both x86 and AMD64 systems.Testing your app on the new OS buildClean install test: On a clean install of Windows 10, ensure your app is fully functional. If your app fails this test and the upgrade test, then it’s likely that the issue is caused by underlying OS changes or bugs in the app. If after investigation the former is the case, be sure to use the Windows Insider program to provide feedback and partner on solutions.Upgrade Test: Check that your app works after upgrading from a down-level version of Windows (i.e. Windows 7 or Windows 8.1) to Windows 10. Your app shouldn’t cause roll backs during upgrade, and should continue to work as expected after upgrade—this is crucial to achieve a seamless upgrade experience.Reinstall Test: Ensure that app functionality can be restored by reinstalling your app after you upgrade the PC to Windows 10 from a down-level OS. If your app didn’t pass the upgrade test, and you have not been able to narrow down the cause of these issues, it’s possible that a reinstall can restore lost functionality. A passing reinstall test indicates that parts of the app may not have been migrated to Windows 10.Testing your app against OS/device featuresEnsure that your app works as expected if your app relies on specific functionality in the OS. Common areas for testing include the following, often against a selection of the commonly used PC models to ensure coverage.AudioUSB device functionality (e.g., keyboard, mouse, memory stick, external hard disk, webcam, headphones, printer, scanner etc.)BluetoothGraphics/display (e.g., multi-monitor, projection, screen rotation, etc.)Touch screen (e.g., orientation, onscreen keyboard, pen, gestures, etc.)Touchpad (e.g., left/right buttons, tap, scroll, etc.)Pen (e.g., single/double tap, press, hold, eraser, drawing/handwriting, etc.)Print/ScanSensors (e.g., display rotation, accelerometer, fusion, ALS, etc.)CameraStep 3: Provide feedbackLet us know how your app is performing against flighted builds. As you discover issues with your app during testing, please log bugs via the partner portal if you have access, or through your Microsoft representative. We encourage this information so that we can build a quality experience for our users together.Step 4: Register for Ready for 10The Ready for Windows 10 website is a directory of software that supports Windows 10. It’s intended for IT managers at companies and organizations worldwide that are considering Windows 10 for their deployments. These IT managers can check the site to see whether software deployed in their enterprise is supported in Windows 10.As an ISV, you have the opportunity to submit your company’s information through the tool to declare your support for Windows 10. The material you submit will be checked and approved by Microsoft. Once your submission is approved, your company will have a listing on the site that includes your company name, trademark or logo, and a list of all your software that is supported on Windows 10. This site only lists your company and software for IT managers to refer to in a directory fashion. There are no other benefits.SummaryAs an organization, we leverage telemetry to regularly evaluate app compatibility issues caused by the OS. By understanding significant changes in key reliability and usage metrics, we can quickly identify compatibility issues within interim builds of Windows 10, and often drive resolutions earlier in the WaaS cycle. We recommend that you decouple your app release and support from specific Windows builds and that you test your app on flighting builds. As you test your apps against these builds and require additional telemetry about your apps, please provide us feedback on what would be useful to you. We will continue providing information via this Compatibility Cookbook format for best practices and documentation of changes for each OS release. You can reference all previous content for Windows 7, Windows 8 and Windows 8.1 on MSDN. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download