Jump to content











Photo
- - - - -

Making the smallest Win10 install (Wimboot mode) on 512 MB VHD

wimboot ramboot

Best Answer alacran , 20 March 2019 - 11:53 AM

Well, I think now this thread has all info, I'm going to make a summary of all relevant post you need to follow to be able to Create and Ramboot from a Wimboot VHD and also how to make a compressed copy (to keep as backup) of the coupled files required to wimboot.

 

I started this thread thinking the smallest the best, and was able to run a 512 MB VHD, as the name of the thread says, but during the development of this thread I change my mind and decided that a 1.5 GB VHD is a good size to load a VHD in RAM on an acceptable time, and this size VHD is also capable to Ramboot on PCs with a minimum of 4 GB of RAM.

 

Introductory info and required programs: http://reboot.pro/to...hd/#entry209470

 

Making the VHD: http://reboot.pro/to...hd/#entry209472

 

Optionally apply unnatend.xml, services modifications and control Telemetry during install: http://reboot.pro/to...hd/#entry209480

 

Install your programs, SVBus driver and Capture Wimboot Image: http://reboot.pro/to...hd/#entry209483

 

Apply Wimboot Image to a 1.5 VHD: http://reboot.pro/to...hd/#entry209485

 

Installing your Wimboot VHD on a USB device and Ramboot: http://reboot.pro/to...hd/#entry209488

 

You may consider this as an Hybrid Ramboot: http://reboot.pro/to...hd/#entry209518

 

Selecting to use wimlib on WinNTSetup: http://reboot.pro/to...hd/#entry209568

 

What I put on my VHD: http://reboot.pro/to...hd/#entry209602

 

Improve Portability: http://reboot.pro/to...e-4#entry209809

 

EDIT: I finally found some info about the WimBootCompress.ini file located on WinNTSetup\Tools\, see: https://wimlib.net/f...wtopic.php?t=16

 

Custom WimBootCompress.ini: http://reboot.pro/to...e-4#entry209815

 

cdob comments: http://reboot.pro/to...e-4#entry209834

 

Making copies of coupled files (VHD + wimboot wim file) for backup pourposes: http://reboot.pro/to...e-5#entry209917

 

cdob suggestion for redirect on the VHD the path to source wim file: http://reboot.pro/to...e-6#entry209947

 

Custom WimBootCompress-2019-03-18.ini: http://reboot.pro/to...e-6#entry209949

 

karyonix suggestion for redirect on the VHD the path to source wim file: http://reboot.pro/to...e-6#entry209952

 

More cdob comments: http://reboot.pro/to...e-6#entry209976

 

Redirect the VHD path to wimboot wim file is finally a success: http://reboot.pro/to...e-6#entry209979

 

NOTE: When relocating the files, edit the BCD(s) may be required, better check to be sure all will work fine.

 

EDIT: If for any reason you want to reduce the source wim file see: http://reboot.pro/to...zx-compression/

 

Hope this can be of any help for some of our members.

 

Best Regards

 

alacran

Go to the full post


  • Please log in to reply
171 replies to this topic

#126 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 18 March 2019 - 08:37 PM

@ wonko

 

Bad news, I was expecting to see redirected paths to the source wim, but this do not happend.

 

I downloaded ntfslinksview from Nirsoft, then Rambooted 10x64 and Ran it, all it can detect is only all located inside C.\ and redirected to some other location into  C:\, It do not detect anything redirected outside C:\, attached Report1.html (28 KB)

 

Scan inside Symbolic links is selected, but Search hard links is deselected, if I keep Search hard links activated also nothing redirected uotside C:\ is detected but then the report is 48 MB size.

 

alacran

Attached Files



#127 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 18 March 2019 - 08:55 PM

Please read again post No. 125 I just edited it.



#128 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 18 March 2019 - 09:21 PM

Well, another finding, i do not know if this is connected to hardlinks, symlinks, junctions etc., but I see that my pc and my wife's laptop have a different vhd free space writing rate, namely:

mine is 1.5gb - free space 470mb (becoming 34mb in half a day, even if idle most of the time) - 64gb ram (I have a lot of ramcaching (primocache))

my wife's 2gb - free space 990mb (becoming 119mb in half a day, even if idle most of the time) - 8gb ram (no primocache)

