On resources and KTHREAD

Jacek Caban jacek at codeweavers.com
Thu Feb 21 07:52:34 CST 2019

Hi Zebediah,

On 2/1/19 4:44 AM, Zebediah Figura wrote:
> As the last leg of my journey (for now) implementing Windows' thousand 
> synchronization objects, I arrive at ERESOURCE. Unlike the last three 
> forms of mutex, these can be recursively acquired, and so it's 
> necessary to keep track of who is holding them. I have a complete 
> implementation that passes its own tests, but only with 
> KeGetCurrentThread() stubbed to return the TID.

As mentioned in bug, if it's the only thing preventing you from sending 
it, using KeGetCurrentThreadId() in ERESOURCE until we have 
KeGetCurrentThread() doesn't seem too bad.

> A proper implementation of KeGetCurrentThread() is already required by 
> some drivers (bug 45844). What would be necessary to implement this 
> function in an acceptable way? If simply returning the TID isn't 
> enough (and I believe this approach has been rejected before), how 
> much of the structure need we correctly implement? How can we find out 
> what that structure is, undocumented as it is? (For a slightly more 
> concrete question: is [1] a legally safe source?) 

I don't know about how much of the actual struct do we need, but even 
being able to reference the object by pointer would be enough for some 
applications (and for your use case, I guess). I recently looked at 
ObReferenceObjectByHandle (which is needed by MRAC anti-cheat as well we 
others, according to bugzilla). It's not strictly needed for 
KeGetCurrentThread(), but having it implemented for threads would take 
care of object lifetime and HANDLE to object pointer mapping. I have a 
proof of concept code for ObReferenceObjectByHandle(). The idea there is 
to do actual handles to client object pointer mapping in wineserver. 
Server also notifies device manager when the underlying object is 
released, so it may free its object.


More information about the wine-devel mailing list