アカウント名:
パスワード:
やっぱり移植はせんと駄目なんですかね？WoW64みたいになってそのまま動ければ幸せですけど。
WoW64みたいにそのまま動くよ。移植が必要なのはそれではパフォーマンスが不足する場合だけ。ただし従来のArm64 ABIではx64のコードと相互呼び出しができなかったので、アプリ全体を一気に移植する必要があった。これに対してArm64EC ABIではDLL単位で少しずつ移植を進めることができる。従来もシステムDLLはArm64ECでビルドされていたので、同じDLLをx64とArm64の両方から使えた(そのためWow64のような分離されたシステムディレクトリは存在しなかった)。今回同様のDLLのビルドをサードパーティーにも開放したということ。
> 従来もシステムDLLはArm64ECでビルドされていたので、同じDLLをx64とArm64の両方から使えた
訂正: これはArm64ECじゃなくてArm64Xだった(Arm64ECと無関係なわけではないが)。
WoW64みたいにていうかまさにWoWの原理でABI呼び出しを変換してるそうですが。まあパフォーマンスとか考えたらARM向けの機械語版もだしてよってのがマイクロソフトの本音でしょうね。 CILにコンパイルしたならそのへんどうでもいいよねとか言わない。
そこで渋るなら別に移植しなくてもいいし、なんなら現状誰も使ってないようなプラットフォームのサポートをしないことを選んでもいい
渋るというか、移植しなくてもそのまま動くのかどうかでしょ
そんなもんテストしろよ
Write once, test anywhere というヤツですね。
むしろwrite once系でそうじゃないものを見たことがない。だけど営業受けはいいんだよね... (´・ω・｀)
面倒なら.NETアプリにすればいいじゃんJITコンパイラが良きに計らってくれる
既存のネイティブアプリを.NETにって、規模にもよるけどまだ今回の仕組み使った方がマシなんじゃ…
.NET 5からは、ちゃんとARMに対応したから .NETで書けば気にせずネイティブ実行されるよ。.NET Framework4 を使って書かれてるやつは、ARM64でも x86/x64の.NET Frameworkが使われる。.NET FrameworkのアプリもWCFとかのような廃止されたものを使ってなければ、 .NET 6でそのまま動くからランタイム指定変えてビルドしなおせばすむ。
どうせなら.EXEを廃止してMacにように複数のコードをバンドルできる仕組みならArm版でもIntel版でも動く仕組みなら理解できるけどターゲットもなくこれって謎だな。
> アップルみたいにデスクトップ市場までARMで統一する未来まで見えてみたのにマイクロソフトは何も関与できない。 マイクロソフトはサーバー側の利益がどんどん増えてるっての知らないの？クライアント側と違って継続的に収入あるからおいしくてたまらん状態。正直うらやましい。
68EC030はそのようにはならなかったな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
徐々に Arm へ移植していくことが可能 (スコア:0)
やっぱり移植はせんと駄目なんですかね？
WoW64みたいになってそのまま動ければ幸せですけど。
Re:徐々に Arm へ移植していくことが可能 (スコア:2, 参考になる)
WoW64みたいにそのまま動くよ。移植が必要なのはそれではパフォーマンスが不足する場合だけ。ただし従来のArm64 ABIではx64のコードと相互呼び出しができなかったので、アプリ全体を一気に移植する必要があった。これに対してArm64EC ABIではDLL単位で少しずつ移植を進めることができる。従来もシステムDLLはArm64ECでビルドされていたので、同じDLLをx64とArm64の両方から使えた(そのためWow64のような分離されたシステムディレクトリは存在しなかった)。今回同様のDLLのビルドをサードパーティーにも開放したということ。
Re: (スコア:0)
> 従来もシステムDLLはArm64ECでビルドされていたので、同じDLLをx64とArm64の両方から使えた
訂正: これはArm64ECじゃなくてArm64Xだった(Arm64ECと無関係なわけではないが)。
Re: (スコア:0)
WoW64みたいにていうかまさにWoWの原理でABI呼び出しを変換してるそうですが。まあパフォーマンスとか考えたらARM向けの機械語版もだしてよってのがマイクロソフトの本音でしょうね。 CILにコンパイルしたならそのへんどうでもいいよねとか言わない。
Re: (スコア:0)
そこで渋るなら別に移植しなくてもいいし、なんなら現状誰も使ってないようなプラットフォームのサポートをしないことを選んでもいい
Re: (スコア:0)
渋るというか、移植しなくてもそのまま動くのかどうかでしょ
Re: (スコア:0)
そんなもんテストしろよ
Re: (スコア:0)
Write once, test anywhere というヤツですね。
Re: (スコア:0)
むしろwrite once系でそうじゃないものを見たことがない。
だけど営業受けはいいんだよね... (´・ω・｀)
Re: (スコア:0)
面倒なら.NETアプリにすればいいじゃん
JITコンパイラが良きに計らってくれる
Re: (スコア:0)
既存のネイティブアプリを.NETにって、規模にもよるけどまだ今回の仕組み使った方がマシなんじゃ…
Re: (スコア:0)
.NET 5からは、ちゃんとARMに対応したから .NETで書けば気にせずネイティブ実行されるよ。
.NET Framework4 を使って書かれてるやつは、ARM64でも x86/x64の.NET Frameworkが使われる。
.NET FrameworkのアプリもWCFとかのような廃止されたものを使ってなければ、 .NET 6でそのまま動くからランタイム指定変えてビルドしなおせばすむ。
どこに向かおうとしてるのわからない。 (スコア:0)
どうせなら.EXEを廃止して
Macにように複数のコードをバンドルできる仕組みなら
Arm版でもIntel版でも動く仕組みなら理解できるけど
ターゲットもなくこれって謎だな。
Re: (スコア:0)
> アップルみたいにデスクトップ市場までARMで統一する未来まで見えてみたのにマイクロソフトは何も関与できない。
マイクロソフトはサーバー側の利益がどんどん増えてるっての知らないの？
クライアント側と違って継続的に収入あるからおいしくてたまらん状態。
正直うらやましい。
Re: (スコア:0)
68EC030はそのようにはならなかったな。