Jump to content











Photo
- - - - -

Get-alladafluff-out

os shrinking ntlite

  • Please log in to reply
323 replies to this topic

#51 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 09 July 2020 - 11:59 AM

*
POPULAR

TrustedInstaller has full permissions at WinSxS, and TrustedInstaller is the owner.

RunAsTI64.exe
http://reboot.pro/to...d-runfromtoken/
https://github.com/jschicht/RunAsTI

This opens a command window. Use this new command window.
Change direcory to the .cmd file.

Mount the VHD image to e.g. M: To create a base winxs. run
base_winsxs.cmd M:\windows

or with language file setting
base_winsxs.cmd M:\windows en-us


M:\windows is a eample, set your offline windows folder instead.

This creates a base WinSxS folder. A copy is created, no files are deleted.
The original WinSxS is renamed to WinSxSorig* and hardlinks are created.
If windows does boot, then you may delete the WinSxSorig* folder.
NTFS permissions are changed, should work at RAM disk boot.

Yes, *isolationautomation_ and i..utomation.proxystub_ are added.
The file description is about side by side.
They are required to boot here, manufaturer Windows ISO
And x86*isolationautomation is used at 32 bit programs.
A small file size is added, I keep all four folders so far.

Should work at Windows 10 1507 up to 21H1.
Could work at Vista and up. Not tested.
This is experimental so far.


To reduce space within system32/syswow64/winsxs, create hardlinks:
RunAsTI64.exe
Run at the new command window
winsxs_hardlink_system.cmd H:\Windows

Attached Files


  • wimb, gbrao and alacran like this

#52 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 09 July 2020 - 12:21 PM

Am i missing the actual batches? :unsure:

 

base_winsxs.cmd

winsxs_hardlink_system.cmd

 

:duff:

Wonko



#53 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 July 2020 - 01:25 PM

well it looks like one hell of an adventure, but I will dare undertake it, to the best of my knowledge, ability and belief.



#54 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 09 July 2020 - 01:36 PM

Posted 59 minutes ago

where do I get the following files:

base_winsxs.cmd

winsxs_hardlink_system.cmd

?

 

me, I am on vhd1.vhd ramloaded, so I have access to a mounted vhd1.vhd ok. is the windows folder that I can reach on the mounted vhd1.vhd the offline windows folder?



#55 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 10 July 2020 - 11:15 AM

Well, while waiting for cdob's or wonko's briefing as to the availability of the two cmd files mentioned above, I tried my winsxs on the 14333 build. I also tried using the original winsxs and deleting what was not on the 19041 winsxs list: no dice --> probably different locations and different linking and file organization structure. 



#56 cdob

cdob

    Gold Member

  • Expert
  • 1469 posts

Posted 12 July 2020 - 07:47 PM

 

I am on vhd1.vhd ramloaded, so I have access to a mounted vhd1.vhd ok. 

 

Don't run this at a actuall ramoladed windows. 
Boot a regular Windows 10. Backup the file vhd1.vhd.  Mount the file vhd1.vhd 

Files are added to previous post.



#57 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 12 July 2020 - 11:53 PM

Oh, thanx, cdob, that was foolish of me not to see it, I was so concentrated on runasti64 at the top as to fail to notice ur 7z at the bottom of the post. Just downloaded anyway, better later than never. Now to start replicating what u said, I have to tell u I do not have an ordinary conventional windows installation on c: I only have vhd's which I can run either as filedisks (thru bootmgr or g4d) or as ramdisks (g4d, obviously). now since u discouraged ramloading, let us exclude the last option. as for backing things up in advance, I have long had my vhd's backed up on several disks. One more thing, all my deployable vhd's are 19041's with the reduced version of winsxs as lately amended (further shrunk) following your suggestions. now, shall I boot my vhd1.vhd and mount one of its copies and experiment it all as u said on that? I guess so from what u posted earlier. or would u (or anybody else, for that matter) rather I experimented it all on another vhd with conventional-size winsxs? waiting for your answers, I will start with what I have now and let u know.



#58 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 13 July 2020 - 12:38 AM

apart from one piece of software, firestorm (a videocard tweaker) and games (all related to directx I believe, which wont get reinstalled until I restore the original winsxs), everything seems to work with this base winsxs. I do not know what else does not work. I will not delete the original winsxs now, unless u suggest otherwise. the following command u suggested (creating hardlinks) did add a few items in winsxs (I also ran the same command on the original winsxs, and the operation added a few items here as well). anyway, the difference in overall folder size between the new winsxs and the original winsxs is slight (83 to 90 megs), but the difference in file count is huge (2 hundred to 9 thousand). 



