A Modest Proposal

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?


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?


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.


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.


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:

  1. 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.)
  2. 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.
  3. It makes troubleshooting easier, because it creates known places for all your stuff. You can make assumptions.
  4. It makes reinstalls easier
  5. It makes updates easier
  6. 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.


Some Reasons why Installers are a mess

The other day, I was kvetching about installers (if you’re new here, I do that. A lot. You get used to it) and got an interesting reply on twitter:

Installers should be a 100% solved problem these days. Use a freakin’ msi on Windows, and use a pkg on macOS and all will be right with the world. Do not use bloated Java-based installers. Yes, I’m looking at you, InstallAnywhere and whatever they use (used to use?) for Archicad.

So the thing is, yes and no. Installers are, as this person said, something that should be solved, but it is not, and the problem is far, far worse on Windows, even if one uses MSI’s, than it is on macOS. Like far worse, for a variety of reasons.

First, and this exists regardless of platforms, outside of a very small number of companies, the amount of care put into installers is basically none. It’s scutwork, it generates zero direct income, it’s the first circle of hell for interns, etc. One of the best reasons for drag and drop installs on macOS is that it literally avoids installer executables.

The problem with this is that an application that has unit tests galore, UI/UX research by the pound, endless resources devoted to making sure it runs in a way that makes angel sing gets installed by executables that take all that and shove it into some of the most awful UI with almost zero testing on anything but the programmer’s machine. (I have literally dealt with installers that had hardcoded paths to the dev’s machine in the config files. More than once.)

It is also a place where the worst sorts of unnecessary cleverness lives, especially if we’re talking about high-end applications that have roaming license servers. In some cases, I have seen installers for Linux servers that:

  1. Require manual undocumented hacks to install on RedHat
  2. Don’t have a command-line option, so the only documented way to install is to install a GUI. On a Linux server. To install software. Shoot. Me.

There is no realm of software that can begin to touch installers for sheer, mind-numbing WAT. The things I have seen…

But even if you do things “the right way”, there’s a lot of problems. I’m going to talk about Windows here, because it’s…well, honestly, it’s easy.

First, MSIs are not a magical end-all. For example, I have seen MSI over MSI that has to be run as an admin, but if you’re not physically logged in as an admin and double-click on the MSI, you’re never asked to elevate to run the installer, it just fails with a mostly-useless error message. This is a trivial thing to avoid, and yet it happens a lot. I’m pretty sure I know why, the one dev building the installer logs in as an admin, so this problem doesn’t exist for them.

Sometimes you get a “you need to be an admin, start over” dialog. Thanks a pantload Chet, you could have handled this as part of the install. But you didn’t, and now you suck.

You end up getting really good with running msiexec from administrator PowerShell windows after a while.

MSI has a fairly standard set of switches for quiet installs, etc., but a lot of MSI installers don’t always use them all for some reason. So the install either fails, (sans logging, and logging on Windows is awful) or it runs in default mode with nary an error message to be found.

Did I mention installers are regularly awful? Because they are. Autodesk for example, has arbitrary filename length limits for its installers. That it regularly violates. Let me say that again, the company that sets the rules for how long a filename can be to work with its installer names files that break that rule. Not filename and path, just the filename. Make it make sense.

But even if you don’t hit that kind of nonsense, even if the MSI is perfect, then there’s the library issue. Also known as the endless strings of VC++ and .NET runtimes that have to be installed, often in a specific order, and when you uninstall, those stay behind, because if some other app is also using it, (and you have no way of knowing this), then removing it breaks other things, often, again, with no useful error message.

This is one place where the package format macOS uses is literal brilliance, a brilliance I did not truly appreciate until I had to deal with Windows deployments again. In some cases, we’re talking about nine or more separate MSIs that have to run in a specific order before the actual installer for the app you want to install can run. None of these will be visible to the user in Settings or the Control Panel. So when you “uninstall” the application, you’re only uninstalling the actual application, not the n things that were actually installed. Because there’s no safe way to do that in Windows.

On macOS, you just shove all the libraries in the application bundle and you’re good to go. For example, Adobe Photoshop 2022 has 121 frameworks, 8 “required” plugins, 52+ other “required” pieces of code and image files, and hundreds of various localization files. All of them are in the application bundle. There’s some other things outside in the Application Folder, some config files in ~/Library/Application Support/Adobe, some in /Library/Application Support/Adobe, and really, that’s mostly it. Compared to how things work in Windows, that’s almost nothing.

There’s also, on Windows, no good way around it. The architecture of the OS forces you into doing stuff like the VC++ redistributable/.NET Runtime dance. You don’t have a choice, because you absolutely can’t make assumptions about anything. Linux is literally more predictable than Windows.

However, that being said, there’s ways to make things easier.

  1. Fully support deployment tools, and no, I do not mean your weird .hta file. I mean SCCM/Intune/MEM, or other managed deployment tools. Out of the box, with support documentation. Autodesk is particularly good here. Solidworks is particularly not good here. If you create the software, it’s your job to make it work with managed deployment tools. Not the IT department’s, not the VAR’s, yours. If you cannot actually test with any deployment tools, then at the very least, do the work so that your installer can be slotted into said tools without weird dances, and undocumented tricks.
  2. When you uninstall, clean up after yourself as much as possible. You can at least delete the application folders. That’s not too much to ask. Mathsoft is a rather annoying offender with this one.
  3. Make it easy to slipstream/update your deployment point. I should not have to build a new deployment point from scratch just to add a .x update file to it. Yes, it’s not zero work. It’s more work for me when I have to push that out to a few thousand machines, and I should start charging consulting fees for ISVs that make this harder than it should be
  4. If on Windows, use the registry as sparingly as possible, and for the love of christ, do not put application-level variables needed to run the app in the user-specific hive. Deployment tools don’t run as a logged in user, doing stuff like that adds a lot of work to deployments. There’s no good reason to do this, stop it.
  5. Avoid environment variables. Those suck to manage outside of your installer.
  6. Document your installers and the process in excruciating detail. Seriously, we don’t mind.
  7. Virtual machines are literally free. It costs only time to test your installer basics. Do that.
  8. If your installer doesn’t work perfectly smoothly in fully manual mode (manual double-click on the installer file), it is not ready to go. Periodt.
  9. If there are multiple post-install steps that have to be done before the installer quits, those aren’t post-install steps. Those are installer steps. Automate them as much as possible. Don’t pause things just so I can click “next”. If I have to click next to finish the install, then just assume “next” will always be clicked, and bake those steps into the installer. Don’t make people click when there’s no real need.

FInally, the installer is not only code, it is the first code your customers will run. Why do you want them to hate you that fast?