recycle bin bypassed by right click command everywhere, temps, swap (only on my wife's) and whatever variable to the best of my knowledge and belief moved outside the vhds on both machines - I wonder who does the free space writing - not us that we know of. Both systems are loaded as ramdisks, so everything goes back to the previous state when we boot the next day. whatever work we did was saved outside the vhd, and anyway my activity on my pc was definitely more substantial than my wife's on her laptop. there is definitely more software and more data on mine than there is on hers. the only thing I can think of is disk caching.



#129 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 19 March 2019 - 12:50 AM

This will work only if you put again on same drive it was before the source folder/file and decompress there the VHD, if you do this on another drive, this DO NOT WORK.

There are powershell dism cmdlets
https://docs.microso...ll/module/dism/

More ideas, no I'havn't tried this so far.
Copy the vhd and the wim file to a new drive, mount the vhd image and run Update-WIMBootEntry
Adjust the drive letter and path to current layout.

PS C:\> Get-WIMBootEntry -Path "C:\"
PS C:\> Update-WIMBootEntry -Path "C:\" -DataSourceID 0 -ImagePath "D:\Windows Images\install.wim"

There are more features like Add-WindowsImage, New-WindowsCustomImage.


Run 7-zip and open the vhd image. Compare file sizes.
If there is small size used, it's a link to the wim file.

fsutil support some wim too:
fsutil wim enumwims c:
0 {81BD618E-53E3-4C0D-8794-48204F4B17AB} 00000001 D:\windows\system.wim:1

As for a plain default WimBootCompress.ini
[PrepopulateList]
bootstat.dat
*winload.*
*winresume.*
wof.sys
\Windows\System32\Config\SYSTEM
\Windows\System32\PlatformManifest\*
C:\Windows\System32\drivers>for %a in (*.sys) do fsutil wim queryfile %a

wof.sys is extracted, part of the vhd file.
Bootmgr loads this driver and can read wim files next.

pci.sys is a link to the wim file. It's not part of the VHD file.
There is no driver stack to the wim file at early boot.

grub4dos VHD RAM booting uses BIOS.
Bootmgr has to have access to the wim file.
Bootmgr searches a BIOS disk {81BD618E-53E3-4C0D-8794-48204F4B17AB}.
This can be a internal or a external USB disk.


We may like the default setting:
small vhd file, low RAM usage, files are read from the wim file. Changes are lost at reboot.

At the other hand, another approach is nice.
inclulde more files to the vhd image. E.g. all files from ntbtlog.txt.
Bigger vhd image, more RAM usage, more files are read form the RAM disk, faster at boot. Driver stack may work more hardware.

Both apporaches are useful, a user has to define his needs.
  • alacran and antonino61 like this

#130 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 19 March 2019 - 02:11 AM

@ cdob

 

Thanks, for your helpfull comments, I will read the info in your link, and try the Power Shell commands ASAP.

 

It will be very good if we can just paste VHD + wim file on any drive we want (as we do with a WinPE.iso or a boot.wim), and do not have to Apply/Deploy the image on each new location.

 

This is last version of Custom WimBootCompress-2019-03-18.ini (still under test)

 

Spoiler

 

 

It includes the files/folders listed on WimBootCompress.ini from WinNTSetup located on Tools folder, this has improved portability, since this line \Windows\System32\drivers\*.sys installs all drivers uncompresed on VHD, not as pointers, I have Rambooted on 4 diferent Intel ChipSets 3 diferent VHDs 10x64, 10x86 and 8.1x64 of 1.5 GH and after a brif driver install all them boot fantastic, also there are a few more additions, first two from wimb and second two mine.

 

[PrepopulateList]

 

\bootmgr
\Boot\BCD
\EFI\Microsoft\Boot\BCD
 

[ExclusionList]

\Recovery\*     <<<<<<<< This is useless on the present wimboot install on VHD, so removing this saves about 300 MB on the source wim

 

Yes I know 7-zip is very usefull, since all files having on column Compressed Size 0 size are pointers or also hard links, I noticed this some time ago on install.wim files with several indexes.

 

Once again thanks for your assistance.

 

alacran


  • antonino61 likes this

#131 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 19 March 2019 - 02:57 AM

Power Shell commands do not seem to work, VHD and wim files are on drive H., and VHD is attached at drive J:

 

See attached pictures.

 

I'm still reading the info.

Attached Files



#132 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 19 March 2019 - 05:02 AM

dear Alacrán and cdob,

I cannot help but enthuse at what u guys are doing!

if I have understood correctly, we have 2 extremes here:

1) the smallest vhd, with next to nothing but pointers on it, everything in the wim file, no persistence across reboots, which is achieved if u bake a wim according to the smallest wimbootcompress.ini cdob proposed first;

