which is a shame because I miss old-school highly-functional win32 apps like this—bursting with soul and a flagrant disregard for modern app design/development principles.
You know, a tool, made by a tool maker, in the relevant trade, making a tool meant to be used by tool makers.
As opposed to the stuff nowadays that seem to be marketed first, made by whoever has the least power to ignore the job, and using some abysmal javascript GUI framework that can't even keep up with desktop framerate.
I also miss the days when the tools I used to do my job didn't HIDE shit from me, like error messages. Sure, I might not know what "ExtremelyExplicitNullException in doFrobThrob" means, but when I paste that error message in the support email, the engineer on the other side knows the exact line of code that error was generated on, and which variable was broken, and 9/10 times that's enough to actually find the root cause and fix it. No telemetry required. I'm so tired of vague, numbered error messages that nobody knows what line of code it corresponds to and nobody cares anyway because it's just going into a giant pile in the telemetry system that nobody except one mediocre PM is allowed to pull bugs from.
Adding support to a tool for a different is that is developed for winapi is really not a thing. If it was written for GTK or Qt or electron then it is possible. But I would guess you should just best write a new app instead?
