6

DOS が Windows に変わったのと同じ方法ですか?

Microsoft から 3 つのプラットフォームのサポートと開発を行うことになったようですが、境界線がどこにあるのかわかりません。

CLR の利点 (タイプ セーフ、メモリ保護など) を Windows 自体に組み込むことができないのはなぜですか?

それともブラウザに？なぜまったく別の仮想マシンなのですか? (現在、仮想マシンの間接化のレベルはどのくらいですか? Silverlight を追加したばかりです。その前に、Flash を追加しました。おそらく、VM インストール内で実行されているブラウザ内で実行されています...)

サーバー用の未加工の Windows を確認できますが、ハードウェアと直接通信するワークステーション用の CLR が存在しないのはなぜですか (または、少なくとも Windows のレガシー ボール アンド チェーン全体ではありません)。

(ooppp - ここで 2 つの質問があります。これを作成しましょう - なぜ .net を Windows に組み込むことができないのですか? 下位互換性については理解しています - しかし、.NET にあるものの安全性は、少なくともオプションで Windows 自体にある可能性があります。それは多くの API セットの 1 つにすぎませんか?)

Factoid - IBM PC 上の MS-DOS に対抗して販売している競合他社のアーキテクチャの 1 つが、UCSD-pascal ランタイム (VM) だったことを思い出します。

4

10 に答える 10

12

そして、DOSがWindowsに変身しなかったことを忘れないでください。少なくとも、今日私たちが知っていて愛しているWindowsはそうではありません。DOSはオペレーティングシステムであり、Windows3.1はそのオペレーティングシステムの上にあるGUIシェルでした。

Windows 95が登場したとき、「Microsoft DOS」というラベルの付いた箱入りの製品はもうなかったのは事実ですが、Windows 95は、アーキテクチャ上、GUIシェルが上にあるDOS7.0でした。

これは、Win98およびWinME（別名Win9X）まで続きました。

今日私たちが知っているWindows（XP、Vista、2003、2008）は、完全に別の獣であるWindowsNTプロジェクトのコアを持っています。（NTは3.1以降の9xバイナリと互換性があるように設計されており、ほぼ同一ですが拡張されたAPIを使用していました。）

DOSは、KDEにモーフィングされた元のLinuxコアよりも、私たちが精通しているWindowsにモーフィングされていません。

2つのAPIは、Windowsに対してネイティブに構築された製品がまだサポートサイクルにある限り、共存し続ける必要があります。WindowsAPIがWindowsServer2008とWindows7にまだ存在していることを考えると、少なくとも2017年を意味します。実際には、マネージコードは素晴らしいものですが、常に最も適切で最良の答えであるとは限らないため、おそらくもっと長くなります。

プラス...プログラマーとして、あなたは誰よりもよく知っているべきです：それが外から見えるかもしれないほど何かをすることは決して簡単ではありません！

于 2008-12-06T05:10:07.647 に答える
9

Windowsは数百万行のコードであり、そのほとんどはCです。これは、数十年にわたる莫大な投資を表しています。今日のユーザーのために常に維持（修正）されています。彼らがC＃のすべての行を10年間書き直し、その後、ビジネスを完全に破壊することなく、さらに10年間デバッグおよび最適化する間、世界を止めることは完全に不可能です。

既存のコードの一部は、理論的にはCLRで実行するようにコンパイルできますが、そうしてもメリットはありません。Cの大きなサブセットをCLRにコンパイルすることは（C ++ / CLIコンパイラを使用して）可能ですが、たとえば、ガベージコレクションを自動的に有効にすることはありません。それを実現するには、ゼロから再設計する必要があります。

于 2008-12-06T09:31:08.273 に答える
8

まず、CLR はオペレーティング システムではありません。それが、そうしない大きな理由です... つまり、研究用 OS である Singularity でさえ、単なる CLR ではありません。Windows カーネルと一般的なオペレーティング システムに関する本を何冊か読むべきだと思います。

