アカウント名:
パスワード:
> 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開発側やアプリ開発側の負担を下げるのにおい
申し訳ありません。
WP7アプリがWindows上のSilverlightランタイム上で動くわけでもない。むしろ動かなくしてでもスマホ上で性能稼げる実装を選んでいる。
適当に書いたのが不味かったですね。言いたかったのはCLR上で動かせられるのでARMでもx86/64でもバイナリ(正確にはMSIL？)の互換性は持たせられるという話でした。Androidで言うならNDKを使って書けばネイティブコードを含むので当然依存が生まれますけど、DEXバイトコードだけならCPUの命令セット依存は無いですよね？
其れと一緒でC/C++を使ってネイティブコードなMetroApp
>言いたかったのは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開発側やアプリ開発側の負担を下げるのにおい
Re: (スコア:1)
申し訳ありません。
適当に書いたのが不味かったですね。
言いたかったのはCLR上で動かせられるのでARMでもx86/64でもバイナリ(正確にはMSIL？)の互換性は持たせられるという話でした。
Androidで言うならNDKを使って書けばネイティブコードを含むので当然依存が生まれますけど、DEXバイトコードだけならCPUの命令セット依存は無いですよね？
其れと一緒でC/C++を使ってネイティブコードなMetroApp
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アプリが動かないという事でしょうか？
実行性能と電力効率のためにネイティブで開発して動かないといわれても、それは自ら選択した事ですよね。
もちろん、自らじゃなく、プロジェクトの意思かもしれませんが。