yes, perfect, everybody has their own priority, but I still do not understand the advantage of having the loading-of-c:\-as-a-filedisk in g4d's charge, when bootfiles could be created on the host drive and inside the vhd for booting smoothly thru bootmgr.
bcdboot c:\windows /s c:
and
bcdboot c:\windows /s d:
like this, u would have no persistence problems.
having g4d load the vhd as a filedisk is something I have tried just for the fun of it, but whatever software installation I tried would never be retained.
so I limited myself to using g4d only for ramloading, and of course I could not expect any software installation to be kept across reboots.
As for the windows updates, I do not think it matters to the system whether the files and folders are really on c: or elsewhere, as long as the junction to c: is there to guarantee the logical position the sofware expects to find whatever in.
Regarding a secondary vhd to be loaded which would contain the "non-core" part of windows (all the stuff we have moved off of c:\ in the previous examples) would the routine have enough time to recognize this second vhd as a useful volume (say d:, as in the examples) that the c:\ junctions point to, and safely continue the routine toward the windows interface? if so, is it any quicker than leaving the non-core stuff "unincapsulated" on the host drive?
The idea of having a vhd instead of a plain disk is that it could easily be preloaded into ram, because it is a file to g4d.
now, the substantial breakthrough, as wonko puts it, would be to see if other stuff could be moved off the c:\ vhd to make it even smaller, not only in terms of preramloading times, but also in terms of quick booting and neat working, as it would only keep the files and directories windows expects to find exactly there during the boot process. then again, let us make an example, along with all those subfolders from the windows directory, i might as well try moving the windows\inf directory to d:\ and junction it to c:\. when I reboot, windows might (and surely does) need a file from this directory - there is a junction to c:\ of the d:\windows\inf, but windows does not see it because it knows nothing of junction at that very stage, so to windows the inf folder is at that time inexistent. the other junction folders do the trick just because the system does not need anything in them at that very stage, but later on, when it has already learned of their existence thru acknowledgement of the junctions that make files and folders logically appear on c:\ event though they are on d:\.
Now if we had an exact or near exact list of the files called by the system in windows and windows\system32 during the bootup routine, we could tailor the c:\vhd more precisely to suit windows' bootup liking and have a much lighter vhd. this is strictly necessary before arriving at an up-and-running session with the windows interface on. once windows gets to that stage, almost everything can be placed anywhere.
Sorry about my logorrhoic accounting.
Edited by antonino61, 12 February 2019 - 12:06 AM.