1025 replies to this topic

[wimb]

Update Download:  from wimb GitHub  -  Win_Reduce_Trusted-54

 

Download File E = Encrypted PassWord = bootwimb

 

Update Manual:   VHD_WIMBOOT.pdf   - Download: Win10_2004_English_x64.iso for smaller size

 

- Remove Extra 1470 DLL Files from System32 using File_List  remove_DLL_System32.txt

- Remove several subfolders of Windows, System32, Program Files, \Windows\Microsoft.NET and \Program Files (x86)

 

==  == 

[wimb]

 

- Remove several subfolders of Windows, System32, Program Files, \Windows\Microsoft.NET and \Program Files (x86)

 

  Mini_2004_US_2022-01-07_121459.jpg

 

 

Update Win_Reduce_Trusted-54

[antonino61]

trying all reductions 1 by 1. would u pls see if this plethoric keepsyswow64 can be reduced?

Attached Files

•  keep_SysWOW64.txt   120.94KB   839 downloads

[antonino61]

it is the minimal syswow64 scenario I have found here on my vhds. there is something wrong in the remove files sys32 list - looking to eliminate the culprit.

[antonino61]

well, after this ordeal, with all the adjustments made on remove_files_system32.txt, I have never reached the desktop without adding the following list of files, which has also restored software functionality. that is as far as I got, now I will get some sleep and resume the remaining reductions tomorrow.

Attached Files

•  File_List_H_New folder (2).txt   41.99KB   816 downloads

[wimb]

 

- Remove Extra 1470 DLL Files from System32 using File_List  remove_DLL_System32.txt

 

 

@antonino61

 

Win_Reduce Software is designed according VHD_WIMBOOT Manual to make the smallest Mini-10x64 in VHD.

It works quite well with Fresh Installed Win10_2004_English_x64.iso and using Microsoft Basic Display Adapter.

 

Win_Reduce is NOT designed to modify as you do your modded Win10x64 OS having added extra software and using NVIDIA display adapter.

If you nevertheless use Win_Reduce to modify your modded OS and run into trouble,

then you can solve the issue by using instead an emty file remove_DLL_System32.txt since that is the change for latest version.

 

The removal of Extra 1450 DLL files according to remove_DLL_System32.txt is most likely the cause of your issue

As earlier stated you should discuss your own modded OS in your thread Get-alladafluff-out

In his thread it is preferred to discuss only making Mini-10x64 from Fresh Installed Win10x64 in VHD and using Microsoft Basic Display Adapter

[wimb]

Update Download:  from wimb GitHub  -  Win_Reduce_Trusted-55

 

Download File E = Encrypted PassWord = bootwimb

 

Update Manual:   VHD_WIMBOOT.pdf   - Download: Win10_2004_English_x64.iso for smaller size

 

- Added - DLL Files Checkbox to Select Remove Extra 1470 DLL Files from System32 using File_List  remove_DLL_System32.txt

- Changed - keep_SysWOW64.txt - Remove most KBD*.DLL but keep US ES FR GR IT -  Added virtdisk.dll for VHD Manager

- Changed - keep_WindowsApps.txt as to let Remove Microsoft.DesktopAppInstaller

 

Now the magic limit of 15.000 Files has been passed ......

 

And the UsedSize = 1.36 GB for Win10x64 with PowerShell x64 and 32-bits App support !

 

== 

[antonino61]

ok sorry about the off-topic.

 

the new version is excellent. now, taking a cue from ur idea of mini-10 and, for that matter, mini-11, would it not be better to move \windows\assembly and \windows\Microsoft.NET out of the vhd and junction both back in? I have noticed their status and behavior fall pretty much more under the realm of the added software than not, as very few of us use apps that rely on them and for purposes that lie far beyond what u have envisaged with mini10 and mini11 (btw, they both work on both systems, because they are pretty much the same, I have tried them and had no issues). plus, together they take as much space as 1.5gb, for non-basic software (if it had been basic, its functionality woulda been included in the mini_system). what do u say to that?

