Plugs PInvoke Clarification [Question]

[AaronLS]

I have a two part question. First determining if my understanding of the purpose of Plugs in the context of PInvoke is accurate, and then determining if a PInvoke into a native library(not something that is part of the OS) is possible. Please do not take any of this as an attack on plugs or criticism of Cosmos OS or its documentation.

The articles I've seen on plugs say they are used in scenarios where PInvoke is needed. Generally a PInvoke is the solution to call into a native library. But I have not seen an example of actually performing a PInvoke, and instead plugs implement code as an alternative to the PInvoke. I think what is really meant is that a "A plug creates an implementation in lieu of a PInvoke. Generally a PInvoke is used to access functions Windows operating system functions which simply do not exist in Cosmos OS, and therefore a PInvoke is not viable, so an alternative implementation must be provided via a plug." I.e. in other words Plugs do are not used to perform a PInvoke, but instead provide an implementation for a .NET core library function which previously relied on PInvoke to a Windows OS function, for which we must now provide a non-PInvoke alternative.

Is that accurate? Or am I misunderstanding something?

In traditional C#, if I had a native library which was not operating system dependent. I.e. perhaps a native C++ library that implements Reed-Solomon error correction codes and does not call operating system specific functions, then usually I can create an interface for that native library and call into it from C# via PInvoke. Is it possible to PInvoke into a native library in Cosmos OS?

I'm fuzzy on the details of native libraries, so forgive me for ignorance. I've done it a few times but don't understand the low level details enough to know if my question is non-sense. It's always great when you find a native library for something very complex like Reed Solomon that has no good C# implementation(I've found one that is buggy) and can just leverage the existing native implementation. Not so much for the performance benefits, but just for the sake of not having to re-write it. I know while you can write cross platform compatible C++ code that contains no OS specific calls, you usually still must natively compile it for/on the target OS and the target instruction set x86/x64. So I suspect this is a no go without a C++ compiler for Cosmos OS, but I don't really see what would be different at the assembly level if there are no OS specific calls. I say that with the awareness of my own ignorance though!

To summarize: I am trying to determine if it's possible to perform a PInvoke into a pre-existing native library.

[czhower]

On 9/26/2015 5:08 PM, AaronLS wrote:

words Plugs do are not used to perform a PInvoke, but instead provide an implementation for a .NET core library function which previously relied on PInvoke to a Windows OS function, for which we must now provide a non-PInvoke alternative.

Is that accurate? Or am I misunderstanding something?

Correct. They are usually used to replace pinvokes, but can be used in other cases too. Ie to replace a minor dependency on a little used library, inject ASM to allow compiler functionality, etc.

native library and call into it from C# via PInvoke. Is it possible to PInvoke into a native library in Cosmos OS?

No, because with Cosmos you don't know what native will be. x86, ARM, etc... so if we allowed pinvoke, it would defeat on of the major goals of Cosmos. Even if we allowed it as an exception, it would still be a problem because as people use it, it would cause architecture lock in essence.

Also any native lib would itself tie to Win APIs etc and then we'd have the same pinvoke problem - there is no WinAPI here.

To summarize: I am trying to determine if it's possible to perform a PInvoke into a pre-existing native library.

It is not possible, nor is it desirable in the context of Cosmos.

[AaronLS]

@charlesbetros Thanks for answering this, and it does clarify a couple things for me, but I think you misunderstood the intention of my second question about pinvoke to a library. I have pondered for awhile before I responded. Don't take any of my questions/comments as a challenge to your response, but clarification and an attempt to better understand.

"Also any native lib would itself tie to Win APIs etc and then we'd have the same pinvoke problem - there is no WinAPI here."

I did initially mention Pinvoke into WinAPI in the context of trying to understand the purpose of a plug, so I would be sure I was clear about what its purpose was. It clarified for me that a plug is for replacing OS specific pinvokes, which is different than a pinvoke to a native library. When talking about native libraries, I'm thinking more about general libraries designed to expose a consistent API regardless of what OS/architecture you are on. They may not even internally interact with OS calls, such as a library that performs Reed-Solomon decoding that might just take and return some arrays that it performs math on. Such a library can be written to be OS agnostic, and can provide binary distributions for major OS/architecture combinations(since it still must be compiled for each OS/architecture despite the C++ being the same). The common way to perform a native call from C# into such a library is through a pinvoke. The code written to perform the pinvoke is not specific to the OS, but can be written and compiled on both Windows and Linux (although the resulting compilation requires a Windows or Linux specific C# compiler). Certainly the resulting compiled assembly in this case is tied to the OS/architecture on which it was compiled, so you get into managing multiple distributions. But the C# code to interact with the library is consistent, so it's more a matter of managing the build/distribution.

I agree it would be cumbersome to integrate these native libraries into the OS, and against your goal.

However, for individual developers wishing to author an application on Cosmos OS, I'm wondering if I'm willing to make the tradeoff/sacrafice of managing multiple architecture specific distributions, is it still possible to perform a pinvoke into a native library? Not a pinvoke into OS system functions.

I was thinking more in terms of applications written to run on Cosmos, than the Cosmos code base itself. There will be cases where re-implementing a native library will be a very large amount of work, and more than a single developer can do in their free time, and an application author may be willing to instead leverage a native library that provides distributions for all the major architectures.