Using SERVER_START_REQ/SERVER_END_REQ in C++ code calls helper methods which need an explicit cast from a void* to __server_request_info*.
Signed-off-by: Mahdi Tayarani tayarani@google.com --- include/wine/server.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/wine/server.h b/include/wine/server.h index b05271b7522..477868c5854 100644 --- a/include/wine/server.h +++ b/include/wine/server.h @@ -70,7 +70,7 @@ static inline data_size_t wine_server_reply_size( const void *reply ) /* add some data to be sent along with the request */ static inline void wine_server_add_data( void *req_ptr, const void *ptr, data_size_t size ) { - struct __server_request_info * const req = req_ptr; + struct __server_request_info * const req = (struct __server_request_info *)req_ptr; if (size) { req->data[req->data_count].ptr = ptr; @@ -82,7 +82,7 @@ static inline void wine_server_add_data( void *req_ptr, const void *ptr, data_si /* set the pointer and max size for the reply var data */ static inline void wine_server_set_reply( void *req_ptr, void *ptr, data_size_t max_size ) { - struct __server_request_info * const req = req_ptr; + struct __server_request_info * const req = (struct __server_request_info *)req_ptr; req->reply_data = ptr; req->u.req.request_header.reply_size = max_size; }
Am 03.06.2022 um 19:15 schrieb Mahdi Tayarani tayarani@google.com:
Using SERVER_START_REQ/SERVER_END_REQ in C++ code calls helper methods which need an explicit cast from a void* to __server_request_info*.
Why do you need this? include/wine/server.h (and pretty much everything in include/wine/) is a private header that should not be used by external code (e.g. programs linking to winelib)
We need to include "include/wine/server.h" as it contains the definition for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) needs to make a Wine Server call so we have to include that header. But by doing so we run into compilation issues.
The proposed changes are valid C and C++ syntax so applying them allows us to include the header file without modification.
On Sun, Jun 5, 2022 at 1:42 PM Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 03.06.2022 um 19:15 schrieb Mahdi Tayarani tayarani@google.com:
Using SERVER_START_REQ/SERVER_END_REQ in C++ code calls helper methods which need an explicit cast from a void* to __server_request_info*.
Why do you need this? include/wine/server.h (and pretty much everything in include/wine/) is a private header that should not be used by external code (e.g. programs linking to winelib)
On Mon, Jun 6, 2022 at 8:59 AM Mahdi Tayarani tayarani@google.com wrote:
We need to include "include/wine/server.h" as it contains the definition for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) needs to make a Wine Server call so we have to include that header. But by doing so we run into compilation issues.
I suspect that this is going to be a tough sell. Why are you trying to call the Wineserver directly, instead of calling the Windows function that calls the Wineserver?
-Alex
We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need.
Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit.
On Mon, Jun 6, 2022 at 11:51 AM Alex Henrie alexhenrie24@gmail.com wrote:
On Mon, Jun 6, 2022 at 8:59 AM Mahdi Tayarani tayarani@google.com wrote:
We need to include "include/wine/server.h" as it contains the definition
for the SERVER_START_REQ/SERVER_END_REQ macros. Our code (written in C++) needs to make a Wine Server call so we have to include that header. But by doing so we run into compilation issues.
I suspect that this is going to be a tough sell. Why are you trying to call the Wineserver directly, instead of calling the Windows function that calls the Wineserver?
-Alex
Hi Mahdi,
On 6/6/22 18:12, Mahdi Tayarani wrote:
We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need.
Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit.
I think the "tough sell" is because Wine doesn't expect wineserver requests to be made from non-Wine code, and doesn't provide any guarantee about the protocol compatibility across versions.
Though if you're well aware of this I guess it's up to you if you do it nonetheless, and the change can make sense indeed, as you say, it's just making a cast explicit.
Then I'm interested to know more about the specific needs you have on input processing, if you can share more detail about it. Like what isn't currently possible to do with __wine_send_input, what you would need, etc.
All wine input goes through it, and I'm investigating possible better ways to handle non-joystick devices through the HID stack as well, which may involve changes in that area.
Cheers,
On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani tayarani@google.com wrote:
We have an input processing system which requires us to directly send input update information to the Wine Server. The existing helper methods don't provide what we need.
Does that mean that you're porting Wine to a new platform and writing something like winex11.drv for that platform? Could your new code be included in upstream Wine one day? If so, it would probably be better to write it in C instead of C++ because the Wine project does not currently accept C++ code.
Or do you mean that you are writing cross-platform software that will run on both Windows and on Wine? If that is the case, how does the code work on Windows? Could the same functions that you call on Windows be improved in Wine to do what you need?
Can you please elaborate why it will be a tough sell? The change provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit.
Although the change itself is very small, it smells like a hack, and the Wine community really does not like hacks. I think everyone would prefer to identify the underlying problem here and, if possible, resolve it instead of working around it. That said, I am just a volunteer Wine developer trying to be helpful; other developers would be able to speak more authoritatively.
-Alex
Thanks for the explanation. The concerns you raise are valid.
To provide a bit of context. We have a Linux-like system without X11, so we've written our own driver to replace winex11.drv. It's written in C++ for various reasons to simplify integrating with the underlying platform. Considering this is part of an internal/proprietary system it will not be upstreamed. So we're not concerned about that. But we would like to keep our local modifications to Wine at a minimum.
The existing input processing system in Wine is heavily built around X11 behaviour. So none of the helper methods winex11.drv uses help our case, and we've resorted to directly sending a message to the Wine Server. While that solution is working well, the only change we need to make to Wine is the patch I have submitted.
Hope this helps clear up why we need it. As to why try to upstream it (aside from our motivation to minimize local changes). Any other project trying to interact with the Wine Server though C++ code could benefit from this. I've seen instances where Wine has made efforts to be C++ compatible even though the majority of the code is C (e.g. a bug I reported some time ago https://bugs.winehq.org/show_bug.cgi?id=52787). So it seems like a good decision to try and merge this.
Mahdi
On Mon, Jun 6, 2022 at 1:14 PM Alex Henrie alexhenrie24@gmail.com wrote:
On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani tayarani@google.com wrote:
We have an input processing system which requires us to directly send
input update information to the Wine Server. The existing helper methods don't provide what we need.
Does that mean that you're porting Wine to a new platform and writing something like winex11.drv for that platform? Could your new code be included in upstream Wine one day? If so, it would probably be better to write it in C instead of C++ because the Wine project does not currently accept C++ code.
Or do you mean that you are writing cross-platform software that will run on both Windows and on Wine? If that is the case, how does the code work on Windows? Could the same functions that you call on Windows be improved in Wine to do what you need?
Can you please elaborate why it will be a tough sell? The change
provides no sort of functional or behavioural change. It's just making the cast that was already implicitly happening, explicit.
Although the change itself is very small, it smells like a hack, and the Wine community really does not like hacks. I think everyone would prefer to identify the underlying problem here and, if possible, resolve it instead of working around it. That said, I am just a volunteer Wine developer trying to be helpful; other developers would be able to speak more authoritatively.
-Alex
-
Alex Henrie -
Mahdi Tayarani -
Rémi Bernon -
Stefan Dösinger