We probably don't need `SHARED_READ_BEGIN` from the server side, but why is this the case?
The server doesn't need it because the shared memory is only ever written from the server side, which is also single threaded?
Yes, it should probably be safe. It was more of a question for myself, seeking something more formal. Shouldn't matter anyway.
Is it a good idea to disable root object type check completely if the name is `__wine_mapping`? What if we open-coded in `DECL_HANDLER(open_mapping)` instead? Would that hurt readability much?
Not sure exactly what you meant by object type check but I did something like that instead, which saves the need for custom lookup_name implementations, and uses a new `get_object_mapping` ops. I think it makes things more clear and the mapping object type is obviously checked by the function signature.
Thanks, your `get_object_mapping` approach seems good to me.
Full disclosure: when I first made this "suggestion," frankly I didn't realize that wine was kind of hacky with regards to `NtOpen*` handling. Specifically, it parses each segment via a succession of `lookup_name` calls. Instead, my observation tells me that:
1. `directory_lookup_name` should perform all the path parsing, including resolution of symlinks, by itself. 2. `symlink_lookup_name` should be just `no_lookup_name`. 3. `file_lookup_name`, should implement filesystem lookups (except this case is always intercepted and handled by the server).
This will let us get rid of the "get_directory_obj" hack in `open_object()`, and perhaps even allow both object-mapping lookup and named-pipe lookup to be done in a more elegant way. However, that would require a nontrivial wineserver refactoring which I believe shouldn't block this patchset.