Antonino

attaboy jfre84. gonna try it out. now @everyone do not junction the following files and folder \progran files\windowspowershell \windows\system32\windowspowershell \windows\temp from anyplace else, or some powershell2-relying or wmi-calling programs may not run properly (it is certainly the case with microwin, inside Chris Titus' winutil.ps1). For the same reason, do not touch the following files and folder \windows\system32\microsoft \windows\system32\mispace.dll \Windows\System32\storagewmi.dll Still for the same reason, do not zerobyte the following folder \Users\USERNAME\AppData\Local\Microsoft\Windows\WebCache and now @jfx and @wimb your minwinning and wimbreducing respectively do not delete the following windows subfolders attached herein. To the best of my knowledge and remembrance, they have been left there because they are too small in size for anyone normal to quibble as to whether they serve any apparent practical purpose or not. As a notorious file and folder exterminator, I have been doing without them for quite some time now, with no hindrance or prejudice to any software functionality. I would like you to differ if you know or believe it is not so or confirm if you know or believe it is so. Thank you ever so much in advance. FolderListJFX.txt FolderListWimb.txt

says the file is infected with a virus

@ibay770 btw if u run this after install, ur system will be all the quicker disableservices.bat @JFX if u can tell us how the above file's content can effectively be integrated or embedded somewhere in winntsetup.exe for use during the install procedure, we would pretty much appreciate it without having to do it after install.

attaboy, then. now tell me if u have taken advantage of sample.ini in the tweaks section. if u have, just open the file with notepad or the like and erase all the semicolons. u can safely remove the appx's listed. I can also give u my version, with more appx's to be taken out. btw, how big is ur vhd? copy it rename the copy differently. make sure u cam boot off both of them. this way, if u modify vhd1 and something has gone wrong, u will still be able to reboot off vhd2 and copy it back on vhd1 so u will be back to your most recent best. no need to backup or restore anything - it is its twin which is its best backup version, the restore one being the vhd you will have copied back to the one that went wrong. if u have more than one disk u can have an omonymous vhd, as u will no longer need to change its name. d'dya get da drift?

guess i've already told u about that; anyway, after 11 my time I'll ask Virgus to explain it to u in more detail - not that easy, believe it or not. as far as the whole windows reduction process is concerned, have u installed win10 or win11 on a vhd yet? that is what I meant when I asked u whether u were ready for more. pls let me know.

ready for more, ibay?

well, as regards scraping off as much as possible from reboot.pro, I guess Virgus tried something of the kind, but as far as I can remember, he did not consider the initiative worth his while taking. only bits and pieces, and... what we really miss is the immediate interaction with the pundits there. scriptwise, Virgus is very good at writing scripts, so when he is not caught up with something else, he usually comes up with something useful. I usually test what he does - so far so good. me, I have good memory to keep track of wherever whatever is at. files, folders, junctions, etc. I usually go by intuition and/or by trial and error. so while waiting for Virgus to continue all the work done so far, I can tell you what scripts turned out alright. a couple of mine are actually empirical .reg files. say I have customized an os vhd and wanna try to customize another one, there is actually no need to do it all again from scratch, so I exported a few registry entries concerning my customization on vhd1.dhd and imported the same on vhd2.vhd. it is not a script but this is something close to what u mean. in these respects, I have been able to automate the repetitive. of course if u do not like my colors u cannot use them regs at once, u would have to do some tweaking inside. to give u a clue, this is the second stage, the first one being the install thru winntsetup. it will take care of most of it from scratch. just grab it and install an iso u already have and then u will recontact me as to what it is not yet clear. c u in a bit.

well, I'm back home, so I can answer u tenet by tenet what got reboot.pro shutdown, lack of funds for hosting? you are quite right Would it help to revive it? this is Virgus's idea, which I totally espouse, and I guess u would as well - virgus calculated that if 10 of us contributed €10, that would make €100. there is only one problem, nuno, the keymaster of reboot.pro, is unreachable. we lost track of him and the site masters probably don't feel authorized to let us know how he can be contacted, if I have understood correctly, but I guess Virgus could be more specific about it. or should we perhaps use this as the replacement? This is my idea for the time being, but I haven't gotten so much feedback as I used to on reboot.pro. JFX's answers are slow but sure, though. "great space gains can be obtained in shrinking the following folders: winsxs, driverstore, and some other ones as well." Curious how to shrink those, can it be done with a batch file? some bits can, while others can't. be ready for a plethora of instructions on the matter. I'm all for a tinyOS, I think a guy on the archive got a winPE of win7 to 65mb, winPE is the inspirational software for what we r doing, but I guess we basically do it the other way round. one could also go about adding things to winPE, whereas we tend to subtract things from an os. winPE is not an os proper, and does not keep any settings across reboots. I know ntlite has ways of deleting winsxs but it costs money. no need for ntlite or similar stuff. jfx's winntsetup, which can be downloaded here does most of the job. check it out and go to the tweaks section which shows a sample.ini where he commented out some appx to be kept; I took out all the semicolons I found in front of those appx because I do not need any of them (this concerns the 3rd section of the file, as the first 2 should be left as they are. In liew of ntlite, chris titus has offered his winutil.ps1 which, among other things, has a microwin function that does about the same, the only drawback being it does not take wims or esds, only isos with wims or esds within them. A guy tried to slim to down windows and make a win10to7 project but he got crucified in the comments so he stopped it: https://forums.mydigitallife.net/threads/project-10to7-slimming-down-debloating-windows-10.76459/ Virgus would find this interesting I know strelec who made a winPE, has unique ways of making his images on the smaller side, for example net framework is only extracted and added to the ramdrive if a program calls for it. we do something similar, but our net framework and vc++ are phisically on d:\ (the physical c:\ hosting the vhd) and logically junctioned back into c:\ (the vhd), just in case a program calls for it.

Interesting tenets - I am out on my smartphone - I'll get back 2u as soon as I get home

I think the clover method is feasible, as I surely read a description of it years ago, which applied to the hackingtosh, but I frankly can't remember, nor do I know how it's done. Never got around to it, honestly. As for win7 in uefi mode, I suggest u ask virgus, who still uses win7 from time to time. U will have noticed we use win10 and win11 as we would have win7. and this is what I would be going to tell u about if u need or wish to try it to. for the time being, I started decades ago with the following vision: why can we not postulate a core of files and folders that enable the os to reach the interface (to arrive at the desktop, so to speak)? this must inevitably reside in c:\. that said, why don't we move the rest on another drive and junction it back to c:\. this is how the vhd idea became useful for containing the core files and folders, those files and folders that the system could not tolerate out of c:, as it did not have the junction system activated to accept them from other locations. so the first challenge was to ascertain which files and folders should be left on c:\. so I saw windows as a combo of booting core, other system files sitting out of the vhd (program files, program files (x86), program data, a few files and folders from \users), and finally the 6 special folders containing work files and all the rest of applications that do not necessarily have to stay inside the vhd. the system would have as few apps as possible installed (just the strictly necessary) and the rest on a portable basis (no location restrictions for them, so, out of the vhd, obviously). I went on like this for a few years, trying to experiment what could still stay out of the vhd, what could be deleted as the system did not need it, and so on and so forth, trying to make the system smaller and smaller, participating in a forum called reboot.pro (which has been down for a cople years now). until wimb, whom I call the Flying Dutchman, a very pragmatically-minded fellow from Eindhoven, told me I did not need to make all this hustle and bustle moving files and folders out and juction them back in again, as he had devised a different deployment strategy which he called wimboot (surely after himself). he added it was a small version of windows most of which was in *wim form (a windows image) connected to a very small vhd containing references pointing to files and folders (the equivalents of the core folders and files I initially had a vision of) but with less hustle and bustle. a wimboot software would take care of the installation process and even allowed u to choose between regular setup and wimboot setup. spacewise it was a very useful clean and consistent idea and practice, but the wim image structure made it all the slower. after years and years of trials and errors, we bumped into a very knowledgeable windows-reducing scholar named jfx, who by very concrete methods reduced the vhd ever further with no hindrance to speed. the closure of reboot.pro was a very hard blow though, so most pundits once working on and for the windows-reducing cause seemed to have lost their enthusiasm. the survivors of that crew are apparently virgus and I. we have actually tried to involve the old'uns back again, but to no avail so far. so I and virgus have reduced the vhd proportionally further, if u consider that most of them claimed they used this vhd-based windows as something between a hobby version and a trial version and advised that everybody should do so to. well I have always been one who treats the vhd solution as a regular one, as it is much neater that the regularly installed os. great space gains can be obtained in shrinking the following folders: winsxs, driverstore, and some other ones as well. I am ready to help anybody out in this initiative, as I want to share a much better OS scenario.

@jfx On the basis of the component store reductions made by you and wimb through the years, Virgus and I have now made a list of generalized winsxs that have apparently enabled all the software we have to work with no hindrance whatsoever. this list is here below. to the best of ur knowledge and belief, can u tell us if there are any redundancies that we can "safely" throw away and/or any elements that we have missed out on? Thanx in advance. amd64_microsoft.vc80.atl_ amd64_microsoft.vc80.crt_ amd64_microsoft.vc80.mfc_ amd64_microsoft.vc80.mfcloc_ amd64_microsoft.vc80.openmp_ amd64_microsoft.vc90.atl_ amd64_microsoft.vc90.crt_ amd64_microsoft.vc90.mfc_ amd64_microsoft.vc90.mfcloc_ amd64_microsoft.vc90.openmp_ amd64_microsoft.windows.c..-controls.resources_ amd64_microsoft.windows.common-controls_ amd64_microsoft.windows.gdiplus.systemcopy_ amd64_microsoft.windows.gdiplus_ amd64_microsoft.windows.i..utomation.proxystub_ amd64_microsoft.windows.isolationautomation_ amd64_microsoft.windows.systemcompatible_ amd64_microsoft-windows-c..panel-adm.resources_ amd64_microsoft-windows-com-dtc-runtime_ amd64_microsoft-windows-com-dtc-runtime-log_ amd64_microsoft-windows-com-dtc-runtime-tm_ amd64_microsoft-windows-deployment_ amd64_microsoft-windows-i..ntrolpanel.appxmain_ amd64_microsoft-windows-international-core_ amd64_microsoft-windows-s..-binaries.resources_ amd64_microsoft-windows-s..ccessagent-binaries_ amd64_microsoft-windows-s..cingstack.resources_ amd64_microsoft-windows-security-spp-ux_ amd64_microsoft-windows-servicingstack_ amd64_microsoft-windows-servicingstack-inetsrv_ amd64_microsoft-windows-servicingstack-msg_ amd64_microsoft-windows-servicingstack-onecore_ amd64_microsoft-windows-shell-setup_ amd64_microsoft-windows-t..languages.resources_ amd64_microsoft-windows-t..panel-adm.resources_ amd64_microsoft-windows-unattendedjoin_ amd64_microsoft-windows-userexperience-desktop_ amd64_policy.8.0.microsoft.vc80_ amd64_policy.9.0.microsoft.vc90_ Backup Catalogs FileMaps Fusion InstallTemp Manifests migration.xml SettingsManifests Temp x86_microsoft.vc80.atl_ x86_microsoft.vc80.crt_ x86_microsoft.vc80.mfc_ x86_microsoft.vc80.mfcloc_ x86_microsoft.vc80.openmp_ x86_microsoft.vc90.atl_ x86_microsoft.vc90.crt_ x86_microsoft.vc90.mfc_ x86_microsoft.vc90.mfcloc_ x86_microsoft.vc90.openmp_ x86_microsoft.windows.c..-controls.resources_ x86_microsoft.windows.common-controls_ x86_microsoft.windows.gdiplus.systemcopy_ x86_microsoft.windows.gdiplus_ x86_microsoft.windows.i..utomation.proxystub_ x86_microsoft.windows.isolationautomation_ x86_microsoft.windows.systemcompatible_ x86_microsoft-windows-c..panel-adm.resources_ x86_microsoft-windows-com-dtc-runtime_ x86_microsoft-windows-com-dtc-runtime-log_ x86_microsoft-windows-com-dtc-runtime-tm_ x86_microsoft-windows-deployment_ x86_microsoft-windows-i..ntrolpanel.appxmain_ x86_microsoft-windows-international-core_ x86_microsoft-windows-s..-binaries.resources_ x86_microsoft-windows-s..ccessagent-binaries_ x86_microsoft-windows-s..cingstack.resources_ x86_microsoft-windows-security-spp-ux_ x86_microsoft-windows-servicingstack_ x86_microsoft-windows-servicingstack-inetsrv_ x86_microsoft-windows-servicingstack-msg_ x86_microsoft-windows-servicingstack-onecore_ x86_microsoft-windows-shell-setup_ x86_microsoft-windows-t..languages.resources_ x86_microsoft-windows-t..panel-adm.resources_ x86_microsoft-windows-unattendedjoin_ x86_microsoft-windows-userexperience-desktop_ x86_policy.8.0.microsoft.vc80_ x86_policy.9.0.microsoft.vc90_

while waiting for ur answer, I will get back to what I was gonna tell about ur double booting (mbr and uefi). If u want to get full grasp of what u r doing, I suggest that u stick to mbr only. from a vm-based perspective, I do not know if uefi+mbr is possible, because I never use virtual machines. but decades ago I started to use virtual disks (vhd's) on a real machine, which entails one bootmgr outside the vhd (on d:\, which hosts the vhd as c:\) which starts the boot process, and one bootmgr inside the vhd which takes over the boot process from the former bootmgr I mentioned. alternatively, this scenario might as well entail ur double booting (uefi outside and mbr inside the vhd). u will have figured, I hope, that this vhd is a file that pretends to be a disk drive, which sits someplace in the real drive and logically takes the letter c: - as a result, the real c:\ takes the letter d:\. the idea is to reserve the vhd for what strictly is the os, and place whatever else on d:\ or any drive other than c:\. we want this vhd to be as small as possible, in order to fit into the ram for rambooting, but if u do not mind I would leave this aspect for later. for the time being I can tell u that we would have a clean system where only the strictly necessary gets installed and the rest can reside wherever u like as long as it does not get in the system's way. the only possible solution is resorting to portables. getting back to the booting, u can have a uefi loader on what the system will call d: (the physical c:\ drive) and an mbr loader on what the system will call c:\ (the vhd). so in this other case the answer is yes, and it is the solution adopted by those who have new-generation mobos that do not envisage legacy booting (they are forced to do so if they wanna enjoy the advantages offfered by vhd os's). pls tell me what is not clear so far, before I risk confusing u any further.

one thing at a time, pls. I will now answer the latter, as it is a sheer no and nothing more, unless u mean vhd booting. I will leave this one at that for now, and move on to the former question of urs. but it is not a one-minute matter. so pls tell me if u r ready to listen, ask further questions, get clarifications and so on and so forth. I have a strong tendency to prolixity, just to let u know in advance.

... and yes, over 95% of winsxs can be moved out of c:\ and junctioned back in again. Good old Wimb, the Flying Dutchman, has provided a feature reducing winsxs which, alas, does not serve all the applications. in order to keep it all working one can move most of the content of the folder to, say, d:\ and junction it all back to c:\Windows\winsxs to have it all there, at least logically, but physically leaving c:\ so small as it has been this far. i think it is worth ur while trying it out.

well, what else on the files&folders dept? do not get rid of \Windows\System32\MicrosoftEdgeBCHost.exe \Windows\System32\MicrosoftEdgeCP.exe \Windows\System32\MicrosoftEdgeDevTools.exe \Windows\System32\MicrosoftEdgeSH.exe \Windows\winsxs\catalogs if u still wanna keep good command of windows features on and off, even after severely pruning or minwinning ur vhd.