The classic approach to adding an app (not "portable") in Winpe:
capture changes in files and hives generated by installing this app
Why this approach?
the main reason comes from the use of a "builder" for winpe. It is a construction that follows the same logic of that of the ADK.
A package (whatever the name of this data set) contains all the necessary elements (files, keys, computer processing (like some OC in ADK)) to add to a boot.wim
The "builder" integrates this package into boot.wim according to its specific logic.
Logic can be described as follows:
In active winpe, capture changes.
Create the package from the modified and collected items
create the "builder"-specific treatment
Benefits:
The package is built only once and made available to all users of the "builder"
The package becomes one option among others that the end user of the "builder" can select
One drawback:
you have to redo the package for each new version of the app
My opinion : it's the only one good solution for who use a "builder" like "winbuilder, WiMbuilder2, Pebacker...
But i don't use any builder and i play with Winpe. I think i'm not the only one. And i want to stay "agile".
Question to get out of habits:
In the case of an application that will be used very very rarely and that does not interest many users, it seems to me uneconomical to create such a package that requires a pretty big job sometimes.
What other solutions are being considered?
I see at least 3 possibilities depending on the needs and desires to discover new approaches
1- "writers filters" as in small PC wyse or competitors (a technology I encountered when I was working on PC virtualization projects)
https://docs.microsoft.com/en-us/windows-hardware/customize/enterprise/unified-write-filterhttps://docs.microsoft.com/en-us/windows/win32/search/-search-ifilter-registering-filtershttp://woshub.com/using-unified-write-filter-uwf-windows-10/I don't know if all the developments are available or if they could be adapted for Winpe
"Unified Write Filter on Windows 10" seems to be a good way.
I'll try it if my mind stay agile.
2- a capture (global or targeted) and then an injection into the envelope of an inactive system: certainly possible
capturing all or part of the system is done on the active winpe system
injection will be done later but with the inactive system
it seems to me that it is a long process, but in the case of multiple installations at the same time ...
3- Take advantage of the context "Winpe in Flat mode in a VHD":
it leads to bypass the winpe limitation without becoming outlawed
Note: MS limitation is normal. It's commercial protection. Linux is free and often a good solution. But i play this MSDOS 2.0 since 1984
The method is simple:
save 2 files when the system is active
inject these 2 files into the inactive system
an advantage: 3 minutes for a technician
disadvantage: it applies in the unique context following "Winpe Flat mode in a VHD"
(Flat - NON-RAM according to the new terminology of MS that speaks almost in French!)
the big drawback:
this manipulation is impossible for a non-technical end user
As i said in an other place, i use this method for injecting a full graphic drivers ( update from devmgr.msc in a winpe and take needed files on a disk), for installing virtualbox 1.6
That's it, I don't have anything to sell, But I don't often see that solution covered.
Only tro share information !