No, this doesn’t involve eating the Irish, nor is it satire. But it does involve the killing of certain ‘sacred’ cows, so not a completely bad title…
Having lived in both the Windows and macOS admin worlds for three decades, I’ve had some time to deal with the foibles of both, and while Windows is a capable, usable, feature-rich OS, it is also a gods-damned mess in ways that are, in 2022, almost 2023, inexcusable. The registry, the issues with library and runtime versions…no matter how hard deploying software on macOS can be, it is orders of magnitude easier than on Windows. So with that in mind, looking at it from a macOS perspective, how can we solve this problem in a sane manner? What ideas can we steal from macOS and Linux to help, while applying them in a way that works for Windows?
Get off the 32-bit pot
It is 2022, almost 2023, MS needs to just pull an Apple and say “As of <version>, we will no longer support 32-bit anything in Windows.” OEMs/ISVs will either go along or they won’t, but hanging on to 32-bit support is no longer justifiable given the amount of work it creates. Stop it. Stop it for every application too. The fact there’s even an option for a current 32-bit Office (and I would be thrilled to be now wrong about that) is even more inexcusable. Dumping all the 32-bit legacy code would be a massive improvement on every level, including OS layout, security, simplicity, etc. That users have to still care what the “bittedness” of their OS or applications is? Stupid. Like straight up stupid. Yes, I know, enterprise customer still have 32-bit apps they use.
If they’re big enough to try to stop this, they’re big enough to have or hire the staff to update their crap. It’s 2022 almost 2023, there is no justification for 32-bit Windows or Windows apps. Just. Stop. It. No, don’t even allow them to run sandboxed. Put them to rest like they should have been years ago. Spine up and do it.
Partition, Partition, Partition
Not in the filesystem sense, but in the OS structure sense. The way Windows as an OS is set up, the difference between user and system data is not as clear as it should be. But, thats something that can be fixed.
First, let’s create some core structures, some of which are already there:
- Windows
- AD
- MyComputer
- Users
Okay, admittedly the AD/MyComputer names are lame, but given MS branding over the years, they’re not as bad as some of what MS has come up with (anyone want to get a brown Zune squirt?) So what are the purposes of each of these partitions?
Windows
This is the local OS, as it is now. But, we’re going to steal an idea from Apple, and make C:\Windows read-only. Like hardcore. There’s no reason not to, it’s a perfectly usable method, as Apple has shown, and while it can cause minor bumps, the management tools on Windows are, or should be, mature enough to manage this. The only thing that goes in here is installed during the OS install. By actual OS installers, not imaging. To be blunt, Imaging needs to die, but that means that MS has to stop allowing OEMs to modify windows to add in their own nonsense as part of the OS. Install it somewhere else, but the Windows OS install has to be carved in stone as it were by MS.
This also means MS has to stop tarting up the OS install itself. The Xbox stuff, the other non-OS essential items don’t have to be eliminated as products, but they can’t be a part of the core OS. Windows as an OS needs to be slimmed down. This would a) be a huge boon to enterprises everywhere, especially in high-security areas. If they can rely on the OS they get on the machine being just the OS, and everything outside of Windows being removable without causing issues with the operation of the computer, a major need for imaging (the “de-tarting” of the OS) goes away. The OS is the OS, the OS directory structure is read-only, periodt. I’m not saying do the partition tricks Apple does, although those have much to speak for them in terms of locking down the OS, but at the very least, you should never be a single password from having your computer owned at the “burn it to the ground to fix it” levels.
Again, the only thing in C:\Windows is the OS, the things needed to be a copy of Windows. Nothing more. Also, stop with the stupid stub files for Office, does anyone not despise those?
AD
This is a nod to the ubiquity and integration with AD that is a part of the Windows world. This is where everything required for AD management goes, and it’s created only on binding with AD. Policies? here. Configs? Here. Device Management configs? Here. Needed Scripts? Here Once it’s in place, the only source that can modify it is AD. No local fuqery allowed. The only thing a local admin can do is wipe the drive to get rid of it. If you want to delete the directory/unbind from AD, the minimal privileges required for a local interactive user should be Enterprise Admins. Yes, you have to lock this down like that to make it work. If the machine is removed from AD remotely via AD tools/processes, then part of that is deleting the C:\AD directory.
Which also means that any AD-only users lose their abilities to log in. This would require the thought process of “do we want to allow this user to be a hybrid AD/Local user?”, which should require some thought. The cases where this would be a problem should be relatively small, but it has to be the starting point. Yes, I am quite serious about how hard I want to lock out local admins/users from being able to modify C:\AD. It’s needed, and since the only way to create C:\AD requires AD (or some other LDAP server that can play AD games correctly), the legitimate needs to be able to modify/delete C:\AD as a local machine admin/user are small.
MyComputer
This is analogous to /Library on macOS. This is for local settings/policies that affect every user on a specific computer. If it affects all users, or is a system setting, it goes here. Obviously, local admins can mess with this, it would exist on every Windows computer. But, you’d have to have local admin rights to do so. Note that nothing here should be required to boot the computer and log in. But if you just delete stuff, your apps or local settings may be very strange. No, it’s not hidden. Hidden directories for this kind of thing are silly, and I very much include hiding ~/Library on macOS in this.
But yes, application settings, login settings for all users, etc., that all goes here. It’s basically the current C:\ProgramData directory, with some updates. Like not being hidden.
Users
I hope this is obvious, since it already exists. This is for User data, including per-user installed applications. We should already understand this concept, so I’m not going to go into details on this. There will be one significant change that I’ll discuss in a bit, but it’s a good change that will make things like user migration easier. I will say get rid of the stupid Roaming/Local/LocalLow, there’s little need for that.
Whither Applications?
There’s no real need to change this, C:\Program Files works fine. What I will say again is, get rid of 32-bit support. That C:\Program Files(x86) still exists, and is still needed is an embarrassment. So we keep C:\Program Files, but we’re going to take an idea from macOS and modify it a bit to make certain things easier: All applications go in their own folder in C:\Program Files, and all application-specific data, files, and libraries goes in the application folder. No more dropping an executable in C:\Program Files and then vomiting library files everywhere, including runtimes that other apps use because “oh, that VC++ runtime is there, no need for me to install mine.”
If your application needs 34 runtimes, they go in your application’s folder. Not in C:\MyComputer, that’s only for things needed by every user on the computer. That your application needs a specific version of the .NET runtime that is different than the OS version? That’s fine, but it goes in your application’s folder, periodt, and only your app can access stuff in that folder. This has a number of effects that are hugely positive:
- Uninstalling becomes orders of magnitude simpler. Along any directories you put in C:\MyComputer, the entire uninstall process no longer requires complex executables. A handful of remove-item statements in a PowerShell script at most are all you need. (Yes, I know about the elephant, patience children, patience.)
- Installing is simpler. You copy a folder to C:\Program Files, put some shortcuts on the current user’s desktop, (other users, if this is a shared use machine can be handled via a First Run action), shortcuts in the Start Menu, create any necessary services, and you’re done. Everything else can, and should be handled by a First Run action on that computer when the human initiates it. So the only reason for .msi at all is integration into managed deployment systems, but those become so much more simple. Also, it helps put an end to setup.exe, the bane of admins everywhere. There is nothing about your installer so clever that you need to write your own. Wank somewhere else, not on my computer.
- It makes troubleshooting easier, because it creates known places for all your stuff. You can make assumptions.
- It makes reinstalls easier
- It makes updates easier
- It removes the need for the OS to manage application-specific library needs
This is such an obvious change that I’m really surprised it hasn’t happened. It simplifies so many things, it removes so much confusion. Seriously, this change alone makes things ridiculously better.
So about that elephant…
So what about the registry? How do we update that for this brave new world?
We don’t. We kill it. We remove it. We obliterate it. We treat it like the Death Star treated Alderaan.
There’s nothing about the registry that is objectively good. It’s awful on every level, and if you look at the actual data it contains, a huge part of that? File Paths. Which are better managed in literally any other way, via settings files. Text, XML, JSON, I don’t care. There is nothing good about the registry. It’s a trivially modified place for critical system settings, it is a hard to read/use database that is a glorious target for every bad actor out there…it was never really a good idea, just admit it and make it go away.
If you get rid of the registry, a lot of things get easier. Installing software. Uninstalling software. Updating software. Migrating users to a new machine. Removing a user from a machine. Adding a user to a machine. In fact, almost everything that uses the registry now gets easier if you remove the registry.
Just kill it. Kill it dead. It was never a good idea, and the only thing the Windows registry does better than any other method is be the Windows Registry. Make it stop, delete it from the computer/IT lexicon. If the path “HKLM:/…” is never seen again, it will be a good day. Kill the registry. Do it.
This is not complete
Obviously, this is a broad strokes post. The details on this are numerous and important, but I really don’t like to complain without at least attempting to offer a solution, and I think this is not the worst attempt.
The question is, does anyone on the Windows team have the spine to actually make the changes to make things better, or are they too stuck in “we can eventually fix it without changing anything?”-ville. Because if that’s the case, Windows will never get better. We’ve watched decades of failed incrementalism on the platform. Time to blow some things up and make it actually better.
Bynkiidotcom 