Rawdeps, Cooking, Oh My!
Here’s a real question from the 'windowsxp.embedded' newsgroup:
“I have noticed in TD that some components have resources called
"RAWDEP (819)"... How do I create such resources in Component Designer?”
OK, here’s the scoop. “RAWDEP” resources are used internally by Microsoft as part of the Embedded build process for every build every day, those rawdeps on files are converted to component dependencies.
When we start the build process each day, we expect that component “Foo” will have no component dependencies but may have one or many rawdeps. After the “cooking” process converts the rawdeps to component dependencies, we now have a component that is basically ready for the customer to add to their configuration because component Foo now has knowledge of its dependency on other components which is what you need for TD to properly build your configuration.
So before this cooking process starts we have no component dependencies and a component that is basically useless if it was added to a configuration. After the cooking process completes the component now has one or more component dependencies.
So your next question is:
“But Andy, why go through this each day for those thousands of components? Surely this is taking you or your build manager hours each day, right? Why not determine the component dependency one time, save off that component as the new master version of the component and reuse it again tomorrow in that same state?”
Good question, it’s because there is so much churn going on within the thousands of components and within the XP-Pro build’s binary dependencies that a component dependency on Monday may not be valid on Tuesday.
Here’s an example that will clarify:
1. On Monday, let’s say Internet Explorer depends on tcpip.sys, so IE has a RawDep on TCPIP.sys.
2. tcpip.sys is owned by the TCPIP Networking component. Also owned by this component are several other networking resources that comprise the tcpip feature.
3. So after the cooking process, the IE component depends on the TCPIP Networking component.
4. On Tuesday, to help reduce footprint of Embedded configurations, the networking team refactors their components, they decide to *move* TCPIP.sys to a *new* component called TCPIP Driver component.
a. The networking team has no knowledge of the IE component or any other feature that has a dependency on them. And since they’re lower in the feature layers, they don’t care who depends on them.
5. Later that day, when we cook the IE component, which still has a rawdep on TCPIP.sys, the cooking process will now find that the driver is owned by a new component.
6. After cooking on Tuesday, the IE component depends on the TCPIP Driver component.
7. You can see that a team was able to refactor its feature to a new component, TCPIP still works, IE still works, the footprint is smaller and everybody is none the wiser.
This was a very basic example and there’s a lot more going on in the cooking process besides resolving rawdeps. Among other things we also take into account static dependencies of the file resources in the components as well. That’s for another time.
P.S.- if you have an eagle eye you'll find a few components actually have rawdeps on REGISTRY Keys. Cooking against Registry keys, interesting concept, no? If you're the first to find one of these components, I have something for you.