Futuristic concept- Delta Commits and RAM Sandboxing

olivered

New Member
This is a bit of an odd feature idea-
It’s more of a total overhaul of the way something is done rather than a suggestion.

let’s say instead of writing edits to the original WIM via the temporary folder, somehow you worked some serious voodoo out and made it so that those edits are instead committed to their own directory tree which can be merged with the main WIM. Something like what SHADOW DEFENDER does- the files appear to be committed to the original folder, but in reality they are in memory and sandboxed.

DISM ~> save to wim behind the scenes creates a new wim from the files in memory, then a subroutine compares the two WIMS and creates a delta between them, and then the delta is written OVER the wim on disk, but only the delta is written. this could be much faster than the way it is done and the faster the machine is the greater the benefit. No wim is ever then ever written to or “mounted” by dism- only extracted and re-created.

secondly to this but drawing on the core functionality, when installing updates to an image, currently i assume this uses a built in functionality to do it the microsoft way. I propose that again the edits be committed to a ram disk so that each update installs over the previous updates, but only after the process is finished do the finalized files commit to the on-disk temp folder : write once; edit multiple.

less of an issue now that we have SSD’s, but it opens the way for deeper and more competent forensics and editing and reduces the wear on the drive, in addition
to being much faster.

Let’s say you removed a component from the WIM, and now you want to install updates without re-integrating it. NTLite could flag files relating to removed components so they never even get written during the update process.


Let’s say you want a list of all changes made by an update and you want to flag certain file changes, even if it’s only a byte or the sum that changes, as interesting. and you want ntlite to provide you with a copy of the old file and the new file. You could then develop or use a tool to automatically extract and diff the assembly between the files.

Let’s say you want to preserve a functionality that microsoft removes with an update, and keeping it won’t break anything, just their intentions.

let’s say it’s 2022 and microsoft wants to ship an update that bundles necessary changes with nagware files to upgrade to windows 12.

Modifying how all of these examples are processed doesn’t require modifying how updates are installed, only applied.
 
another way this can be used is to port on-demand features between windows editions that are capable but don’t include them, like games from desktop to server. for the sysadmin in all of us.

files and edits could be extracted as featureset.buildnumber.deltax(5mb) along with a depends.xml that describes what components must be present for it to work,
and installed to any windows with an identical build number.

Obviously this does not include ADDING edition features specified as exclusive to that edition like changing the kernel or other capabilities, only things you can configure via on-demand.
 
Last edited:
Back
Top