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

I believe (but I might be wrong) many of u are trapped in the assumption (very enlightment-like, theoretical, for that matter). that big systems do not benefit from space reduction so much as it is worth the trouble. Theoretically fine, but with the processors today, with the ram today, with the hardware today, why not take advantage of a neat system, leaving space for things other than the os itself, when somebody like me has never had so fast and responsive a system in years before the wimboot era? u think it is an arbitrary counter assumption on my part? fine if u feel better, but at least consider that here, a large non-wimboot system like a 6gb vhd with 1.5gb free space inside (slightly lesser than alacran's 1.9gb) takes paradoxically (only according to theory) longer to boot and operate than a 3.9gb wim + 570mb (lz4'd to 73mb) vhd combo. the tests have been carried out on THE SAME SYSTEM, i did not change hardware in the meantime. now if u tell me why it is so, I do not know. but this is not enough to make it not-so. I think it is because the wimboot combo is not so taxing on this architecture, but if u have another explanation pls contribute, I am willing to learn.

Compact Mode has a severe disadvantage and that is heavy fragmentation of FREE SPACE.

I show here the Drive Map of 4 different Modes:

WIMBOOT == Compact XPRESS 4K == Compact LZX == Full Install == Compact XPRESS 4K Expandable

==  ==  ==  == 

It is clear for me that Compact Mode is NOT the way to go, because of the heavy fragmentation of FREE SPACE.

Apply of WIM file in WIMBOOT Mode is so much faster than the other methods and it uses less than 1 GB of disk space 

Just to inform the 10x64-FCL.vhd booted very fine and only 9 files 16 MB fragmented = 0 %, then I copied WOF_Compress and some other files/folders to My documents and ran WOF_Compress, it said was saved 131 MB, running defraggler just to verify now there are 20 fragmented files, 20.1 MB  = 1 % fragmented, but I didn't fragmented it, it was really unnecessary.

Previous state before booting: 5.5GB, 3.57 GB used and 1.93 GB free, 0 files fragmented.

Just after booting: 5.5GB, 3.68 GB used and 1.82 GB free, 9 files fragmented 16 MB = 0 %

After copying some files/folders to My documents and recompress that folder: 5.5GB, 3.7 GB used and 1.8 GB free, 20 files fragmented 20.1 MB = 1 %

It is working better than I was expecting, I will run it for longer time and do some task on it, but I know Windows itself is very capable to create a lot of garbage, log files etc., there is no AV installed, Avast (about 300 MB a day on more than 500 sigle little files) and any browser depending on usage (I use Firefox) are also fantastic to acumulate garbage, but Chrome is a real champion.

My attached pictures don't look bad, the colors induce wrong ideas, check the numbers reported, also remember fragmentation affects rotational HDD, but on a Solid State device fragmentation means nothing.

Alacran

NOTE: Same WIM used an all cases.

Wimboot === Compact 4K expandable === Compact LZX Fix size

Of course if we are thinking in Rambooting the VHD, a Wimboot install on a fixed size VHD and latter LZ4 compressed is the fastest and the more saving space option, second best option is a Wimboot install on an expandable size VHD.

And if we make a FFU image of our Wimboot VHD we can rebuild it or create a copy lightning fast, same image is capable to be deployed on fixed or expandable virtual disk, as I have tested.

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.

The whole point of the given links is about the fact that it is entirely possible to run Windows WITHOUT a pagefile at all, PARTICULARLY if you have an insane amount of RAM (such as 64 GB), BUT a number of programs (a known one is Adobe Photoshop) will REQUIRE one.

Since with that large amount of RAM then pagefile will never be hit, it is PERFECTLY OK to make a small one 100 or 200 MB on a "conventional" disk or SSD without ANY impact on performance, only to allow those programs requiring it to run.

Then, having a pagefile in RAM is ridiculous (said by Mark Russinovich, likely the world most knowledgeable person on Windows internals) and - said by a much less knowledgeable person (yours truly) it is also ridiculuous:

1) to let it be managed by windows
2) to have it of variable size, a FIXED size, determined on the specific system, is the right choice

See also:

https://blogs.techne...virtual-memory/

You cannot waste 4 GB of RAM (actually you can ) but then you cannot nitpick on 1 GB - more or less - for a .vhd or .wim size (out of 64 - sixtyfour! - GB of RAM) .

BTW, and as a side note, having a pagefile any smaller than size of RAM + 256 MB won't normally allow to have a full crash dump when/if needed (and good luck interpreting a 64 GB crash dump ) BUT one of the very few improvements that Windows Vista brought (and not as reknown as it should be) is the possibility to specify a separate file for the crash dump:

