202 replies to this topic

[antonino61]

will portables run faster from a pre-attached vhd than from a common hdd or usb folder? is it a way of bypssing swiftsearch? i do not mind being persuaded if that is the case.

[alacran]

NO, the portables will NOT run faster, they run from inside an attached/mounted VHD (the VHD IS NOT loaded to Ram) located into the HD or USB device.

 

And once the VHD is mounted in Y drive, SwiftSearch64.exe program will work just as always, for it Y drive is just another drive.

 

alacran

[antonino61]

So the only advantage i c is to feel to have everything useful close at hand, everything all out there for the taking. Any other advantage?

[alacran]

Yes, another big advantage, maybe the best advantage is having my friend antonino61 asking questions about obvious things.  

 

Beside that no other advantage for your specific case.

 

alacran

[antonino61]

Tx 4 ur admiration

[alacran]

Automatically load to RAM an IMG file to Y drive every boot:

 

Easier way to be able to load on Ram an IMG file created from a physical drive or a VHD, both LZX Compacted, that contains all our Portable Programs is the following:

 

Procedure:

1. Install the very little GUI program ImDisk Toolkit by v77, that is based on the great ImDisk by Olof Lagerkvist.
2. Having mounted a drive or a VHD, LZX Compacted, containing your Portable Apps.
3. Capture your VHD to an IMG file on the desired location.
4. Unmount the VHD or drive, if using the drive letter you want for your IMG file when loaded to Ram.
5. Run Ram Disk Configuration.
6. Open Data Tab and select the IMG file.
7. Open Basic Tab, select Drive Letter Y, and Launch at Windows Startup and press OK.

The IMG file will be loaded after pressing OK, and from then every boot, as long as the path remains the same.

 

Plese see attached photos.

 

This can be usefull for people having a PC with good amount or Ram, and usually boots his VHDs from same PC, and then the path to the IMG file should remain unchanged.

 

Advantages:

• Easy to implement.
• The Portable Apps should run faster as they will be loaded/executed from Ram, that is always faster than any HDD or SSD.

 

Disadvantages:

• This approach doesn't work in WinPEs, as they assign new drive letters starting from internal HDs every boot.
• A little delate during boot for load on Ram the IMG file.
• More Ram consumed, than attaching the Portable Apps VHD.
• In portable devices it is very possible the drive letter of the NTFS partition holding the IMG file may change, if we don't take care to manually assign one of the firsts letters to the USB NTFS partition holding the IMG file.

I suggest (during filedisk booting our bootable VHD) to manually assign drive letter D or E to the USB NTFS partition, and make the respective correction in the path to the IMG file if required.

 

@ antonino61

 

Hope this approach may fit better your case and preferences, as I know you only Ramboot your VHDs on same PC, and also you have a lot of wasted Ram.  Just remember the automatical loading doesn't work if booting from a WinPE, but you can load the IMG manually

 

alacran

Attached Thumbnails

• 
• 
• 

[antonino61]

Tx 4 ur consideration. Btw, why should it be a img? can it not be a lz4 instead?

[alacran]

JFYI

 

I just made a little program Load_Ramdisk in AutoIt, very similar to VHD to fixed drive, but Load_Ramdisk program finds in any drive and runss \Ramdisk\ImDisk.cmd, (with required parameters), that in turn runs \Ramdisk\imdisk.exe and loads to Ram our desired IMG or VHD file.

 

I already have all required REG files to create services to run every boot imdisk.sys and Load_Ramdisk, and during my tests all is working very fine, in manual or automatic mode.

 

I will release it very soon, after making respective README files for new users.

 

The advantage of this approach is that it can work also in WinPEs, so we will be able to use this two approachs for all cases now:

 

Load_Ramdisk loads an IMG or VHD (both LZX Compacted) file to Ram (to selectable drive letter), useful when having enought Ram available.

 

VHD to fixed drive mounts as filedisk a VHD file to fixed Y drive, useful when Ram is limited.

 

EDIT: I was thinking in using a very reduced set of files from ImDik: only imdisk.sys, imdisk.cpl, imdisk.exe, and my ImDisk.cmd, (with required parameters), and provide a REG file to create a service for imdisk.sys, but changed my mind, and decided to have as a pre-requisite to install ImDisk v2.1.1 by Olof Lagerkvist.

 

