Jump to content











Photo
- - - - -

Get-alladafluff-out

os shrinking ntlite

  • Please log in to reply
323 replies to this topic

#76 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 09:51 AM

it is all right! i already said science has triumphed over magic, and it has not been the first time. Remember my hotch potch deployment of hybrid windows with program files, program files (x86), program data, most of \windows (including winsxs) and most of \system32 on another disk junctioned to c:\ in order to have a small core of windows for booting? that happened here a few years ago. then I discovered wimboot which does the same with much more order and much less ado. and now here we are. that was another instance of triumph of order over chaos.



#77 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 10:13 AM

the batches are simple and fine. When Alacrán says 4,92gb vs. 3.97gb I hope he means the whole vhd size, not the winsxs size only. here, as I was saying earlier, I tried the batches on a fresh (unmodded version) of winsxs (about 5gb) and they shrunk the folder to a mere 72 megs. Consider that, unlike Alacrán, I don't have office or other software installed except for the vcredist and directx and openshell. that is probably why winsxs became so small. following your suggestions, I have everything else (and whatever else I can) portable. the amount of ram I have enables me to even choose to run the full vhd without wimbooting even on ram. well, I have both full vhd and wimboot vhd, to be loaded either as filedisks or as ramdisks. Another achievement was to discover that these batches work on any build, not only 19041. so, another win. this is what I can say now, not before the batches appeared!



#78 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 10:14 AM

I kept thinking about this:

 

 

I think to know wich especific version of comctl32.dll is required for each program we use is almost impossible.

 

And then I understood why MS guys prefered to keep all versions to avoid issues, and solve potential problems.

 

Then what we do running winsxs_hardlink_system.cmd is eliminate MS solution and create back the cause of issues, and only for trying to make the OS a little smaller.

 

I understand and appreciate very much all time and effort cdob invested on creating this command, and with very good motivation and intentions, but unfortunately on this case IMHO Win10 has enough issues itself in every new version and do not need our help to make it worst.

 

EDIT: More info about possible cause of this issue is on pots: http://reboot.pro/to...e-4#entry215380and http://reboot.pro/to...e-4#entry215380

 

@ cdob

 

Sorry my friend, but that is my honest opinion.

 

alacran



#79 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 10:21 AM

When Alacrán says 4,92gb vs. 3.97gb I hope he means the whole vhd size, not the winsxs size only.

Yes, they are the used size of the VHD, before and after running only base_winsxs.cmd and deleting the winsxs backup file.

 

alacran



#80 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 10:26 AM

my dear Alacrán, pls let us throw the bathwater and save the baby, instead of throwing the baby with the bathwater. I also did have issues with a few pieces of software after the batches, which I solved by copying original manifests back to the new winsxs. for those who have a lot of software installed, like u, then it is a good point not to take advantage of the batches, but for those who use windows only to get to the desktop interface and rely on portables, it is not so crucial to have different versions of dlls which they never will use. in my case, I still have a redundant manifests folder inside the winsxs. with a little patience, i think even manifests will be smaller, but I will never say 5gb is better than 72megs just because I have not yet found out which manifests files I need to solve the issue less redundantly.



#81 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 10:32 AM

I think wonko has a point there. "depends" will tell u which files are needed. I am sure u have issues for a small amount of ur software, not for most of it. many ppl here tried the batches, and instead of shrinking winsxs to a few megs, they only halved its  already plethoric size, which means the batches do take into account the software one has installed. the more u have installed, the less u can shrink of winsxs, because there are dlls to take into account. in my case, there are almost no dlls that the system has to keep. sometimes, like in our cases, for some reasons unknown to me, the procedure might fail, but the failure is slight compared to the gain (baby and bathwater). want another? I am concerned as to how to shrink the manifests folder, whose size amounts to a mere 15megs. these 15 megs, at least visibly (not sure if it is really so), contain over 9 thousand files. I am just curious which of these files I really need to solve the issues without all other unneeded files. but if I had not been curious, I would not have cared.



#82 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 10:51 AM

My good friend it seems to me you didn't read carfully my posts, running base_winsxs.cmd on my portable VHD didn't create any issues on it when booting so far, and this batch file is the one that makes the bigger size reduction.

Only the winsxs_hardlink_system.cmd has created some issues on the installed OS and also on the portable VHD, and the reduction made by this batch file is very small compared with the other one, and it is not worth using it for such low profit and the problems it creates.

 

