Win32 plugins via RPC

[JakubVanek]

Hi,

I want to propose a solution to the old problem of native plugins. I understand these aren't going to be supported for long, but as we've seen in #192 it is still possible to encounter routes using these plugins.

I think the only practical way of using native Win32 binaries on other platforms is through Wine. I propose implementing Win32 plugin server written in C/C++. It would run in Wine, wrapping the plugin into a RPC interface. For communication between Wine and Mono, we could use Apache Thrift or similar RPC. The same approach could then be adopted for native plugins on Windows.

The main tasks are:

• Launching and maintaining a running standalone Wine instance.
  • We can either use Wine provided by the system, or we can download a self-contained package like PlayOnLinux does.
  • We can either use single server instance for all plugins (preferably), or we can spawn a new one for each plugin.
• Reimplementing AtsPluginProxy to rely on RPC instead of on P/Invoke. It would connect to listening plugin server via TCP socket on localhost.
• Implementing the RPC server using Win32 API and Thrift C++ API.

We can also avoid using existing RPC and implement our own, optimized protocol, as we precisely know which functions with which arguments can we call.

Best regards,

Jakub

[JakubVanek]

RPC might have issues with latency, but I have no idea whether it will be a real problem.

[leezer3]

That's a very interesting idea.

Exactly how much work this would be I'm not entirely sure, but it shouldn't be mega amounts.
Having said that, I'm not the happiest in the world bundling Wine (or relying on this) at all.

This is a marginally WIP framework for replacing Win32 plugins on the fly with C# alternatives:
#137

The main issues with that are that the configuration files are manually copied into the plugin directory at the minute.
I also proposed this privately as a 'solution' to a couple of major UK developers (e.g. trains would generally work on Linux etc, but with in some cases a reduced featureset), but got pushback as things would no longer be 100% as designed/ under their control.
It's on my list of things to do more digging into and work on the plugins themselves, as this is a technically better solution in the long run.

Onto your proposal:
Plugins use Mackoy's Win32 API ( http://openbve-project.net/documentation/HTML/train_plugin_legacy.html ) which is dead simple.
Essentially, we need to spin up a loop in our proxy program, and just communicate backwards and forwards between the two/

My instinct would be to use a packet based TCP implementation rather than RPC as legacy plugins have no knowledge of openBVE's internals.

[leezer3]

Closed via #606