The day this happens in kernel, Linux is officially sabotaged. I promise I be nice, I promise I be good, I promise I be fair. ProMiS, proMiS, proMiS. And a story of anti-linux and anti-opensource emails.
There are three kinds of people in this thread:
1) Microsoft junkies
2) FOSS fighters
3) Senseless mercenaries.
Good thing the Linux kernel would never be allowed to run any of the following:
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.
Last edited by allquixotic; 05-17-2012 at 10:42 PM.