アカウント名:
パスワード:
> Metro Style Appsについてはx86版Windows 8とバイナリ互換であるのだが、バイナリ互換なんだっけ? ソースコードの再コンパイルが必要だと思ってたんだけど。むしろ.NET FrameworkみたいなVM上で動くわけでもないのにどうやったらバイナリ互換にできるの?
むしろ.NET FrameworkみたいなVM上で動くわけでもないのにどうやったらバイナリ互換にできるの?
その通りです。ですから.NET Framework使ってます。今出回っているWindowsPhone向けのMetroアプリは一部例外を除き [nanapho.jp]全て.NET上のVM上で動いてます。
>その通りです。ですから.NET Framework使ってます。>今出回っているWindowsPhone向けのMetroアプリは一部例外を除き [nanapho.jp]全て.NET上のVM上で動いてます。
それはまったく話が違う。つーかあなたの話はいつも筋違いばかり。
たとえばAndroidはDalvik VMを実装しJavaっぽいもの(と一応書いておく。ベースのHarmonyがOracle/Sunの認証通ってないから)で記述したアプリ開発ができるけど、それはWindows上などで動作するOracle/SunのJavaランタイムと互換性を取るためにやっていること”ではない”。
スマホ向けにおいてOS開発側やアプリ開発側の負担を下げるのにおいて既存有力言語からのノウハウ流用が効くもの、ガベージコレクションが使えるものがよかった、が目的で結果としてたとえばAndroidアプリがWindows上のJavaランタイム上で直接動くわけでもないし、WP7アプリがWindows上のSilverlightランタイム上で動くわけでもない。むしろ動かなくしてでもスマホ上で性能稼げる実装を選んでいる。
とりあえず、IDで書くのを抑えて3年ACで勉強したほうがいいと思うよ。
参考になるかわかりませんが...
http://japanese.engadget.com/2012/02/02/windows-phone-8-windows-8-nfc/ [engadget.com]
http://www.atmarkit.co.jp/fdotnet/chushin/xamlfamily_01/xamlfamily_01_... [atmarkit.co.jp]
http://www.atmarkit.co.jp/fdotnet/chushin/xamlfamily_02/xamlfamily_02_... [atmarkit.co.jp]
まあ、カーネルがどうかはいいんですがMetro Style App = WinRT(on CLR)であり、現WP7でも利用されてる部分がある、というカンジじゃないかと。
なので、コメ元は多少はしょってますが、言いたいのは下が.NET(CLR)になっており、Win8/WP8で共通となる(カンジ)ということじゃないかなー。# もちろんネイティブ呼びだししたらどうしようもない
という気がします...どっか抜けてなければ。
>なので、コメ元は多少はしょってますが、言いたいのは>下が.NET(CLR)になっており、Win8/WP8で共通となる(カンジ)ということじゃないかなー。
問題は、はしょるどうこうでなくまずスタート地点の「バイナリ互換性のためにWP7はsilverlight上でのアプリ開発とされたのだから(注:完全に間違い)」からです。スタートが間違いなのでその先の過程はぶっちゃけ全部無意味です。
ちなみに、Win8/WP8でも(あなたの表現で言う).NET(CLR)上でのバイナリ互換性は確保されません。
申し訳ありません。
WP7アプリがWindows上のSilverlightランタイム上で動くわけでもない。むしろ動かなくしてでもスマホ上で性能稼げる実装を選んでいる。
適当に書いたのが不味かったですね。言いたかったのはCLR上で動かせられるのでARMでもx86/64でもバイナリ(正確にはMSIL?)の互換性は持たせられるという話でした。Androidで言うならNDKを使って書けばネイティブコードを含むので当然依存が生まれますけど、DEXバイトコードだけならCPUの命令セット依存は無いですよね?
其れと一緒でC/C++を使ってネイティブコードなMetroApp作れば当然無理になるのは当たり前ですが、MSILだけで済むように組めばCPU依存は起きない。極端例ならHTML5+JavaScriptなMetroAppとか。
ACだと他の方が私のような品質の低いコメントを自動フィルタ出来なくなるので当分IDかと。少なくともこのストーリーのこのツリー内では。
>言いたかったのはCLR上で動かせられるので>ARMでもx86/64でもバイナリ(正確にはMSIL?)の互換性は持たせられるという話でした。
あのー、話を理解できてます?そんなこと言い出したらx86エミュレータをARM上に実装すれば互換性は持たせられるんだ、に行き着くんですよ?でもそのルートはわざわざ選択”しない”ことを選び、互換性を捨てているわけです。さらに今回の場合ではSilverlight基盤としてある程度共通性を持たせていてもそれでも捨てている。それが現実であってあなたの論調はスタート時点で強烈に否定されています。
そこで反論があるならあなたがARM採用スマホやタブレットの上で「Win8と互換性を維持した上で現実的な実行性能と電力効率を実現した」実装を書いてみてください。教科書ばっか読んでないで現場で苦労してから出直して来いということです。
すでに旬を過ぎている上にACさんなので見てないし通知も無いので気づかれないかもしれませんが・・・
Windows8の場合、C#やらVB.NETなWinRTアプリを実行するためのCLR(MSIL)実行環境がありますよね。それとも、今現在のARM版Windows8はx64上のWindows8で開発したC#やらVB.NETやHTML5+JavaScriptで開発したWinRTアプリが動かないという事でしょうか?
実行性能と電力効率のためにネイティブで開発して動かないといわれても、それは自ら選択した事ですよね。もちろん、自らじゃなく、プロジェクトの意思かもしれませんが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
バイナリ互換 (スコア:0)
> Metro Style Appsについてはx86版Windows 8とバイナリ互換であるのだが、
バイナリ互換なんだっけ? ソースコードの再コンパイルが必要だと思ってたんだけど。
むしろ.NET FrameworkみたいなVM上で動くわけでもないのにどうやったらバイナリ互換にできるの?
Re: (スコア:2)
その通りです。ですから.NET Framework使ってます。
今出回っているWindowsPhone向けのMetroアプリは一部例外を除き [nanapho.jp]全て.NET上のVM上で動いてます。
Re:バイナリ互換 (スコア:0)
>その通りです。ですから.NET Framework使ってます。
>今出回っているWindowsPhone向けのMetroアプリは一部例外を除き [nanapho.jp]全て.NET上のVM上で動いてます。
それはまったく話が違う。つーかあなたの話はいつも筋違いばかり。
たとえばAndroidはDalvik VMを実装しJavaっぽいもの
(と一応書いておく。ベースのHarmonyがOracle/Sunの認証通ってないから)で記述したアプリ開発ができるけど、
それはWindows上などで動作するOracle/SunのJavaランタイムと
互換性を取るためにやっていること”ではない”。
スマホ向けにおいてOS開発側やアプリ開発側の負担を下げるのにおいて
既存有力言語からのノウハウ流用が効くもの、ガベージコレクションが使えるものがよかった、が目的で
結果としてたとえばAndroidアプリがWindows上のJavaランタイム上で直接動くわけでもないし、
WP7アプリがWindows上のSilverlightランタイム上で動くわけでもない。
むしろ動かなくしてでもスマホ上で性能稼げる実装を選んでいる。
とりあえず、IDで書くのを抑えて3年ACで勉強したほうがいいと思うよ。
Re:バイナリ互換 (スコア:1)
参考になるかわかりませんが...
http://japanese.engadget.com/2012/02/02/windows-phone-8-windows-8-nfc/ [engadget.com]
http://www.atmarkit.co.jp/fdotnet/chushin/xamlfamily_01/xamlfamily_01_... [atmarkit.co.jp]
http://www.atmarkit.co.jp/fdotnet/chushin/xamlfamily_02/xamlfamily_02_... [atmarkit.co.jp]
まあ、カーネルがどうかはいいんですが
Metro Style App = WinRT(on CLR)であり、現WP7でも利用されてる部分がある、というカンジじゃないかと。
なので、コメ元は多少はしょってますが、言いたいのは下が.NET(CLR)になっており、Win8/WP8で共通となる(カンジ)ということじゃないかなー。
# もちろんネイティブ呼びだししたらどうしようもない
という気がします...
どっか抜けてなければ。
M-FalconSky (暑いか寒い)
Re: (スコア:0)
>なので、コメ元は多少はしょってますが、言いたいのは
>下が.NET(CLR)になっており、Win8/WP8で共通となる(カンジ)ということじゃないかなー。
問題は、はしょるどうこうでなくまずスタート地点の
「バイナリ互換性のためにWP7はsilverlight上でのアプリ開発とされたのだから(注:完全に間違い)」からです。
スタートが間違いなのでその先の過程はぶっちゃけ全部無意味です。
ちなみに、Win8/WP8でも(あなたの表現で言う).NET(CLR)上でのバイナリ互換性は確保されません。
Re:バイナリ互換 (スコア:1)
申し訳ありません。
適当に書いたのが不味かったですね。
言いたかったのはCLR上で動かせられるのでARMでもx86/64でもバイナリ(正確にはMSIL?)の互換性は持たせられるという話でした。
Androidで言うならNDKを使って書けばネイティブコードを含むので当然依存が生まれますけど、DEXバイトコードだけならCPUの命令セット依存は無いですよね?
其れと一緒でC/C++を使ってネイティブコードなMetroApp作れば当然無理になるのは当たり前ですが、MSILだけで済むように組めばCPU依存は起きない。
極端例ならHTML5+JavaScriptなMetroAppとか。
ACだと他の方が私のような品質の低いコメントを自動フィルタ出来なくなるので当分IDかと。
少なくともこのストーリーのこのツリー内では。
Re: (スコア:0)
>言いたかったのはCLR上で動かせられるので
>ARMでもx86/64でもバイナリ(正確にはMSIL?)の互換性は持たせられるという話でした。
あのー、話を理解できてます?
そんなこと言い出したらx86エミュレータをARM上に実装すれば互換性は持たせられるんだ、
に行き着くんですよ?
でもそのルートはわざわざ選択”しない”ことを選び、互換性を捨てているわけです。
さらに今回の場合では
Silverlight基盤としてある程度共通性を持たせていてもそれでも捨てている。
それが現実であってあなたの論調はスタート時点で強烈に否定されています。
そこで反論があるならあなたがARM採用スマホやタブレットの上で
「Win8と互換性を維持した上で現実的な実行性能と電力効率を実現した」
実装を書いてみてください。
教科書ばっか読んでないで現場で苦労してから出直して来いということです。
Re:バイナリ互換 (スコア:1)
すでに旬を過ぎている上にACさんなので見てないし通知も無いので気づかれないかもしれませんが・・・
Windows8の場合、C#やらVB.NETなWinRTアプリを実行するためのCLR(MSIL)実行環境がありますよね。
それとも、今現在のARM版Windows8はx64上のWindows8で開発したC#やらVB.NETやHTML5+JavaScriptで開発したWinRTアプリが動かないという事でしょうか?
実行性能と電力効率のためにネイティブで開発して動かないといわれても、それは自ら選択した事ですよね。
もちろん、自らじゃなく、プロジェクトの意思かもしれませんが。