#59 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 13 July 2020 - 03:11 AM

well, I managed to get a base winsxs folder working by re-adding the manifests folder from the original. the spacegain in terms of overall folder size is 74mb instead of the original 90mb, whereas it is negative in terms of file count (about 9400 instead of the original 9200). this time I eventually did delete the original winsxs.



#60 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 13 July 2020 - 01:32 PM

in the meantime, ... not an off topic for sure - since I am a massive copier and backupper, I really would not care about recycle bins. is there any way ever in the world of getting rid of it completely? it would only serve the purpose of getting more free space on the drives. I do not need the basket, really. should I delete something important by chance,  i can get it from the copy.



#61 wimb

wimb

    Platinum Member

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

Posted 13 July 2020 - 06:18 PM

TrustedInstaller has full permissions at WinSxS, and TrustedInstaller is the owner.

RunAsTI64.exe

....

Mount the VHD image to e.g. M: To create a base winxs. run
base_winsxs.cmd M:\windows
....
To reduce space within system32/syswow64/winsxs, create hardlinks:
RunAsTI64.exe
Run at the new command window
winsxs_hardlink_system.cmd H:\Windows

 

Just to report that the batch files are working fast and OK. :)

The WinSxS folder is reduced and Windows in VHD is still booting OK   :thumbup:

 

VHD WimBoot is probably more useful to reduce Windows size for booting VHD from RAMDISK  :)

 

base_winsxs.cmd  ==  winsxs_hardlink_system.cmd == Booting VHD after WinSxS_reduce

==  ==  

 

Mounted VHD as seen in FreeCommander - R: Reduced VHD compared to P: Original Copy of VHD

== == 



#62 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 July 2020 - 04:00 AM

I wanted to test cdob's commands on a mounted VHD and all went fine and very fast, VHD rebooted fine.

 

Then I wanted to delete the new WinSxSorig23690 folder:

 

Having the VHD mounted on J:, first I tried to delete it directly on the Win10 OS, it didn't work, then tryed:

 

RunAsTI64.exe

>del J:\windows\WinSxSorig23690

 

It ask if I'm sure, I answered yes and it goes to C:\ and don't delete the folder.

 

Any ideas?

 

 

alacran



#63 gbrao

gbrao

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    India

Posted 14 July 2020 - 04:57 AM

TrustedInstaller has full permissions at WinSxS, and TrustedInstaller is the owner.

RunAsTI64.exe
http://reboot.pro/to...d-runfromtoken/
https://github.com/jschicht/RunAsTI

This opens a command window. Use this new command window.
Change direcory to the .cmd file.

Mount the VHD image to e.g. M: To create a base winxs. run
base_winsxs.cmd M:\windows

or with language file setting
base_winsxs.cmd M:\windows en-us.....

 

Can I use this for a regular Windows 10 install (installed to a partition)?



#64 wimb

wimb

    Platinum Member

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

Posted 14 July 2020 - 05:43 AM

I wanted to test cdob's commands on a mounted VHD and all went fine and very fast, VHD rebooted fine.

 

Then I wanted to delete the new WinSxSorig23690 folder:

 

Having the VHD mounted on J:, first I tried to delete it directly on the Win10 OS, it didn't work, then tryed:

 

RunAsTI64.exe

>del J:\windows\WinSxSorig23690

 

 

 

In the Trusted Installer Command Window you can use RD to delete a complete directory tree. For my case of folder WinSxSorig9889 I used:

I:\WinSxS_reduce>RD /?
Removes (deletes) a directory.

RMDIR [/S] [/Q] [drive:]path
RD [/S] [/Q] [drive:]path

    /S      Removes all directories and files in the specified directory
            in addition to the directory itself.  Used to remove a directory
            tree.

    /Q      Quiet mode, do not ask if ok to remove a directory tree with /S

I:\WinSxS_reduce>RD /S /Q R:\Windows\WinSxSorig9889

I:\WinSxS_reduce>

== ==

 


  • alacran likes this

#65 gbrao

gbrao

    Frequent Member

  • Advanced user
  • 474 posts
  •  
    India

Posted 14 July 2020 - 09:09 AM

Can I use this for a regular Windows 10 install (installed to a partition)?

