The Next Coding Project (Premium)

I’m getting ahead of myself here, but in writing up Win11Debloat yesterday after a week or so of testing, a thought occurred. When I finish up this year’s .NETpad modernization project, perhaps my next coding project could be a Windows 11 de-enshittification utility.

Yes, there are lots of these tools. But the appeal here is multifold. None of the existing tools does exactly what I want. I could create something that looks native and “correct” in Windows 11. And this would be a nice evolution beyond an app like .NETpad that’s meant to mostly to emulate something else.

So, we’ll see what happens. But I took a few tentative first steps to see if such a thing made any sense at all.

Last night, I took a closer look at the source code for Win11Debloat. It’s a standard PowerShell script, which means it’s based on .NET–like the WPF framework I’m using for .NETpad right now–so it was mostly readily understandable. And then I looked up how WPF supports the Registry, since a good chunk of Win11Debloat’s functionality involves editing that. It looks straightforward, though I’ll want to be careful when changing (or adding) Registry values for obvious reasons.

Scanning through the features you can toggle with Win11Debloat, I found two that are visual and thus easy to test, especially since neither requires restarting Explorer.exe or anything like that: The Search and Task view items that can appear in the Taskbar. These are fairly innocuous features, and not the sort of thing I associate with enshittification. But, again, a good test.

So I started a test project in Visual Studio. Added a button for toggling the Task view item in the Taskbar. And then wrote the code to toggle it, using the code in the Hide_Taskview_Taskbar.reg file included with Win11Debloat as a guide. I came up with this for the button’s event handler:

A final version of this would need more error checking: You don’t want to screw up the Registry, of course. But this value exists in every Windows 11 Registry, so it felt reasonably safe. And while it’s wordier than it needs to be, that’s by design. It will eventually need to do more. But for now … it works. Each time you click the button, the Task view button toggles on (if it’s off) or off (if it’s on).

Search is a bit more complex in that there are four states–Search box, Search icon and label, Search icon, and Hidden–but looking at the four relevant Reg files included with Win11Debloat (Show_Search_Box.reg, Show_Search_Icon.reg, etc.), I could see that it’s just a single Registry key that’s set to 0, 1, 2, or 3 depending on which Search item choice the user makes. So a simple switch block would suffice.

And that works fine, too: Each time you click the Search button in the app, the Search item changes to the next state (one of which is Hidden).

These are the simplest possible configuration changes I could have chosen. But it’s enough to make me think about the next steps. Which, to my mind would include the notion of saving (and exporting) the configuration changes the user specifies and then loading (or importing) them each time the app runs so you can compare your choices against what’s actually configured: When Feature Updates or other updates change settings quietly, this might be an interesting way to see that.

What form it takes, this feels interesting and useful. I’ll keep at it.