Windows 7 Resetbase backport

[vinifera]

there is difference between holding runtime versions of lets say VB 6

and like 5 versions of same system dll, some even as old as 5 years

yet disk cleanup for SP1 doesn't even detect it

 

so no, SxS is not cure for DLL hell

[jaclaz]

Well, it's just a linguistic nuance, SXS was introduced as a cure for DLL hell, but clearly it resulted as a largely ineffective cure, a lot *like*:

The operation was successful, but the patient died.

 

 

 

jaclaz

[dencorso]

Well, it's just a linguistic nuance, SXS was introduced as a cure for DLL hell, but clearly it resulted as a largely ineffective cure, a lot *like*:

 

The operation was successful, but the patient died.

 

Another fine alternative formulation is:

 

The patient's condition has evolved...    ... to expiry!

[vinifera]

Well, it's just a linguistic nuance, SXS was introduced as a cure for DLL hell, but clearly it resulted as a largely ineffective cure, a lot *like*:

The operation was successful, but the patient died.

 

 

 

jaclaz

 

lol this is best description ever made hahaha

respect

[dencorso]

THREED.VXD is yet another multi-version thing that had to be in Windows directories, but there were just too many of them.

THREED.VXD??? You mean THREED.VBX, of course!

[harkaz]

Well, it's just a linguistic nuance, SXS was introduced as a cure for DLL hell, but clearly it resulted as a largely ineffective cure, a lot *like*:

The operation was successful, but the patient died.

 

 

 

jaclaz

 

As a med student, I couldn't agree more.

 

The first pre-alpha tests had failed completely (program crashed) but now I'm on good track (debugging finished + important bugs fixed). I'm looking forward to the results of the first "proper" test.

 

A winsxs secret I came across and caused me lot of trouble:

 

- There are hardlinks inside the Winsxs folder between identical files, even if they are in different folders.

[harkaz]

Plus a side-note: The tool currently takes about 90 minutes to cleanup a x86 image on 1 thread, estimate 3 hours for x64 image.

I guess this could be improved somehow.

[vinifera]

dunno what exactly your prog does, but filtering helps

most of .7600. are not needed, same goes for build numbers below 21xxx

you can also nuke non en-us fonts backups and code-pages (or whatever its called)

then everything not named after your SKU

 

 

manualy, I managed SP1 + 2015 updates, winsxs to trim down on 764 MB

with more detailed crap -10 MB could go down maybe, but thats as far as it goes (32 bit)

Edited December 8, 2015 by vinifera

[harkaz]

"most of .7600. are not needed, same goes for build numbers below 21xxx"

 

Not always true, actually only the active (minimum+latest) versions of updates are needed. If you want 21xxx only, you must force LDR installation.

 

In my reference image I have installed .NET Framework 4.6 + all of its updates + ~520 Windows 7 updates (including optional components and request-only hotfixes).

I haven't properly tested it yet, but rebase reduces the image size by about 30%. Because LDR versions are active for specific components only, the 7601.21xxx+ files are kept in such cases. In some other updates, however, GDR versions are active, so the LDR versions are removed. In the end, the image contains a mix of GDR/LDR versions.

Base (minimum) versions are compressed to further reduce disk size.

 

Rebase does not remove any components.

 

Specific components like .NET, CLR, ServicingStack, common controls library, wingdi require all versions to be present so they are not touched.

 

Probably we could get lower than 800MB for x86. I will test it later.

[vinifera]

it can go up to 500 MB (without any compression)

 

also i wrote "most of 7600 are not needed"

didn't say all

 

thats why i look for counterparts (read duplicates) with 7601

 

dunno if I want to hassle with manifest files & reg hive tho, seems like a drag

I mean if file is missing then its missing, no BSOD will happen, only error dialog which would happen anyway

 

but basically win7 SP1 ++ can fit on 700MB CD, without any major loss of components

in fact the only thing that has to be sacreficed is stupid "natural language search" and .net 3

 

would be cute to see something like "tiny7"

stiffing it on 250 MB CD haha

Edited December 8, 2015 by vinifera

[harkaz]

The goal is to avoid any error messages from sfc or checksur or Windows Update.

I won't publish rebase unless it's 100% clean in this respect.

 

Peering through registry is essential to understand what should be removed and what should be kept.

[vinifera]

well sorry to say but that won't get you too far in reducing size

since you'd have to keep ALL language versions with its lesser sub-builds

 

as I see, you can only remove Backup folder and few delta files

but as you stated in 1st page (with backup folder intact) you don't clean too much

[bphlpt]

Hey harkaz,

 

It's nice to see that you are working on Win7.  It's also great that your goal is that your cleanup stays "clean" as far as sfc etc are concerned.  Your thorough approach should make things more stable and reliable even it doesn't produce as small a result as other approaches might.

 

Will your tool be able to cleanup a "source" on which you have integrated all updates in addition to cleaning up an installed system?  It would be very nice to not have to clean things up every time you install the OS.

 

Cheers and Regards, my friend.
 

[harkaz]

@vinifera I disagree with the fact that the tool does not cleanup so much on Windows 7. I said that with Windows 8.1 and later because there is /resetbase functionality already available that cleans up most redundant stuff.

 

The first proper internal test of rebase is complete:

 

No file checksum errors were found.

Need to fix the registry cleanup algorithm so as not to delete registry keys required by multiple components.

I will retest after that, because servicing of future updates currently is too slow due to these inconsitencies.

 

On a syspreped Win 7 Home Premium image (offline) with ~520 non-superseded updates fully installed, the winsxs size went down from 7296274269 bytes to 5153536273 bytes. This is a 29.36% reduction of winsxs size. Again, components inconsitencies are only registry-related, so this seems to be final.

 

@bphlpt Yes, I plan to enable support for online and offline use. Windows PE cannot be serviced online.

Edited December 8, 2015 by harkaz

[harkaz]

UPDATE: I just optimized the code and the tool runs MUCH faster than before. Let's see if algorithm is fixed...