The Load_Ramdisk program just have being released, please see this topic

 

@ antonino61

 

Tx 4 ur consideration. Btw, why should it be a img? can it not be a lz4 instead?

 

ImDisk can't handle lz4.

 

alacran

Edited by alacran, 28 August 2022 - 03:36 AM.
New info

[erwan.l]

...

 

@ antonino61

 

 

ImDisk can't handle lz4.

 

alacran

 

With a proxy it might.

Look in my signature, I have made a few proxies in the past.

With some little time, since I had already integrated lz4 in CloneDisk, I might be able to make a lz4 proxy for ImDisk.

[antonino61]

Can svbus instead?

 

or better still,

 

for Alacrán and/or those of great intellect and understanding and deduction,

 

I am apparently better off using all that ram in any more convenient way possible, that goes without saying,

 

Fortunately or unfortunately, this raises a philosophical issue - despite we have talked of portables so far, I would venture to gather that we all had in mind whatever one uses the most everyday. I make this point because I have 40gigs of portables but I am sure I use only 10gigs on a regular basis. together with some utilities which have been lying somewhere in mass storage (some internal drive or other), including all wimb's and jfx's and alacrán's software, that makes 20gigs at most. can we consider all these above good candidates for this second vhd? I think so, but I would ask anybody who begs to differ to explain why. all this software is hardly modified, so no update hustle and bustle.

 

pls provide ur feedback    

[alacran]

About SvBus driver:

 

SVBus driver will not work in this case, as its use is to install it into a Windows OS that will run on Ram from a VHD, and the Portable Programs VHD doesn't have integrated any OS (just the Apps) so there is no way to install SvBus driver on that VHD.

 

Also SVBus driver is to be used with grub4dos (MBR/CSM or UEFI versions), and we are not using it in any way to deal with the PortableApps VHD.

 

About you have 40 GB of portables:

 

I think that is too much, my Portables VHD LZX Compacted is 2 GB and the used space is 1.44 GB (2.54 GB if uncompressed), having 561 MB free yet.

 

I know your PC has 64 GB of Ram and load 40 GB to Ram is possible in your PC, but it will take long time to load even one half  (20 GB), just to be there in case you need some of those Apps.

 

I really don't recommend to spend time every boot to load on Ram a very big Portables VHD, in this case it is preferable to attach/mount the VHD as filedisk.

 

alacran

[antonino61]

U could not have been any clearer

[alacran]

JFYI

 

Load_Ramdisk program just have being released, please see this topic

 

alacran

[antonino61]

for alacrán and/or whomever else cares to contribute
morning afterthought,
pls do not get mad at me.

is a vhd with a fictitious OS containing svbus64.sys (+ little or nothing else) where g4d expects to find it enough for g4d to recognize it as hd and load it in ram on the mere basis of
map --top --mem /vhdwhatever.vhd (hd)
?

me I tried inserting the above line in a regular g4d script with a regular vhd and it did boot ok with both the online and the offline os loaded in ram,
now I am thinking of a vhd containing what we have talked about so far (portables and whatever else) + the little g4d would need in order to recognize it as regular vhd and just load it in ram. if it is little it is worth it.
if it is feasible, guess the good it will do, especially to those who have tested their vhd's thruout this time and had the superfluous or the common-to-many out of the os vhd and junctioned back in (my case, for instance, ... the assembly folder, the framework.net folder, the windowsapps folder, the systemapps folder, the driverstore folder, etc.). these are kept out of the os vhd in order to make tests comparable spacewise to those of those who have nothing of the kind in their OSes which is kept basic. these folders could be preloaded in ram as well as the above already included in one single and sole vhd. another reason for keeping this "location arrangement scenario" is that it is very convenient to handle updates this way
I hope I have made myself understood. from what i have tested, the other vhd has been loaded in ram not because it was a real os, but because it had svbus.sys somewhere (c:\windows\system32\drivers\svbus64.sys), or is there anything else I am missing out on?

