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

Update VHD_WIMBOOT Version 2.4

- Added VHD Info button - gives Info on which WIM File is connected to selected VHD File

This Info presented in file makebt\wim_info\vhd_info.txt is quite useful and helps to recall which VHD and WIM belong together   

The Info corresponds to WIM File path as given in the VHD file  \System Volume Information\WimOverlay.dat

More Info here: http://reboot.pro/to...n-vhd/?p=210594

and here: http://reboot.pro/to...n-vhd/?p=210751

and here: http://reboot.pro/to...n-vhd/?p=210771

In the program: After mounting VHD as drive V: then fsutil is used in admin command window

fsutil wim enumwims V:

makebt\wim_info\vhd_info.txt

fsutil wim enumwims V:  gives:

VHD File  Q:\W10x64_NL_3.vhd  Mounted as drive V:  is connected to WIM File:

   0 {819CE4FD-30A7-9816-8B99-E9C46207A274} 00000001 Q:\Wimboot\W10x64_NL_3.wim:1
Wim State:      SUSPENDED

Objects enumerated: 1

=

Download:  VHD_WIMBOOT

== ==

 

My dear Wimb and everybody else,

I dont wanna be a stickler or a stick in the mud, but there is a twich on my shoulder that I would like to get rid of: more often than not, I happen to be unable to boot off the vhd that I have just applied the wim to, which is a copy of the vhd I am currently on ("cant find \system in registry" it says on the bootscreen); but if I do it reverse, the other way round, meaning booting off the unsuccessful one and try applying the wim to the one I am currently on (copy it, reboot off the copy and apply the wim on the original one), it boots off like a charm --> rephrasing it, if a is c:\ and b is h:\, failure; if b is c:\ and a is h:\, success - why so?

@antonino61

You should NOT copy VHD, but instead let VHD_WIMBOOT APPLY the WIM File to New Created Or to Existing VHD

Copy of VHD will lead to disk signature conflicts.

Also of course for CAPTURE and APPLY the OS inside VHD should not be running.

You have got to boot with Other OS Or PE in order to do CAPTURE Or APPLY on VHD.

thanks for the info, wimb. a few days ago I actually decided to let wimboot apply the newly-created wim afresh by leaving the vhd hatch empty. then again, it did work from one "copy" (probably the original) but did not from the other (probably the actual copy), which seems to be in line with what u have just said. I keep one copy to work on the vhd from the outside (as h:\, not c:\). it is handier to make on-the-fly tries and experiments than resorting to a wimpe usb drive. it would be all the more convenient to keep track of which is the original and which is the copy though. As they both work, I tend to forget which after a few days.  

Long Live the Flying Dutchman!!!

I can never stop repeating this tribute to an individual who might as well be too pragmatic for a philosopher or not so technical for a a scientist, as the pundits here would suggest, but with the synergy and help of other individuals here, I can say that he definitely contributed to changing the windows philosophy.

nino

I can never stop repeating this tribute to an individual who might as well be too pragmatic for a philosopher or not so technical for a a scientist, ....

Well, he may also be very, very shy, and you may be thus making him blushing ....

Wonko

No blushing!!! This is the Wimboot Era!!! A transitional era, but still an era!!! WIB, it is a transitional era that has so far proved to be perennial - I haven't booted conventional windows in years!!! and I do not think I am the only one.

nino

Update VHD_WIMBOOT Version 2.5

- Added exit in DiskPart scripts (sometimes script would not close)

- For VHD / VHDX on Internal GPT Drive, Use in Boot Manager entry Drive Letter instead of locate (otherwise reboot could fail to display Boot Manager menu)

Download:  VHD_WIMBOOT

Update VHD_WIMBOOT Version 2.6

- wim files Captured with WinNTSetup4 can be used

Download:  VHD_WIMBOOT

Hi wimb, thanks for yor new version, keep doing this good work my friend.

Just downloaded your new version, haven't tested it yet, but noticed your VHD_WIMBOOT.pdf is from July/14th/2019, in order to help not advanced users, I think it is a good idea to uptate it to include WinNTSetup new features and how they can be used in your program.

I hope you don't mind, I compiled the VHD_WIMBOOT_x86.exe to make things easier for other readers who may need it (attached).   Any virus warning is a false positive as usually happens with almost all AutoIt *.exe

Just extract VHD_WIMBOOT_x86.zip content on same folder of VHD_WIMBOOT-26.

alacran

thanx to both wimb and alacrán,

I am gonna try it and let u know too.

In the meantime, one more question for both of u, hoping not to run into an off topic. As I have just run across ccboot and read about the main uses of it (server and client(s)), I was wondering if ccbooting wimboot (vhd+wim combo) on a single standalone pc could be done and be of any help in terms of speed, time and persistence. what do u guys think?

@alacran

