Feature Proposal: Implementing an interface to the object manager via shared memory

[Derek Lesho]

Currently, two apps/drivers that I know of, Battleye (BEDaisy.sys) and
EasyAnticheat (EasyAntiCheat.sys) utilize the object manager.  Right
now, we can only emulate this by setting the object pointers to handle
values, and interpreting the pointers as such when app passes it to
another function.  The problem is, not all object pointers are opaque,
and some apps (EAC) try to read the contents of the structure even
when they documented as being opaque.  To get around this, we could
try filling in dummy data on a case-per-case basis, but this solution
may not hold up on rapidly changing software like anti-cheat software.

My proposal is that we utilize shared memory, written to by the object
manager in wineserver, and mapped as read only in all of the
winedevice processes to implement the kernel's object manager
interface.  Wineserver would update data in the object structures as
necessary, and when an driver calls something like
ObReferenceObjectByHandle, we would request a pointer to the simulated
structure.

I haven't worked out all of the kinks on how practical this would be,
and am only getting started with my implementation, but I'm curious
what you guys think of this idea.  I know shared memory is generally
not supposed to be used, but I can't think of anything else that would
retain the accuracy.