Eliminate Windows PAL layer for non-Windows CoreCLR builds

[sdmaclea]

Fix/investigate usage of Windows file in non-windows CoreCLR builds.

https://github.com/dotnet/runtime/blob/ce925072739702ebf8f6a4c6131ca3b73b81a44f/src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems#L1449-L1501

This usage is suspicious. It is also non-conventional.

Recommend:

• Remove files from set which are not needed for non-windows builds.
• Rename file paths if possible to remove confusion.

/cc @marek-safar @jkotas @danmosemsft @stephentoub @Anipik

See comments https://github.com/dotnet/runtime/pull/28819#discussion_r374680113

[jkotas]

CoreCLR uses PAL layer that emulates Windows API on Unix. This is bridge for that PAL layer.

It would be nice to get rid of the CoreCLR Windows API emulating PAL layer and replace it something leaner (ideally written in C# as much as possible - we have some prior art for this in CoreRT).

We can use this issue to track elimination of the Windows PAL layer.

[danmoseley]

It would be nice to get rid of the CoreCLR Windows API emulating PAL layer and replace it something leaner (ideally written in C# as much as possible - we have some prior art for this in CoreRT).

Including the dependence the runtime itself has on it? Isn't that huge - CreateFile, etc - all those things would call into managed code which does pinvokes (possibly itself using the libraries PAL)? Or would this be just for managed dependencies on the CoreCLR PAL?

Just trying to figure out what it would look like.

[jkotas]

We would not want to call back and forth between managed and unmanaged code.

For file I/O, the runtime itself does not have that many places that read/write files. I think we would end up with combination of the following strategies:

• Rewrite the caller in managed code and switch it to use managed file I/O.
• Use standard C file I/O APIs instead of OS specific ones.
• Use a custom PAL that provides just the right abstraction. It is the strategy that we are using in the dotnet host: https://github.com/dotnet/runtime/blob/master/src/installer/corehost/cli/hostmisc/pal.h .

For WinNT synchronization that started this issue, the runtime itself uses only a small subset of it . We can have this subset implemented by a custom PAL in C/C++ that would be order of magnitude smaller that the current PAL. The full set of WinNT synchronization primitives that are exposed as managed APIs can be implemented in C#. We have done that in CoreRT and I see there is plan to pick up that implementation for Mono too: https://github.com/dotnet/runtime/issues/44795 .

[danmoseley]

I was just confused by this, on CoreCLR on Unix, Mutex is implemented in Mutex.Windows.cs and does not use Mutex.Unix.cs.