アカウント名:
パスワード:
WindowsのArm対応をもっと真面目にやれよとMacですらArmに乗り換えたAppleの爪の垢でも煎じて飲め
armをサポートしてないMacのアプリもあるし、そこは善し悪し。簡単に乗り換えられるはずのLinuxサーバーでも、まだ主流はamd64だしな。
Macに文句いうより、今後のWindows版を懸念すべきでしょ。Macの場合これでも対策をしてるこの程度の範囲で収まっている。Windowsに当てはめてみれば、惨憺たる結果にしかならないわけだし。悲惨な未来しか見えないわけだ。それを考えればWindowsの場合絶対に移行不可。
普通はへんな妄想をCEOが言う前に、何とも準備してないできない。マイクロソフトは準備してないので無理だな。
ほぼ、Apple Silicon対応になったけど、音楽関係は、プラグインの問題で、まだRosetta2頼みの所がある。あと、Apple SiliconのmacOSは微妙にメモリーリークしている気がする。
サウンド周りCore Audioのメモリ解放をOS側がするかプラグイン側がするか仕様に明記されてなくて、プラグイン側でメモリ解放しないとリソースリークするからとプラグイン側でメモリ解放してたら、ある時OS側で開放するようになってダブルfree状態になってクラッシュするように。
みたいなアレな要素が有るので、メモリリークは仕様かもしれない。
カーネル類はともかく、問題はドライバなんだよなぁハードウェア境界のところが一番大変なのよ移植ってだからMS単独で全部どうこうできる話でもないんだな
いろいろなコンポーネントがあるんだろうけど、.NET Frameworkなんかは4.8で機能追加終了した後に4.8.1出してArm対応しとる
IntelとAMDほんとワッパ悪いからなあ死んでほしい
使わなきゃいいじゃん
MSVCはARM64対応しましたよ下地は出来てるから時間掛かるんで徐々にやっていくしかない
自社採用のハードしかサポートしなくていいMacがArmサポートしただのどうの言われましても……MSがやる場合、PCIeやUSB越しにx86用ドライバしかない機器のサポートも一斉に求められるだろうけど、ドライバどーすんの？ストアアプリと出来合い構成のモバイル端末のみならまだ行けそうだけど、それがWPやらRTやらでしょ。で、売れずに撤退。だからこそ続けてたら、のタラレバ話になる。
.NETのMSIL,CILはx86,x64,ARMサポートできるんだし、ドライバ周りもそれで実装できるようにしてたら面白そうなのにね。普通のデスクトップアプリですら、全アーキテクチャサポートがデフォじゃなかったのがなぁ……Javaと違って初回起動以外で重い言われる事が稀な良い中間言語だし、もっとうまく使い倒してくれよぉ……
Appleが気軽にArmに乗り換えられたのは、intel用ソフトをほぼネイティブで走らせれる様にしたからだけど、あれはCPUに専用の拡張があるから [hatenablog.jp]実現できたことで、汎用Armを想定してるWindowsに同じレベルを期待するのは酷だと思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
それはいいから (スコア:0)
WindowsのArm対応をもっと真面目にやれよと
MacですらArmに乗り換えたAppleの爪の垢でも煎じて飲め
Re:それはいいから (スコア:1)
armをサポートしてないMacのアプリもあるし、そこは善し悪し。
簡単に乗り換えられるはずのLinuxサーバーでも、まだ主流はamd64だしな。
Re: (スコア:0)
Macに文句いうより、今後のWindows版を懸念すべきでしょ。
Macの場合これでも対策をしてるこの程度の範囲で収まっている。
Windowsに当てはめてみれば、惨憺たる結果にしかならないわけだし。
悲惨な未来しか見えないわけだ。それを考えればWindowsの場合絶対に移行不可。
普通はへんな妄想をCEOが言う前に、何とも準備してないできない。
マイクロソフトは準備してないので無理だな。
Re:それはいいから (スコア:1)
ほぼ、Apple Silicon対応になったけど、音楽関係は、プラグインの問題で、まだRosetta2頼みの所がある。
あと、Apple SiliconのmacOSは微妙にメモリーリークしている気がする。
Re: (スコア:0)
サウンド周りCore Audioのメモリ解放をOS側がするかプラグイン側がするか仕様に明記されてなくて、
プラグイン側でメモリ解放しないとリソースリークするからとプラグイン側でメモリ解放してたら、
ある時OS側で開放するようになってダブルfree状態になってクラッシュするように。
みたいなアレな要素が有るので、メモリリークは仕様かもしれない。
Re: (スコア:0)
カーネル類はともかく、問題はドライバなんだよなぁ
ハードウェア境界のところが一番大変なのよ
移植って
だからMS単独で全部どうこうできる話でもないんだな
Re: (スコア:0)
いろいろなコンポーネントがあるんだろうけど、.NET Frameworkなんかは4.8で機能追加終了した後に4.8.1出してArm対応しとる
Re: (スコア:0)
IntelとAMDほんとワッパ悪いからなあ
死んでほしい
Re: (スコア:0)
使わなきゃいいじゃん
Re: (スコア:0)
MSVCはARM64対応しましたよ
下地は出来てるから時間掛かるんで徐々にやっていくしかない
Re: (スコア:0)
Re: (スコア:0)
自社採用のハードしかサポートしなくていいMacがArmサポートしただのどうの言われましても……
MSがやる場合、PCIeやUSB越しにx86用ドライバしかない機器のサポートも一斉に求められるだろうけど、ドライバどーすんの？
ストアアプリと出来合い構成のモバイル端末のみならまだ行けそうだけど、
それがWPやらRTやらでしょ。で、売れずに撤退。だからこそ続けてたら、のタラレバ話になる。
.NETのMSIL,CILはx86,x64,ARMサポートできるんだし、
ドライバ周りもそれで実装できるようにしてたら面白そうなのにね。
普通のデスクトップアプリですら、全アーキテクチャサポートがデフォじゃなかったのがなぁ……
Javaと違って初回起動以外で重い言われる事が稀な良い中間言語だし、
もっとうまく使い倒してくれよぉ……
Re: (スコア:0)
Appleが気軽にArmに乗り換えられたのは、intel用ソフトをほぼネイティブで走らせれる様にしたからだけど、あれはCPUに専用の拡張があるから [hatenablog.jp]実現できたことで、汎用Armを想定してるWindowsに同じレベルを期待するのは酷だと思う