Poster has not worked very deeply with Win32, is unaware of its conventions. Film at 11.
For example:
> Yes, that’s right, every user of the Event Tracing for Windows API has to do the arithmetic and layout of the packed structure format themselves.
These represent very common idioms in Windows. One common idiom is about binary compatibility. Microsoft can change the length of the structure in a future rev of the SDK. Old callers can still work because they are specifying sizes and offsets - the library can look at these and know what to do. The other common idiom (very common in the NT kernel for example) is similar to what C99 introduced for structures with variable-length members, something C definitely didn't do for you and even today with it standardized still gets pretty clumsy.
The author lost all credibility when he wrote this:
> StringCbCopy((LPSTR)((char * )pSessionProperties + pSessionProperties->LoggerNameOffset),
sizeof(KERNEL_LOGGER_NAME), KERNEL_LOGGER_NAME);
Why on earth would you say (LPSTR)(char * ) ? That is literally saying (char * ) (char * ).
To me a "bad" API enters into questions like:
* How does it handle errors? Consistency is good. Swallowing them to the caller is bad.
* Does it give the caller the right level of detail about what is going on? It's especially common for it to be a black box and completely fail under some condition that the author did not envision. Some kind of escape hook that exposes implementation details makes library maintanence difficult but sometimes it's needed.
I haven't looked too deeply at etw but I don't suspect it fails at these. Maybe it errs too much on one extreme on the 2nd bullet.