VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD

and what u just said is the cause for my wimboot capturing and applying not working and my dism capturing and applying working - i don't mean to contest u, i simply mean that there must be a reason for the earlier not working and the latter working here, don't u think?

 

my wimbootcompress.ini is almost bare and it works; dism does take it into account and your wimlib does not, apparently. dism here yields a slightly bigger wim image (4.1 instead of 3.99) and allows for a better compression of the related vhd and boots ok. at least here the wimboot tool yields an incomplete vhd (for example, nvidia control panel missing from taskbar) which boots erratically.

 

of course, if there are any technical errors in the bare character of my wimbootcompress.ini, I am in no position to say. I can only state what happens here.  

But have you tried the former with the old version attempting to create a bigger vhd and a smaller wim re-applying the latter with the newer approach?[1]

Wonko

[1] You see , I am perfectly capable of writing incomprehensible and meaningless blurbs, but usually conversations - particularly on technical matters - require:
1) clarity
2) exactness

both completely missing in your late posts.

I understand you did a lot of experiments, but unless you detail, exactly, what you did and report, again, in detail and exactly the results, noone will be able to understand you, let alone try and assist you in finding the mistakes (if any) you did or suggest better or alternative methods/tools.
 

wonko, you are talking of a bloody wim and a bloody vhd, expecting einstein-like clarity. pls. what do u expect to happen from a capturing of a system into a wim image and a consequent applying of the image into a wimboot vhd? the consistence (or consistency) which anyone would, that is to say what u find in the integral vhd logically matching the wimboot vhd. if the latter has less than the former in logical terms (of course not in physical ones, the wimboot vhd is rightly smaller) in one case and exactly the same as the former in another, this is enough of a difference - it means one tool does let u have the same content (still in logical terms) and the other does not (still in logical terms) - what other information do u need to understand? Anyway I think u missed exactly what u consider detailed - my wimbootcompress.ini content, which I apparently posted later than u replied.

Wonko, u dont detest me, u just loathe my wording.

Sure I don't detest you.

I simply hate (personally) your use of abbreviations, often unmotivated, such as "u" instead of "you", or confusing, like having in the same sentence g4d, G4D and 4gb[1] and the lack of [CR+LF] or newline after the full stops (or periods) to parse easily sentences.

But I am not an English professor, let alone a literary critic, and, as long as the contents are understandable, all that is fine.

When the overall meaning of a post is undefined, unreferenced, apodictical or vague (and possibly also "wrong") there it starts the issue, like:

At least here, dism tool appears to be the most coherent tool for faithful capturing and applying, even if the wimboot tool deems it incompatible, or not so compatible (but then it does the wimboot job ok).

and, when Wimb noted the inconsistency, your original reply (not that after the added info it is much better as you added 1 (one) piece of info), your 

and what u just said is the cause for my wimboot capturing and applying not working and my dism capturing and applying working - i don't mean to contest u, i simply mean that there must be a reason for the earlier not working and the latter working here, don't u think?
 
my wimbootcompress.ini is almost bare and it works; dism does take it into account and your wimlib does not, apparently. dism here yields a slightly bigger wim image (4.1 instead of 3.99) and allows for a better compression of the related vhd and boots ok. at least here the wimboot tool yields an incomplete vhd (for example, nvidia control panel missing from taskbar) which boots erratically.
 
of course, if there are any technical errors in the bare character of my wimbootcompress.ini, I am in no position to say. I can only state what happens here.  

is assuming that everyone else know exactly which EXACT command(s) and parameter(s) you used, which EXACT source, which EXACT settings, etc., etc., i.e. the "standard litany":

https://jdebp.eu/FGA...ard-litany.html

We are in the (unpleasant) phase of "forcing everyone to spend one or more rounds of communication back and forth simply trying to wring the relevant information out of you".

You may have been doing this unknowingly, now you have been told.

https://jdebp.eu/FGA...oolishness.html

Wonko

[1] it's ok, because you later mentioned 3.5gb and 0.5gb

 

as for 3.5 i dont know where u got it from. 

