Antonino

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.

hell no, I had not known anything about it until u mentioned it above, Then I checked mine to see if it was off (00000), which it was. a big thanks for telling.

and, yet another caveat. do not take out c:\windows\globalization\ICU if u want ur most recent winhance to work.

BTW, another caveat, before I forget to tell you: cleaning ur windows side-by-side configuration folder (winsxs) might leave u unable to run certain software that usually worked before. no worries. make a backup of the folder and place it anyplace else but where it's at, and then run the cleaner. Once u spot the software that halts as a result, copy the backup back to its original; rerun the software - now it will work. Once u make sure of this, leave the software running and try to delete the whole content of the winsxs: u will not succeed in it because, while the software is on, it involves a few winsxs subfolders that have open files. Now copy this select list of subfolders and elsewhere and keep them in a folder named, say, "softwarename"sxsstuff. u can now have the whole winsxs back again where it should be at, rerun the cleaner and add the content of softwarenamesxsstuff back to where it was before the cleaning, and u r good to go. I am sure you will find it much simpler to do than I have explained.

Attaboys!!!

windows version u mean? ?querés decir la versión de windows?

thank you, I'll check it out and let you know.

@JFX btw, sometimes I get a "could not copy the offline registry" message at the end of the minwinning procedure. Any idea how to troubleshoot it? if I try to reboot this specific vhd, it gets stuck at the first stage of the booting process saying it could not find system or system is corrupt; instead, if I copy the whole config dir to the windows\system32 subfolder before rebooting, everything goes spick and span, also the letter z:\ for ramdisk which, as I mentioned in earlier posts, was loaded as j:\ (the next useful drive letter) at other times.

I figure u r talking about sample.ini, which already contains a list of apps u have surely added. is that all the lot there is to it or are there any more to possibly and safely remove?

Oh, btw, one more caveat, before I forget: could we have a list of "officially" redirectable folders and subfolder in windows (those with the location tab in the properties mask, so to speak) and possibly a way of making "officially unredirectable" folders redirectable (provide them with the location tab in the properties mask)? It is somewhwt frustrating, if I may, to find out about this "new" opportunity only after years of us going about in the realm of OS reduction. It is just awkward of us to resort to junctions to do what can be done naturally and/or (if possible) "naturalize the not-so-natural folders and subfolders" by a facility that the OS offers. The aim of the quest delves upon a remote wish of mine to keep just the "sheer Os core" (whatever contributes to and guarantees the booting to the desktop inferface, perhaps the windows system32 and syswow64 files) inside the vhd, and move the rest of files and/or folders outside the vhd, especially if we find that they can coexist and be shared with other corresponding ones in another os vhd (windows 10 and windows 11, for instance). thanks in advance for your possible contribution.

hi again, here is another one of my latest findings, which I would like to share with u in the form of a tip do not get rid of \Windows\System32\ServicingUAPI.dll lest u should not be able to have a stable immersive cpl any longer I will tell u about any other must-leave-alone dll in a bit. well, here's another one of them coming up \Windows\System32\SwitcherDataModel.dll \Windows\System32\SettingsHandlers_Gpu.dll don't take them out lest u should get one of those nasty unknown hard errors on an explorer tag right at the start and all the ms:settings-connections lost (and the significance is no immersive explorer window) I hope that is all, but u never know. As a matter of fact, there follows a bunch of them to leave alone as well: \Windows\SysWOW64\d2d1.dll \Windows\SysWOW64\d3d10warp.dll \windows\syswow64\dlcoer.dll \Windows\SysWOW64\dpapi.dll \Windows\SysWOW64\gpapi.dll \Windows\SysWOW64\ncryptsslp.dll \Windows\SysWOW64\NetSetupApi.dll \Windows\SysWOW64\NetSetupEngine.dll \Windows\SysWOW64\ntasn1.dll \Windows\SysWOW64\rasadhlp.dll \Windows\SysWOW64\rasapi32.dll \Windows\SysWOW64\twinapi.appcore.dll \Windows\System32\ws2help.dll lest u want to see netsetman.exe totally unable to run properly. well, see u in a bit for other leave-alone dlls here u go with \Windows\servicing \Windows\System32\winmetadata keep both of them subfolders lest winhance.ps1 should fail

