Determining Application Resource Usage

  • Article

5/10/2007

Before you create a custom component for an application , you must determine its exact use of resources such as binary files, .ini files, dynamic link libraries (DLLs), device drivers, registry keys, ActiveX controls, and COM registration.

To determine application resource usage

  1. Examine the following in your source code:

    • Calls to registry access functions, for example, RegCreateKey in Win32.
    • Calls that indirectly access the registry, for example, ShellExecute in Win32.
    • Calls to file access functions, for example, fopen in the C run-time library.
    • Calls that indirectly access files, for example, invoking a Help engine or accessing a database.
    • Calls that load executable code, for example, LoadLibrary in Win32.
    • Calls that indirectly load executable code, for example, creating a COM object, calling an exported dynamic-link library (DLL) function that creates a COM object, or starting a service.
    • Calls to exported functions in DLLs.

  2. On a computer running Microsoft® Windows® XP Professional, install a resource-monitoring tool distributed by Microsoft or a third party.

  3. For information about third-party tools, see Third-Party Tools in the MSDN Library.

    Use the resource-monitoring tool to discover any additional binaries, core operating system files, or registry entries that are required by your application. Use it to analyze both the application and the application setup program.

    For example, Microsoft provides the following tools:

    • The Windows operating system (OS) resource kit tool APIMon can monitor all Win32 API calls that belong to an application. You can scan its output for calls that access the registry and the file system.

    • The Installation Monitor resource kit tool can show the difference between registry snapshots before and after you run a process like a setup application.

    • Microsoft Visual Studio® includes a tool called Depends that can report on the DLLs used by an executable. This tool examines the portable executable (PE) header and reports on all DLLs that have been linked into the executable using import libraries.

      Note

      A good technique to determine dynamic DLL use is to run your software with a debugger application, such as Microsoft Visual C++® or NTSD, run common usage scenarios, and note module load messages in the debugger's output window.

  4. Determine whether required files are included in other components or already included in your configuration.

    • In Target Designer, create a filter that uses the "component contains the following file [filelist]" rule and use the filter to search the component database. If components are not found, consider lowering the Target Designer visibility threshold to 100 or 200.
    • View the files in the components in your configuration. One method for doing this is to build your configuration and then search for the files in the build output folder, typically \Windows Embedded images/.

  5. If the required files, registry entries, or other resources are included in other components, add those components to your configuration. Otherwise, add the required files, registry entries, and other resources to your component.

  6. If you add other components to your configuration to satisfy the requirements of your component, you must make your component dependent on those other components. Follow these steps:

    • Add the components to your configuration.
    • Build the configuration.
    • Test the run-time image to ensure that everything functions properly.
    • After you ensure that everything functions properly, open your component .sld file by using Component Designer, and in the definition of your component, add component or group dependencies upon the other components.

  1. Examine the following in your source code:

    • Calls to registry access functions, for example, RegCreateKey in Win32.
    • Calls that indirectly access the registry, for example, ShellExecute in Win32.
    • Calls to file access functions, for example, fopen in the C run-time library.
    • Calls that indirectly access files, for example, invoking a Help engine or accessing a database.
    • Calls that load executable code, for example, LoadLibrary in Win32.
    • Calls that indirectly load executable code, for example, creating a COM object, calling an exported dynamic-link library (DLL) function that creates a COM object, or starting a service.
    • Calls to exported functions in DLLs.

  2. On a computer running Microsoft® Windows® XP Professional, install a resource-monitoring tool distributed by Microsoft or a third party.

  3. For information about third-party tools, see Third-Party Tools in the MSDN Library.

    Use the resource-monitoring tool to discover any additional binaries, core operating system files, or registry entries that are required by your application. Use it to analyze both the application and the application setup program.

    For example, Microsoft provides the following tools:

    • The Windows operating system (OS) resource kit tool APIMon can monitor all Win32 API calls that belong to an application. You can scan its output for calls that access the registry and the file system.

    • The Installation Monitor resource kit tool can show the difference between registry snapshots before and after you run a process like a setup application.

    • Microsoft Visual Studio® includes a tool called Depends that can report on the DLLs used by an executable. This tool examines the portable executable (PE) header and reports on all DLLs that have been linked into the executable using import libraries.

      Note

      A good technique to determine dynamic DLL use is to run your software with a debugger application, such as Microsoft Visual C++® or NTSD, run common usage scenarios, and note module load messages in the debugger's output window.

  4. Determine whether required files are included in other components or already included in your configuration.

    • In Target Designer, create a filter that uses the "component contains the following file [filelist]" rule and use the filter to search the component database. If components are not found, consider lowering the Target Designer visibility threshold to 100 or 200.
    • View the files in the components in your configuration. One method for doing this is to build your configuration and then search for the files in the build output folder, typically \Windows Embedded images/.

  5. If the required files, registry entries, or other resources are included in other components, add those components to your configuration. Otherwise, add the required files, registry entries, and other resources to your component.

  6. If you add other components to your configuration to satisfy the requirements of your component, you must make your component dependent on those other components. Follow these steps:

    • Add the components to your configuration.
    • Build the configuration.
    • Test the run-time image to ensure that everything functions properly.
    • After you ensure that everything functions properly, open your component .sld file by using Component Designer, and in the definition of your component, add component or group dependencies upon the other components.

See Also

Tasks

Determining Device Driver Resource Usage

Concepts

How to Componentize an Application
Resources (Update Rollup 1.0 for Windows XP Embedded)

Other Resources

Application and Device Driver Components
Dependencies