I often find myself searching "how to find X in Windows", and the answer is to run one of these tools. But what I really want to know is how the tool does it.
I often find myself searching "how to find X in Windows", and the answer is to run one of these tools. But what I really want to know is how the tool does it.
If you really want to know, this is how you find out.
Even when source code is available, these tools are both easier to use (reading source code can be very time consuming for large projects), and they give more accurate results.
By the way, sometimes I use these tools when I debug or troubleshoot my own software.
Source code only helps for simple programs. For sufficiently complex software, looking at source code increases development time instead of helping.
I've learned more about posix and the GNU API reading the source code to busybox utilities (which is super easy because they're so somall) than just about anywhere else.
Windows has huge API surface. If you really want to learn it, I suggest reading books, not source code. E.g. “Windows internals” is descent one.
If you’re just interested how particular program works, with the tools that I’ve mentioned in the above comment, you’ll find more about the API than looking at the source code. Especially if you’re just learning. Many apps use big libraries like MFC or QT, the source code will tell you how the developer called these libraries, but the tools will tell you how the process interacts with OS. Due to the complexity of the libraries, can be huge differences between the two.
When you release code, you need to do following.
1. Ensure it builds. Old software can only be built with old compilers, with old Windows SDK. Sometimes they also rely on old custom build tools. Other times builds requires manual steps.
2. Ensure you have not violated any copyrights or patents. The relevant laws are ridiculous these days, potentially, you can get in legal trouble even by copy-pasting stuff from stackoverflow.
3. Ideally, that it comes with documentation/comments, at least minimal.
Neither of these are free, they’re quite time consuming. Speaking from experience, I did release a few things, e.g. https://github.com/Const-me/EsentSerialize/
> That way one can trivially look through it
Looking through is not enough. To be sure, you need to build the software and run the binaries you’ve built. Building third-party code, especially old one, can be very hard: dependencies, build environment, mismatched OS versions, and thousand more papercuts. I sometimes spending a whole day just to build some third-party project that I need to use. BTW I’ve been programming for living for couple decades now.
Even if it builds, security audit of a program longer than a couple pages of code is very non-trivial. If you’ll ask “how do you know they are longer than a couple pages?” the answer is “because GUI”. Despite user friendly, GUI usually require substantial amount of code. That’s probably the main reason why open source community is reluctant to create GUI apps despite users obviously prefer them over CLI.
Some days you just can't win.
Everybody else can go take a long walk off a short pier, if they're going to send angry emails about not being able to build something they didn't pay me for.
Imagine Breaking Bad, only with malware instead of drugs.
Nir Sofer has been around forever and has a great reputation in the Windows dev community, but^Wso he could do a lot of damage in a hurry if he wanted to.