,
11 tweets,
3 min read
Read on Twitter
Here we go
Build 18917 shows first signs of Microsoft's work towards separating the base OS and the shell when it comes to standard desktop Windows
The build introduces a new component called the "Shell Update Agent" which is capable of obtaining and updating the shell on demand
Build 18917 shows first signs of Microsoft's work towards separating the base OS and the shell when it comes to standard desktop Windows
The build introduces a new component called the "Shell Update Agent" which is capable of obtaining and updating the shell on demand
Features associated with this new mechanism call it the Undocked Shell, the first time we've seen "Undocked" in feature names was when Microsoft decoupled the Search and Cortana experiences
As of right now, there is not much to see. The Shell Update Agent comes with some preconfigured values which reference components that don't yet exist. See screenshots for the values & their location 
Seeing Package Family Names suggests that the shell will indeed be a separate, packaged component. In theory, you could ship the whole thing inside an Appx. However, don't get too hopeful (at least not yet), the publisher ID you see here [cw5n1h2txyewy] is used for non-Store apps
One fun tidbit: You can see that one of the strings rests in a key called "Retail." If you suspect that it checks more locations, congrats, you're correct. The Shell Update Agent is capable of querying an "Internal" shell as well.
Another interesting thing related to the shell: It appears that Microsoft is silently working on replacing the current Settings Sync implementation with a new one. The new one should support syncing more advanced and previously "legacy" options such as File Explorer configuration
Build 18917's Explorer also seems to update your Pins to a different/newer(?) format
Action Center seems to be among the first few things that even current builds try to source from a Shell package if available. In case something feels off about AC in future builds, this might be why
Related to this:
To contradict myself (because why not)
Even though the current package IDs use the non-Store publisher ID, the Shell Update Agent does indeed contain functions that can obtain a package using Store APIs
Makes you wonder where this is headed
Even though the current package IDs use the non-Store publisher ID, the Shell Update Agent does indeed contain functions that can obtain a package using Store APIs
Makes you wonder where this is headed
Turns out calling ShellUpdateAgent's StartInternalPackageAcquisition function does do something
The UX package got magically installed, sadly just a placeholder for now though
The UX package got magically installed, sadly just a placeholder for now though