ps.: my dear alacrán,
any vhdwhatever,vhd containing only svbus64.sys in c:\windows\system32\drivers\ is recognized as a hd and loaded into ram by g4d. i tested it by making a copy of a vhd and stripping it of everything but svbus64.sys. and it is loaded into ram as an offline vhd, try it urself if u do not believe. I am not sure if svbus64.sys can be anywhere else in order for it all to work. so u need no os in the end. only a "lousy" file. pls try it before dismissing it. the result is a vhd whose user space is 55.8 megs bigger than in the
vhd u have envisaged.

[alacran]

@ antonino61

 

When I made first VHD to fixed drive that mounts as filedisk a VHD file to fixed Y drive, my first ideas were:

 

1 - Attach the secondary VHD by means of grub4dos, using a secondary grld or editing its internal menu.list, to look (automatically during OS boot or manually after boot) for a second menu.lst in my new pre-designated location, then when running, it will load the new  menu.lst, but grld and grub.exe are 16 bits programs, and 16 bits programs usually doesn't run in Windows by default, this can be solved enabling a module in Win10 Windows Features, or by a PowerShell command, (but maybe that module is not present anymore in MinWin versions) and definetively is not present in WinPEs, so per sure this wasn't a solution for general application.

 

EDIT:  Just to confirm 16 bits module is not present in MinWin.

 

2 - Another idea was to pre-load the secondary VHD by means of original grub4dos menu.lst. But not every body runs the Win OS into the VHD by means of grub4dos (MBR/CSM or UEFI versions), as it can be run also by Win bootmanger, it wasn't also a good idea.

 

3 - Besides it was also required to find a way to mount the VHD in the desired drive letter.

 

The main idea to use a pre-designated drive letter to mount the VHD, is we already have all required REG files to make Y:\FirefoxPortable\FirefoxPortable.exe the default browser and same applies to portable Y:\VLC\vlc.exe, etc.

 

So for the mentioned reasons, I definitively discarted the idea of use grub4dos to attach as filedisk or load to Ram a secondary VHD, because this doesn't work for general use, and only could apply on certain specific cases.

 

Then please my friend, if you want to continue talking about your idea, I strongly suggest you to open a new topic to not polute unnecessarily this topic, you can be sure I will read your topic and will try to give you ideas as much as possible.

 

alacran

[antonino61]

ok sorry about the pollution. no need for support. give me ideas if u can. I will tell u what I can run or what I cannot run no matter what u have included or excluded. me as an eclecticist, I do not exclude anything, but of course everybody has got their own taste.

[virgus]

Dear all,
many many thanks for this topic and for many others of invaluable interest. I really appreciate the effort of teaching to newbies the findings and the procedures to replicate what you've achieved so far

I've been following this particular thread for a while, reading some of the comments many times until I finally started testing.
I have so many questions that cumulated through time and today is the perfect day to ask some advise.

 

First issue: Setup duration
is it normal that the MinWin setup procedure, after first boot takes more than two hours ?
I'm sticking to Wimb recommendations using "Win10_2004_English_x64.iso" MD5 CRC "3cf9848ce17271e7c895366bdad98a8e"; I used the latest WinNTSetup release posted by Alacran and tried running it both from W10 and W7 (the latter hangs at the end of the procedure but works correctly apparently).

- I've tested it the first time on a quad core i7 Dell Latitude running W10 and at the first run I tought it got frozen. By restarting I screwed the EFI bcd file (forgot to flag the option "Find and add Windows version already installed on this PC") and then recovered it. At the second attempt it was already late and I left it working before going to bed. The next morning the MinWin was there finally.

 

- Yesterday evening I tried with another laptop (HP i7 quad core with 32GB of RAM as well, running W7U) hoping to get faster results and tried to follow the setup without adding any driver, just some default tweaks from WinNTSetup. It took 75 minutes just to get to the first reboot ! After two hours I gave up so I cannot tell how long the overall setup takes exactly, and this morning the MinWin was there finally.

I'd like to know if there's a way to troubleshoot the slowness of the process as I still didn't manage to have the italian keyboard working and I might need other tweaks in the future. If the process is so slow I'm afraid it will take too much for a satisfactory result.

 