The new features of WinNTSetup4 are indeed very interesting and it is worthwhile to Update the VHD_WIMBOOT PDF Manual

VHD_WIMBOOT_x86.zip Addon for VHD_WIMBOOT is removed immediately by Windows 10 Defender.

So the download VHD_WIMBOOT_x86.zip Addon is only useful when you switch off Defender

@antonino61

I have no experience with ccboot , so I have no idea yet about it ....

@wimb

@alacran

VHD_WIMBOOT_x86.zip Addon for VHD_WIMBOOT is removed immediately by Windows 10 Defender.

So the download VHD_WIMBOOT_x86.zip Addon is only useful when you switch off Defender

 

Ok, now I understand more clearly why you didn't include it in your download, I never noticed that problem since I allways have Defender dissabled.

alacran

Update VHD_WIMBOOT Version 2.7

- Auto Mount of Hidden EFI drive so that it is selectable as drive Z: which is useful to install vhdx on Internal UEFI GPT SSD for booting in WIMBOOT mode

- The selected Boot Drive of USB disk with MBR partitioning is always Set Active when making boot entries for BIOS mode booting with Windows Boot Manager and Grub4dos Menu

- VHD Info and WIM Info visible in Notepad process is kept alive and allows to continue with VHD_WIMBOOT program

Download:  VHD_WIMBOOT

thank u wimb for what u do for us

Update VHD_WIMBOOT Manual

Download:  VHD_WIMBOOT

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

so u merged gimagex, dism tool and wimboot tool into one tool! Attaboy! The Syncretic Flying Dutchman Strikes Again!

so u merged gimagex, dism tool and wimboot tool into one tool! Attaboy! The Syncretic Flying Dutchman Strikes Again!

@ antonino61

JFYI

I'm not trying to disrespect your enthusiasm but there is not gimagex or dism on this program, all capture and apply is made by means of wimlib-imagex from Erick Biggers.

@ wimb

Congratulations for this new idea, it makes the program more versatile, keep the good work.

Your friend

alacran

thanx for telling, but I really meant gimagex or anything else with like function; consider it a more precise synonym for dism tool (so I really meant some imagex or other). alacran had already told me wimlib imagex was therein, now that I remember correctly.

BTW, two doubts I wanted to talk 2 u about wimboot (I have also tried the newest version today):

1) the most space-saving version of wimbootcompress.ini, both wim-wise and vhd-wise, for local hard disk deployment (no usb) - I have already posted what seems to me the most "reliable" one:

1) You are focused on space-saving, whereas my goal is to have a Portable Operating System booting as FILEDISK from USB on various equipment.

It will be clear that my goal is not obtained with your WimBootCompress.ini,

while your goal to boot as RAMDISK with a small size VHD of 3.9 GB is also possible with WimBootCompress.ini as supplied.

I am looking for a reasonable compromise with best performance in all cases.

2) The FILEDISK/RAMDISK combo-box serves just as an easy way to get optimum settings for VHD Size and VHD Type (Fixed Or Expandable) for booting as FILEDISK Or as RAMDISK.

A given Preset does not mean that the other boot option is not available. Both Boot Options (FILEDISK Or RAMDISK) are always available, but not always as useful for the settings used.

My dear Wimb and, for that matter, all other ppl of good intellect and understanding, 

I feel the urge to say what has ailed me for the whole day. I have tried almost all options (wimbooting and non-wimbooting virtual disks of all sorts of sizes and types (filedisk, ramdisk, vhd, vhdx, fixed, expanding)) on as many as 3 versions of g4d (the nvme/ahci-intelligent one 0.45, the most popular one out here 0.46 and the latest one dated 28.10 (still 0.46)) - one does a but not b, another does b and c but not a, and yet another does a bit of a, b and c. Jokes apart, I believe wimb et al. are at pains trying to improve tools and compression rates, me I am at pains testing the best one FOR ME, I admit it. I even went so far as to launch 7gb standalone nonwimbooting vhd on the first g4d, the intelligent one, but the solution that I consider the best SO FAR is Wonko's the smallest the best, because with my architecture there is no need to improve on speed to the detriment of smallness. If the 3 versions of g4d were "totally interchangeable" or if the next G4D encompasses all features that we need, of course this report would/will not be the same, and we would/will also get somewhere in terms of putting all our efforts "on the right path", but so far there has been no right path. or there probably have been too many of them. 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

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).

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).

No.

wimlib as used in VHD_WIMBOOT is more useful for wimboot Capture and Apply than dism.

wimlib Capture will replace the Windows\System32\WimBootCompress.ini file so that the WIM file contains WimBootCompress.ini file as supplied in makebt folder.

That is needed to allow grub4dos booting VHD from RAMDISK and it allows to make Portable Operating System having uncompressed drivers instead of WOF pointers.

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.  

here is my wimbootcompress.ini