I've been doing a mid-sized project in C++/CLI and I think it's a really awesome and intuitive way to mix native code with managed code. I view it as basically taking the C# language, renaming all of its features that would collide with C++ names, and
shoving it into C++ in a relatively seamless manner. Clearly the compiler folks have done a lot of work to make it happen so easily.
I think the IDE support for C++/CLI is a little weak in comparison to C#'s support, but that's likely due to the greater complication in the C++ language and the fact that C++/CLI is not the preferred development environment of those who want a lot of tool
Why can't there be a legal solution to the WHQL-cheating issue?
One of the stipulations of submitting a driver for WHQL could be that the manufacturer signs a contract asserting that they are making a good-faith effort to fairly test their driver. If there are serious customer reports of malfunction (it would only matter
for high-volume devices), Microsoft could reserve the right to sue the manufacturers if they passed the tests only due to cheating.
So... is anyone working on a version of this system to be implemented as a driver within the NT kernel? It seems like there's no reason this should be impossible when CoLinux did this with an entire linux kernel.
Can some similar system to Singularity be implemented as a device driver in the existing NT kernel? Perhaps the singularity runtime could run all of its code and "lightweight processes" in kernel mode and all calls out of managed code would be simple
function calls to normal NT device drivers without changing processes or switching VM spaces.
Also, singularity has no shared memory; does it have shared type instances? Or is the best one can do more like proxy objects? Does singularity even have a JITer in the kernel (perhaps for application and upper level code)?