Second issue: Keyboard
I tried to setup the italian keyboard by looking at Antonino's comments and by looking at the remove txt files.
My changes followed what Alacran did for the spanish keyboard but I still cannot set the italian keyboard to work and I must be missing something besides the two lines I added to \WinNTSetup_v526\Tools\MinWin\Default\Remove\Languages.txt

!LANG=it-it|it-it !\Windows\System32\KBDIT.DLL
!LANG=fr-fr|fr-fr !\Windows\System32\KBDFR.DLL
!LANG=es-es|es-mx !\Windows\System32\KBDSP.DLL
!LANG=es-es|es-mx !\Windows\System32\KBDSP.DLL

Since the setup takes so long, while waiting to find a solution to the first issue, is there a way to tweak the system without starting the setup process again ? Would it work with smaller tweaks like this one ? Maybe Antonino61, the master of "getting-alladafluff-out" has some tips ?

 

Third issue: SVBus
In the first MinWin test I added it by drivers options in WinNTSetup interface. SVBus was the only driver I added.
In the second test I installed it manually after first boot. I used in both cases the signed 1.3 version provided by Alacran recently. I wasn't able to boot it via G4D and Chenall NTBoot as I'm used to do with XP and W7

As this issue might be related to versioning, to avoid wasting more time, I'd like first to check with you which versions of grub4dos should I use with W10 and also which versions of bootmgr would be compatible with NTBoot for W10 (and W7, XP as well). The current bootmgr file I'm using is 399.860 bytes and its CRC32 hash is 4751ba1a

BTW I also saw this really useful Alacran's post about NTloader and I will test it asap as an alternative to NTBoot (despite the fact that it won't work with WIMboot). So I'll have to make further tests but meanwhile I'd love to have a feedback from you about this: which is preferable for SVBus installation ? DISM the driver into the ISO, adding it via WinNTSetup (or other possible methods if there are others scriptable ones) or manually installing after first boot ?


Fourth issue: Differencing disks
The reason for using Chenall NTBoot is that I can keep using Grub4Dos as the main bootloader and use dynamic differencing disks for my W7 VHDs. This is useful when I want to setup an OS to work with different hardware: one base image for all of them, then one diff vhd with the installed drivers and eventually another diff to protect the "base+drivers" OS from "accidents".

 

I suppose this idea might be overcome by WIMboot option but I didn't have the time yet to study and test WIMboot method as I've been allergic until now to upgrading to OSs higher than W7. I'd love to become soon a pro with it but the learning curve for me is not so fast unfortunately.

Other alternatives, to my setup needs, might be Windows2Go (I've zero experience with W2Go but it should be good for different drivers settings for each hardware) and/or a sandbox (for keeping the OS safe from "accidents"). Ramboot might be a good compromise, provided that the OS is small enough to leave enough RAM avaliable. And this is the main reason for trying to setup a MinWin10 VHD.

 

Any recommendation about this use case ?


Another issue I experienced (the last one for now) is the following:
For my W7 VHDs I didn't use WinNTSetup. I simply installed the OS from an iso with SVBusb injected with DISM (I've seen that with some personalised ISOs WinNTSetup sometimes fails), then I captured the VHD (one single partition with the boot files in it) and used it with G4D (with NTBoot or without NTBoot according to my needs).

 

The first MinWin W10 test was made directly on a VHD volume, while the Boot volume was the main OS's one. It worked and despite it doesn't work with NTBoot (error 0xc000000f missing hardware) I was able to move the VHD on the second laptop and boot to it via bootmgr.

 

The second MinWin test was made on a 32GB ssd. First FAT32 500Mb boot partition and the rest as NTFS primary partition for the MinWin. I then grabbed it via Starwind V2V Converter (creating a two partions VHD) but I cannot boot it neither via NTBoot nor via bootmgr (it cannot find /Windows/System32/winload.exe). The procedure seems the same I used with W7U except for the use of Starwind tool instead of "Paragon Virtualization Manager 14" or "Disk2vhd" and the dual partition VHD instead of the single partition VHD

 

I wonder if any of you has a tip/hint for this last issue...

 

 

Thanks again to all of you !

 

Cheers,

Virgus

 