https://blogs.msdn.m...em-memory-dump/

Wonko

My attached pictures don't look bad, the colors induce wrong ideas, check the numbers reported, also remember fragmentation affects rotational HDD, but on a Solid State device fragmentation means nothing.

File fragmentation is not the issue. The colors in the Drive Map give a good impression of FREE SPACE fragmentation which is heavy in case of Compact Mode.

NTFS Compression gives file fragmentation. Compact mode does not give file fragmentation, but it gives heavy fragmentation of FEE SPACE.

Compact Mode can be seen as an improvement since it does not give the file fragmentation like NTFS compression.

WIMBOOT is something totally different and in no way comparable to Compact mode.

In WIMBOOT mode we have an almost empty VHD related by pointers to the files in WIM archive.

Fragmentation of FREE SPACE as occurs in Compact mode makes it difficult (or impossible) to Create large unfragmented files.

After Analyse of Drive C: you can select the Drive map tab and then click in the Color field to reveal how bad Disk Usage is .....

I think it is preferrable to have as much as possible Unfragmented FREE SPACE available as is realised in the WIMBOOT case.

Also I think an Expandable VHD is good for fast loading into RAMDISK, where the VHD on expanding gives the desired free space.

An Expandable VHD used as FILEDISK will lead to fragmentation of the VHD file for a gradually growing content.

How come that your mother WIM file is 2.90 GB which is much smaller than WIM file Captured from fresh installed Win 10 x64 ?

... also remember fragmentation affects rotational HDD, but on a Solid State device fragmentation means nothing.

How about a 200mb pagefile.sys in ram? I do use Photoshop, the portable version

one more question before I try it, wonko. resmon.exe here yields

1) some space that is system-reserved  (grey), 

2) some space that is memory in use (green),

3) some space that is modified memory (orange),

4) some space that is standby memory (blue),

5) some space that is free memory (azure).

in copying big files from one place to another the orange one (modified memory) enlarges somehow - is this pagefile.sys or related to it? if it is, won't I cripple it if i constrain it to 200mb? and if I do, will this space be retrieved from the free space on the hard drive? this is my only perplexity in reducing the size of pagefile.sys.

one more question before I try it, wonko.

Life is trying things to see if they work.

wonko, ur dead rite - 1 second gain in booting. do u think 100mb fixed pagefile.sys would do too, considering photoshop? and if it would, why not 1mb?

wonko, ur dead rite

No.
I am right (by definition [1]BTW) and pretty much alive and kickin'  . 

 

do u think 100mb fixed pagefile.sys would do too, considering photoshop? and if it would, why not 1mb?

You see? ... give him an inch, he'll take a mile ...

Why not going all the way down to 4 KB [2]?

Wonko

[1] exception made for the rare cases in which I am wrong, ça va sans dire

[2] or some other very little multiple of it corresponding to the fastest transfer rate on your hardware, possibly 64 KB

ok gonna try it! BU&M, windows is a piece of butter, in the Italian sense, in order to be made so in the English sense. I mean, trying to trim it down as well, no office in the background, since I use portable (libre office), and sidebar, which i do not need, and security, defender and stuff it still retains in the background, I mean it could be skimmed any further, but as u say, with caution and only if one sees that it does not create more problems than it solves. the fact of the matter is that the debloating thing, does not debloat the system to the full, what it claims to debloat gets debloated only partially.

Coming back 2 u in a bit

a piece of butter in the sense that u can take out cortana and office, as i got good alternatives, but don't take out security, unless u want the piece of butter to become "painful". 64mb swap working ok but no significant gain compared to 200mb from 4gb. back to u in a bit.

ps.: sidebar ok to take out too

I'll tell u what - photoshop does not even require the existence of a pagefile.sys. so I got rid of it completely. It is my first wimboot combo without one. Thanks to wonko's tip, it's way faster. wonko is a wonderful advisor and lousy pontificator.

According to Microsoft the WIMBOOT feature isn't supported in Windows 10.

Nevertheless until now WIMBOOT was working rather well for Windows 10.

Version 1909 after Windows Update has Windows Explorer version 10.0.18362.449

For Windows 10 x64 version 1909 in WIMBOOT mode I observe that Windows Explorer is often not responding and we have a freezing Operating System 

Probably we may conclude that WIMBOOT is not working anymore since Windows 10 version 1909.