于 2008-12-06T05:09:39.473 に答える
6

マイクロソフトはまだそれからいくつかのWindowsリリースです。
しかし、彼らは私が思うに特異性のようなものから始めるでしょう。

于 2008-12-06T05:17:53.793 に答える
3

私が目にする最大の問題は、CLRがVMで実行され、VMが抽象化レイヤーとして役立つことです。一部の.NETアプリはLinuxで実行できます（Monoプロジェクトを参照してください。現在、.NET 2との互換性があると思います）。そのため、すべてがなくなります。C / C ++またはハードウェアと直接通信する言語では、OSおよびハードウェアアーキテクチャごとにコードを異なるバイナリに再コンパイルする必要があります。そこにVMがあることのポイントは、それを抽象化することです。これにより、コードを記述してビルドし、どこでもまったく同じバイナリを使用できるようになります。Javaの観点から見ると、VMを「writeoncerunwhere」モデルとして使用するというはるかに優れた仕事をしています。同じJavaクラスは、再構築せずにWindows、Mac、およびLinuxで実行されます（とにかくプログラマーによって、技術的にはVMがその作業を行っています）。

ここでの一番のポイントは、.NET / CLRはWindows固有ではなく、IMO Microsoftは、OS間の互換性にもう少し努力した場合にのみ、.NET言語スイートを支援するということだと思います。

于 2008-12-06T15:22:02.230 に答える
3

後方互換性が壊れるから？また、主流のチップ アーキテクチャは VM アーキテクチャと一致しませんか? 彼らは少し前に Java VM 用のハードウェアを作成しましたが、誰も気にしませんでした。

于 2008-12-06T04:44:15.450 に答える
2

Microsoft は巨大なレガシーを持っているため、単純にドロップすることはできません。企業は、無視できない Windows および Win32 ソフトウェアに多額の投資を行ってきました。

于 2008-12-06T04:45:22.563 に答える
1

CLRまたは一部のVMを使用して（VMが使用されている）、その上でOSを実行している可能性があります。しかし、問題は、VMを構築するために何を使用すべきかということです。おそらくC/C ++または他の同様の言語であり、（ほとんどの場合）場合によってはアセンブリを使用して処理を高速化します。

つまり、VMには、Windows（または任意のOS）が現在直面している問題がまだ残っているということです。他の人が指摘しているように、OSと関連アプリケーションの一部は、VMを介して移植される（またはモーフィングされた）場合がありますが、OS全体をVMの上に置くことはあまり役に立ちません。その理由は、VMが実際のOSになり、モーフィングされたOSのガベージコレクションやその他の保護手段を実装するためです。

それらは私の2セントです。:)

于 2008-12-06T09:59:13.287 に答える
0

CLR 自体はどの言語を使用しますか? どの API を呼び出すか? ファイルを開いたり、メモリを割り当てたり、プロセスを作成したりする必要があるとしたら、CLR がそれを行うと思いますか? CLR は、ネイティブ コードの上に構築されます。マネージド OS ではオーバーヘッドが発生します。

CLR はアプリ開発用であり、アプリの作成を容易にし、バグの少ないソフトウェアの作成を容易にするために存在します。ガベージ コレクターを使用するため、パフォーマンスが低下する可能性があります。それらも素晴らしい場合がありますが、通常、ガベージ コレクションが原因で、開発中に何らかのパフォーマンスの問題が発生します。

下位互換性を持たせる必要があるため、ある種のネイティブ API を持たせる必要があります。

純粋な 100% マネージド OS を作成し、下位互換性を忘れるか、後で大きな互換性を持たせようと言っている場合、実際にはすべてにガベージ コレクターを強制しようと言っているだけですよね? ガベージ コレクターと、CLI に準拠することで得られる移植性の保証の他に、何を得られるのでしょうか? アルゴリズムとすべては、実行時にはまだネイティブ コードにコンパイルされているため、唯一の大きな違いはメモリ管理です。

于 2012-10-20T04:59:01.500 に答える