2) a larger vhd, with only a few pointers and a lot of files on it, which is more or less what alacrán proposed in the spoiler hatch.

Me I might be interested in the latter as well, is it universal as wimbootcompress.ini or does one have to derive it from one's own ntbtlog.txt on a per-machine basis? if the latter is true, is the list to be derived applicable to the prepopulated list or to the exclusion list in order to achieve faster boot times and more comfortable deployment by those who have a lot of space on board? 

thanks in advance

nino



#133 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 19 March 2019 - 11:47 AM

Power Shell commands do not seem to work, VHD and wim files are on drive H., and VHD is attached at drive J:
 
See attached pictures.
 
I'm still reading the info.

How about using DISM.exe instead of PowerShell ? https://docs.microso...25258(v=win.10)

Example:
DISM.exe /Update-WIMBootEntry /Path:C:\ /DataSourceID:0 /ImageFile:R:\Install.wim


Is WIM "pointer" stored in BCD in VHD ?
Can you view or change it with bcdedit or BOOTICE ?

#134 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 19 March 2019 - 09:22 PM

How about using DISM.exe instead of PowerShell ?

Thanks, good idea, dism is part of a default installation DVD.

Let's play:
Given two files \windows\system.vhd and \windows\system.wim at a 16 GiB hard disk
Flat file vhd booting, no RAMdisk so far. Windows 10 wimboot to a 16 GiB disk.

The two files system.vhd and system.wim copied to a new 12GiB hard disk.
Bootmgr and \boot copied too.

The file \boot\bcd adjusted a the new 12 GiB disk.

bcdedit /store bcd /set {default} device vhd=[locate]\windows\system.vhd
bcdedit /store bcd /set {default} osdevice vhd=[locate]\windows\system.vhd
.
A Win 10 DVD booted. C: is at the new disk.

DISKPART> sel vdisk file=C:\windows\system.vhd
DISKPART> attach vdisk
E: is the wimboot disk.

dism /Get-WIMBootEntry /Path:E:\
Data Source ID : 0
Image File : \\?\GlobalRoot\Device\HarddiskVolumeUnknown\windows\system.wim
 
dism /Update-WIMBootEntry /Path:E:\ /DataSourceID:0 /ImageFile:C:\windows\system.wim
.
The operation completed successfully.

dism /Get-WIMBootEntry /Path:E:\
Data Source ID : 0
Image File : C:\windows\system.wim

Windows 10 wimboot to a 12 GiB disk.


@antonino61
The ntbtlog.txt can lead to a intermedia approach.
Add some files to the VHD image, available at RAM boot.
Create a windows 10 default list:
dism apply a install.wim, bcdboot and set bootlog at bcd file.
Catch ntbtlog.txt from first reboot.
Generic USB3.0, IDE, AHCI and NVME drivers are included.

#135 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 19 March 2019 - 11:14 PM

@ cdob

@ karyonix

 

Good news, Thanks very much for your help to both of you.

 

Both ways work, Power Shell and Dism.

 

VHD and wim files are on drive H., and VHD is attached at drive J: as in my previous post. (Running commands from 10x64 Pro 1709, nothing additional installed to the OS)

 

This time opened PS as Administrator directly on J: and ran from it:

 

First ran: Get-WIMBootEntry -Path "J:\" and this time it ran and gave me I:\Wimboot\10x86-WB.wim (initial location of wimboot image)

 

Update-WIMBootEntry -Path "J:\" -DataSourceID 0 -ImagePath "H:\Wimboot\10x86-WB.wim"

 

And it returned: C.\Windows\Logs\DISM\dism.log  and the info on log was useless.

 

Ran again: Get-WIMBootEntry -Path "J:\" and gave again:  I:\Wimboot\10x86-WB.wim (initial location of wimboot image)

 

Then I detached the VHD and Attached it again to J:

 

And runing again: Get-WIMBootEntry -Path "J:\" and this time it ran and gave me H:\Wimboot\10x86-WB.wim (The path was updated)

 

It is required to detach and reattach to verify the path change.

 

Latter tested Dism command too:

 

First delete the VHD on drive H: and pasted it again from drive I:, Attached it as J: and ran first PS to see original Path.

 

Then ran: in commaand promt directly on J:

 

DISM.exe /Update-WIMBootEntry /Path:J:\ /DataSourceID:0 /ImageFile:H:\Wimboot\10x86-WB.wim

 

