Comment by jjaredsimpson | Hacker News Reader

Comment by jjaredsimpson | Hacker News Reader

ETW isn't supposed to be written like this at all. MS has entire codegen toolchain that lets you define events in an xml manifest as part of your build process. This codegens a C header file which lets you fire events in your own code with a simple function call.

When you want to correlate events from your own code and OS events you use a tool like XPerf which knows the OS events and can read your application manifest to get strong typing on the events your application fires. This also lets you take traces on deployed software on customer machines.

If you want to roll your own event consumers you can do that too. But XPerf probably already does what you want.

This all existed back in like 2010 when I was using ETW. I'm sure the tooling has only gotten better since then. So yeah you can go write your own bad incomplete version of XPerf and not leverage your existing build process and MS tooling. But then is the API really bad? Or are you just not googling correctly?

It has gotten much better since then. These days the preferred logging API is the Tracelogging API https://msdn.microsoft.com/en-us/library/windows/hardware/dn... . No schemas, no XML, no build integration required, no decoding problems.

As for collecting logs, WPR is currently the best tool.

There's a great .NET library for both logging and reading recorded events. http://www.nuget.org/packages/Microsoft.Diagnostics.Tracing....

How is that API supposed to be used from C (not C++)?

This page has sample code in both C and C++, look at the #ifdef's: https://msdn.microsoft.com/en-us/library/windows/hardware/dn...

The API is still bad, it seems to have been badly designed regardless of whether the intended consumers are external developers or internal code

I don't see a well argued point that it is badly designed. It supports a powerful set of low overhead performance analysis tools.

If you want to correlate OS events, SQL server events, and application events, etc, you can get this working simply,correctly, fast and maintainable.

An api having a point of view about how it should be used doesn't make it a bad api.

This seems to be Microsoft's pattern. Make the APIs super low level and difficult to use, and build tooling on top to make it palatable. If you're doing simple stuff with Visual Studio, no problem, but as soon as you need to go deeper, good luck.

I think it's probably embedded in MS developer culture, leftover from the old days when the ulterior motive was to make Windows "easy to develop for, difficult to port away from".

"If you're doing simple stuff with <insert high level tooling here>, no problem, but as soon as you need to go deeper, good luck."

This is how technology works in general. The deeper you go, the more abstractions you remove, the more difficult the job becomes.

The point is that there was no effort to use meaningful abstractions and a coherent interface at the API level. The art of building a good product is finding the right level of abstraction for your audience, and I don't think 3rd party developers are well served here, although internal Windows performance engineers might be.

Funny how for me this works completely the other way. Often people try to make things simple but in the process achieve exactly the opposite.

> lets you define events in an xml manifest as part of your build process

... at which point you should run screaming.

Because all uses of xml are wrong by default? Something like:

<myevent> <int/> <timestamp/> <string/> </myevent>

Will codegen to a function like myevent_fire(int,timestamp,string).

Why is this bad? You separate the definition of event classes from their use sites and have correctness by default.

Reply on news.ycombinator.com