OSNews

I think you are right and I am wrong about SIPs. I have done a little reading and it seems that singularity has inspired a few design decision in other managed OS's. It also seems that manifest based programming is being implemented in differing forms in other managed OS's.

http://lab.obsethryl.eu/content/sharpos-stream-c-sharp-c-kernels was in interesting read for me.

From the interview

Bruce Markham: There has been a bit of debate as to how we should approach this. There is no doubt that we want the performance and security gains of SIPs, (with the exception, from the original Singularity implementation, of still having code sharing.) But we also expressed a desire to be able to virtualize other OS's application binary interfaces (ABIs) down the road, so that basically we will be able to run, say, a Windows program, without recompiling the way WINE and ReactOS already allow. This would require hardware isolation, and reduce performance for any processes involved.

William Lahti: The SIP functionality that Singularity integrates is really one of the exciting parts of a managed operating system. Although we do not have code for processes yet (as we are still flushing out the AOT compiler, runtime, and corlib), we intend to use SIP (software isolated processes) as the first-class citizen process in SharpOS.

With that said, we realize pragmatically that hardware isolation will be required for unsafe/unmanaged code, and we want to account for that. Our SIPs will run in the same address space/ring as the kernel, allowing us to reduce context switching time considerably, as well as the overhead of communication between the kernel core, drivers, and the individual processes. For those who are unfamiliar with SIPs, the idea is that verification of IL code replaces the need for barriers between separate software entities.