Yes. Worked with a 32-bit modded Win 10 installed to a partition. Thanks a lot, wanted something like this for a while.

5.15 GB to 3.63 GB !

 

btw, I ran the cmd from a Win 7 PE, did not need RunAsTI.

Also to delete the orig WinSXS.

 

EDIT : I don't know if WinSXS_reduce caused it, or it was originally present : After running reduce_winsxs I ran chkdsk - it did find and correct some errors.

Running chkdsk is what I always do after modding Windows.

Attached Files



#66 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 July 2020 - 09:28 AM

Well, I can see that we are getting somewhere! I will now try it all on a conventional winsxs folder, bearing in mind that 5gb reduced to 3gb is something, but still a long way from 90megs reduced to 74megs with the albeit unorthodox winsxs folder I have used on the 19041 build for the past few months.



#67 wimb

wimb

    Platinum Member

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

Posted 14 July 2020 - 09:46 AM

After WinSxS_reduce I used VHD_WIMBOOT to Capture and Apply to New VHD in WimBoot mode and in Normal mode.

The used size of the VHD drive is only 523 MB in WimBoot mode but it is still 10.9 GB in normal mode (instead of 19 GB before using WinSxS_reduce)

 

It means that in case of Win10x64 that WinSxS_reduce will give initially extra free space of 824 MB but that Capture followed by Apply will increase the extra Free space to 8.1 GB.

On the other hand the most important reduction of Windows Size is obtained by using WimBoot mode so that it really can be used in small VHD booting from RAMDISK.

 

==  == 

 

EDIT: After WinSxS_reduce the size of the captured WIM file is 2.5 GB smaller being now 5.6 GB instead of originally 8.1 GB as shown in the attached picture.



#68 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 July 2020 - 02:00 PM

I ran RunAsTI64.exe + base_winsxs.cmd J:\windows es-mx from a Win 10 OS to reduce winsxs folder on a mounted VHD (J:) and it booted fine, then removed the backup folder with following commands:

 

RunAsTI64.exe

RD /S /Q J:\Windows\WinSxSorig*

 

Latter tested gbrao approach booting from a Win7x64PE and  mounting the VHD, this time without RunAsTI64.exe, just ran base_winsxs.cmd with same result, also I was able to delete the backup folder directly from Win7x64PE Explorer without any issue.

 

Quoted from gbrao post No. 65

 

btw, I ran the cmd from a Win 7 PE, did not need RunAsTI.

Also to delete the orig WinSXS.

 

Latter I tryed RunAsTI64.exe + winsxs_hardlink_system.cmd J:\Windows, it ran fine but when rebooting to test it on old hardware once on Windows screen, I opened Classic Shell menu and the OS froze and I was forced to reboot.

So if you want to be able to boot your VHD from a USB device on multiple hardware or you are using Classic Shell I recommend don't run winsxs_hardlink_system.cmd to be on the safe side.

 

alacran



#69 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 July 2020 - 03:41 PM

So if you want to be able to boot your VHD from a USB device on multiple hardware or you are using Classic Shell I recommend don't run winsxs_hardlink_system.cmd to be on the safe side.

Maybe only one or two (or a few) files/hardlinks were deleted in excess.

 

The experiment would be to find which are these files.

 

But I am somehow missing the "or" relationship.

 

I mean, if too many files were removed EITHER the VHD will fail to run properly (without running Classic Shell) when hardware is changed OR system will freeze/lock when starting Classic Shell (on the same hardware or no matter the hardware), or if you prefer, the "excess" removal either affects Classic Shell or it affects portability on different hardware.  :dubbio:

 

It would be a rare case where a same issue is triggered by two very different changes (running a program/shell vs. changing hardware). :unsure:

 

:duff:

Wonko



#70 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 July 2020 - 03:53 PM

Wonko has a wonderful point, I guess, and I would be happy to contribute to solving only the first half of his point. As for wimb's findings, I bet he meant "without ticking lzx" when he said size was 10.9, and "plus the *.wim" when he said "523mb".



#71 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 July 2020 - 07:39 PM

