INFO: Tips on How to Create Components for Microsoft Windows NT 4.0 Embedded |
Q247824
The information in this article applies to:
- Microsoft Windows NT Embedded 4.0
SUMMARY
The tips described in the "More Information" section may help you create components for Microsoft Windows NT 4.0 Embedded.
MORE INFORMATION
Use Sysdiff to Discover Necessary Files and Registry Keys
Sysdiff is a Microsoft tool that creates a system difference package, applies a system difference package to a Windows NT installation, and can generate Windows NT installation information files (INFs) and $OEM$ distribution share points.
You can download the latest copy of Sysdiff from the following site:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/utilities/Sysdiff-fix/SYSDIFFI.EXE
You can find documentation for Sysdiff in TechNet, MSDN, or in the Windows NT Deployment guide, which is available from the following sit:
http://www.microsoft.com/ntworkstation/technicalresources/deployment/DeploymentDocs/DepGuide.asp
When creating components, you can discover the necessary files and registry keys by doing the following:
- Install a clean version of retail Windows NT 4.0 with Service Pack 5 (SP5) on a computer. (Note that "clean" means no additional applications are installed, and you have not configured or changed the installation).
- Use SYSDIFF /SNAP to take a snapshot of the clean system. See the Sysdiff documentation for details.
- Install and configure your application on the computer. If the application or driver you are capturing with Sysdiff require that you restart the computer or registers controls, allow this to occur before proceeding. This way, all necessary system changes will be reflected in the system difference package.
- Use SYSDIFF /DIFF on the computer to create the SYSDIFF package.
- Use SYSDIFF /DUMP on the package to inspect the package contents.
- Use Component Designer and the information you have gathered by using SYSDIFF /DUMP to build a Component Definition file (.KDF) for your component.
Test Your Component on Windows NT 4.0 Embedded Minimal and Standard OS Configurations
Many files and registry keys that are found in the Standard operating system (OS) component are not present in the Minimal OS component. By testing on a Minimal OS configuration, you can determine whether your component includes all the necessary files and registry keys.
If your component does not work properly on a Minimal OS configuration, you can use various third-party file and registry monitoring tools while your component is running to determine the missing files and/or registry keys dependencies and add them to your component.
Once you determine the missing resources, copy any missing files and registry keys directly to the running Windows NT 4.0 Embedded system and validate that your component works when they are present. Then, add them to the component and rebuild the configuration after you have identified all the missing files and registry keys. This approach verifies that the missing resources and your component work correctly, and saves time by not forcing you to rebuild and reinstall the embedded run-time image multiple times.
There are some caveats to the "live copy" approach when you are working with registry keys:
- The CurrentControlSet key is used on the live system, but this is mapped to the ControlSet001 key in the KDF itself.
- Volatile registry key data (data that changes over the life of the application or system or is generated by the application or system at every run) should not be migrated to the embedded system.
- Some registry changes require that the application or driver be restarted, or that the system be restarted.
Note that this is not a complete list, however, it illustrates some issues that must be considered when you use this technique, which may require the you rebuild the configuration with an updated KDF to completely and confidently test.
Break Large Components into Smaller Pieces
Large components, such as large applications or device drivers with many support files, are difficult to troubleshoot and update. Applications can be broken down into a core component and components for specific feature sets, while device drivers can be broken down into the actual driver and sets of support files. This approach allows for easier creation and troubleshooting of components, as well as flexibility in configuring systems.
A logical breakdown of large components is largely determined by the nature of the application or driver to be put in the component. However, custom install options make this job easier.
For device drivers and applications with customizable install options, install only the base application, by using Sysdiff to capture the core components. Then, use the Add/Remove Programs application of Windows NT 4.0 to add more features to the application, and use Sysdiff to capture the changes. For device drivers and applications without the ability to add features after the first install, multiple clean Windows NT 4.0 setups may be required to capture all possible installation scenarios.
Help files should almost always be broken out into a separate component.
Use Dependencies to Relate Components to Each Other
When you break down a large component into smaller components, you lose the intrinsic relationships between the files and the registry keys in the component. You can use dependencies between the components to make sure, for example, that an application feature set is not added to a configuration without the application core files component being added as well.
Additional query words:
Keywords : kbOSWinNT400 kbDSupport kbGrpDSOPK kbGrpDSETK
Issue type : kbinfo
Technology : kbWinNTsearch kbWinNT400xsearch kbWinNTEmb400
Last Reviewed: May 11, 2001 |