Detached the VHD, and reatached again and verified with PS and it worked fine too.

 

Of course tested the VHD on this new location, booting from bootmanager as Filedisk and also from grub4dos as Ramboot, all working fantastic.

 

Attached some pictures

 

On PS-1.png it seems the command did nothing, but after the VHD is detached and reattached on PS-2.png you can see the new path to source wim file, on Dism.png you can see it is more explicit, then after the VHD is detached and reattached the new path to source wim file has changed, just as on PS-2.png

 

This makes the Wimboot VHD more versatile, in some way as a WinPE.iso or a boot.wim, but with the full power of a full OS.

 

Now we can move/copy the coupled files (VHD + wim) to any location without limitations, and there is no need to re deploy/apply again (in wimboot mode) the wim to the VHD, on every new location.

 

But BCD(s) may require to be edited, better check to be sure all will work fine.

 

alacran

Attached Files


  • wimb likes this

#136 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 20 March 2019 - 03:18 AM

@ karyonix

 

About:

 

 

Is WIM "pointer" stored in BCD in VHD ?
Can you view or change it with bcdedit or BOOTICE ?

 

Excuseme, I didn't answer your questions before, answer to both is NO.

 

alacran



#137 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 20 March 2019 - 03:21 AM

Attached File  WimBootCompress.txt   3.17KB   3 downloads
 

wimboot vhd 684mb + express4k wim 7gb works like a charm, though it's kinda bulgy. vhd expansion is to be expected. any suggestions to make it more stable?



#138 alacran

alacran

    Silver Member

  • .script developer
  • 878 posts
  •  
    Mexico

Posted 20 March 2019 - 11:53 AM   Best Answer

Well, I think now this thread has all info, I'm going to make a summary of all relevant post you need to follow to be able to Create and Ramboot from a Wimboot VHD and also how to make a compressed copy (to keep as backup) of the coupled files required to wimboot.

 

I started this thread thinking the smallest the best, and was able to run a 512 MB VHD, as the name of the thread says, but during the development of this thread I change my mind and decided that a 1.5 GB VHD is a good size to load a VHD in RAM on an acceptable time, and this size VHD is also capable to Ramboot on PCs with a minimum of 4 GB of RAM.

 

Introductory info and required programs: http://reboot.pro/to...hd/#entry209470

 

Making the VHD: http://reboot.pro/to...hd/#entry209472

 

Optionally apply unnatend.xml, services modifications and control Telemetry during install: http://reboot.pro/to...hd/#entry209480

 

Install your programs, SVBus driver and Capture Wimboot Image: http://reboot.pro/to...hd/#entry209483

 

Apply Wimboot Image to a 1.5 VHD: http://reboot.pro/to...hd/#entry209485

 

Installing your Wimboot VHD on a USB device and Ramboot: http://reboot.pro/to...hd/#entry209488

 

You may consider this as an Hybrid Ramboot: http://reboot.pro/to...hd/#entry209518

 

Selecting to use wimlib on WinNTSetup: http://reboot.pro/to...hd/#entry209568

 

What I put on my VHD: http://reboot.pro/to...hd/#entry209602

 

Improve Portability: http://reboot.pro/to...e-4#entry209809

 

EDIT: I finally found some info about the WimBootCompress.ini file located on WinNTSetup\Tools\, see: https://wimlib.net/f...wtopic.php?t=16

 

Custom WimBootCompress.ini: http://reboot.pro/to...e-4#entry209815

 

cdob comments: http://reboot.pro/to...e-4#entry209834

 

Making copies of coupled files (VHD + wimboot wim file) for backup pourposes: http://reboot.pro/to...e-5#entry209917

 

cdob suggestion for redirect on the VHD the path to source wim file: http://reboot.pro/to...e-6#entry209947

 

Custom WimBootCompress-2019-03-18.ini: http://reboot.pro/to...e-6#entry209949

 

karyonix suggestion for redirect on the VHD the path to source wim file: http://reboot.pro/to...e-6#entry209952

 

More cdob comments: http://reboot.pro/to...e-6#entry209976

 

Redirect the VHD path to wimboot wim file is finally a success: http://reboot.pro/to...e-6#entry209979

 

NOTE: When relocating the files, edit the BCD(s) may be required, better check to be sure all will work fine.

 

EDIT: If for any reason you want to reduce the source wim file see: http://reboot.pro/to...zx-compression/

 

Hope this can be of any help for some of our members.

 

Best Regards

 

