Quote:
Well what happens if I write an application which claims to have been built with C#, but wasn't? Can they accurately detect and prevent this? If not, can they detect "dangerous constructs" at runtime? If not do I not now have instant full access to all of memory and therefore the system?
You do not have to use c#. The application must be compiled by some compiler to IL. The app therefore could be written in every language an CLR-Compiler is available for.
At install-time the applications IL-code is verified and compiled to native code by the operating system. So it seems to be a lot harder to "pretend to be trustfully".
I'm not really sure how strong the validation of intermediate code can be performed, but it seems there are a lot of possibilites to validate the code before compiling it natively.
The concept of sealed processes pushes this a bit further, so no process can ever directly access memory of another process. This is allows an amazingly stable system if implemented well. The worst case would be that an malicious program would crash it's own process, but never harms any other running application, driver or service.
The entire interprocess communication in singularity is working with channels (as far as I understand this, it's similar to a win32 pipe) with some restrictions which data is allowed to be passed and which not.
And as you mentioned the hardware protection mechanics aren't needed in such an environment, which safes a lot of execution time that can be used by the CLR for task like scheduling, garbage collecting, ...
I really like this whole approach, because it seems to be a huge gain in stability of the entire system.
Quote:
In my opinion C# is a nasty language and Microsoft is a nasty company..
I think that OS development is much more efficiently done in C/C++ or Assembly.
Whether MS is nasty or not is not really the point, I think ...
I'm not sure if efficiency should be reduced to performance. Of course well written C/C++ code and optimized assembly will beet any CLR code in case of performance. The main problem is to get the code of the entire OS and especially the 3rd party software to this level.
In the last years I saw much more mediocre C/C++ code, than highly optimized. And the maintance of optimized code is almost worse than cancer. On the other side, it's much more "cost-efficient" and "time-efficient" to write high-quality C# code, which will in 80% perform better then mediocre C/C++ code. This is the advantage of a higher level language.
Oh **** ... this looks like "War and Peace" ... sorry guys, I stop here
![Smile :)](./images/smilies/icon_smile.gif)