Could a mod de-hype the headline please? I propose, "Context switch logging with the Windows Event Tracing API"
Ok, done.
Context switch logging with the Windows Event Tracing API (2014)
61–70 of 78 posts
Re: Context switch logging with the Windows Event Tracing API (2014)
#62js;dr
Please don't do this here.
Re: Context switch logging with the Windows Event Tracing API (2014)
#63Please amend with '2014' this is not a new post
OK, done.
Re: Context switch logging with the Windows Event Tracing API (2014)
#64Re: Context switch logging with the Windows Event Tracing API (2014)
#65This 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 prod…
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.
Re: Context switch logging with the Windows Event Tracing API (2014)
#66Somewhat related, Jeff & Casey take down another MS API: How to draw a rectangle with Direct2D. http://braid-game.com/news/2009/01/the-jeff-and-casey-show-o...
The files on that page wouldn't load for me-- the podcast that's being drawn from is here, and the Direct2D portion is around the 1 hour mark:
Re: Context switch logging with the Windows Event Tracing API (2014)
#67I thought this might be about the (old) Java Date API (which also inspired the JavaScript API as well): https://stackoverflow.com/questions/1969442/whats-wrong-with... As it is, it's a JavaScript laden blog about a Microsoft Win32 API and is virtually unreadable, so there's not much point in following the OP link.
I had no problem reading it on my mobile phone. Did you have any comments about the content of the article?
Re: Context switch logging with the Windows Event Tracing API (2014)
#68Earlier quoted context omitted.
Oh, they're not that bad. It uses the ioctl() metaphor. I'm surprised somebody who's read ALP doesn't see that.
ioctl() isn't a metaphor, it's a sin-bin for things that don't fit in the file metaphor.
I'd agree if there were no codes for READ and WRITE under the ioctl() rubric :)
Re: Context switch logging with the Windows Event Tracing API (2014)
#69Well, I don't know about the API, but that's certainly the worst blog software ever made, requiring me to enable JavaScript and execute code in order to read some simple HTML and CSS. Why‽
Casey said in one of the J&C shows that he tried to do the site in HTML & CSS but ragequit and wrote it in C.
Re: Context switch logging with the Windows Event Tracing API (2014)
#70This 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 prod…
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…
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.