This document describes features of CooS for people which want to know them shortly. Thus this shows new features that aren't in exisiting OSs and doesn't have the topics comparing any other existing OSs and also relating to hardware.
This document is preliminry. So this touches unimplemeted or imcomplete things. I know it maybe wrong to describe such topics but I did because CooS is constructing software and it's more difficult to understand with only facts.
CooSがもつ特徴――またはアピールポイント――には次のようなものがあります。
CooSはOSが.NETランタイムを内包していますので、Windows用として配布されている.NETプログラムが動作します。（.NETプログラムではない"ネイティブ"プログラムは動作しません。）
これは、明らかですが、Windows用にある豊富なアプリケーションがそのまま使えるという利点があります。エンドユーザは、必要なソフトウェアが.NETプログラムとして配布されていれば、CooSのための特別なバーションを探す必要はありません。ふつう、OSが新規に開発される際は、アプリケーションプログラムも同時に開発されなければなりませんが、.NETプログラムを実行可能にすることでCooSはこの問題を解決しています。
CooSのアプリケーションは.NET用としてコンパイルされるのであれば、それがコンパイルされた環境については関知しません。つまり、現状もっとも普及した環境であるWindowsで（CooSでも動く）アプリケーションをコンパイルすることができます。もちろん、そのソフトウェアをCooSのために開発したとしても、それはきっとWindowsでも動くアプリケーションでしょう。
僕は、たとえ自分のOSのためであっても、慣れた環境でないとプログラムを書く気にはなれません。これは些細な問題のように思えますが、僕は大変重要な要因だと考えています。
OSを作ることは誰にでもできます。資料はあちこちに散在していますし、何より僕が作れているのがその証拠だと思います。
しかし、アプリケーションをそろえることは誰にでもできません。どんなに優れた開発者であっても、一人でできることには限界があります。実用に十分なだけのソフトウェアをOS開発者だけで作り上げること不可能なのです。
最近の傾向として、この問題はオープンソース化することで間接的に解決しようとすることが多いようです。オープンソースに携わる人たちに言わせれば「オープンソースにすれば世界中の開発者が参加してくれる」そうなので、それが正しいのであればそのアプローチは間違っていないと思います。実際のところ、なにかとても特別な特徴でもない限り、OSの開発についてこれるだけのプログラマを参加してもらうにはオープンソース化するしかないようにも思えます。
CooSはこれに対して、「あなた（開発者）が今お持ちの環境で、何も変更することなく、いつものように開発ができます」として、開発者を募集する予定です。（現状ではOS自体が不安定なのでアプリケーションは募集していません。） ある意味反則技なのですが、開発にかかる負担が少ないというのはとても良いことだと思います。
CooSはごく一部を除き、ほとんどがC#言語で開発されています。
C#言語を使うことによって、（C++言語などではプログラマが自分で何とかしなければいけなかった）バグの原因となる処理を完全に切り離すことができました。また、C#言語がもともとセキュリティやエラー処理を考慮してデザインされていることにより、それから作られるCooSも、それらについて非常に高い品質を持っています。
CooSはOSのほとんどがC#言語によって記述されています。C#言語は記述しやすいなどの単純な利点もありますが、コンピュータシステムとしてはセキュリティホールを作りにくいという特徴があります。
セキュリティホールはいくつか種類が存在しますが、そのなかで代表的なものに「バッファオーバーフロー」があります。C#（および.NETを基本とする言語）では、言語によってバッファオーバーフローへの耐性が実現されており、原理的にこの種の脆弱性が発生することがなくなります。
また、セキュリティホールには、ソフトウェアのバグから生み出されてしまうものもありますが、.NET環境は従来よりも強いセキュリティチェックを行うため、このようなセキュリティホールにも一定の効果があると考えられます。
これは開発者向けの機能です。
従来のOSではプロセスを保護するために、プロセス境界を越えるデータのやりとりは厳しく制限されていました。また、データをやりとりする場合でもアドレスによって間接参照することは許されず、データそのものを受け渡すという方法しかありませんでした。
CooSでは、他のプロセスにアドレスによってデータを渡すことが可能です。そのため、たとえばあるプロセスがnewしたオブジェクトへの参照を、そのままの他のプロセスへ渡し、他のプロセスがそのオブジェクトを使うといったことができます。これはWindowsにおいてもマーシャリングなどによって擬似的には実現されていますが、マーシャリングは間接的にOSが介入する仕組みであるために効率が犠牲になってしまいます。CooSではオブジェクトをそのまま渡しますので、高効率でのアクセスが可能です。
これはプロセス間の協調動作に有効です。既存のOSではプロセス間の協調はあまり行われていませんが、CooSではスレッド間通信と同じような感覚でプロセス間通信をプログラムすることが可能です。
一方、このようなオブジェクトの直接的な共有は、プロセス同士の結合を密にし、大規模なクラッシュの確率を高めます。しかし、これは共有されるオブジェクトを慎重に設計することで対処可能だと僕は考えています。どうせ、プロセス間で共有されるべきクラスの数は多くても一桁でしょう。プログラムにあるすべてのオブジェクトがプロセス間で共有されるわけではないのです。それらについて厳密な管理をすることは、不可能ではないはずです。