5 ms·

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.

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?

anentropic 10y ago
The API is still bad, it seems to have been badly designed regardless of whether the intended consumers are external developers or internal code
- jjaredsimpson 10y ago
  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.
kabdib 10y ago
> lets you define events in an xml manifest as part of your build process ... at which point you should run screaming.
- jjaredsimpson 10y ago
  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.
popmystack 10y ago
>But then is the API really bad? Yes.
ataylor284_ 10y ago
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".
- burnstek 10y ago
  "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.
  - ataylor284_ 10y ago
    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.
  - raarts 10y ago
    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.
marcoperaza 10y ago
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/dn701953(v=vs.85).aspx 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.TraceEvent http://www.nuget.org/packages/Microsoft.Diagnostics.Tracing....
- Varriount 10y ago
  How is that API supposed to be used from C (not C++)?
  - marcoperaza 10y ago
    This page has sample code in both C and C++, look at the #ifdef's: https://msdn.microsoft.com/en-us/library/windows/hardware/dn904622(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/dn...

anentropic 10y ago

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

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

kabdib 10y ago

> lets you define events in an xml manifest as part of your build process ... at which point you should run screaming.

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

popmystack 10y ago

>But then is the API really bad? Yes.

ataylor284_ 10y ago

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".

burnstek 10y ago
"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.
- ataylor284_ 10y ago
  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.
- raarts 10y ago
  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.

marcoperaza 10y ago

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/dn701953(v=vs.85).aspx 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.TraceEvent http://www.nuget.org/packages/Microsoft.Diagnostics.Tracing....

Varriount 10y ago
How is that API supposed to be used from C (not C++)?
- marcoperaza 10y ago
  This page has sample code in both C and C++, look at the #ifdef's: https://msdn.microsoft.com/en-us/library/windows/hardware/dn904622(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/dn...