Re: [boost] [context review] Windows ABI requirements

Subject: Re: [boost] [context review] Windows ABI requirements
From: Holger Grund (holger.grund_at_[hidden])
Date: 2011-03-23 02:52:36

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