Compartilhar via

Cache Me If You Can

  • Artigo

There are generally two trends when creating new configurations- one group import their pmq into Component Designer and create a macro component out of them which they then import into Target Designer and can thereafter add to their configurations. The other group imports their pmq directly into Target Designer and this forms the basis of their configuration. However, with this second method, if you have to build a new configuration that uses that pmq you have to start from scratch and re-import the pmq which takes a significant chunk of time. You also encounter this time hit if you need to import multiple pmqs into Target Designer because you want to build an image for different sets of hardware.

For those using the second method there is an easy tweak you can make that will speed up this import process. It involves setting a registry key, so before I proceed let me stress that you need to use caution when changing anything in the registry, as you can possibly corrupt your OS. On your development machine (the machine that you have installed the XP Embedded suite of tools on):

  • Go to Start >Run
  • Type regedit to open the registry
  • Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Embedded\Target Designer
  • Right-click on the key and select "New > String Value"
  • Name the value "EnableCache"
  • Double-click the new Key value name and enter the value data as "True"

The result of this setting is that a cache of the component data in the database will be created the first time you import a pmq into the database. Thereafter, any subsequent pmq imports will utilize the cached data to resolve the data in the pmq to components, rather than having to research the entire database for this information. The cache will be valid for as long as your database remains the same, so any imports into the database of hot fixes, updates or custom components would render the cache out of date and a new cache would need to be created on the import of the next pmq.

- Lynda

Comments

  • Anonymous
    August 07, 2007
    PingBack from http://www.universityupdate.com/Technology/Microsoft_Windows/4392894.aspx

  • Anonymous
    August 22, 2007
    The comment has been removed

  • Anonymous
    August 22, 2007
    The comment has been removed

  • Anonymous
    August 22, 2007
    The comment has been removed

  • Anonymous
    August 22, 2007
    Good points. :)  The only argument I'd make against pre-resolving your hardware dependencies is that it might potentially introduce conflicts later on, such as for the version of NTLDR if you need to use EWF, or the version of NTDETECT should you decide to use USB Boot.  It's not a big deal, though - different development styles for different people. :) Thank you for your comments. -- Matt

  • Anonymous
    August 22, 2007
    Correct. I'd leave the Tasks like choosing "Minlogon vs Winlogon" and "NTLDR vs EWF", etc. as unresolved if they are going to change on a per build basis. But, the rest of the dependencies (95%+) will already be pre-resolved, and save time. :) Jeff