alacran


  • wimb likes this

#139 wimb

wimb

    Platinum Member

  • Developer
  • 2500 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 20 March 2019 - 01:09 PM

@ cdob

@ karyonix

 

Now we can move the coupled files (VHD + wim) to any location without limitations, and there is no need to re deploy/apply again the wim to the VHD, on every new location.

 

 

 

Thanks to all for the interesting solution so that we can relocate the (VHD + WIM) combination.

 

:cheers:


  • alacran likes this

#140 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14726 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2019 - 01:28 PM

Now we can move/copy the coupled files (VHD + wim) to any location without limitations, and there is no need to re deploy/apply again (in wimboot mode) the wim to the VHD, on every new location.

 

So, NOW you can have backups that can actually be restored on different drives (the latter being IMHO the quintessence differentiating a backup from a "half-@§§ed temporary (compressed) copy" ).  :thumbsup:

 

Q.E.D.  :smiling9:

 

:duff:

Wonko


  • wimb and alacran like this

#141 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 20 March 2019 - 01:45 PM

sorry to sound unpopular again, but ... do u really need to move the couple perforce? can't u just move the wim about as and where u pls and then bake a wimboot vhd in 30secs to 4/5 minutes? come on, with most of my openmindedness and least of my narrowmindedness, I really do not see the use of moving both to make just that vhd work, when you all know, among other things, that it will be all the smaller. not only that, u might as well rebake a new wim from the vhd x and then derive a new wimboot vhd y. so, for all intents and purposes, do u really need to keep this couple?



#142 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14726 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2019 - 04:05 PM

sorry to sound unpopular again, but ... do u really need to move the couple perforce? can't u just move the wim about as and where u pls and then bake a wimboot vhd in 30secs to 4/5 minutes? come on, with most of my openmindedness and least of my narrowmindedness, I really do not see the use of moving both to make just that vhd work, when you all know, among other things, that it will be all the smaller. not only that, u might as well rebake a new wim from the vhd x and then derive a new wimboot vhd y. so, for all intents and purposes, do u really need to keep this couple?

You don't sound unpopular at all, but you do sound - with all due respect  :) - "silly".

 

A backup (and the possibility to restore it to different devices) offers possibilities that are different (even if partially overlapping) from "simply" rebuilding. 

 

The idea of having a "proper" backup is to have a copy of something "as is" (exactly) at a given moment and having the capability to restore it (exactly as it was) at a later time.

 

Say that today you make a .wim+.vhd and that after having tweaked it, added programs to it, customized its looks and what not you are perfectly satisfied of the result.

 

You could achieve the above in three ways:

1) completely automated by having each and every change, setting, addition and removal, patch and what not fully executed by scripts or programs <- this is what in technical jargon is defined as "reproducible".

2) partially automated as above but with a few changes/tweaks/whatever applied manually

3) manually built 

 

Say that in three months (or 2 years) time that build (for whatever reasons) doesn't work anymore and you want/need it OR you want to transfer it to another PC/disk/device/whatever.

 

IF (and almost surely you haven't  :rolleyes:  ) used approach #1 above you don' t really need a backup, as - as long as you have access to the source windows files - the build/setup is - by definition - "reproducible", BUT IF you used approach #2 or #3 a backup is what you would want to have.

 

Please note that even if you used approach #1 in three months (or 2 years) time you will likely have between 2 and 17 different windows source versions, and in order to rebuild the "reproducible" build you will have to find the "right" one anyway.

 

:duff:

Wonko 



#143 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 20 March 2019 - 04:23 PM

wonko, 

sorry to insist, whatever u say so analytically I do synthetically every next version of wim+vhd, which is what I consider better than the previous one, the reason being had I not considered the next version of wim+vhd better than earlier ones, I would simply have remained with the previous one in the first place, so there would not have been any next version. sorry for my convoluted wording, but I am sure you know what I mean. As for portability and reproducibility elsewhere, you might be right from a theoretical point of view. Believe it or not, this wim+vhd combo is empirically so perfect that anything could be righted and/or bettered on the spot with successive baking of either and/or both. I really do not know how many wim+vhd's I have baked in a week, I reckon a few score, give or take a few. Never mind going to the trouble of checking which one combo was the most crucial to the baking of the next one. e.g., If and when I do have to install some substantial software, I re-bake whatever it takes,  presumably both. no sooner had I tried to check how long I had spent baking it than I did.

In any case, if anyone must keep a combo of both for future reference (btw, this is what I consider really useful, in the event of unwanted deletion, or to feel psychologically more protected (less serious than the latter, though), so be it.

nino

ps.: who told you that I have not used approach 1? I always do, in fact.



#144 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14726 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2019 - 05:50 PM

Well, exactly:

I really do not know how many wim+vhd's I have baked in a week, I reckon a few score, give or take a few.

 
 before or later, you will manage to arrive to (what you believe to be) a "perfect" build. 

And that will be just the right time when you might appreciate the possibility of "storing" it "as is" and being able (in the future) to restore it.
 

ps.: who told you that I have not used approach 1? I always do, in fact.

Hmmm :dubbio:.

I have my sources :w00t: :ph34r:, but basically noone (and I mean noone) ever manages to do anything (unless it is trivial) that is fully reproducible, as a matter of fact a large part of my time (and grumpiness :ranting2: ) on this and other boards is  dedicated to encourage and try and convince people to make things reproducible or as reproducible as possible.

 

I trust however your word for it that you are an exception :) to this otherwise generally applicable rule.

 

No, wait ;):

