[PATCH] include: Allow making Wine Server requests from C++ code

[Mahdi Tayarani]

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 at gmail.com> wrote:

> On Mon, Jun 6, 2022 at 10:12 AM Mahdi Tayarani <tayarani at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220606/57aaeaf9/attachment.htm>