There is also Sysmon for Linux [1]. I work often with Windows systems that's how I know it (it's a popular choice on Windows to analyze Sysmon logs for suspicious events), but it's probably niche in Linux world.
Have you tried running it on wine? [1] I use it this way on Linux and, after adjusting my commands for running editors and start menu tools, everything runs smoothly.
I feel that nowadays Rust is the language to go when you are doing system programming, but C# is not a bad choice either. With .NET 9 being released in a few weeks we will get NativeAOT (compilation to a native single binary) for x86 (x64 and ARM64 are already available). At work, I'm writing patches for legacy apps and needed to use C++ for most of my tasks. Nowadays, I'm doing more and more stuff in C# and enjoying it. For WinAPI there is a fantastic cswin32 [1] project that generates FFIs signatures on the fly. And it's fairly simple to extend it for other Windows libraries (I did it for detours [2], for example). And using pointers or working with native memory blocks is straightforward and intuitive for people with C/C++ background.
Although NativeAOT sounds cool and it's better than nothing: I don't like that it comes with a bunch of limitations[1]. I would have loved this if you could just use it without any changes, but I'm very worried that at some point I used something that prevents me from getting it to work and I have to figure out which limitation I just walked into. Correct me if I'm wrong.
Those limitations are often obvious. With AOT, you don't have the VM around, you can't load new bytecode or introspect the objects. I would focus on writing working code, and try to go AOT close to the end. If it fails and it's not fixable, tough luck, but it works on the standard runtime.
Technically speaking, there is VM (you could also consider GC to be a part of it, but in HN understanding it's an umbrella term that can mean many things). Because the type system facilities are there which is what allows reflection to work.
The main source of confusion as to why some believe that NativeAOT prohibits this are libraries which perform unbound reflection in a way that isn't statically analyzable (think accessing a method by a computed string that the compiler cannot see and not annotating with attributes the exact members you would like to keep and compile the code for) or libraries which rely on reflection emit. But even reflection emit works for limited scenarios where runtime compilation is not actually required like constructing a generic method where argument is a class - there could only be a single generic instantiation of __Canon argument in this case, which can be emitted at compile time. You can even expect the reflection to work faster under NativeAOT - it uses a more modern pure C# implementation and does not need to deal with the fact that types can be added or removed at runtime.
That's interesting - I would have thought targeting aot at the outset and then switching away only when the design became incompatible would be more effective, only because by going for aot at the end I'd probably have introduced some code or dependency that isn't aot compatible and yet too much work to replace
With source generation, I'd say that its biggest limitation is rapidly diminishing. Even ASP.NET Core is embracing it, allowing for better support for json deserialization and eventually MVC.
Apart from search customizations, I also use the bang searches (a few mine and many from https://github.com/kagisearch/bangs). I also recently switched to ultimate and created a few assistants with system prompts for my various needs (coding, learning chemistry, etc.)
Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649
I haven't considered the execution policy such a blocker since you may change it on the powershell.exe command line (for example, run "powershell.exe -ExecutionPolicy RemoteSigned -File script.ps1" from a bat file). Also, the default execution policies changed between PowerShell 5.x, shipped with Windows, and modern PowerShell 7.x, which you need to install separately. In 7.x RemoteSigned is the default in the server environment.
Not to mention that WinUI is not supported on Windows Server. Therefore, if you need to deploy to server and desktop environments, it's better to stay with WinApi (WinForms) or WPF.
Have you tried running it under wine? It works perfectly fine on my Linux system. You may only need to add a few shortcuts to convert paths for your custom commands.
[1] https://github.com/microsoft/SysmonForLinux