Software Development and Test Guidelines for Standard 7 (Standard 7 SP1)


Microsoft Corporation

December 2011

This technical article discusses several important development and test areas that you should consider when you develop Windows Embedded Standard 7 applications and images.

Windows Embedded Standard 7 is a componentized version of Windows 7 that helps enable the power of Windows on embedded devices. Standard 7 Toolkit assists embedded developers to create custom Windows Embedded images that are customized to their specific scenarios and applications. Developers who use the Standard 7 Toolkit expect the resulting customized Standard 7 images to reach high quality standards that will help meet the needs of their own customers. Software product quality is a top priority for the Standard 7 development team, so the team follows the same standards that many of the teams at Microsoft use when developing products.

When planning for software quality assurance, it helps to consider both functional and non-functional software test areas. Some examples of the non-functional areas would be criteria referred to as the “ilities” by the authors of the book How We Test Software at Microsoft (dependability, reusability, testability, and so on). In the following sections, we present several fundamental areas for software testing and include pointers to more information about the topic. These guidelines are heavily used by the Standard 7 development team, and we suggest that you consider and follow them whenever possible.

Accessibility empowers users to utilize the potential of their systems, and for some individuals, makes the use of a computer possible. Microsoft has been a strong advocate of accessibility, and this is reflected in the support that Windows, and other Microsoft products such as Microsoft Office, have provided over the years. For more information about how Microsoft products address accessibility requirements, see this Microsoft Website.

A Voluntary Product Accessibility Template (VPAT) is a standardized form that describes how a product can address these regulations. Other regulations may apply depending on the product that is being developed. For example, Section 255 of the Communications Act represents the Telecommunication Access for People with Disabilities regulation and you may also want to consider it when you design a related product.

While some regulations mandate that data be accessible by people with disabilities, usability is not mandated. However, general applications in industry show that usability has become a best practice followed by many software developers and technology companies. For more information about accessibility, visit the Microsoft Accessibility website and Windows Accessibility Developer Center.

Protecting intellectual property and avoiding related lawsuits is another issue to consider when releasing software. Software patents should be carefully considered by qualified individuals to make sure that the software product is protected and that it does not violate intellectual property rights. License documents let you inform the user of certain rights, restrictions, and obligations that apply when using the software product. While different types of license documents exist, the choice of type depends on the software product.

Computer security has become one of the most discussed topics in the computer software industry. Many books are available that discuss the processes that should be followed to make sure that an installed software product does not compromise the security of the underlying system. In the early 1970s, malware such as Creeper and Rabbit were among the first to find their way onto computers, which led developers to find ways to track and remove malicious software. Reaper, which differs from the anti-virus software that exists today, was developed for the sole purpose of tracking and eliminating the Creeper worm. Today, malware exploits and anti-virus software algorithms have become very complex. For more information, see The Evolution of Viruses and Worms.

Software development lifecycles have progressed to include accountability for software security early in the planning and design phases. Software vulnerabilities can range from buffer overflows to code injections; therefore, we strongly recommend training software developers to write more secure code. For example, a simple input validation test might help prevent a buffer overflow attack on specific code block. It is recommended that guidelines about how to write the most secure software, which may also be language specific, be followed by software developers to help make sure that their code is as secure as possible. For an example guideline, see the Security Guidelines: ASP.NET 2.0 topic on MSDN. For a more general Microsoft process guideline, see the Trustworthy Computing Security Development Lifecycle on MSDN. The Security Development Lifecycle (SDL) guideline is highly recommended and is frequently adopted by software developers and technology companies.

One process frequently used in software security is threat modeling. This process helps identify software security risks and to prioritize them according to their impact on the quality of the software product. Writing a secure software product is a complex process, and threat modeling helps give developers a systematic way to identify attack surfaces and to account for risky and costly areas in the code they write. Many approaches to threat modeling are available. Attacker-centric, software-centric, and asset-centric are several examples of how threat modeling can be approached, depending on the type of product being developed. The developer must select the best combination of threat modeling techniques to use when they design for security. An excellent resource on this topic is Threat Modeling, (Microsoft Press), by Frank Swiderski and Window Snyder.

Fuzz testing is another technique used in software security testing and can test how the code reacts to randomly-generated inputs. Examples of random inputs would be negative numbers, unexpected data, or data that exceeds expected buffer sizes. This type of testing can often detect bugs that are related to areas such as memory leaks and security threats.

Privacy assurance is an important part security testing and has become a significant part of the software release process. Recently, many online services have emerged that focus on a user’s personal information and preferences and that increase the significance of user privacy. When critical user information is acquired by malicious users, it has significant legal and business implications. To help address this issue, Microsoft publishes Privacy Guidelines for Developing Software Products and Services as a part of the SDL guidelines. We recommend that you review these guidelines to help reduce legal risk and to help increase end-user trust.

Software that has been developed anywhere in the world may be instantly accessed by any Internet-connected user around the world. Users with different languages and different cultures may end up using the same product. Some phrases or words that might be non-offensive in one part of the world may prove to be very offensive in other regions or cultures. When releasing software, make sure that a scan is performed on the software and data to prevent including any potentially offensive wording or language. Many software companies that develop software in different languages have advisors who are local to the area in which the software is to be published. Checking for sensitive data before releasing a software product helps in building a trustworthy image, lowering legal implications, and in reducing the risk of product bans or boycotts.

Sensitive data is not just limited to offensive material (which might include phases, terms, icons, flags, and so on), but includes other types of data like credit card numbers, social security numbers, or any kind of internal company information that should not be disclosed. There are several tools that can be used to scan for sensitive-data, most of them use a term database that they use to compare data against and attempt to flag any suspicious data. During the scan process, these tools may generate false positives. However, many tools can adapt and learn which helps minimize the false positives numbers. An advantage of using such tools is the speed at which they can scan. An example of a scanning tool is Spider, an open-source tool developed by Cornell University.

It is the responsibility of the software developer to ensure that the software is virus and malware-free. Several third-party companies provide higher quality tools for capturing suspicious viruses and malware that might find their way into an embedded software product. By using these tools you can provide the safest product possible.

Authentication is another critical issue to help ensure software integrity. By using code signing and certificate generation, a software developer can help provide a high level of trust for users. Microsoft provides tools and guidelines on how to use code signing in a software product. For more information, see Introduction to Code Signing on MSDN.

Many software quality tools are available as part of the Windows SDK, Windows DDK, or the Visual Studio product suite. Beginning with Visual Studio 2005, the compiler will issue C4996 warnings if C runtime library functions are used that are vulnerable to buffer overruns (for example, banned APIs). By inserting #pragma warning (error: C4996) in your header files, you can help ensure that these functions are not accidentally used in your code.

For example:

#include "stdafx.h"
#include "string.h"

#pragma warning (error : 4996)

int _tmain(int argc, _TCHAR* argv[])
    char a[] = "A String";
    char b[256];
    strcpy(b, a);
    return 0;

The compiler also enables runtime buffer security checking with the /GS compiler switch. This can also be set via the UI on the project properties page (Code Generation). For more information, see the /GS (Buffer Security Check) topic on MSDN.

The enterprise version of the C++ compiler supports the /analyze switch. This switch enables the PREFast C++ code analyzer. For managed code applications, the FxCopy tool provides a similar functionality. For more information, see the /analyze (Enterprise Code Analysis) topic on MSDN.

By using the information presented in this article, you should now have a better understanding of how to design and test your Standard 7 applications and images by using available standards, guidelines, and tools to help ensure high quality software.