It is a pity not to invest further time and energy on a faultless 4gb version of windows. yes, 3.5gb for the wim and 0.5gb for the vhd (well, lz4'd, of course), but still nice, small and faultless, with all comforts. Now let us see if we are able to put our eggs in the right basket.
nino

You are welcome, I am sure .

Wonko

Wonko, that was on a previous post, 3 or 4 wim+whd combos ago

I have made in about 7 minutes a Win10XPE WIM file based on 1909 version of Windows 10 x64

Capture and Apply of WIM files with VHD_WIMBOOT is much faster in Win10XPE environment as compared to Win10 x64 environment.

==  ==  ==   

EDIT:

The Windows Defender in Win10 x64 OS environment slows down the Capture and Apply of WIM files.

After swithing Defender Off then Win10 x64 OS results for Capure and Apply correspond quite well to Win10XPE x64 environment.

Thanks to ReTokener for indicating that defender might be the reason of the 4x higher Capture time in Win10 x64 OS environment. 

Wonko, that was on a previous post, 3 or 4 wim+whd combos ago

It was 6 (six) days ago, and exactly where you seemed to start "going astray" (we use days as a unit of measure of time, not unreferenced wim+vhd builds), I expressly said "late posts" at a time where that post was your third last post.

Capture and Apply of WIM files with VHD_WIMBOOT is much faster in Win10XPE environment as compared to Win10 x64 environment.

Only to understand, is the Win10XPE also 64 bit or is it 32 bit?

Wonko

Yes, I can confirm making a capture/apply with DMS (Dism based) or a capture/apply with wimboot-clc (wimlib-imagex based) is faster from Win10XPE_x64.wim than from the full OS Win10x64 but in my case, I have been using 10 v1809 as OS and also as source for the WinPE.

Also for capture wimlib-imagex is faster and with small size of captured file at same compression level, the oposite happends during Apply the image, in this case Dism is faster, my scratch folder when using DMS during capture or apply from WinPE is always on a dir on phisical HD, I really don't know if this can make any influence  but just in case.

alacran

Only to understand, is the Win10XPE also 64 bit or is it 32 bit?

Win10XPE is made from ISO file Win10_1909_English_x64.iso

Booting with Win10XPE x64 WIM file size 867 MB installed by UEFI_MULTI as boot option on Internal SSD

is extremely fast - loading into RAMDISK in 3 seconds and total boottime 30 seconds.

Here are some measurements all based on Win10 x64 1909 and using VHD_WIMBOOT (=wimlib) in WIMBOOT mode

In Win10XPE x64 environment - wimlib Capture 150 sec and Apply 41 sec

In Win10 x64  OS environment - wimlib Capture 605 sec and Apply 60 sec - defender on

In Win10 x64  OS environment - wimlib Capture 150 sec and Apply 45 sec - defender off

EDIT:

The Windows Defender in Win10 x64 OS environment slows down the Capture and Apply of WIM files.

After swithing Defender Off then Win10 x64 OS results for Capure and Apply correspond quite well to Win10XPE x64 environment.

Thanks to ReTokener for indicating that defender might be the reason of the 4x higher Capture time in Win10 x64 OS environment. 

wonko, I sometimes try 3 builds a day, while others 2, while others yet I keep 1 build for months. anyway u have good reason to trust or distrust whom u like to. I suggest u be more stochastic, but what can I do if u choose to be pseudo-deterministic. u miss out on a lot, believe me, but all in all, have it ur way.

 

wimb #161

In Win10XPE x64 environment - wimlib Capture 150 sec and Apply 41 sec

In Win10 x64  OS environment - wimlib Capture 605 sec and Apply 60 sec

could the capturing time be influenced by defender?

could the capturing time be influenced by defender?

You are right 

After switching off Windows Defender, then in Win10 x64 OS environment - wimlib Capture 150 sec

So the difference in wimlib Capture time is totally due to Defender 

could the capturing time be influenced by defender?

You are right 
 
After switching off Windows Defender, then in Win10 x64 OS environment - wimlib Capture 150 sec
 
So the difference in wimlib Capture time is totally due to Defender 

I can confirm that capturing with dism yields more consistent results than capturing with wimboot, at least here, have tried it again today. I would like to remind u all that my wimbootcompress.ini is almost bare, but still I do not see any difference in the results of the applying stage. No need to specify any further, unless otherwise asked, not unless otherwise pontificated against. I am still baking the consequent vhd. consequent means that it was caused by all the previous work that's is required; this further specification is purely ironic.

Well, done, I can only corroborate what I said in my previous post. 3.9gb wim + 576mb vhd (lz4'd to 73mb) combo. here are the steps I have taken:

1) launching lzx.bat on my latest integral vhd os (whichever it is, it is the same all the way down the line, so it is intrinsically scientific);

2) restarting in order to make the effect of the overall compression settle into a workable deployment;

3) shrinking the vhd to the smallest workable measure, thus leaving 1.5gb free space for an overall vhd size of 6gb;

4) resizing it with vhd resizer;

5) making a copy of this vhd and capturing it with Dism tool (lzx) - the same with wimboot tool yields erratic results, today again;

6) optimizing the resulting wim (lzx:800) - it is the most extreme level that gives a substantial gain in space (no sense in trying any greater level);

