It is an OS component, it's provided in kernel32.dll and accesses internal OS data structures that are not publicly defined or stable between versions. You cannot safely implement fibers in Windows without the fibers API, period. Boost.Context's direct Windows context switching code hacks undocumented fields in the TIB: https://github.com/boostorg/context/blob/6fa6d5c50d120e69b2d...

...and this causes problems, because it can't guarantee that all fields are initialized or switched successfully: https://lists.boost.org/boost-bugs/2014/10/38476.php

Microsoft continually adds and changes fields in the TIB with each new release of Windows. Attempting to implement fibers manually is a ticking time bomb that should never be used in production.

That bug was caused by the TLS slots pointer being uninitialized in the newly created Boost fiber, not a change in Windows API. TLS pre-dates boost::context, the field had existed since the very first commit.

I already said "MS would rather you not", obviously, otherwise they would have documented the TIB.

The fact remains that tons of production systems rely on officially-unofficial elements of NT's architecture and this is one such element that is heavily relied on by everyone who uses boost stackful coroutines. Hyrum's Law in action.

The bug was caused by Boost.Context manipulating OS data structure fields that it has no business changing.

And yes, those fields do now have to be maintained for backwards compatibility -- because libraries like Boost.Context hardcoded this into applications, unbeknownst to the users of that library.