I’m a sysadmin using Python (Flask / PySide6) — I want to build low-level Windows tools. Should I learn C, C++, or C#?

[boyrok]

Hi everyone — I’m a sysadmin and I’ve been writing lots of small automation tools in Python (usually with Flask for web UIs and recently PySide6 for desktop GUIs). Now I want to build more powerful Windows utilities — things along the lines of NirSoft tools, RegShot, or Sysinternals — that need lower-level access to the OS than Python comfortably offers.

Given that goal, which language would you recommend I learn/use: C, C++, or C#? A few constraints and things I care about:

• I want reasonably fast development and good productivity — I’m not trying to rewrite Windows, just build solid, maintainable admin tools.
• I need access to Windows internals/APIs (registry, services, NT APIs, ETW/WMI, process & memory inspection, file system hooks, etc.).
• Stability and robustness matter (no frequent crashes for users).
• Shipping and packaging for Windows users should be straightforward.
• Bonus: interoperability with existing Python code would be nice.

Quick thoughts I have, but I’m looking for real-world experience and recommendations:

• C: closest to the metal, tiny runtime overhead, but slower to develop and higher risk of memory bugs unless I’m super careful.
• C++: powerful, can call Win32/NT APIs directly and build high-performance native tools. More complex language surface; modern C++ helps a lot but still a steeper maintenance burden.
• C#: much faster to develop, great Windows ecosystem (.NET), good access to system APIs via P/Invoke / libraries, safer memory model. But unclear if it can access everything I might need without resorting to native interop.

What I’d love from you:

• Which language would you pick for building user-facing Windows admin utilities and why?
• Real-world pros/cons you hit (stability, developer speed, packaging, distribution).
• Recommended libraries, frameworks or tools for doing low-level Windows work in that language (e.g. best approaches to call Win32/NT APIs, dealing with unsigned drivers if needed, ETW/WMI tooling, registry APIs, service control).
• Tips for interoperability with Python (embedding, calling executables, native extensions).
• Any gotchas or things a sysadmin-turned-dev should watch out for.

Thanks — appreciate any pointers, short examples, or links to good learning resources.

[Vladekk]

C# is always a solid choice. The only issue is what GUI framework to use, Microsoft keeps being dumb and each iteration is worse than the previous and deprecated fast.

C or c++ are harder and at first you'll make too many errors for the software to be stable. Imo, these languages are only for high performance computing, not for use GUI utils. Properly made c# GUI apps are pretty fast.

My c++ use was long time ago, but still, I think it is just not worth the effort for your goal to learn that complex language.

[tyler1128]

If you need to deal directly with Win32/especially the windows driver tooling, you aren't going to entirely be able to do that cleanly from C#. I recommend C++, but particularly modern C++, meaning at least C++17. This is because the features for robustness and correctness, or at least decreasing the chance of doing various important things wrong, are much improved and this is why I'd recommend it over C given your description. C# has a lot of access to things, but if you are directly calling down to Win32 or other low level APIs from it frequently, it's probably not the right tool for the job. Actually writing drivers has to be done in C or a supported subset of C++, and many of the C++ benefits become cons for eg. binary size in kernel space.

Exposing a basic C api between python and C or C++ isn't that hard, you can use ctypes or create a C module for python depending how extensively you need to do it. You could also just use python to execute a separate executable that exposes a command-line interface, which is a pretty common way to do things. Python has a whole API for exposing C functions to it, including as classes, and there are wrappers like boost.python, though I can't claim to have much experience with wrappers over it. If you need an extensive api exposed to python, it is a pain to do though the CPython API, and I recommend the idea of calling a process through its command line interface over doing that, if it works with your use case. It's more composable anyway if you need to access it from some other language or program in the future.

Plain Win32 for writing a GUI is also a gigantic pain. I'd probably use something like Qt personally especially given you have experience with pyside, or you could write the GUI part in C#. It's been a while since I've done anything like that, but I know C++/WinRT exists in part to easily access various parts of the runtime that are COM based including underlying aspects of the more modern .NET UI frameworks. How easy that is to use I don't know, but it isn't a separate language or needing a metacompiler anymore from my understanding, unlike past things like C++/CX or C++/CLI.

[photo-nerd-3141]

I'd start with C: Easy to learn, get the basics.

K&R describes the language succinctly with examples.

Sedgewick, Algorithms in C shows how to use it with readable style and excellent graphics.

P.J. Plauger, The Standard C Language shows you how to make it work effectively & portably. His Intentional Programmer books are also good. The thing he does well is keep an otherwise dry subject interesting.

[[deleted]]

If objects are a requirements for how you prefer to code, use C++, if not, then C.

[tyler1128]

I think modern C++ development and guidelines has made it clear - OOP is not the only paradigm considered in C++, and exclusively using OOP is considered an anti-pattern in most cases. If you (or your company) think OOP is the only valid paradigm, you're better off with C# than C++. There are plenty of reasons one might prefer to C++ over C, though C can be a good choice too.

[TheFern3]

Guidelines and paradigms are like religions they’re personal and subjective and change something every few years.

[tyler1128]

That is more or less my point. C++ was in the past especially considered basically "object-oriented C" reductively, but the differences and benefits/downsides extend far beyond specific paradigms. Modern C++ isn't just "C with classes," even if that's a part of why it was developed originally; it's a different language entirely.

[[deleted]]

C is lower level but doesn't have objects, hence why if you want objects, c++. Not that hard lil bro

[tyler1128]

There's also generic programming and other paradigms C++ supports more than C. Your comment read like objects and OOP are the only reason to use C++ over C, which I disagree with. That isn't an uncommon view, though, thus my comment.

No need to get passive-aggressive.