(This is an issue extracted from JDK-8295146: Clean up native code with newer C/C++ language features. See https://github.com/openjdk/jdk/pull/11081. It's an enhancement rather than a bug because it isn't currently causing any known issues.)

Class os::win32 declares `thread_native_entry` to be a friend function. In os_windows.cpp it is defined as a static (file-scoped) function. Those declarations are inconsistent. "A function first declared in a friend declaration has external linkage." (C++14 11.3/4). It seems Visual Studio versions through 2019 don't diagnose the inconsistencey, though that may change in the future, especially if we enable more strict compilation modes (such as `-permissive-`).

For other platforms, the corresponding function is file-scoped, and there is no corresponding friend declaration.

There are several ways we could address this.

(1) We could declare the function to be file scoped in the header, though that's weird. The declaration would be present in every translation unit, but only be defined in os_windows.cpp. And it nominally pollutes the global namespace of every including file (though name clashes seem unlikely).

(2) We could leave it with external linkage and fix the definition to be non-static. Again, this nominally pollutes the global namespace.

(3) We could remove the friend declaration, addressing the reasons for it.

The reason for the friendship is to provide the definition with access to the private enum os::win32::Ept and os::win32::exit_process_or_thread. Those could be made public. Alternatively, the function could be changed to be a private static member of os::win32.

There is also a mismatch between the signature and the type where it is used that is currently dealt with via a cast. That should also be fixed.