dear hyperion, sorry for not getting back to this one earlier.
regarding hacking up a replacement for the DCE compatible threads library: GREAT.
i have made a start by removing the POSIX Draft 4 threading requirements, which has been on the cards for like ... ermmm... five years.
see http://sf.net/projects/freedce, cvs requirements, see dcethreads-win32 give me a while to commit what i've done so far.
there's actually very little code left, because of pthreads-win32.
the only stuff left in dcethreads-win32 is actually the DCE exception handling stuff.
which i understand is right in your area of expertise :)
btw: one important point.
it is NOT, i repeat NOT important that "speed be of the essence".
the usual argument "exceptions are expensive and therefore evil" simply doesn't apply.
exceptions in DCE are used to catch memory and _networking_ errors.
_networking_ errors.
order of milliseconds and greater.
DCE/RPC applications (the Windows NT 4.0 Domains and Administrative suite are good - and relevant - examples) are _designed_ with networking errors and networking delays taken into consideration and into account.
the only instance where someone didn't bother to take networking into account is the idiots who ported win16 (yes, win16, remember we're talking Windows NT 3.1 here - where do you think win32 came from? not from the idiots in the win95 team :) printing API to spoolss (taking the "blobs" as [in,out] parameters - imagine what _that_ does when you have the double-function-call thing, the first one to ask how big a "blob" to allocate).
but i digress...