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...
--
--
<a href="http://lkcl.net">http://lkcl.net</a>
--