7) now and only now using wimboot tool to apply it to a wimboot vhd (1gb, the least allowed by the software);

8) restarting with the original integral vhd (the one in 3 and 4);

9) launching lzx.bat on the wimboot vhd (the 1gb one)

10) restarting with the wimboot vhd in order to make the effect of the overall compression settle into a workable deployment;

11) shrinking the wimboot vhd to the fully smallest workable measure (579mb to be precise);

12) resizing it with vhd resizer;

13) launching lz4 compressor tool on it (parameters -150 --content-size, the best I could find) --> 73mb lz4 file

14) everything working ok (no free-space bulging, no issues).

BTW: I repeat, my wimbootcompress.ini all over the places (folders) concerned (system32, syswoa or whatever it is called and wimboot makebt:

hope this is enough info now, but if it is not, i am willing to provide - no sense in ruling it all out, what good will it do?

@ wimb

Update VHD_WIMBOOT Version 2.8

 

- Added WimBoot Mode checkbox - when unchecked it enables Apply of Full Windows in VHD instead of WimBoot Mode

 

Download:  VHD_WIMBOOT and

 

If I may make a suggestion, with this option available now, it will be good to add an option to instal in Compact mode, available options on wimlib for compact mode are 4K, 8K, 16K and LZX.

4K is the default used by MS on Dism (and also on wimlib), and using this compress level the OS automatically compress all new info added (as far as it is compresible), as drivers, documents, or any other file/folder that has changed from its initial state.

If using a higher compression level the OS will not compress the added or modiffied files/folders automatically, the user then has to do it manually if desired, but running your WOF_Compress may do it safely using JFX WimBootReCompress.ini

The Compact mode can be used on fixed and expandable VHDs, and using both together I made manually (using wimlib-clc) on September a 10x64-EC4.vhd (Expandable, Compact 4K), max expanded size is 7 GB, used space is 4.57 GB and free space is 2.42 GB as you can see on attachment, in order to make the install minimal no additional drivers were installed, only Office 2003 + Compativily pack for Office 2007 and higher, and a few other programs as CCleaner and Defraggler, all other programs are portables located outside of the VHD on the root of the storage device.

If using Compact mode LZX (WIM files default compression) the expandable VHD size will be close to the size of the WIM used to install it, but as said before the used space will increase during use (but as also said can be recompressed when requiered), havent tested Compact LZX myself, I prefer to be conservative and use 4K and let the OS do the task, it is good to run from inside de VHD CCleaner to clean all garbage files and Defraggler to defragment the OS (preferable on a HDD) before copy it to our SS device.

As you already have a check box to select LZX and Compact 4K is default if giving only this 2 options you will need to add only a check box for Compact on the program screen (of course after making all required code).  8K and 16K do not improve very much the saved space, maybe only about 4 to 7 % more saving than 4K respectively, depending on compressivility of files/folders), LZX is the best on reducing used space (can't give a % as haven't made an install this way).

Hope this suggestion helps improve your great tool my friend.

alacran

@antonino

The procedure seems rather complicated and the extreme reduction in VHD size seems unneeded for your fast computer having 64 GB RAM.

@alacran

Compact Mode can be added to the program, but WIMBOOT remains the more interesting option.

Conversely, if I occupy a lot of ram with a bulky vhd, chances are I run out of ram in heavy tasks.

Don't forget I devote some of the ram to pagefile.sys and temps, so as to have the system have as little impact as possible on disks.

Just Read ur links, no apparent issues of the kind

@alacran

Compact Mode can be added to the program, but WIMBOOT remains the more interesting option.

Hi wimb, I'm agree WIMBOOT is the more interesting option.

JFYI new experiment:

10x64-FCL.vhd (Fixed size, Compact LZX) made with wimlib-clc, 5.5GB, 3.57 GB used and 1.93 GB free, the mother WIM file is 2.90 GB.

Not booted yet.

alacran
 

talking about pagefile in ram, wonko, it is just for the software that still believes it needs it, although only nominally. Chances are the system likes to believe there is one, even though it is of little or no value. in fact, it was not I who decided upon its size, it is system-managed on that "drive" (drive z:\, for that matter). one might as well forget it exists. just try it on a 64gb ram system, if u dont believe - negligible impact or no impact at all, or anyway less impact than its absence. as for the very heavy tasks, it is enough for u to think that a big *.rar file exhausts all the memory I have if I try picking its content with the mouse and drag it anywhere out, ending up not completing the task, whereas everything ok if i unpack it by clicking on extract. so first try it and then frown, if that be the case with a situation that wants frowning.