alacran
 



#83 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 15 July 2020 - 10:55 AM

My first idea is there is a compatibility problem with comctl32.dll last version,

The true reason is unknown. 
There is a simplification at the hardlink batch, new file: seach by date. A simple 'dir /O' is used.
The file version should be used instead.

This can lead to errors.

There are v5 comctl32 and v6 comctl32.
The file system32\comctl32.dll is seldom updated by windows update.

 

Some random ideas:
Maybe hardlink WinSxS files only, don't hardlink system32\comctl32.dll
Hardlink v6 comctl32 and gdiplus.dll only.
Hardlink gdiplus.dll only. 
Use the file version to sort files.
 



#84 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 11:11 AM

@alacrán, now I see what u mean and I noticed only a slight gain from the second batch too. It did not cause any issues in my case, though.

@cdob, which files from the original manifests folder do u think I need in order to make firestorm and directx related software work back again without retransferring the whole manifests folder from the original to the new winsxs?



#85 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 11:28 AM

Deleted for double post.



#86 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 11:48 AM

The true reason is unknown. 
There is a simplification at the hardlink batch, new file: seach by date. A simple 'dir /O' is used.
The file version should be used instead.

This can lead to errors.

You are totally right, and I was wrong, but anyway the issue is related to comctl32.dll, attached a picture of all ocurrences of comctl32.dll on my original unchanged 10x64 1909 VHD, as you can see some (light blue) are compressed (as the OS was installed as 4K Compact mode), some not (black), but all of them have same date, then as it seams winsxs_hardlink_system.cmd needs to be fixed, it is better to not use it, until it is fixed.

 

Some random ideas:
Maybe hardlink WinSxS files only, don't hardlink system32\comctl32.dll
Hardlink v6 comctl32 and gdiplus.dll only.
Hardlink gdiplus.dll only. 
Use the file version to sort files.

Thanks for the ideas, but I do not have the skills to modiffy your batch file.

 

EDIT: I will make a note on my previous post about this subject for future readers.

 

alacran

Attached Files

  • Attached File  dll.png   589.26KB   0 downloads


#87 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 03:12 PM

After a more carefull analysis of comctl32.dll ocurrences and sorting them by size (in bytes) I found the total size used by possible redundant files (with exactly same size) is only 1.76 MB (or 1.16 MB in my case as they are 4K compacted).

 

Then IMHO the gain in recovered free space means almost nothing, and I think there is no valid reason to spend more time or effort trying to modify/fix cdob's winsxs_hardlink_system.cmd

 

alacran

Attached Files



#88 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 July 2020 - 04:41 PM

After a more carefull analysis of comctl32.dll ocurrences and sorting them by size (in bytes) I found the total size used by possible redundant files (with exactly same size) is only 1.76 MB (or 1.16 MB in my case as they are 4K compacted).

 

Then IMHO the gain in recovered free space means almost nothing, and I think there is no valid reason to spend more time or effort trying to modify/fix cdob's winsxs_hardlink_system.cmd

 

alacran

It is reasoning like that that creates the bloat. :w00t:

 

1.76 is more than a floppy worth of data!

 

It may mean nothing, but 1.76 saved here, another 1.76 saved there ...  ;)

 

:duff:

Wonko


  • antonino61 likes this

#89 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 07:17 PM

well, talking about squeezing here and there, I can tell u ppl that I am just after trying the batches on another fresh, pristine, winsxs. Well, we definitely beat oprekin --> 5gb-plus to 66megs. Me I still have the same manifests problem, but it is ok. one day, with a little more patience, we will find the culprit. the procedure was carried out after installing the build, seeing to it that I had all I need ticked and all I don't need unticked in the programs and features list and uninstalling the software I do not use. both batches work.



#90 alacran

alacran

    Platinum Member

  • .script developer
  • 2704 posts
  •  
    Mexico

Posted 15 July 2020 - 09:20 PM

It is reasoning like that that creates the bloat. :w00t:

 

1.76 is more than a floppy worth of data!

 

It may mean nothing, but 1.76 saved here, another 1.76 saved there ...   ;)

 

:duff:

Wonko

 

Come on, don't argue that, just analyse it this way:

 

Applying base_winsxs.cmd:

 

