- PR -

.NETをWindows以外のプラットフォームで使えますか?

投稿者投稿内容
sumin
ベテラン
会議室デビュー日: 2003/07/17
投稿数: 93
投稿日時: 2003-07-27 15:42
今までJAVAだけをやってきた物です。

@ITの.NETの紹介の記事を読んだ位の知識しかないですがふと.NETフレームワークの図面を見た時、CLRって下のOSがWindowsに限らなくても良さそうな気がしましたがどうでしょうか?実際にWindows以外のOSでも使用が可能でしょうか?もしその例があれば知りたいですが。。
未記入
大ベテラン
会議室デビュー日: 2003/06/28
投稿数: 219
投稿日時: 2003-07-27 17:09
Ken-Labです。こんにちは。
この内容は、この会議室のスレッド - 特集「私がJavaからC#に乗り換えた10の理由」に
ありますが、大変長いスレッドですので簡単に纏めておきます。
(もちろんこれは.NETの中のC#に限定される部分はあります。)
Windowsプラットフォーム以外での実装は次のものが紹介されています。

dotGNU
Mono Project
Microsoft shared source CLI

ちなみに、自分はMacOS X(FreeBSD)上でMicrosoft shared source CLI実装を実施してみました。
コンソールプログラムにおいては、日本語の扱いも含め動作することを確認しましたが、
Window型アプリケーションについてはコンパイルも実行もできませんでした。
これからMono Projectあたりも評価したいのですが、ビルドだけで2時間もかかってしまった
ことから、どうしようか考え中です。もし、お試しいただくことができましたら、
ご報告いただけると有難いと考えていますが、如何でしょうか?

[ メッセージ編集済み 編集者: Ken-Lab 編集日時 2003-07-27 17:13 ]
MUSE
常連さん
会議室デビュー日: 2003/04/06
投稿数: 42
投稿日時: 2003-07-27 17:43
こんにちは。
回答でなくてsuminさんには申し訳ありませんが、私の疑問とも少し重なることがあるので、追加のテーマとして、このスレッドに投げさせて頂きます。別スレッドを立てた方がよいとお考えの方がいらっしゃる場合、会議室の有効利用性も考慮して、別スレッドへ移動させて頂きます。

まず、.NET Frameworkは、「CLIという仕様に対してMicrosoftが実装したもの+α」だと認識しているのですが、この認識は正しいでしょうか?
αというのは、MicrosoftのオペレーティングシステムであるWindowsファミリ固有の機能を使用するクラスライブラリのこととして考えています。

この質問の意図は、例えCLIという限定された機能範囲内であっても、自分で作ったManaged Codeが、Windows以外のオペレーティングシステム(例えばLinuxなど)で動けば、これはこれで大変、興味深いものになるだろうなと考えたからです。

次の質問ですが、もし、前述の質問がYesであるなら、.NET Frameworkの中で、どのネームスペース、或いは、どのクラスがCLIの範囲内なのか調べることが可能なのかということです。もし、調べることができるのなら、その範囲内のクラスを使用すれば、他のオペレーティングシステム上でもバイナリ互換として、動作させることのできるプログラムを作成できるのかなと考えています。
未記入
大ベテラン
会議室デビュー日: 2003/06/28
投稿数: 219
投稿日時: 2003-07-28 08:12
CLIについては、Microsoft shared source CLIのリンク先にあるECMA-334および
ECMA-335に仕様があります。
また、業務で使うことを前提とする場合は、まずライセンス条項を確認する必要があります。
それから、ADO.NET以外でのDBConnection、およびHTTPリクエスト・レスポンス処理を
どう扱うのか、を考えますとそれなりにフロンティアスピリットが必要かと。
このあたりは識者の方のご意見をお聞きしたいところであります。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2003-07-28 10:58
引用:

LEDさんの書き込み (2003-07-27 17:43) より:
まず、.NET Frameworkは、「CLIという仕様に対してMicrosoftが実装したもの+α」だと認識しているのですが、この認識は正しいでしょうか?
αというのは、MicrosoftのオペレーティングシステムであるWindowsファミリ固有の機能を使用するクラスライブラリのこととして考えています。

この質問の意図は、例えCLIという限定された機能範囲内であっても、自分で作ったManaged Codeが、Windows以外のオペレーティングシステム(例えばLinuxなど)で動けば、これはこれで大変、興味深いものになるだろうなと考えたからです。


 Microsoftや、System.Windowsなど、明らかな名前付けがされているように思います。それ以外は動くはずです(仕様上)。また、System.Windowsについても、近日中に動くようになると思われます。というのも、Borland社が「Linux版のC# Builderを出す」というような発表をしているからです。ただし、Linux版のコモンランタイムを「誰が、いつ」作るかについては、お茶を濁していますが。
MUSE
常連さん
会議室デビュー日: 2003/04/06
投稿数: 42
投稿日時: 2003-07-28 22:34
引用:

Jittaさんの書き込み (2003-07-28 10:58) より:

 Microsoftや、System.Windowsなど、明らかな名前付けがされているように思います。それ以外は動くはずです(仕様上)。また、System.Windowsについても、近日中に動くようになると思われます。というのも、Borland社が「Linux版のC# Builderを出す」というような発表をしているからです。ただし、Linux版のコモンランタイムを「誰が、いつ」作るかについては、お茶を濁していますが。


なるほど。でも、あれですね。LinuxでSystem.Windowsをサポートするというのもなんでね。GUIの文化はOSごとにあるわけですから、かなり違和感があるような気がします。もちろん、Linux版の.NET環境が登場するのは大歓迎ですけど。
GUIに関して、クラスライブラリがどうあった方がすっきりするのか私にもよく分かりません。例えば、Unix、Linux、FreeBSDなどのUNIX系のFrameworkの場合、System.XWindowとか、そういうのがあった方がいいんですかね? まあ、メーカー固有であれば、Borland.XWindowとかになるんでしょうけど。どう思います?
未記入
大ベテラン
会議室デビュー日: 2003/06/28
投稿数: 219
投稿日時: 2003-07-28 23:01
引用:

LEDさんの書き込み (2003-07-28 22:34) より:
例えば、Unix、Linux、FreeBSDなどのUNIX系のFrameworkの場合、System.XWindowとか、そういうのがあった方がいいんですかね? まあ、メーカー固有であれば、Borland.XWindowとかになるんでしょうけど。どう思います?


うーん、自分の考えとしては例外は無いほうがいいと考えます。
プラットフォーム毎にソースコードレベルで違いがあれば移植作業が伴う。
また、違いが引き金となっておかしな方向へ行って欲しくない。
(立場は逆ですがMicrosoft VMのような事態を恐れます。)
もし、例外を許すようなら.NET FrameworkはWindowsだけでいいのでは、と考えます。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2003-07-29 09:41
引用:

LEDさんの書き込み (2003-07-28 22:34) より:

例えば、Unix、Linux、FreeBSDなどのUNIX系のFrameworkの場合、System.XWindowとか、そういうのがあった方がいいんですかね? まあ、メーカー固有であれば、Borland.XWindowとかになるんでしょうけど。どう思います?


 どこかのニュース記事ですが(古くて探し出せませんでした)、BorlandのKylix(というより、CLX)が使用しているプロジェクトを利用するだろう、ということです。元のプロジェクトの.NET対応の進捗が芳しくなく、そのためにお茶を濁す言い方をしているのではないか、ということでした。
 まぁ、XWindowシステムがオープンな仕様(でしたよね?)なので、System.XWindowとか、ルートでXWindowとかになるのではないでしょうか。それも『元のプロジェクト次第』でしょう。

###
ODP.NETと.NET Framework Data Provider for Oracleのようなことにはならないようにして欲しい。。。

スキルアップ/キャリアアップ(JOB@IT)