Perhaps the best place to really start with XPE QFE's is to go over, as best I can, the QFE process from my point of view.

Most QFE's don't start with the Embedded team - they start with the Windows team. There are exceptions, but for the purpose of argument, we'll assume every QFE published for XPE starts with bits patched for the Windows XP product. I routinely author security builletins, available through the MSDN Security Bulletins page and Windows Update.

QFE packages for the desktop contain two very important things - a set of patched files, and an INF file that direcs the live installation of those files. The INF also contains registry keys that are needed by the patch. This INF tells me which files need to be updated and which registry keys need to be added to an XPE runtime to implement the QFE.

From there, I go a'hunting - I find the components that own the updated files and registry keys. In some case, no component owns the registry keys - most QFE's come with a set of tracking registry keys which need to be added to the runtime. Once I've identified the components, I find the original SLD files we used to build the database and update them.

The updating process is fairly straight-forward, but a little confusing. First, the components have certain metadata changes made to help us ID the new component as a QFE, like the name, version, revision, and additional extended properties. The repository is also changed to point to the SP1 QFE repository found in Q811279. A new package for the QFE components is created in Component Designer to give us a quick way to remove the QFE later.

Once that's done, I rename all the patched files, prefixing them with the QFE number. This is to avoid any file name collisions with the older, unpatched files already in the SP1 repository. Then I change the Source Name property of the file resources representing the patched files to reference the new name.

The new registry keys are somewhat tougher - if there is more than one component being affected by updated files, I need to pick one component to hold the new keys. Sometimes it's easy, sometimes not, but it always gets done. Updated registry keys are much easier - just change the keys in the owning component.

With all that done, it's time to package everything up into an installation package. We developed an installer for XPE QFE's that automagically imports all the components and copies the files into the SP! QFE repository. It's driven by it's own INF file, which needs to be written. The the whole thing gets tested twice - once by me, and once by our stellar Test team. We also loop in the testers for the feature being updated to help us make sure the functionality works as expected on our runtimes.

Once everything is fully tested and has everyone's OK, I digitall sign the executable package and publish it to the Microsoft Download Center. Once it's published, I send that info to our web masters for inclusion on the Microsoft Embedded web site.

That's about it - pretty dry, but necessary for a complete understanding of why it takes a while for QFE's to get out to you. I need to start with a complete QFE package for the desktop, go through some reauthoring and a lot of testing, then the publishing process which requires more verification along the way. Throw in some cross-group cooperation with other test teams, many of whom I've never met before and may not know anything about XPE, and mix in some hot QFE's that need to be done immediately that throw the whole schedule off, and you can see the difficulties.

Next time, I'll tell you what kind of stress of worm writer can induce....