The original used size was 4.92 GB, the used size after first reduction is 3.97 GB

 

Then reduced size is 4.92 GB - 3.97 GB = 0.95 GB;  (0.95 x 100)/4.92 = 19.30894308943089 % reduction.

 

That is a big size reduction of almost 1/5 of original size.

 

Applying winsxs_hardlink_system.cmd

 

When I said 1.76 MB means almost nothing is comparing it with:

 

The used size after reduction 3.97 GB = 4065.28 MB; (1.76 x 100)/4065.28 = 0.0432934508816121 %

 

It means almost nothing because the size reduction is less than 5/10000 of the size.

 

alacran



#91 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 15 July 2020 - 11:50 PM

yes in a rough&ready way, Alacrán, but like this we will never find the problem, never mind solve it.



#92 gbrao

gbrao

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    India

Posted 16 July 2020 - 04:35 AM

For people like me who like to load and boot a vhd from memory, this tool is def worth it.

These days I boot a Win 10 32-bit, 3GB vhd with 2.2GB (compressed) space occupied. Works well, I have abs no complaints.

I can't thank cdob enough.


  • antonino61 likes this

#93 wimb

wimb

    Platinum Member

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

Posted 16 July 2020 - 05:16 AM

For people like me who like to load and boot a vhd from memory, this tool is def worth it.

These days I boot a Win 10 32-bit, 3GB vhd with 2.2GB (compressed) space occupied. Works well, I have abs no complaints.

I can't thank cdob enough.

 

base_winsxs.cmd of cdob is certainly a very smart and interesting tool to reduce very fast the Windows used size.  :magic:

But to get the real reduction of 8.1 GB in used size of the Win10x64 VHD it requires to do after WinSxS reduce a Capture and Apply as shown here

 

After WinSxS reduce followed by Capture and Apply then the used size of Win10x64 in VHD is  still 10.1 GB

For a Full Win10x64 after WinSxS_reduce the size of the captured WIM file is reduced by 2.5 GB which is really an advantage.

 

I guess you never tried VHD_WIMBOOT where the used size of a full Win10x64 in VHD is only about 500 MB

WIMBOOT mode is a very powerful space saver which allows small VHD loading and booting fast from RAMDISK



#94 gbrao

gbrao

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    India

Posted 16 July 2020 - 05:52 AM

base_winsxs.cmd of cdob is certainly a very smart and interesting tool to reduce very fast the Windows used size.  :magic:

But to get the real reduction of 8.1 GB in used size of the Win10x64 VHD requires to do after WinSxS reduce a Capture and Apply as shown here

 

After WinSxS reduce followed by Capture and Apply then the used size of Win10x64 in VHD is  still 10.1 GB

For a Full Win10x64 after WinSxS_reduce the size of the captured WIM file is reduced by 2.5 GB which is really an advantage.

 

I guess you never tried VHD_WIMBOOT where the used size of a full Win10x64 in VHD is only about 500 MB

WIMBOOT mode is a very powerful space saver which allows small VHD loading and booting fast from RAMDISK

Hi,

Thanks. But I prefer the original way of booting from ramdisk. Simpler and works well for me.

my 32-bit Win 10 has a 3 GB vhd, this is what I normally use.

my 64-bit Win 10 has a 5.5 GB VHD.

That's good enough for me.

 

You actually got me hooked on booting from memory :-)

These days I just can't use regular (from disk partiton) Windows.

 

I would have liked to continue using Win 7 or Win 8.1 but I can't get some things running on them - like my Apple USB-C to 3.5mm headphone adapter. If some one can solve the Apple prob, I'll go back to WIn 8.1.



#95 wimb

wimb

    Platinum Member

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

Posted 16 July 2020 - 06:08 AM

Hi,

Thanks. But I prefer the original way of booting from ramdisk. Simpler and works well for me.

my 32-bit Win 10 has a 3 GB vhd, this is what I normally use.

my 64-bit Win 10 has a 5.5 GB VHD.

That's good enough for me.

 

You actually got me hooked on booting from memory :-)

These days I just can't use regular (from disk partiton) Windows.

 

I would have liked to continue using Win 7 or Win 8.1 but I can't get some things running on them - like my Apple USB-C to 3.5mm headphone adapter. If some one can solve the Apple prob, I'll go back to WIn 8.1.

 

But I think your 64-bit Win 10 is in that case not a Full Win10x64  ?

