3 ms·

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 th

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.

_yosefk 10y ago
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.

_yosefk 10y ago

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.