• Introduction to the Windows Embedded Standard 2009 Component Manifest
  • Development Environment Audit
  • Objective Ensure that your XPe image contains all the functionality it needs to fulfill the needs of your limited functionality runtime. Audit checklist
  • Serviceability Audit
  • Licensing considerations
  • Serviceability Audit checklist
  • For additional information
  • Select components carefully, in order to minimize surface exposure area
  • Security audit checklist
  • Objective To eliminate or reduce potential points of hardware or software failure. This includes but is not limited to prevention or elimination of software bugs. Audit checklist
  • Image Footprint Reduction
  • Analyzing the size of the components in your runtime
  • Additional Footprint Links
  • Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing Windows xp professional for embedded systems developers




    Download 5,67 Mb.
    bet6/36
    Sana26.12.2019
    Hajmi5,67 Mb.
    #5189
    1   2   3   4   5   6   7   8   9   ...   36



    Quality Assurance Checklist


    This chapter is divided into the following QA task categories:

    Development environment audit.
    To help you maintain an appropriate development environment for developing your XPe image.

    Functional audit.
    To ensure that your XPe image contains all the functionality it needs to fulfill the needs of your limited functionality runtime.

    Serviceability audit.
    To ensure that your image is serviceable after it has been deployed to the end user. This includes having in place a fully-tested process for updating the image or applying hotfixes.

    Security audit.
    To produce a secure solution, based on considerations such as the environment in which your device will be deployed.

    Reliability audit.
    To eliminate or reduce potential points of hardware or software failure. This includes but is not limited to prevention or elimination of software bugs.

    Image footprint reduction.
    To offer guidelines regarding building configuration files and satisfying dependencies, in order to produce the smallest footprint possible.

    The steps above can offer a reduction in development time thereby resulting in reduced development cost and quicker production deployment.


    Introduction to the Windows Embedded Standard 2009 Component Manifest


    This chapter makes reference to a companion Excel spreadsheet, named

    "Windows Embedded Standard 2009 Components.xls".

    This spreadsheet contains a list of all feature-type components found in Windows Embedded Standard 2009, along with columns that you can sort in order to group components by various categories.

    The spreadsheet enables you to improve your component choice decisions.

    For example, if you want to group all the Debugging/Development type components together, in order to make it easier to pick and choose components that are useful during image development, follow these steps:

    Using Excel, open " Windows Embedded Standard 2009 Components.xls"

    Choose Data->Sort

    In the Sort by field within the Sort dialog, choose Debug / Development tools, and turn on the button to indicate your data range has a Header row.

    Click OK to perform the Sort operation

    Note that all the Debug / Development Tools related items will be grouped together at the beginning of the spread sheet. Pick and choose those components that you wish to use for development.

    Here is a summary description of the columns contained within " Windows Embedded Standard 2009 Components.xls":

    COLUMN NAME

    DESCRIPTION

    Component Name

    This is the formal component name as observed in Target Designer.

    Purpose

    A short description of the component name.

    Unique customizable component settings

    If the component can be customized using Target Designer, this column contains a brief description of the customization options. Sort by this column if you wish to identify and review all the customizable components in your Target Design.

    Macro Component

    An “X” indicates the component is a Macro component, i.e. a component that contains only component dependencies. Macro components are a convenient means of specifying an arbitrary group of components to be included in your build.

    Networking

    An “X” indicates the component is a networking related component. Sort by this column to group together networking components. This can be useful when performing a security audit.

    Additional MSDN resources:



    Comparing TCP and SMB connections for Windows XP Embedded-based devices

    Working with Netsh in Windows XP Embedded

    Graphics and Multimedia

    An “X” indicates the component is related to Graphics and Multimedia.

    User Interface (UI)

    An “X” indicates the component is related to the user interface. Sort by this column to help you review the user interface options available.

    Printing / Imaging

    An “X” indicates the component is related to printing or imaging. Sort by this column to help you review printing related components.

    Security

    An “X” indicates the component is related to security. The component may relate to “surface attack area”, i.e. potential attack vulnerabilities. Most commonly, network related components fall under this category. The component may relate to security enhancement, such as the Windows Firewall. Sort by this column to review all the security related components.

    Windows Platform (API)

    An “X” indicates the component is related to the Windows Platform Application Programmer Interface (API). Sort by this column to help identify components related to the Platform API. You can choose exactly those components that you need, in order to fulfill the requirements of your specific Standard 2009 runtime application.

    Storage

    An “X” indicates the component is related to storage technology. Note that Windows XP Embedded target devices are typically configured to use one of the following storage technologies as the boot device: Conventional hard disk, flash IDE storage devices, CD-ROM (via El Torito CD), and Remote Boot. Remote Boot is a means of booting a diskless system, as it uses a portion of system memory to serve as the system boot storage device.

    Language

    An “X” indicates the component is related to language, internationalization or MUI functionality. Note that you also may need to install corresponding MUI packs in order to achieve full functionality of these components. Sort by this column in order to review and choose Language related components.

    Additional MSDN resources:



    Windows XP Embedded Language Support Overview

    Language Support

    Adding Multiple Language Support in a Windows XP Embedded Image

    App Compatibility

    An “X” indicates the component is related to Application Compatibility. Application Compatibility refers to the ability of the operating system to remain compatible with legacy applications. You may need to include certain Application Compatibility components if you intend to use older applications that were originally developed for use in earlier operating system versions.

    Embedded Enabling (EEF)

    An “X” indicates the component is a feature that is unique to Standard 2009, i.e. not available in conventional Windows XP Professional. Sort by this column to review these components to determine which ones are useful to you.

    WMI / Instrumentation

    An “X” indicates the component is related to Windows Management Instrumentation, or other instrumentation such as Event Tracing, system monitoring tools, etc.

    Debug / Development Tools

    An “X” indicates the component is related to debugging and/or development. Sort by this column to review and choose all the development and debugging tool features. When it is time to produce a production image, you can review these components to identify which ones should not be included for the production image.

    Service (executable name)

    If the component is part of a Windows Service, this column contains the name of the service, and, in parentheses, the corresponding binary DLL or EXE of the service. Sort by this column to pick and choose Windows Services. After you deploy your image, you can run the Services control panel applet (services.msc) to confirm that the services are installed, and you can inspect the status of each service.


    Development Environment Audit

    Objective


    To help you configure and maintain an appropriate development environment for developing your XPe image.

    Audit checklist




    Item




    For suggestions regarding the configuration of your development system, review these on-line resources:

    Installing Windows XP Embedded with Service Pack 2

    Release Notes for Windows XP Embedded Service Pack 2 Feature Pack 2007

    Development Process

    Building and deploying XP Embedded Images

    Configuring a Windows XP Embedded Thin Client

    Dual-Booting Tips for XP Embedded

    Building a Diskless Automation Controller Using Windows XP Embedded

    Rapid Prototyping with Windows XP Embedded

    Developing an Embedded Run-Time Image from Start to Finish

    Tutorial: Building and Deploying a Run-Time Image




    Establish and deploy a regiment of regularly backing up your Target Designer development system, in particular the following:

    • Component database or databases (your repository folders and *.MDF, *.LDF)
      Working with SQL Server to Manage Your Windows Embedded Standard Database

    • Configuration files (.SLX)

    • Custom components (.SLD) that you created and manage.




    If you are maintaining and servicing XPe images that were developed using SP1 or SP2, do not install SP3 on top of your SP1 or SP2 database; instead retain the older databases in order to continue servicing older deployed images.

    For more information:



    Installing Windows XP Embedded with Service Pack 2




    If your development systems are part of a corporate network, ensure that your SQL Server database and your folders are adequately protected, by configuring them with restricted permissions.




    If you do not intend to share your Component Database for use with other developers in your company who use Target Designer, configure SQL Server so that it does not accept network clients, using the svrnetcn.exe tool to disable all network services.




    Become familiar with third party tools to facilitate Windows XP Embedded development:

    Useful Tools for Creating Components and Troubleshooting Configurations

    Third-Party Tools for Windows XP Embedded




    Review the Component Help system:

    Finding Information in Help

    Functional Audit

    Objective


    Ensure that your XPe image contains all the functionality it needs to fulfill the needs of your limited functionality runtime.

    Audit checklist




    Item




    If using Minlogon instead of Winlogon, review these resources:

    Introduction to Minlogon




    Review these links to establish their applicability to your project. Then use the applicable ideas.

    Building Your First Windows Embedded Standard Test Image

    Development Process

    Design a Run-time Image

    Building and deploying XP Embedded Images

    Configuring a Windows XP Embedded Thin Client

    Dual-Booting Tips for XP Embedded

    Building a Diskless Automation Controller Using Windows XP Embedded

    Rapid Prototyping with Windows XP Embedded (using Virtual PC)

    Developing an Embedded Run-Time Image from Start to Finish

    Tutorial: Building and Deploying a Run-Time Image

    Finding information in Help




    Review and choose Embedded Enabling Features (EEFs) – these are components that are only available in Windows XP Embedded.

    Embedded Enabling Features

    Chapter 4. Embedded Enabling Features




    If considering using the Enhanced Write Filter (EWF) component, review the EWF section in Chapter 4. Embedded Enabling Features, as well as these on-line MSDN resources:

    Programmatically Dismounting Volumes

    Dismounting Volumes in a Hibernate Once/Resume Many Configuration

    Controlling EWF by Using the EWF APIs

    Using CompactFlash (CF) with the Enhanced Write Filter (EWF)

    Configuring the CompactFlash Device

    Using the Enhanced Write Filter (EWF) in Windows XP Embedded




    Configuring the User Interface (shell)

    Review this on-line MSDN resource regarding user interface shell options:



    Different Shells for Different Users




    Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “Unique customizable component settings”. For each component that is in your build that contains customizable settings, review each setting to ensure that it is correctly set for your production image.




    Finish developing all custom components that you need.

    Basic Componentization

    Componentizing Applications (Standard 2009) (formerly published as a blog at: Componentizing Apps (Winamp project))

    Creating custom components for Windows XP Embedded

    Author Components and Customize Shells

    Tutorial: Creating a Custom Component

    How to Componentize an Application

    Component Designer: Pulling It All Together




    Finish developing all custom driver components that you need.

    Review this content: Creating Driver Components






    If you have further problems componentizing a third party driver or application, particularly if the driver or application is being installed via a third party installer package, follow these steps.

    Use an installation monitoring tool found here Third party installation monitoring tools to determine what binaries and what registry entries have been added to your image by the driver installer program. Run the driver installer on an XP Professional SP2 system (not your XPe SP2 system) via while running the installation monitoring tool which monitors all files and registry keys added to the image.

    Analyze each file that is being installed by the installer, using the DEPENDS.EXE tool (available in the Windows SDK or a version can be found here: http://www.dependencywalker.com/ - this site is also not formally endorsed by Microsoft). Verify that the binary dependencies required by the driver binaries are included in your XPe image.

    If further analysis is needed, you can monitor file access using FILEMON and monitor registry access using REGMON. These third party tools are available at this site:


    Windows Sysinternals




    Ensure that the status of each of your custom component(s) are set to “Released”. Otherwise your components will not be properly versioned and you will get "unreleased" warnings when building.




    Ensure that any custom components are backed up (along with your component database and repositories).





    Serviceability Audit

    Objective


    Ensure that your image is serviceable after it has been deployed to the end user. This includes having in place a fully-tested process for updating the image or applying hotfixes.

    Background


    You, as the OEM, must maintain 100% “ownership” of your deployed Windows Embedded Standard 2009 (Standard 2009) image. Every Standard 2009 image is a “sub-platform” of Windows XP Pro. As such, it has been custom tailored to fulfill exactly one target device scenario. In contrast, Windows XP Professional serves as an operating system platform designed to accommodate any third party application that adheres to MSDN XP Platform development guidelines.

    Please review Chapter 6. Servicing for details.


    Licensing considerations


    Windows XPe cannot be used on a PC as a Windows XP Professional replacement. To be clearer, Standard 2009 can only be licensed to run line-of-business applications on fixed function devices. You can have an unlimited number of applications running locally, if the line-of-business application requires them locally.  For example, a device that has a retail management application may have a local spreadsheet for the store manager to create daily reports.  Running Microsoft Office is usually outside the scope of this definition.

     

    Serviceability Audit checklist




    Item




    Most Important

    Review Chapter 6. Servicing






    Planning Ahead
    Think about servicing when you design your devices. Servicing should not be an afterthought. Will your devices be able to connect to the Internet and communicate with a server? Will your devices use modem access? How many servers do you need to handle the load of servicing?




    Servicing Experience

    Invest the time required to design a clear and consistent user experience for servicing. For example, a set top box periodically downloads a program guide. It can also download updates, which simplifies its design and makes the user experience clear and consistent.






    Testing Your Servicing Solution

    Test your servicing solution thoroughly so that you are sure that it works correctly. By the time you have deployed your devices in the field, it is too late to fix major bugs. If you thoroughly plan your testing and then test against your plan, you can potentially save time and money. Include scalability testing (tests that ensure that servicing scenarios work the same way, regardless of the number of devices) and corner cases (tests that introduce small deviations in sets of devices).






    Having a Back-Up Plan

    Make sure that you create a back-up plan in case your primary servicing solution fails. If you typically service devices by using a broadband connection, you might want to be able to dial up by using a modem, also. You might want to be able to service devices through a CD-ROM or a universal serial bus (USB) storage device (via USB Boot if needed), and plan to replace media and devices in case of failures.






    Ensure image contains the Servicing tools you need

    Include useful maintenance tools in your image such as Registry Editor, Administration Support Tools, Misc. Command Line Tools, Net.exe Utility, etc. See Addenda 1. Table of built-in Windows XP utilities.




    For additional information


    Comparison of Servicing Solutions

    Supporting Windows XP Embedded-based Devices

    Servicing Windows XP Embedded with Service Pack 2

    Manage and service a run-time image

    Building Serviceable Devices

    Security Audit

    Objective


    To produce a secure solution, based on considerations such as the environment in which your device will be deployed.

    Select components carefully, in order to minimize surface exposure area


    • You can optimize the security of your image by including only those components that you need to support your embedded limited functionality runtime application.

    • Consider removing components that may contain feature functionality that carry a possible risk of exposing the system to viruses or malicious intruders.

    • Consider adding components that serve as security protection or security control.

    • Since malicious intruders commonly use the network as the principal access conduit, you should also review all Network related components when conducting a Security review.

    Security audit checklist




    Item




    Most important

    Review and deploy the section named Security Considerations in Chapter 6. Servicing






    Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “Security”. Review those components related to security. Pick and choose those security related components that are applicable to your image.




    Administrator Account component: Depending on your device scenario, consider specifying a secure password (cmiUserPassword). Also consider using the User Account component to add one or more user accounts with restricted user access settings.




    In order to reduce surface attack area, i.e. reduce exposure to malicious intruder software, consider excluding components from your configuration that are not required for your configuration to function – especially components that are networking or UI related.




    Consider including in your consideration, all components that enhance or support system security, such as Windows Firewall/Internet Connection Sharing.




    Consider the inclusion of Antivirus software.

    Runtimes and Antivirus Software




    Design the image so it can be updated with Microsoft security updates. Develop a servicing strategy for accomplishing this.

    Deploying Microsoft security updates


    MSDN Links


    Security Considerations for Your Image

    Security Considerations for Windows XP Embedded Developers

    Add Security Features to a Run-Time Image

    Creating a Component for the Custom Security Template

    Microsoft Security Home Page

    API Audit


    You should review components that typically contain APIs (Application Program Interfaces) which are intended for public use.

    Audit checklist




    Item




    Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “API”. Then review those specific components.




    In order to minimize image footprint and increase image security, consider deleting components in your image, exposing APIs that are not required by your runtime image.


    Reliability Audit

    Objective


    To eliminate or reduce potential points of hardware or software failure. This includes but is not limited to prevention or elimination of software bugs.

    Audit checklist




    Item




    Ensure you use SP2 or greater for all new development!

    List of fixes included in Windows XP Service Pack 2




    Reliability in Windows Embedded Standard




    Building a Reliable Windows XP Embedded Platform




    Ensure you have in place a test procedure that covers all known code paths for your (limited functionality) runtime, and that you perform a complete test pass before deployment.


    Image Footprint Reduction

    Objective


    This section offers guidelines regarding building configuration files and satisfying dependencies, in order to produce the smallest possible disk image footprint.

    In order to produce a fully functioning device in the shortest time, the first time you build your image you should not worry about minimizing the size of the image.

    Footprint minimization should occur after proving that your (non-minimized) image is 100% functional. To minimize footprint, rebuild the image from scratch, using a minimal set of hardware components. This way, if any problems develop while building the minimal configuration, you will know the problems are due to inadvertent removal of necessary components.

    Ultimately if you want to minimize image footprint, you should build from scratch with the set of known components you need. This is because whenever you add a component to your configuration, all its dependency requirements get pulled in, but when you remove that component later, its dependency requirements are not typically removed at the same time, causing image bloat.

    Rebuilding the image from scratch will help ensure that you do not have unnecessary components that were introduced while you were developing, experimenting and testing your original configuration.

    Make sure you can view file, registry, and other resources of the components in your .slx file by navigating to and then enabling the option. In Target Designer, click View on the toolbar, and then click to select the Resources check box. You may also need to lower the default visibility in Target Designer to 100 to see most of the components in your database and in your .slx configuration.


    Dependency analysis


    You can start with a known set of components that you need, then turn automatic dependency resolution off (a Target Designer option). You will see task items for every dependency resolution issue. This will let you see who is dependent on Outlook for example. The Macro components (those components that are shown in bold) are nothing but components containing lists of dependency needs. You might want to review what macro components you are using because they can bloat your footprint quickly. After completing Dependency Checker, you can delete or disable the macro component, because it will already have done its job of pulling in its list of dependent components.

    Analyzing the size of the components in your runtime


    Review the Build.log file that is generated when you build your image. The footprints of each component are given at the end of the log. Inspect the largest components first and determine whether they may be deleted from your runtime.

    Audit checklist




    Item




    Review this MSDN content:

    Footprint




    Delete unneeded hardware components (originally obtained via TAP) in order to reduce the total disk and memory “footprint”. If you used Tap.exe to generate the hardware configuration, see the Disabling Software Enumerated Devices Picked up by TAP.exe tip. The hardware configuration list generated by Tap.exe and imported into your design can have a significant impact on your footprint if you are not careful.




    Rebuild a new configuration using the reduced hardware component configuration.




    Add only the feature components that you know your image requires.




    Do not attempt to minimize footprint by failing to let Target Designer resolve all the component dependencies. This is likely to result in a non-functioning device, or even worse, feature failure that is discovered only after the device has been deployed.




    Disable paging file support. If you have enough RAM to support the services you expect the user to run, you may not need the paging file. Note that paging file is disabled by default.




    Consider removing the Indexing Service component.

    Typically, you can safely remove the Indexing Service component to reduce footprint.

    The Indexing Service component installs the "Fast Find" indexing that the Windows XP Professional Search functionality uses. This service is not enabled by default in Windows XP Professional and in Standard 2009, so in many cases, it can safely be removed with little to no impact in most runtime images.

    The Indexing Service component itself adds approximately 15 MB to most runtime images, so you reduce the overall run-time footprint if you do not need this service.






    Convert the partition on your target embedded device to NTFS, and then compress the volume (the compression feature requires NTFS file system). This can reduce the footprint by up to 40 percent. This requires that you add the NTFS component to the runtime.




    Review the Additional Footprint Links below.


    Additional Footprint Links


    Advanced Run-Time Image Techniques

    Footprint

    Finding and eradicating big footprint

    Support WebCast: Microsoft Windows XP Embedded: Reducing the footprint

    Footprint Reduction: Remove Indexing Service

    Tips for Reducing Footprint Size of a Windows XP Embedded Runtime

    File Sharing vs Footprint

    Winlogon vs. Minlogon

    Adding MMC without the Overhead of IE

    Using BOOTPREP

    Kaspersky Anti Virus sample component for XPe

    Download 5,67 Mb.
    1   2   3   4   5   6   7   8   9   ...   36




    Download 5,67 Mb.

    Bosh sahifa
    Aloqalar

        Bosh sahifa



    Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing Windows xp professional for embedded systems developers

    Download 5,67 Mb.