[wimb]

Microsoft.NET 4.0 x64 is included in Mini-10x64 and is needed for PowerShell and for Advanced FireWall Settings.

Microsoft.NET 4.0 x64 and assembly folders are in my opinion belonging to the desired core of Mini Windows 10x64

 

I copy a lot VHD files nowadays and it is preferred that the interconnected parts of the OS are in 1 file.

 

That is also the advantage of Compact over WimBoot, that the copied VHD file is always working OK

without the need to Fix the connection of different parts of the OS.

 

We try to stop all Windows Updates with the WUB Blocker and try to Block all Telemetry Contacts with Microsoft.

I just discovered that there is still a leak somewhere, since assembly folder is growing unwanted.

Don't know yet how this Update works but it must be Blocked as well .....

 

I wish that Mini-10x64 does Not change at all and that there is No Internet Traffic when connecting to internet.

[antonino61]

Then u need to zerobyte a lot of folders, as I do, but the growing of assembly is new 2 me. Whenever the system boots up, I select c: in swiftsearch and press enter: the growth I get is where in users I have not yet zerobyted the folders concerned. No sign of assembly or .net.

[antonino61]

As for wimboot baking, whether full vhd or not, whether with .net and assembly in or out the vhd, the wrapping up works fine here.

[wimb]

Yes, but I think you use LTSC and Not  Win10_2004_English_x64.iso

May be in your case assembly is not updated and remains stable ....

[antonino61]

No update blocking? I'll try the versions u suggested (10 and 11) and see if zerobyting will help.

[antonino61]

well, the initial cleaning with toolkit went seamlessly (1st time in my life) with the win10 iso u suggested and left me with a lot more free space than the LTSC had done. tomorrow I will see if the debloating and reduction "keep the promise". the test is being carried out on equal conditions, otherwise ... what kinda test would it be?  

btw, I have been thru a half-hour uptime and, no sign of a bulge whatsoever in used space or respective shrink in free space, so I presume no major "spontaneous writing to vhd" - so far so good. 

[antonino61]

well, reduced seamlessly! used space 1.75gb with all my favorite functionalities, much better than LTSC - and it still wants further pruning! Wimb's right again!!! Attaboy, Wimb!!! 

the .net stuff has grown a bit (some 500 megs (assembly)).

the vhd stays with a 700meg free space. wanna see if the zerobyting will help.

 

Will be testing the win11 one this evening and see how it goes.

[wimb]

well, reduced seamlessly! used space 1.75gb with all my favorite functionalities, much better than LTSC - and it still wants further pruning! Wimb's right again!!! Attaboy, Wimb!!! 

the .net stuff has grown a bit (some 500 megs (assembly)).

the vhd stays with a 700meg free space. wanna see if the zerobyting will help.

 

Will be testing the win11 one this evening and see how it goes.

 

Nice to hear about your results. Also in your case assembly is growing a bit.

May be we can stop the Update of assembly and Microsoft.NET ....

 

I did Not use Toolkit since Win_Debloat is doing the Un-Install of Apps and Features and Capabilities.

So in my view Toolkit is an unnecessary extra step ......

 

It helps a lot that we agree about using the same source, which is favorite by alacran

Now we can better cooperate in making progress in solving the issue of unwanted Updates for assembly and Microsoft.NET

[antonino61]

2 mysteries for now:
1) how come normal iso yields a 500meg smaller product than ltsc?
2) how can anything get updated if we have blocked the updates?

[gbrao]

I'm not sure this will help, but ...

 

Regarding the size of the assembly folder, I remember long back I was having the same problem, that was with Win 7.  The size of the Windows installation would suddenly increase.

 

What I did then, and still do even for Win 10, is run "Easy Ngen (.NET Framework) Runner v5" by burfadel (option 3 I think).

 

See burfadel sig in this post : https://forums.mydig...-9#post-1385452

the link is still active.

 

This will not reduce the size of the assembly folder. As I understand it this will create all the files that are normally created in the background by windows. So the size of assembly will not increase any further, after it is run.

 