left, right and center, I daresay

btw, I owe this one to jfx, and I apologize for not learning it any earlier than yesterday evening. I am alluding to the power of Sample.ini. In an era of constant quibbling as to whether it is better to reduce the windows iso a-priori by ChrisTitus' Microwin, by NTLite or by tiny10/11, I can guarantee you that JFX has always thought and acted ahead. Sample.ini contains all the a-priori deletions to do it more quickly and effectively - a radical dude like me has gone so far as to take out all of them, by deleting jfx's semicolons. Well, I have reduced all windowsapps to just 2 or 3 of them (the vclibs), which caused no hindrance to the system. what is more, the procedure can be carried out on an already minwinned system as well. the gain in recovered space is slightly less than 1gb. Attaboy jfx. btw2, I have just found out that u do not need the boot folder on c:\ if u boot thru the original bootmgr, whereas u can't do without it if u boot thru svbus, whether in filedisk or in ramdisk mode; of course u do need bootmgr inside ur c:\ no matter what (no doubt about that), as it will take over the process started by the bootmgr on d:\; also svbus, for that matter, takes over the process started by bootmgr on d:\.

everything ok if it does boot ok, which can be done even by simply assigning the desired drive letter (a posteriori, as it were). But if it does not boot ok, and it does not probably on account of that, how can I change the letter the way u suggested on an offline basis? Well, I'll be, I'm going to minwin the thing before adding ramdisk as z:.

Hi again, JFX, I need to set my temp-and-scrap ramdisk letter z:\, where I have juctioned stuff from c:\; my problem is that if and when I do get to reboot the system after minwin, the ramdisk defaults to i:\ instead of the desired z:\. what can I do to sort that out? Most of the time it does not eve comp0lete the boot process to the desktop, probably as a result of wrong temp location (it cannot find the z:\ drive indicated by z:\temp in the environment variables). this last concept also applies to whatever needs temps on z:\ even after it does get to boot to the desktop. what can I do to force the minwin version to assign z:\ on the ramdisk?

another caveat reminder - I do not remember exactly if I have already told u, but I can state and/or confirm that \windows\L2schemas must not be deleted if u want wifi. Let me see if it can be alternatively moved on some other drive and juctioned back to c:\ I will come back 2u in a minute or so. And yes, I can confirm that it can as well be on another drive and work just the same as long as it is junctioned back to c:\windows (its original location), which is particularly handy when u want one folder to serve various windows os's.

whatever is missing, u can retrieve it from the previous version, i guess. this is also true of ur settings that cannot be memorized for each and everyone of us across generalized upgrades. I guess it is up for each of us to do that too. For instance, when it comes to the remove dir inside minwin, jfx said to leave everything as it is, and add some mysoftware.txt file which should contain the info on what else to keep (!\...) and what else to delete (\...), so if anything goes wrong, we can limit our search for the error(s) inside this file, without the hustle and bustle of searching around.

I totally and thoroughly agree with Atari800xl in his wish for permanent happiness, improvement and the pursuit of a somewhat valuable "higher aims ahead" motto. I had the same fear it would end up like reboot.pro and other examples of info-tech sharing, socializing and learning that died out. along with a few of us, I am still ready to contribute to set the aforesaid websites back up again and fully associate with atari800xl in wishing everybody a merry xmas and a happy new year. a big thanx sure goes to jfx for keeping this thing alive with his updates and advice. btw, when I told King... I wish I could help him, I did so because that was what I really meant, as I ain't no expert, but just an enthusiast who was sorry he could not help. One more time, a happy holiday season to all.

thanks

attaboy where do we get it? In the meantime, a merry xmas and a happy new year!