Although they don't contain a registry editor, the Windows Sysinternals tools from Microsoft have some great ones like Process Explorer (task manager replacement), Process monitor (shows all real-time Registry activity as well), ZoomIt (great for screen drawing during presentations) and so on. Written by Azure's CTO way before the cloud existed :)
Instead of process explorer, I highly recommend people to use Process Hacker[0]. It's open source, contains a lot of information missing from process explorer, and has a much cleaner user interface.
Another great one is WinObjEx64[1], which allows exploring the NT namespace.
I like that Process Hacker has broader set of features, but what I am missing compared to Process Explorer is the the ability to quickly identify the process by using the "sniper" and the integration with VirusTotal.
I wish there was a single tool with all the bells and whistles :) Maybe I should start contributing to FOSS.
ProcessHacker has both VirusTotal integration and the sniper feature, at least in the nightly builds (Called Process Hacker 3). I highly recommend using the nightly builds, they are packed with amazing features.
I just don't get it. Not using Electron, no Angular, not using any latest web technologies, not cloud-native, no social network features... WTF was this guy thinking?
When clicking that link in Chrome I get a "The site ahead contains harmful programs" warning page with a bright red background.
"Attackers on github.com might attempt to trick you into installing programs that harm your browsing experience (for example, by changing your homepage or showing extra ads on sites you visit)."
How strange... I don't get it for other github pages.
N.B. A few antivirus programs incorrectly flag Policy Plus as malware. Policy Plus is a powerful tool and so may cause problems if used recklessly, but it is not malicious.
No so much different than "hacking tools" or similar being detected as "malware". In other words, just another example of the paranoia typical of the authoritarianism that is so common in the software industry today.
> In other words, just another example of the paranoia typical of the authoritarianism that is so common in the software industry today
I don't think it's authoritarian, just that the more positives your antivirus detects that others don't, the better you can sell it. Something like Process Hacker should have never been detected as malware, as it can't harm others, but it ups those numbers.
The same happens sometimes when trying to download netcat and almost always when downloading any of the SysInternals password recovery tools. Cybercriminals use these tools in attacks and so they must be malicious! You know, like bank robbers use hammers and cars...
I'm always amazed by just how much community tooling is developed for Windows. From PowerToys to SysInternals, those two package managers, TerraCopy, etc. All things that improve on what Windows ships with because Microsoft refuses to put any effort into doing it themselves and it's not open source so you can't exactly open a pull request and do it for them.
I guess that kind of approach quickly hits an API ceiling when it comes to administration tools. A lot of them need pretty low-level access to things that MS doesn't provide good APIs for and few people want to develop a product on top of entirely unsupported reverse-engineered APIs.
The two problems I see are that the program could have bugs that the original gpedit doesn’t, and how most enterprises wouldn’t dare trust third-party software to manage group policy on their internal network.
I was about to post it too, fiddling with registry directly where things are scattered all over the place should be last resort when there are better tools out there.
I'm just mentioning it because it can perform regex searches and open .reg files for editing. This does come in handy when you create backups of the registry and later want to search some keys in that backup, copy some sub-keys from there into the current registry.
There was a time when I was fiddling a lot with the registry (I think while developing some DCOM stuff) and this helped me a lot with keeping the system somewhat clean.
I say that because when C# was released, many Windows developers refused to use it and continued to only write Windows programs in "native" languages like C++, VB6, and Delphi.
I must admit my own bias and state that I still prefer applications written in "native" code on Windows (C++ / Delphi) to C#. It's not really an issue worth arguing over these days (and hasn't been for years), but there it is. FWIW, all the SysInternals tools are C++
The startup times are noticeably longer for anything non-native, and noticeable can turn into annoyance when it's an application you're unlikely to leave open all the time, like a registry editor.
Once Microsoft makes up its mind about which way it wants to go for UI and distribution of desktop applications, maybe. I don't want to use buggy, incomplete WinForms, deprecated, half-abandoned, buggy WPF, or unfinished WinUI.
WPF is complete, done, never to be changed again according to Microsoft. But nevetheless they have recently started fixing bugs for .NET 6. Notably not the one where returning from the Windows 10 lock screen made the application freeze. They called that production-ready for .NET 5. [1]
WinForms is a mess. They reinvented the wheel when porting it from .NET Framework by changing APIs, then noticing that this wasn't a good idea because porting applications from .NET Framework would become a complete rewrite which would make WinForms on .NET pointless. So they stopped changing the APIs halfway through, which makes it still necessary to rewrite complex UIs. [3] The WinForms designer in Visual Studio does not work with third-party controls (even your own) when targeting .NET 5/6. You need to sign an NDA to get access to internal VS APIs to do that. They call that production-ready. [2]
WinUI 3 is missing a lot of controls and features. But because Windows 11 needed to be released, they implemented the bare minimum that they needed for themselves and called it production-ready.
It's a mess. A huge mess when developing a desktop UI application larger than a calculator.
> We are working closely with the control vendors such as Progress Telerik, DevExpress and GrapeCity on supporting their controls in the Windows Forms designer in the nearest future for .NET Core and .NET 5 projects. We are also collaborating with ActiPro, Infragistics, and SyncFusion.
Situation unchanged, no access to the APIs without an NDA.
Windows 11 doesn't currently use WinUI 3 at all, it's all still WinUI 2.x/UWP XAML based, including the new stuff.
Actually I don't think WinUI 3 currently has any immediate advantages over WinUI 2.x from the app developer's point of view, except that there's a nice Visual Studio template for creating standalone Win32 apps using it, but I believe you can achieve more or less the same thing with a little more upfront work by just making an app that does its entire UI in one big XAML Island, and in fact that's how Windows Terminal works. The long-term advantages are supposed to come from WinUI 3's XAML and composition stack being decoupled from the Windows OS build.
That's a hope I currently do not share. There were multiple cases where Microsoft employees proposed features for WinForms that were only stopped by community members because it would have broken WinForms in very subtle ways. If Microsoft were on their own, it would already be broken. Also see the VS WinForms designer problem in the sibling comment.
I have the feeling that the original WinForms designers quit Microsoft years ago and some juniors are left trying to force their new ideas into it to make a name for themselves.
The Windows Registry API is an incomplete wrapper over the NT Registry API. One glaring problem with it is that the windows API uses null-terminated string, whereas the NT API (and the underlying file format) use length-prefixed strings. This means you can effectively hide keys and values from software using the normal Windows API.
Having VS 2019 (which is free as Community Edition) is not a really high requirement, it's probably already installed by any developer developing on one of the MS stack.
Yeah if you wanted to you could also probably use VS Code, there is a .vscode directory in the GitHub source code so I imagine the author used that too at some point.
https://docs.microsoft.com/en-us/sysinternals/downloads/