In WIMBOOT mode then Windows Explorer is especially sensitve to become not responding when clicking in the Search Box field

In normal mode I have no problem with Windows Explorer.

Bad news, sooner or later this was going to happen, only option remaining to have an small size portable OS starting from 10 x64 version 1909 will be Compact LZX.

Personally I like better Wimboot but this will be only option left on version 1909, unless keep using a previous version for Wimboot.

I have been testing a 10x64 1809 Compact LZX install on a 4.75 GB fixed VHD and still having 1.05 GB free including Office 2003 + Compativility update for v2007 and newer, (as newer versions of Office are too heavy), and all working fine so far, after some time of use the used size will grow, it is a sign that it is necessary to run CCleaner followed by your WOF_Compress and Defraggler, so far only ran this VHD as Filedisk.   But there is the alternative to Ramboot the VHD.

As the size is not excesive this seems as a good candidate for Ramboot, and I think any PC with at least 8 GB of Ram should load it without issues, and this will avoid the maintenance of the VHD, I will install SvBus driver and Compress the VHD by means of lz4_compressor to improve loading to Ram time as much as possible, and will let you know my findings.

EDIT: after using lz4_compressor the 10x64-FCL.vhd.lz4 is 3.34 GB, but I wasn't able to boot it on a 8 GB Ram PC, I got a grub4dos message: Selected item can not fit into memory

alacran

Hello wimb

Thanks for the note:

 

In WIMBOOT mode then Windows Explorer is especially sensitve to become not responding when clicking in the Search Box field

When trying to reproduce this, I noticed the search box refused input when searching in the same directory twice.

But switching to an other directory and back cleared the input field for a new search.

I recommend "Search Everything" for desktop search anyway.

Regards   T.

https://crackedhome.com

Crack torrent software is free here 

@alacran

As alternative for WIMBOOT we can use Win10XPE for booting from RAMDISK.

Also we can use a full Windows 10 x64 installed in 50 GB VHD as Portable Operating System on USB and booting as FILEDISK.

Nowadays portable SSD T5 of size 500 GB can be used to boot from USB with both options.

Install Windows 10 from USB after booting with WIM or VHDX

  PE  RAMDISK   ==   FILEDISK 50 GB VHD Win10 x64

== ==

 

@ReTokener

Everything - just for the record - is a good tool, but SwiftSearch IMNSHO beats it:

http://reboot.pro/to...y-that-is-fast/

and - in case - portable:

http://reboot.pro/to...essed-portable/

The whole point is that Everything indexes the volume(s) so not only it is a tadbit slower the first time you use it because it has to create the index file(s), but additionally  it needs some space to store the index file(s) whilst SwiftSearch, like similar NTFS only search tools, operate on-the-fly using the $MFT i.e. the already existing and surely (hopefully) accurate index file of NTFS.

Wonko

Wonko stated:

 

Everything - just for the record - is a good tool, but SwiftSearch IMNSHO beats it:

that depends on the point of view.

Unfortunately, SwiftSearch has no CMDLine option and can not be integrated into the explorer menu as a shell extension. this makes the handling (compared to "Everything's" context menu) more difficult and does (IMHO) not compensate for the speed gain.

Edit: let's say "Everything" : "SwiftSearch" - 1 : 1

I checked twice the "Search Box field - case"

My system configuration:

 

Wimboot-Win10Pro 1909 Build 18363.418
1.9GB used on 24GB Expandable VHDX (on SSD)
Defender disabled
OOShutup 1.7 "all settings applied"
no Updates installed.

Select "Computer" in Windows Explorer, writing "exe" to search box: first findings (green bar in adress filed) after ~7sec.

Select any folder with much executables: writing "exe" to search box: first findings (green bar in adress filed) after ~4sec.

Could not observe any severe delay this time (compared to yesterday's test) even after searching in the same folder twice.

Possible conclusion: the "Search Box field - case" might be resulting from software configuration and are not necessarily caused by wimboot.

Regards   T.

 error - ignore this

Actually there is command line in SwiftSearch BUT (unless it has been added in the meantime ) outputs need to be piped through FIND, FINDSTR  or Grep or similar.

See:

http://reboot.pro/to...-fast/?p=176858

But if you want/need a command line tool, there several ones, a few ones mentioned in the given threads, namely:

Ntfs-search

http://reboot.pro/to...lick-like-tool/

Tfind

http://www.deadnode.org/sw/tfind/

ndff

https://web.archive....u/en/index.html

https://web.archive..../0.9.6/ndff.exe

Wonko