For the enthusiasts who are doing the debloating, it's almost like they are gaming the system as they move from one level to another.
Twenty years ago I had already been installing Windows XP to FAT32 volumes directly to be more compatible with W9x multibooting. I didn't know anybody else doing this (some thought it couldn't be done) but every time I installed XP you can see the names of every driver as it loads during creation of the pre-installation environment. The very last two drivers are FAT32.SYS followed by NTFS.SYS. I figured Windows might have first been made functional on FAT32 but launched with the intention of total migration to NTFS for most people as seen.
In my later experimentation I found that Vista would run from a FAT32 partition but default Windows 7 would not do it very easily, simply because the WinSxS folder (pronounced win-sucks) was oversized in an insidious way.
The W7 WinSxS folder size was bigger than Vista's but it did not approach the maximum size that FAT32 can handle.
Instead it was the un-necessarily stupidly long filenames which overran the long-filename handling ability of FAT32 early when there were enough of them. Like the best engineers would never have even considered doing at the time, much less go into production.
By judiciously deleting the majority of the contents of WinSxS (but not all by any means), W7 can be run from FAT32 as well without any functional shortcomings as far as my office was concerned.
The modern approach to testing this for yourself would be to install the default W7 to a regular NTFS volume, then debloat the WinSxS folder manually, perhaps in safe mode or when booted to an alternative OS so none of the files on the W7 volume are in use at the time.
Reboot to something like the W11 USB setup media, "Troubleshoot" to go to the command prompt (instead of installing W11), then capture (back up) the debloated dormant W7 partition manually using DISM.EXE.
Then later, on a freshly formatted FAT32 drive, apply the captured W7 system, again using DISM.
Create new boot files for the newly applied W7 system using BCDBOOT.EXE.
Boot W7 while it's on FAT32 and prosper.
Works not that much faster than on an NTFS volume, but if you can reboot to Windows 9x on a multiboot system, you can search the FAT32 W7 volume blazingly faster than when the identical W7 system searches itself while on NTFS.
Now of course all of this needs to be done in legacy BIOS mode since UEFI alone is not adequate for such continued full PC performance.
I guess I could have been playing video games instead but reaching this level seemed just as rewarding anyway.
Wonder if W11 would do this.
Edit: For extra credit I already put W11 onto old BIOS PC's without any GPT, with regular MBR like it was W10.
Bypassing hardware restrictions into smaller-than-recommended NTFS volumes using DISM.
Twenty years ago I had already been installing Windows XP to FAT32 volumes directly to be more compatible with W9x multibooting. I didn't know anybody else doing this (some thought it couldn't be done) but every time I installed XP you can see the names of every driver as it loads during creation of the pre-installation environment. The very last two drivers are FAT32.SYS followed by NTFS.SYS. I figured Windows might have first been made functional on FAT32 but launched with the intention of total migration to NTFS for most people as seen.
In my later experimentation I found that Vista would run from a FAT32 partition but default Windows 7 would not do it very easily, simply because the WinSxS folder (pronounced win-sucks) was oversized in an insidious way.
The W7 WinSxS folder size was bigger than Vista's but it did not approach the maximum size that FAT32 can handle.
Instead it was the un-necessarily stupidly long filenames which overran the long-filename handling ability of FAT32 early when there were enough of them. Like the best engineers would never have even considered doing at the time, much less go into production.
By judiciously deleting the majority of the contents of WinSxS (but not all by any means), W7 can be run from FAT32 as well without any functional shortcomings as far as my office was concerned.
The modern approach to testing this for yourself would be to install the default W7 to a regular NTFS volume, then debloat the WinSxS folder manually, perhaps in safe mode or when booted to an alternative OS so none of the files on the W7 volume are in use at the time.
Reboot to something like the W11 USB setup media, "Troubleshoot" to go to the command prompt (instead of installing W11), then capture (back up) the debloated dormant W7 partition manually using DISM.EXE.
Then later, on a freshly formatted FAT32 drive, apply the captured W7 system, again using DISM.
Create new boot files for the newly applied W7 system using BCDBOOT.EXE.
Boot W7 while it's on FAT32 and prosper.
Works not that much faster than on an NTFS volume, but if you can reboot to Windows 9x on a multiboot system, you can search the FAT32 W7 volume blazingly faster than when the identical W7 system searches itself while on NTFS.
Now of course all of this needs to be done in legacy BIOS mode since UEFI alone is not adequate for such continued full PC performance.
I guess I could have been playing video games instead but reaching this level seemed just as rewarding anyway.
Wonder if W11 would do this.
Edit: For extra credit I already put W11 onto old BIOS PC's without any GPT, with regular MBR like it was W10.
Bypassing hardware restrictions into smaller-than-recommended NTFS volumes using DISM.