What driver do you use for booting from ramdisk ?

 

Mini 7 and Mini 8 in VHD have a similar reduction of the WinSxS folder as obtained by the batch of cdob.

 

From copy_8vhd.txt

\Windows\winsxs\manifests\*_microsoft.vc80.*
\Windows\winsxs\manifests\*_microsoft.vc90.*
\windows\winsxs\manifests\*_microsoft.windows.c..-controls.resources_*.manifest
\windows\winsxs\manifests\*_microsoft.windows.common-controls_*.manifest
\windows\winsxs\manifests\*_microsoft.windows.gdiplus_*.manifest
\windows\winsxs\manifests\*_microsoft.windows.i..utomation.proxystub_*.manifest
\windows\winsxs\manifests\*_microsoft.windows.isolationautomation_*.manifest
\windows\winsxs\manifests\*_microsoft.windows.systemcompatible_*.manifest
\windows\winsxs\manifests\*_microsoft-windows-servicingstack*
\Windows\winsxs\manifests\*_microsoft.windows.fusion*
\Windows\winsxs\manifests\*_policy.*
\Windows\WinSxS\Manifests\*_microsoft-windows-twinui*.manifest

\Windows\winsxs\*_microsoft.vc80.*\*.*
\Windows\winsxs\*_microsoft.vc90.*\*.*
\windows\winsxs\*_microsoft.windows.c..-controls.resources_*\*.*
\windows\winsxs\*_microsoft.windows.common-controls_*\*.*
\windows\winsxs\*_microsoft.windows.gdiplus.systemcopy_*\*.*
\windows\winsxs\*_microsoft.windows.gdiplus_*\*.*
\windows\winsxs\*_microsoft.windows.i..utomation.proxystub_*\*.*
\windows\winsxs\*_microsoft.windows.isolationautomation_*\*.*
\windows\winsxs\*_microsoft-windows-servicingstack*\*.*
\Windows\WinSxS\*_microsoft-windows-twinui*\*.*


#96 gbrao

gbrao

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    India

Posted 16 July 2020 - 07:30 AM

^ Yes. its a lited Win 10.

 

I'm a firadisk "fan", works ok for me :-)

 

I would like to decide what I retain and remove from my Windows, that's why I do the liting myself.

I did use your tools long back.



#97 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 16 July 2020 - 11:43 AM

I dont get wimb's point. is capture and apply an alternative to cdob's batches or a completion of them? if i capture and apply a full vhd into a vhd+wim combo, i can still obtain a 500meg vhd (plus the wim file associated to it), but without cdob's batches the winsxs still stays plethoric. of course, if I capture and apply the full vhd into vhd+wim after cdob's batches, the wim file is a few gb smaller, which is what i do. is this what wimb meant? capture and apply the full vhd from the resulting cdob shrinking of winsxs? if it is, that is what I already do. if it is something else, wimb pls say.



#98 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 16 July 2020 - 11:44 AM

btw, i would like to try the smallest winsxs folder (yesterday's, obtained from a pristine windows install) on other windows installs. I will tell you how it went.



#99 wimb

wimb

    Platinum Member

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

Posted 16 July 2020 - 12:44 PM

I dont get wimb's point. is capture and apply an alternative to cdob's batches or a completion of them? if i capture and apply a full vhd into a vhd+wim combo, i can still obtain a 500meg vhd (plus the wim file associated to it), but without cdob's batches the winsxs still stays plethoric. of course, if I capture and apply the full vhd into vhd+wim after cdob's batches, the wim file is a few gb smaller, which is what i do. is this what wimb meant? capture and apply the full vhd from the resulting cdob shrinking of winsxs? if it is, that is what I already do. if it is something else, wimb pls say.

 

It is a completion - see here  and here - case discussed is full Win10x64

It means After WinSxS_reduce then I used Capture and Apply WIM to new VHD in Normal mode (not WimBoot) to get reduction of used size by 8.1 GB.

Without the additional Capture and Apply the reduction in used size due to WinSxS_reduce is only 824 MB



#100 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1521 posts
  •  
    Italy

Posted 16 July 2020 - 12:57 PM

yes, wimb, what u say is applicable to any any-way-whatever--shrunk full vhd, not only to this circumstance, as the winsxs is not the only directory that becomes all the smaller as a result of a wimbooting procedure.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users