What could be the benefit to backport Component-Based Servicing (CBS) to Windows XP and Windows Server 2003?
Well you would replace Windows NT's Optional Component system with a more modern one that is perhaps more akin to the one found in Vista/modern Windows. Things like Windows Embedded Standard 2009's Target Designer would not be needed for extreme customisation of a target Windows image anymore (things that you do with dism nowadays, also I do not nLite for reasons I might go into sometime later). Furthermore, while you are already migrating Windows NT's Optional Component system to a more modern one, you could make things like Internet Explorer, Windows Media Player, Windows Media Center, Tablet PC, Messenger uninstallable by the new component management system. Also such a system should be implemented in a way that does not interfere with Windows File Protection and these component management programmes should use as little external dependencies outside the Windows APIs as possible, so the choices for programming languages for building that would maybe be c, c++, legacy versions of rust or go, so good luck with that.
For me, Target Designer from WES2009 is the most flexible solution, for XP customization. I also use integration of other components by hand. I have build such image under 500mb and run successfully without problems and no WFP problem at all.
Indeed, there are two parts : - In one hand, there is the Offline management related to DISM/Panther/... with already existing great initiatives beyond .INF and the old i386 setup (.wim for XP, phanter setup, ...) - In the other hand, there is the Online stuff related to Windows NT's Optional Component system (sysocmgr, ocsetup, ...) The link between both parts could have been implemented by a DISM provider (for CBS). The parallel evolution of Windows Embedded tools over Windows versions is somehow also a demonstration of this convergence between Offline and Online. LH pre-reset builds could be worth to look at. I guess adopting a top-down approach (starting with high level "feature" like Notepad or Calc) would avoid a lot of difficulties. For Offline, I wonder if a DISM provider (existing to be written) for managing .INF, extracting metadata and generating feature and package descriptions for .WIM images could not be considered. Another source could be to generate this from the Windows XP embedded database. For Online CBS experiments, perhaps the easiest path would be to start using ReactOS.
I'm working on it. It's based on Longhorn 5048. Things I have done: 1. Implement CBS-based executables on 2600/3790. 2. Replace oobe folder in system32 with 5048's. 3. Add required hal DLLs and kernel executables. 4. Replace existent components with 2600's ones recursively to \build\filerepository folder. 5. Make WinPE working, 5048 PE + ramdisk. Normally boot.wim and install.wim are in the same file before 5098, however I've sucessfully separated them. 6. Capture both boot.wim and install.wim with Ximage v5112. Boot.wim has to be two indexes with flags 9 and 2 respectively. Both indexes can have the same image. Bugs: First boot cannot run \Windows\system32\oobe\setup.exe, saying user must be "Administrator" while UAC did not exist in XP/2003 nor 5048. Following reboots end up with Smss.exe BSODs. Spoiler: Screenshot Edit: I fixed the error by deleting NTUSER.DAT files in Documents and Settings folder. Spoiler: Loop