Hello again, ppl. well, I can see that it works better than my "oprekin-transferred" one if one does it on one's own system: reboot.pro beat oprekin 72megs to 90megs (lower is better). if I carry out the same procedure (as we all are saying, all cdob's, wimb's, alacrán's commands work) on an oprekin-winsxs system, it yields a 1meg-lesser (71) winsxs (not so much of a shrink). what remains, at least here, is still the directx-based software and firestorm (a videocard tweaker) not working until I copy the manifests subfolder from the winsxsorig* back to the newly created winsxs. Here comes a splinter of wonko's observation --> I am not convinced I need all the contents of the original manifests folder (9 thousand files or so), but only a few of them, if only I knew which ones! for the time being, my comfort is that those 9 thousand files occupy only 15megs of the 72megs on disk. I am still curious to know, though.



#72 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 July 2020 - 07:48 PM

and, ... don't get me wrong, oprekin might as well have carried out the same procedure to yield the 90meg winsxs, but he did not say he did or did not (I did ask him, but got no reply). so, I think it is a reboot.pro win, as well as a triumph of science over magic.



#73 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 July 2020 - 02:46 AM

What I can say is cdob's commands are very easy to run on each user OS, there is no mistery or forced donations involved, they do not distribute any MS patented software, and also you do not have to download several GBs of oprekin modded OS (illegally distributed) with who knows what else inside.
 
I know for RAM booting it is better a Wimboot install, but in this case my Win10 1909 (filedisk bootable) is a full install on a 6 GB VHD (fixed size) including Office 2003 + compatibily pakages, FireFox browser + other prgrams, and also some portable programs but without page file, (CR)Apps, drivers or AV and it's installed on Compact 4K mode (native on Win10) and fully defragmented with Defraggler (I usually run it from a 32 GB fast MicroSD +USB 3.0 adapter).:

 

Total used space on the VHD before reduction: 4.92 GB

Total used space on the VHD after WinSxS reduction: 3.97 GB

 

As you can see it fits fine on a 6 GB VHD (using less space than a Wimboot VHD + source WIM file couple), and space comsumption can be reduced using let's say a 5 GB fixed VHD or even less consumed space on the USB device using a expandable VHD

 

@ Wonko

Yes, I'm agree with you, my recommendation includes 2 diferent causes of the issue (but I think in some way connected), unfortunately all my allready made VHDs have Classic Shell last version installed, and I'm not interested in testing furter since the PC allready has all required OSs installed.

Only thing I can add is the VHD with Win10 1909, during testing booted fine on this old hardware, until I opened Classic Shell Boot Menu.

My first idea is there is a compatibility problem with comctl32.dll last version, this issue has also very high risk to be present on any other old device software/driver, so to be on the safe side better don't apply winsxs_hardlink_system.cmd if you are booting a win10 VHD from a USB device and you want THE BEST portability (even on old hardware) or have Classic Shell Boot Menu installed, I hope my recommendation makes more sence now.

 

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

I booted to this PC only for testing purposes, in no way I want to run that VHD from it on a daily base.

My old PC for old games:

Gigabyte GA-G41MT-S2 v1 MB
DualCore Intel Pentium E5700, 3000 MHz (15 x 200) socket 775
4 GB RAM at 1066 MHz
Gigabyte NVIDIA GeForce GT 730  (2 GB)

I keep this PC because I have several partitions to multiboot : XP-SP3 x86, Win7x64 and Win10x64 to be able to run all my very old games that only run on certain OS.

alacran



#74 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 July 2020 - 08:42 AM

Hey guys, I don't really see the problem.

 

The cdob's batches are NOT a take it all or nothing proposal :w00t:, they can be modified (or - even more simply - one could write a post-process batch re-adding the missing files).

 

Of course which files are actually needed has to be determined.

 

In the case of a missing file, tracing the behaviour with Filemon (or with Dependency Walker, or both) should be relatively easy and straightforward to find which files are missing.

 

In the case of a "wrong" version of comctl32.dll (or of other .dll) it might be much more complex, but it is still possible with a little patience.

 

:duff:

Wonko



#75 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 July 2020 - 09:24 AM

In this old PC PC I have Windows 10 Pro x64 1709 installed, but without Classic Shell, in order to make a quick test I made a backup using wimlib-clc to Win10x64.wim, then from a Win7PE just ran base_winsxs.cmd followed by winsxs_hardlink_system.cmd, both ran fine, the OS booted fine, but now the Avast UI is not able to run, see attached picture.

Latter I installed Classic Shell, and on this 10 1709 wich has several comctl32.dll but now all from 2017-09-24, it run very fine.

So this new issue with another program (Avast in this case) confirms to me keeping a single (no matter if it is the newest) date versions of comctl32.dll can cause issues with some programs.

 

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

 

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

 

alacran

Attached Files




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users