Provide assets for using gRPC interface in Windows applications

[mink99]

Describe the request

GRPC under Windows is not easy to use under Windows, gcc is not supported and it has to be built on your own, requiring a toolchain that is not always available.
As the Arduino IDE and CLI developers have all required components available under windows it would be helpful to provide with each new release / build support for the users of the CLI under GRPC:

• A DLL that exports the GRPC functions/services (as described in https://arduino.github.io/arduino-cli/dev/rpc/commands/)
• (optional) A DLL that exports the GRPC functions/services with debug symbols (as described in https://arduino.github.io/arduino-cli/dev/rpc/commands/)
• An import lib for MSVC ( if an addtional DLL with debug symbols is included, an import lib for this too)
• An import lib for gcc ( if an addtional DLL with debug symbols is included, an import lib for this too)
• A header file

Describe the current behavior

GRPC under Windows is not easy to use under Windows, gcc is not supported and it has to be built on your own

Arduino CLI version

all

Operating system

Windows

Operating system version

10,11

Additional context

No response

Issue checklist

• I searched for previous requests in the issue tracker
• I verified the feature was still missing when using the nightly build
• My request contains all necessary details

[dankeboy36]

Hi there!

GRPC under Windows is not easy to use under Windows

Thank you for sharing your experience with the challenges of using gRPC under Windows. Starting with the gRPC API and the CLI daemon might not be straightforward. However, waiting for a specific generated client code—especially with DLLs—might be a bit unrealistic.

The Arduino CLI already provides the proto files, so you have the freedom to generate the client code that fits your needs. Have you explored using any generator frameworks?

As the Arduino IDE and CLI developers have all required components available under windows it would be helpful to provide with each new release / build support for the users of the CLI under GRPC:

The Arduino IDE uses grpc_tools_node_protoc from grpc-tools to create JS/TS code from those proto files. Given that the Arduino IDE is built with TypeScript/JavaScript, it's a bit of a stretch to expect pre-packaged DLLs for Windows just because the IDE talks to the CLI via the gRPC API.

[mink99]

I would not call this a freedom… why should I even explore any „Generator Frameworks“ if everything is already there with the IDE developers ? The API of the CLI is finalised, no need for everyone to generate the same bindings again and again.
I am sure that it is not only me

• On Windows
• using gcc/c++
• accessing the cli

This is not (per case) specific generated client code, this is code to access exactly one server (the cli) , which is well defined (per version) and will be used exactly the same way by every client. So i understand the dll as server code, being an integral part of the server (aka cli) and not as a specific feature for each client.

Under windows it is common practise for service-providers like the CLI to provide access features to the services for clients.

And to include those features there are (under windows) two preferred ways to communicate within the same machine: static and dynamic linking.
Static linking would be really a challenge for the developers of the CLI, due to the different runtimes of go and (everything else).
Dynamic linking therefore would be the preferred way. A DLL can be used by (almost) every programming language under Windows, whether it is some scripting language, some weird basic dialect, c / c++ ,c#, java or even anomalities like smalltalk, cobol, etc.

This DLL is (or at least should be) provided and maintained by the service provider, in our case the CLI devs, and not by the service consumers.

This is typically done with utility libraries like boost, GUI libraries , Multimedia libraries etc. all their manufacturers provide either precompiled libs for static or dynamic linking or makefiles to create them, either as libs to feed the linker, or as shared libraries.

[cmaglie]

Making a DLL requires exposing a "C" ABI. This is not easy to do in Go.

The other way round is a bit easier (due to the very simple memory model of C), but exposing a C binding from Go requires writing of wrappers to handle garbage collection, and mappers to map Go types to C types (not all Go types are available in C like map and slice for example... even strings needs to be converted back and forth...).

Unfortunately, we don't have the bandwidth to make a DLL to support C/C++ (for the same reason we do not provide an ".class" to support Java or a ".py" library to support python).

[mink99]

So the reasoning for you to decline the request is the same as why this request was created ? You create an api and chose a programming model that is so highly complicated that you do not have the resources make it accessible from Windows ?
You knew from the very beginning „ making a DLL requires exposing a "C" ABI. This is not easy to do in Go.“

[mink99]

See eg https://medium.com/codex/calling-go-code-from-c-922e4d8266c7