PS: For the other questions I'll wait some time to let things get ripe: this would avoid to make "confused questions" and waste our precious time.

Edited by virgus, 04 September 2022 - 01:00 PM.

[alacran]

Yes, MinWin istallations always take a very long time to reach the desktop for the first time, in my tests usually about 1 hour (minimum) in desktop PCs with mechanical 7200 RPM HDD, or SSD HD, no appreciable change in time.

 

I suggest you to use my MinWin Medium Profile

 

I always prefer to make the MinWin installations from a running Win10 (OS, VHD or WinPE).

 

You don't need to use the en_US version, you can use your own lang version if you prefer, and you will avoid your keyboard issues.

 

If you install an English version, you can edit Languages.txt as you mentioned, it is the right way to keep other keyboards available.

 

But you also need to go in the running OS to Regional and Lang settings, in Lang select the current lang, and then with a right click on it, you will get the option to install other keyboards, but they will not install if they are not available, (that's why the Languages.txt was edited to keep them available), once you have your prefered keyboard(s) installed, delete the US keyboard so yours will be first option, optionally if you want you can add again US keyboard and it will be the last option.

 

It is better to install SVBus driver manually after first boot as filedisk, and make sure in Device Mangement it was installed fine, (as before installed you can not boot on Ram).

 

Forget about diferential VHDs and Chenall NTBoot, and make Wimboot installations where the re-captured WIM image file, (made after first boot and all your favorite programs, and SVBus driver are installed), is located in safe place outside of the VHD, and additionally you can also keep a separate WIM copy in another location, (just in case), as an example mine is only 837 MB, there is no better backup, and it can be re-installed in same or a new VHD in Wimboot mode in about 30 seconds, for recapture and reapply I recommend you to use (from a running Win10 OS or PE) VHD_WIMBOOT by wimb, selecting Mini option during capture, see the photo attached to this post.

 

Ramboot is the best option to keep your VHDs always unchanged after booting.

 

To avoid isues during Ramboot and save some space better use a pre-made 2 partitions VHD, I suggest to use this layout:

 

First primary 40 to 50 MB active partition FAT-32

Second primary partition NTFS the rest of space.

 

You can use following commands in menu.lst for MBR/CSM grub4dos:

 

Spoiler

 

# Ramboot from internal disk:

title MinWin-WB.vhd - SVBus  RAMDISK  - map as (hd) for WIMBOOT
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map --top --mem /MinWin-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

# Filedisk booting from internal disk:

title MinWin-WB.vhd - SVBus  FILEDISK - map as (hd) for WIMBOOT
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map /MinWin-WB.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr


# Ramboot from external USB device:

title MinWin-WB.vhd - SVBus  RAMDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map --top --mem /MinWin-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr


# Filedisk booting from external USB device:

title MinWin-WB.vhd - SVBus  FILEDISK - map as (hd-1) for WIMBOOT
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map /MinWin-WB.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

 

And you can use following commands in \EFI\grub\menu.lst for UEFI grub4dos booting:

 

Spoiler

 

# UEFI boot WIMBOOT VHD files on internal or external device

title MinWin-WB.vhd - SVBus RAMDISK - 512 MB - map as (hd)
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map --mem --top /MinWin-WB-512.vhd (hd)
chainloader (hd-1)

title MinWin-WB.vhd - SVBus FILEDISK - 512 MB - map as (hd)
find --set-root --ignore-floppies --ignore-cd  /MinWin-WB.vhd
map /MinWin-WB-512.vhd (hd)
chainloader (hd-1)

 

So far I'm using this grub4dos versions, haven't tested newer yet:

 

MBR/CSM version:  grub4dos-0.4.6a-2022-01-18.7z

 

UEFI version:   grub4dos-for_UEFI-2022-01-18.7z

 

Hope this info answers your questions and can be useful for you.

 

alacran

[virgus]

Dear Alacran,

thanks for your prompt reply and yes your answers are useful indeed.

 

Thanks for the MinWin Medium Profile, i missed that post. I'm using it and waiting for a new LZW compressed VHD to be ready. I prefer always English OS so I'm following your recommendations to get italian keyboard active.

 

To prepare this VHD I used the diskpart scripts you posted here weeks ago. The first MinWin I got working had only a single NTFS partition and I left WinNTSetup do the job of bcd modification in the laptop boot partiton. Now I created a 2GB VHD (LZW option) with the FAT32 and NTFS partitions but then I had to bcdedit the boot bcd file manually to make it boot via bootmgr and do the first setup.

 

There are so many options available that I didn't understand what's the exact usage of the boot partition inside the VHD file. Could you please teach me which are the use cases where the two partitions are required ? Can I use a single partiton for the first MinWin WinNTSetup and then use two partitons for WIMboot creation ?

 

About WIMboot I'll have to experiment with it and hope to learn fast but I've still not understood how different drivers sets are handled for different hardware. Should I get a WIM file of a sysprepped VHD ? And should I re-capture a wim file for each different PC/Laptopo after drivers install ?

 

So at the end I could backup one WIM file for each configured hardware and build a VHD everytime I need a "new OS" ? Many VHD would share the same WIM file eventually. But in the event that I'd like to update the WIM file (e.g. update 7zip to a newer version) without re-capturing and re-creating every single VHD, could I edit just the WIM file and replace single files inside it with newer versions ? Are there any checksum verifications for WIMboot that would break everything ? Editing it offline would be quite an improvement compared to differencing VHDs.

 

Cheers,

Virgus

Edited by virgus, 05 September 2022 - 12:41 PM.

[alacran]

About:

 

To prepare this VHD I used the diskpart scripts you posted here weeks ago. The first MinWin I got working had only a single NTFS partition and I left WinNTSetup do the job of bcd modification in the laptop boot partiton. Now I created a 2GB VHD (LZW option) with the FAT32 and NTFS partitions but then I had to bcdedit the boot bcd file manually to make it boot via bootmgr and do the first setup.

 

You can make the first VHD single partition, and copy from \MinWin\Medium\Optional Reg files your prefered options, to the Reg folder and they will be integrated by WinNTSetup during installation, I never said it has to be 2 partitions since the begining, I was talking of the final VHD ready for Ramboot:

 

 

To avoid isues during Ramboot and save some space better use a pre-made 2 partitions VHD, I suggest to use this layout:

 

First primary 40 to 50 MB active partition FAT-32

Second primary partition NTFS the rest of space.

 

 

But anyay if you made your first installation in a pre-made two partitions VHD, WinNTSetup takes care to edit the BCD(s) in your internal HD, and also to create the BCD(s) into the FAT-32 partition, you don't need to do anything manually.

 

The two partitions VHD is the best option for UNIVERSAL Boot/Ramboot by means of grub4dos (MBR/CSM and UEFI) without any other thing required as Chenall NTBoot (it is and old version for MBR boot only) that you mentioned, or other aditional helper files as ntloader (by A1ive) or loaderNT (by yaya) that don't work in 100% scenarios.

 

VHD_WIMBOOT by wimb, can create for us several VHDs partitions options but the 2 partitions VHD it makes has a  150 MB FAT-32 partition (IMHO a waste of space in case of MinWin), that's why it is better tu use our own created 2 partitions VHD, and save space.

 

So to summarize:

 

1 - Make the frist installation in MinWin mode using WinNTSetup, in a single partition VHD, after first boot install SvBus driver, and only your favorite small programs, I install only 7-Zip, ClassicShell, Sumatra PDF. I usually don't install any drivers, and the recommendation is to use portable programs located outside of the VHD.

 

2 - Re-capture with VHD_WIMBOOT, selecting Mini option during capture.

 

3 - Having a pre-made 2 partitions VHD as per my recommendation, use again VHD_WIMBOOT, but this time for Apply the new WIM image to the VHD in Wimboot mode, it will take care of create BCD(s) into your internal HD and also into the FAT-32 partition, and will create the Ramboot entries in menu.lst for MBR/CSM and also in menu.lst for UEFI.

 

There is no need to use sysprep as you didn't installed any drivers into the VHD, and every time it Ramboots it uses the OS generic drivers for the hardware found, so no need to make several VHDs, it is exactly as a Windows2Go, unless you want to run it permanently in that PC, and install all absent especifical drivers.  Or in this case maybe make a Differential VHD, please see following post.

 

As  during Ramboot all changes made are made on Ram, your VHD will remain unchanged forever.

 

But it may be possible that you could need/want to install something, a driver or a program permanently in the VHD, to do this you have to Filedisk boot and install it to make it permanent.  

 

alacran

[alacran]

JFYI

 

Grub4dos for UEFI supports Differential VHDs since version 2021-01-31:

 

From: ChangeLog_UEFI.txt

 

2021-01-31 (yaya)
  Supports starting a first-level differential VHD image.

 

I never had a need for this option, so I haven't tested it.

 

From this post:

 

JFYI

 

From a Post of yaya (on January 2021) in G4E Topic in wuyou.net (Chinene forum): http://bbs.c3.wuyou....652&pid=4221838

 

 

Differential VHD is supported, please test.
map --mem --parent-vhd-name="parent VHD file name (with path)" child VHD file name (with path) (hd)
chainloader (hd-1)

 

I will test this and let you know.

 

alacran

 

 

alacran

[antonino61]

hey, pls, listen up to this fool writing right now,

 

the best way possible timewise, not spacewise, so far is nvme/ahci g4d 4.5 patch both as filedisk and as ramdisk (4.6 more recent? not our fault if it is not as fast), in the following fashion:

 

title vhd3.vhd (SuperRamDisk)

nvme --set-drive=0x80 --set-controller=2 --showselected

map --top --mem (hd0,0)/vhdtest.vhd (hd1)

map --top --mem (hd0,0)/vhd3.vhd (hd0)

map --hook

nvme --uninit

root (hd0,0)

chainloader /bootmgr

 

title vhd3.vhd - SVBus  FILEDISK - 1.6 GB - map as (hd)

find --set-root --ignore-floppies /vhd3.vhd

map /vhdtest.vhd (hd)

map /vhd3.vhd (hd)

map --hook

root (hd-1,0)

chainloader /bootmgr

 

of course for those who have gotta lotta RAM. no need for svbus64.sys in the non-boot vhd (just found that out).

the latter script can also apply to other g4d's, if I am not mistaken, whereas the former applies only to nvme, unless u want to change the instruction to ahci if it is the case with u. also the controller number might want changing.

 

I do well know many pundits out here are quite familiar with menu.lst, but repetita iuvant (no harm in repeating). and of course, if anyone knows better, pls tell. that is how to go about knowledge the Erasmus way.

 

btw, ... lzw?

[alacran]

 

hey, pls, listen up to this fool writing right now,

 

 

You've never said anything truer, so I'm 100% agree with you.

 

As always your egocentric mind only thinks in solutions that work in your very specific case, and is not capable to see the big picture that includes all scenarios.

 

If you don't have anything new to comment, better think twice before commenting same thing over and over, in several Topics, that only create confusion to the readers.

 

You are living in the past, that patch is for grub4dos for MBR/CSM ONLY.  And additionally you lose a lot of new improvements that v4.6a has.

 

I wish you good luck trying to use that patch in UEFI environment, That by the way is virgus case, so your comment has nothing to do in this talk with him.

 

And by the way it seems newer versions of grub4dos for UEFI have gotten an improve in speed:

 

From ChangeLog_UEFI.txt

 

2022-03-26 (yaya)
  Improve startup functionality.
  Fix ext4 read function.
  Fixed mount external command buffer overflow.

 

alacran

[antonino61]

Uefi?

 

btw

 

TAKEOWN /F “C:\Windows\System32\DriverStore\FileRepository” /R

ICACLS “C:\Windows\System32\DriverStore\FileRepository” /T /L /GRANT *S-1-1-0:F

RD /s /Q “C:\Windows\System32\DriverStore\FileRepository\”

 

that is to reduce a plethoric filerepository in driverstore (from 23gigs to a few hundred megs).

[antonino61]

and the same would go for other plethoric or plethoric-becoming or even "multi-filed" folders, if I only knew what set of commands I could use to purge them too (I am thinking of assembly, systemapps, windowsapps, etc). would anyone pls make their own suggestions? the driverstore folder is wontefully purged thru the three lines above, I can confirm - very handy and "issue-less".