That's understood -- and I do tend to think that there are certain dangers with your approach, which should be kept in mind. I maintained the VC++ CRT for quite some time and I had access to the source code, the hidden docs and all the right people and tend to think that especially the exception handling part is an incredibly hard thing to get perfectly correct.
probably you are not allowed to tell me the secrets :^)? The only chance to get it rigth on Windows is to rely on the MSDN, test (try-and-error). These things are not secret in the sense that Microsoft doesn't want anyone to know.
It's more that some implementation details shouldn't be relied on and probably more importantly, people just don't have the time to polish things up for external consumption. Exception handling is particularly nasty in that it's extremely messy code and involves compiler FE, BE, operating system and the runtime library. There are very few people inside MS to fully understand what's going on under the covers. I'm happy to help out where I can, but just glancing over the boost mailing lists is very time consuming.
For fiber-local-storage the user is responsible to cleanup. I don't recall the specifics, but FLS allows you to register callbacks for when a fiber exit (see FlsAlloc). There's some book-keeping information somewhere near the end of the TIB for that.
TIB isn't well described in the MSDN (at least the end of the TIB). AFAIK FLS can only be used if the thread was fibierized (ConvertThreadToFiber()). In the case of fcontext on x86 Windows this isn't done- so boost.context could require not to use FLS.
FLS can be used without ConvertThreadToFiber. In fact, the CRT uses FLS on x86 Vista+ and x64 (and many people don't use fibers).
That makes it a bit dangerous. Security has become more of a religion at Microsoft...
I don't know what MS will do in its next versions of Windows. If MS decides to break some calling conventions then I've to fix the code. what could I do instead? I guess, it's a fairly safe bet that the calling convention isn't changed in incompatible ways.
There are strong compatibility guarantees in Windows. There are a lot of people working no nothing but it (and they will let you know if you break something :-) ). But there's a difference on relying on documented behavior and information obtained by trial and error of a particular version of the OS. My take would be that you're doing this at your own risk. In theory, it's possible to run a process without a kernel32.dll, but all bets are off then. So it is possible for Windows to make a change to the OS that requires coordination between user and kernel parts. My point here is, that you are at a significant disadvantage to the OS here as you would have to track a moving target. Again, UMS might be worthwhile to look at in Win7 SP1+.
http://ok73.ok.funpic.de/boost/libs/context/doc/html/ it reads
... protected_stack( std::size_t stacksize)
contructor of class protected_stack takes size_t as argument - do you miss the 'explicit' keyword?
Yes, I almost write it by default and everywhere :-) Thought, that this was a glitch of the doc build system. But it seems the ctor isn't declared explicit. Seems odd, but then I haven't looked to closely. -hg