Spoiler

 

:duff:

Wonko


  • wimb likes this

#145 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 20 March 2019 - 05:57 PM

My Dear Wonko, 

I appreciate your sheer illuminated and Enlightened (1700s) Positivism (1900s) (albeit up to a point, as I am much more of an empiricist (late 1600s onwards)) and I can tell u that if I do lie I do it unconsciously. 

Moving back to more substantial things, would u pls tell me why g4d + menu.lst script takes longer to boot filedisk vhd than conventional boomgr does? I don't know whether it is my perception, but the difference feels noticeable. as for ramloading, never mind, we have no alternative.

nino



#146 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14726 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2019 - 06:41 PM

I guess that the difference is in the driver used, if my assumptions are correct without using grub4dos (and the SVBUS or the Firadisk, or WinvBlock or whatever other third party driver) you are probably using Windows own "Native VHD" booting mechanism and driver, and it is perfectly possible that the MS driver is faster.

 

I am not at all familiar with how the feature evolved, in the ol'times (Windows 7) only Ultimate and Enterprise edition allowed native booting, maybe Windows 10 removed this restriction? :unsure:

 

In case a workaround (for experimenting only and very near if not beyond the border) was found at the time:

http://reboot.pro/to...b4dos/?p=193572

http://reboot.pro/to...tpolicy-viewer/

http://reboot.pro/to...using-grub4dos/

 

:duff:

Wonko 



#147 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 20 March 2019 - 07:15 PM

well, I can see that u have really gone places much earlier and with a lot more know-how than many ppl, including me of course. the strange thing for me is that with much less bloat and system protection than windows, it is a bit counterintuitive to find out that native bootmgr is quicker than any solution found by so many good academics and technicians here by means of the much more controllable grub4dos

nino

ps. I wonder what part of italy u r from



#148 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14726 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 March 2019 - 07:48 PM

well, I can see that u have really gone places much earlier and with a lot more know-how than many ppl, including me of course. the strange thing for me is that with much less bloat and system protection than windows, it is a bit counterintuitive to find out that native bootmgr is quicker than any solution found by so many good academics and technicians here by means of the much more controllable grub4dos
nino
ps. I wonder what part of italy u r from

1) JFYI, only a very few academics (AFAIK/AFAICR one or two), quite a few (mostly self proclaimed BTW) technicians , a few handfuls of (good) programmers :) and technicians (real ones), numberless self-proclaimed ones :(  (actually good-for-nothing) , and a vast number of simple hobbyists, among this latter group a single grumpy old bastard (yours truly ;) )
2) Remember that only MS can throw the secret seven:
https://jdebp.eu/Hum...t-monopoly.html
3) near Florence, Tuscany
 

:duff:

Wonko



#149 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 301 posts
  •  
    Italy

Posted 21 March 2019 - 04:26 AM

ur command of English is near-native-like



#150 Camiel

Camiel

    Newbie

  • Members
  • 26 posts

Posted 4 weeks ago

I am failing to see where the wim and the vhd are connected, and how. 

Couldn't find it in the OP and didn't go through all posts thereafter. If anyone be so kind to show me how to connect the vhd to the wim, because if I get it all right, it seems to me that there's a mother wim from where a child vhd retrieves data from, during normal OS operations, ram or disk booted regardless. 


Edited by Camiel, 4 weeks ago.




Also tagged with one or more of these keywords: wimboot, ramboot

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users