Hope I correctly understood what you guys were saying, LOL.

 

I run that script just before creating the final wim of my Windows + apps.

[antonino61]

I don't know if it's just what we were saying, but the assembly folder was some 700megs yesterday and it's 1.5gb today.

[gbrao]

With Win 10 64-bit LTSC 2019 this is what I have : see image attached.

 

[antonino61]

With ltsc I had assembly the same size as urs and framework some 1.2gb, while now with normal iso I have assembly 1.5gb and framework 500meg.

[antonino61]

btw, now I am witnessing a "strange" behavior - selection input text missing from some applications (also button text is missing, but mouse-over text is visible. the rest of the text is visible ok all over the interface, etc. have I messed up the en-gb, en-us, it-IT or something? if so, where shall I put what back?

 

hell no!!! it is not text that is failing but the designing of mouse clickable space, which gets so little at mouse over as to hide the text inside - some dll or other.

 

all's well that ends well, even though it is never over with - problem solved by reintegrating syswow64 dlls from the previous reduction. whether I shall be able to tell u in minutes which dll restored text in apps is another kettle of fish, or a different fish of the same kettle, as u like it. Così è se vi pare. hope to see u in a bit in order to share the name of the culprit dll.

 

well, I have found the culprit to be related to the syswow64 checkbox. in a bit i will be able to tell u exactly which file.

 

I have found a 33-file difference between the two lists before and after the restoring of the function.

 

while perusing both lists for the possible culprit(s), I have found that the mfc1xx.dll files are language-bound, so any of us can keep those related to the languages desired and discard all the remnant, I guess. Well, not damn likely - I guessed wrong - Never again!

 

In a bit.

 

textshaping.dll? let us see if there are more of the kind - WindowManagementAPI.dll?

 

well, folks, it was textshaping.dll, which I have included in my keep_syswow64 list, and I strongly advise u do so too (apparently, several applications still look for this version, even though we have the system32 version as well in the system).

[wimb]

Update Download:  from wimb GitHub  -  Win_Debloat-36  and  Win_Reduce_Trusted-56

 

Download File E = Encrypted PassWord = bootwimb

 

Update Manual:   VHD_WIMBOOT.pdf   - Download: Win10_2004_English_x64.iso for smaller size

 

I think assembly growth issue in Mini-10x64 VHD is solved

 

- Changed - Win_Debloat - script disable-tasks.ps1 is changed so that .NET Tasks are Removed

- Changed - Win_Debloat - Default Uncheck WinTel Block Telemetry so that a lot of Blocking FireWall rules are Removed

- Changed - Win_Reduce - File_List   remove_MS_NET.txt is changed so that assembly folder is Removed in Mini-10x64 VHD

 

== 

 

File_List  and  Folder_List  are given in   Mini_2004_US.zip   144.87KB   999 downloads

[antonino61]

generally working fine. this time I have been trying to debloat and reduce the system first thing after install. going fine, I was saying, ... windows\system32\oledlg.dll wants keeping instead of removing, in my view. other possible suggestions to come, sorry to have delayed the win11 test, but i wanna get it over with win10 first. last night it was textshaping.dll, tonight it is oledlg.dll. and I have seen that some apps do use the installer subfolder in windows, the one which has just been taken out. Well, since there is no telling which app will or won't use net framework, are we sure we r not better off moving it all out of the vhd and junctioning it back in, so that it can grow or shrink at its own pleasure and volition with no hindrance or prejudice to c:\? I have seen one app using 2. another using 3, yet another using 4 and not liking 3.5, ... is there any point in our becoming slaves of these trifle issues? all out and forget about it I suggest, or all in if one can afford more space. how about applications that will be using 5 and 6, will we be setting other standards?

[wimb]

@antonino61

 

Issues with missing  \Windows\SysWOW64\TextShaping.dll Or \Windows\SysWOW64\oledlg.dll

 

are introduced by yourselve,  since the supplied keep_SysWOW64.txt has these files on the list.