Originally posted by crazycheese
View Post
- A garbage-collected virtual machine like the CLR
- The userspace C runtime (libc)
- Floating-point arithmetic, which is required to support any Mono/.NET language
- Dynamically loaded libraries, which exist only in userspace
Basically this will NEVER be in the kernel. Even if a 100% Free As In Freedom project started with the goal of implementing features similar to the CLR but with a unique design and license it under the GPLv2 Only (for license compatibility with the Linux kernel), it wouldn't make it into the kernel for (at least) the reasons stated above.
Your knee-jerk reaction to the programmatic construct "DllImport" is ridiculous. It has nothing to do with Windows or DLLs. To give a similar example, I could write a C function called "GetWindowsAPIHandle()" and provide it in a shared library, and compile it on Linux with GCC. But just because it's called something that sounds like it might have to do with Windows, doesn't mean it actually has anything to do with Windows in practice.
DllImport in CLR-speak has no more to do with Windows than JNI has to do with Windows in Java, or native bindings in Vala, or CPython wrapper libraries in Python, or any other foreign function interface. It is simply a way for one programming environment to interoperate with another. If you want, you can think of "DllImport" as saying "I want to invoke native code". If the native code it invokes is a Linux library, then Windows is completely and utterly out of the picture.
Comment