PowerShell / PowerShell-Native

MIT License
50 stars 33 forks source link

We could get rid of libpsl-native.so #67

Closed iSazonov closed 3 years ago

iSazonov commented 3 years ago

Inspired by https://github.com/dotnet/runtime/issues/24271#issuecomment-786936072 There is a link to a prototype using libSystem.Native.so: https://github.com/ericstj/sample-code/blob/e0efc3458f0a68bdf2f69be7a2e154386939ff81/symLinkConfig/Interop/Unix/Interop.Libraries.cs#L9 and using in a code: https://github.com/ericstj/sample-code/blob/e0efc3458f0a68bdf2f69be7a2e154386939ff81/symLinkConfig/Interop/Unix/Interop.ReadLink.cs#L23-L24


PowerShell libpsl-native.so is stable and libSystem.Native.so has most of libpsl-native.so API.

I suppose the MSFT PowerShell team could have an internal partner contract with the .Net team, move additional API from libpsl-native.so to libSystem.Native.so and remove libpsl-native.so at all.

I would expect this to reduce PowerShell support costs. For example, we will automatically get support for all systems that are supported by .Net.

(Even if the .Net team creates a more modern replacement for this libSystem.Native.so, then PowerShell will be able to use that as well.)

andyleejordan commented 3 years ago

Hey, that's a good idea. Definitely warrants some investigation. Thanks @iSazonov!

iSazonov commented 3 years ago

I saw a long history in .Net repository about using Mono achievements to pinvokes, some preparation PRs for this and a design document. But I see nothing about the work in current .Net 6.0 milestone https://themesof.net/ If they have plans to continue this work in the next cycle, then most likely they will not want to give access to this libSystem.Native.so library, but they can offer something better and modern.

Make sense to open new issue to discuss this in .Net repo or you @andschwa will do this internally?

Themes of .NET
Tracking Themes, Epics, User stories and Issues for the next phase of .NET runtime development