If X is a roman numeral, then π must be a greek numeral. I'm not super familiar with greek numerals, but I have to assume that they are in some way compatible with roman numerals. Pi probably confused the greeks in the same way it confused the Indiana State Senate, so the greek numeral π must actually be 3. Therefore, Xπ is actually 13.
Edit: Ok I looked it up. Looks like π actually is a greek numeral (who knew?) with a value of 80. X would be 600. So it would actually be 680.
Does anyone know exactly WTF happened after XP to make the disk space requirements balloon so much, so fast? I know they started including more drivers, but, I mean, so does Linux and you can go pretty nuts with driver modules there and still not move the needle much on disk space requirements. Certainly not to the tune of gigabytes. New features definitely don't seem to justify the increase. Even supporting both 32 and 64 bit, that still doesn't come close to justifying it. Combine Win2k and Win98, double that for no real reason, double it again for 32 and 64 bit, and you still don't touch Win7.
For one thing, Vista onwards includes the entire system on the hard drive, including optional drivers, language packs, features, etc, so you never get the dreaded “Please insert Windows setup disc” prompt. This also makes Windows setup a bit faster as it can for the most part just install one big disk image.
Another factor is 64-bit Windows, which became mainstream with Vista. 64-bit installs include both 64-bit and 32-bit system libraries, so it takes significantly more disk space. This is still the case with Windows 10, which might explain why some low-end devices still have 32-bit pre-installed.
Think about how many icons it would take to use up say 10GB.
256 x 256 x 3 bytes (24-bit color uncompressed) is ~200K. That's 50,000 icons. So you've only moved the question to why would Windows need 50,000 icons in raw format.
Icon files are uncompressed bitmaps, and in good tradition Windows features 32-bit and 16-bit versions. And Windows contains a lot of icons, just look at shell32.dll or imageres.dll for instance. Still, it is probably part of the reason.
I've never developed a "real" application for Windows, so I didn't know this off the top of my head, but it appears that compressed PNG format has been supported for icons since Vista, which came out in like 2007.
That's demonstrably not true. There are a few specific DLLs that have separate versions shipped in the same OS build (like comctl32), but 99% of DLLs have only x86/x64 versions.
Do/have you use(d) this? Any screencaps? :) No classic theme was one of the deal breakers from me going from 7 to 10.
Worth mentioning here that XP support only really ended last April (POSReady).
7 is supported at least 3 more years:
> Windows 7 ESU include security updates for critical and important issues as defined by Microsoft Security Response Center (MSRC) for a maximum of three years after January 14, 2020.
Vista was basically a massive rewrite of a bunch of components, and the devs had more hw resources at their disposal when they did it. One place I can think of taking up more disk space is all of the theme ing and icons. Imagine how many different images are included in windows, those need to be high-res for hidpi now.
They'd work better, but wouldn't be perfect either since they had some arbitrary jumps. For a long time, release build version numbers were divisible by 400 - they had to be divisible by 16 for servicing reasons[1], and divisible for 100 for marketing reasons (to look nice) [2] so build numbers were divisible by 400 for a long time.
This meant that the final versions had some correlation to how much time had passed between versions, but it wasn't reliable. For instance, Win7 RTMed on 2009-10-22 as build 7600. Win8 RTMed on 2012-08-01. At one build a day, you'd expect a build number of 8614....and internally, we were pretty close to that, but the actual release number was 9200 (so we instantly gained almost 2 years of build numbers). For the story of why 9200, see [2].
They eventually got rid of both requirements, which is why the latest Windows release is 18363.
I have enterprise windows on a domain joined machine and literally gigabytes of data are devoted to shadow versions of games. Does anyone have a solution for this? Why is this happening on Enterprise?
Windows has been a compliance nightmare with a small team.
Edit: I can't delete these to be clear, even with a local admin and domain admin account. I saw some solutions online but I need something I can have an admin create a script and/or gpo for.
I've been dealing with that garbage since migrating my office to Windows 10. Each update, things would reinstall. Or scripts I used to automated uninstallation stopped working because they just change the game roster. Or various GPOs I used no longer worked if you merely had Windows 10 Pro, so I had to shell out for new Enterprise licenses.
I've really liked some things MS is doing recently, like VS Code. But the Windows team--I just don't understand what they're doing. They're treating an OS--an OS that's frequently used for serious business purposes and ought to be predictable and stable--like some startuppy web app that changes everyday according to the latest A/B test. It's infuriating.
> But the Windows team--I just don't understand what they're doing. They're treating an OS--an OS that's frequently used for serious business purposes and ought to be predictable and stable--like some startuppy web app that changes everyday according to the latest A/B test. It's infuriating.
And there's your answer. Microsoft has become infected with these kind of people and they're fucking up Windows 10. The situation hasn't been fixed because attention is on more profitable portions of the business like Azure.
Turning off the "cloud content" gpo I think it is will prevent them from being installed. You can remove the packages with powershell, try googling remove candy crush appx
The price of storage has pretty much plummeted compared to the size of Windows. A quick glance at a magazine shows that in 1987, a few years before Windows 3.0, a 20MB hard drive was about $300 (in 1987 dollars).
Win 3.0 came out March 1990, which puts HDD at 4$/MB or 50MB for 200$. https://jcmit.net/diskprice.htm So 6MB win 3.0 should be ~12% of a hypothetical 200$ disk.
Now HDD prices dropped a lot, but high end PC’s used SSD’s in 2009. A 120GB SSD cost ~250$ when windows 7 came out, which is ~13% of the drive.
Inflation pushes these further apart, but $200 in 1990 is only $324.15 in 2009.
Fair enough. Though that's probably on the early side for most people to have put an SSD in their computer. (Inflation also means the 1990 number is also about 50% higher relative to 2009.)
TBH, I probably spend as much on disk drives as I ever did but that's because of the redundancy I can afford, all the media, and because I just leave a lot of stuff laying around because it's easier than pruning.
> My last post was about either The SSH protocol or The reason you need to install a karaoke captioning library if you want to change your desktop wallpaper.
Not sure what to make of this since my gaming machine that I sometimes use for programming has the C:\Windows directory at ~40GB. This has been the case ever since I installed the Win10 Beta somewhere in 2015 (okay, it started at about 25GB but grew pretty quickly, over the course of just a few months). I run both variants of the disk cleaner (user and system) after every update.
Sure the PC is like 9 years old at this point but has seen only a minor amount of external plug-and-play hardware. I can appreciate all this bloat including all drivers for all well-known hardware but damn, that's 40GB still.
Back in Windows 98 days there was 98lite project, that allowed to customize Windows 98 components, even replace explorer.exe with one from Windows 95. Smallest version was just under 50MB.
I wonder how much Windows 10 can be shrunk? And probably hardest thing of all - keep updates working after that.
You've got a few responses spelling out a few ways it can be done.
Almost all of them are based off something called "WinPE" or the Windows Preinstallation Environment. [0]
This is a similar OS, used when installing your OS. It usually shares the same kernel, but with everything stripped away, including useful things like the desktop, etc. You can add some, but not all, of these things back.
As WinPE uses the Fat32 file system by default (you can change it with some difficulty), most of these installations will be less than 4GB.
Building a WinPE-based environment is a fun weekend project. Totally against the license agreement to make it into a useable OS, but that shouldn't matter if you never share it and are just using it to get to grips with how WinPE works.
Microsoft also today has containers and images that they themselves streamline as much as possible, for certain use cases. The two most common I've seen referenced:
1. Windows IoT Core [0] designed for IoT devices and embedded scenarios. The RPi build of Windows 10 IoT Core is around 800 MBs. (The Raspberry Pi build is an interesting one to note because you can explore yourself easily in a weekend project.)
2. Windows Nano Server [1] is a fascinating Windows 10 build intended for among other things Docker containerization [2] and virtualization projects. I've heard some images of Nano server are as small as about 400 MBs. Given its intent for containerization/virtualization, it's pretty amenable to experimenting with in weekend projects, too.
Microsoft has seemed quite interested in the last few years with how small and modular they can make Windows under the hood. It's not always apparent at the consumer level because of backward compatibility and all of the required "modules" (like Win32) that folks think of "as Windows".
There was an unofficial build of XP called TinyXP that I used to like to use for VMs. It would use under 200mb of disk space, yet somehow be fully functional.
Ah that brings back memories. I don't know if I was just crazier or if it was just easier to trim things without breaking them back then. These days I don't even dare try to remove some of the built in Appx packages on Windows for fear it silently breaks some feature you'd never think was part of that.
Funny, but it still would be more interesting to see the same chart with an x axis making more sense. Windows 2000 is just a brand name, it's actual version number is 5.something.
Part of the Windows 8 (8.1 actually) objectives was to reduce the memory and disk footprint so that cheap tablets could be viable. With WIMBOOT enabled a full 8.1 install could fit in slightly over 3 GB on certain devices (the evolution of WIMBOOT is automativally enabled in 10 when the installer sees fit)
Anyone else notice that this is starting to form a letter 'M'? Perhaps, with the correct versioning scheme[0] and appropriate install size fluctuations, they could write out the company name.
I distinctly remember fresh install of Win 95 taking 73 MiB of disk space (definitely between 70 and 79 MiB; with a 7 in the front). So I'm not sure where the 50 MiB number comes from.
Anyone with me on this? (not that it's a huge difference, but still).
ps: Also horrible chart due to x-axis. No offense.
