On Aug 29, 2013, at 6:43 PM, Bruno Jesus wrote:
Hi all, I need some help to continue my current wine work.
In order to implement SO_PROTOCOL_INFO for getsockopt I need to retrieve some information from the socket like its family and protocol.
I have searched for a few days and ended up with a solution I dislike so I had a better idea (at least I hope I did).
Instead of using non-portable SO_DOMAIN and SO_PROTOCOL/SO_PROTOTYPE to retrieve the socket family and protocol or using non-reliable guessing using only the socket type I thought it would be better to ask the server for this information. Using a request just like is used for several other information in ws2_32 (operation which will work on every OS).
So, all I need is a server request that based on the socket fd will return the socket family, type and protocol. I tried to understand how requests work but I failed completely.
Maybe this request can be later improved to return the connection time so we can finally fix SO_CONNECT_TIME option.
The current solution is attached, since I sent the tests separated and they were commited the patch will not apply, it's only for reference. The idea is to remove the functions get_sock_[family|protocol|type] to a single server request.
So, is this a good idea?
There's no way I know of to get this information directly on at least Mac OS, so I'd say go for it. (But I can't speak for anyone else on this list, so...)
If yes, how can I create and use the request?
To add a new request to the server, you first add a definition to server/protocol.def . This file is processed by the make_requests tool, which generates a bunch of other files from it. The syntax of the server protocol definition file is somewhat like Objective-C (if you've ever used or seen that). A typical server request definition looks like this:
@REQ(request_name) /* input parameters go here */ int input; obj_handle_t handle; /* don't use Windows types */ @REPLY /* output values go here */ int output; @END
As with all generated files, the files generated by make_requests shouldn't be included in your patch.
After defining a new server call, you define the handler in the server like so:
DECL_HANDLER(request_name) { /* implicit parameters: req, reply */ /* use the 'current' global to refer to the process and thread that made the request */ if (req->handle != ((obj_handle_t)-1)) { reply->output = do_something(req->input, req->handle); } else { set_error(STATUS_UNSUCCESSFUL); /* NTSTATUS is returned to client */ } /* no return value */ }
Then, in the client DLLs, you make server calls like this:
SERVER_START_REQ( request_name ) { /* implicit variables: req, reply */ req->input = 1; req->handle = wine_server_obj_handle( handle ); /* converts Windows HANDLE to a server obj_handle_t */ if (wine_server_call( req ) != STATUS_SUCCESS) { /* SetLastError(), return error code, etc. */ } do_something(reply->output); } SERVER_END_REQ;
There's lots of examples throughout Wine of this in action, especially in lower-level DLLs like ntdll and kernel32; I encourage you to look at them. (That's how I figured all this out, after all.) If you have any more questions (and not just because you were too lazy to even look ;), feel free to ask.
Chip