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.