Comment by _yosefk | Hacker News Reader

Comment by _yosefk | Hacker News Reader

This API is for people (both program authors and users) who really know quite well what they're doing, for very rare occasions, and the alternative/status quo was to not be able to get this info from the kernel at all. I imagine someone at MS thought they did a favor to people doing performance optimization by giving them something instead of nothing, perhaps they even had to fight to include this feature in the product because obviously Windows would sell rather well without the feature. They must have had a bad day reading this criticism.

(I'm not saying "poor Microsoft" - it's definitely not poor - and I'm not saying "you should thank people for whatever API they give you" - a lot of programs/features do more harm than good - and I'm not saying someone shouldn't vent having had a lot of time burnt by some ugly API. I'm saying specifically that this here is a dark corner of the OS that the API in question sheds at least some light on and I have a hunch, perhaps an entirely mistaken one, that it was someone's pet initiative and they thought it was definitely better than nothing. "Little did they know." To take a simple example of the other kind of API: sprintf, the version that doesn't take a buffer size, is a really bad API because that's something everyone's gonna use a lot and you just shouldn't give this kind of thing to people (give them snprintf at the very least) and you certainly can't be excused by "one should know what they're doing" in this case because it's between hard and uneconomical to use safely while passing the buffer size is the obvious thing to do, also one seems entitled to care-free string formatting, definitely 100x more so than care-free kernel status monitoring on the grounds of it being something many more people do much more often.)

Normally, I'd agree with your optimistic assumption, but having spent a bunch of the early to mid 2000s writing code for Windows applications, the oddness of this API relative to the simplicity of what you're actually doing was, IMO, nearly universal across Microsoft, including for APIs (like Direct3D in the first couple of releases, DirectShow, COM in general from any non-Visual Basic language, etc) that were wholly intended to be public facing APIs by their very nature.

I can't speak to the conspiracy-theoryish idea that Microsoft wrote bad APIs on purpose to make it easier to compete with other software companies at the application level, I suspect the issues were more subtle than that (an overly bike-sheddy code review culture, maybe?), but I did find them nearly universally bad to use as a programmer for a Windows "ISV" at the time.

Having said that, most modern Microsoft/Windows APIs I've used have been quite sane. Not bashing Microsoft in general here, just their APIs from about the mid 90s to the mid 2000s.

I've used Win32 (I guess calling it that in the 64b era dates me) including some of the COM stuff, though I guess not as extensively as you did (TFA definitely brought some memories, the stuff looks a lot like the usual Win32 stuff.)

I think it's generally hard to make an easy-to-use API in C, unless the memory management involved is really trivial. (Let's ignore C++ for the moment including Microsoft's attempts like MFC and ATL, on the theory that binary compatibility issues make C that much more practical than C++ for this kind of thing.) IMO say poll or select (and the rest of the socket API, actually) aren't a picnic, either, and the only way to have a nice experience with these is by using a higher-level wrapper, and that's because everything involving variable-sized data structures, or any sort of data structure nesting, or literal initialization of this sort of thing, or lifecycles and memory management, or callbacks with private state, etc. etc. is just gnarly in C. (In C++ everything of course is just ducky and hence we never tire of articles discussing why smart pointers should really be passed by reference and shared_ptr is as good as gc except it's slower if used throughout and it doesn't work with circular references and don't use it unless you really have to etc. etc.) I haven't used the standard X C API but I glanced at it and it didn't looked very appetizing; that Microsoft's C API for GUI and OO looks worse than most of the standard Unix APIs kinda results from MS's APIs doing more, IMO, and X in particular, or Motif, which do more of what Win32 does, do not seem superior to Win32 in terms of usability, though if someone with experience in both strongly disagrees I'd take their word for it.

Now if you're saying that their C APIs of today are better than my argument is off. If you're saying that say writing a Windows program in C# is better than a C/C++/VB COM-infested program, then I think it's more of a testament to the strength of .NET/similar runtimes than anything else.

ETW is used in major pieces like the windows performance analyzer. There is zero possibility that this is a single person's pet project.

Yes, some people are able to use ETW effectively; there just isn't much motivation to share knowlege in this (commercial/Windows) space.

https://news.ycombinator.com/item?id=11418334

Reply on news.ycombinator.com