Microsoft、次期WindowsでARMアーキテクチャをサポート

1 ：11/01/06 〜 最終レス ：11/11/07

米Microsoftは5日、2011 International CESにおいて、Windowsの次期バージョンでARMアーキテクチャをサポートすると発表した。
リリースの中で、次期Windowsは、AMDとIntelのx86アーキテクチャに加えて、NVIDIA、Qualcomm、Texas Instrumentsなどの
ARMベースのSoC(System on a Chip)プラットフォームをサポートするとした。
ARMのサポートにより、Windowsをより広範囲のフォームファクタで動作させることができるようになるとしている。
また次期WindowsをARM上でデモストレーションした。
デモにはハードウェアアクセラレーションによる3Dグラフィックスとメディア再生、Internet Explorer、
さらにUSBやプリンタのサポートなどが含まれる。
さらに、OfficeもARMアーキテクチャでネイティブに実行できることもデモされた。
http://pc.watch.impress.co.jp/docs/news/event/20110106_418205.html

2 ：

Windowsは複数アーキテクチャに対応できるOSということが
証明できてしまったな。

3 ：

これがWindowsの潜在能力ですよ。
Windows NT 4.0のあまり知られていない事実
http://pc.watch.impress.co.jp/docs/article/960919/nt40us.htm
右の画面キャプチャ、一見何の変哲もない普通のWindows NT 4.0のように見えるが、よく見ると驚くべき事実が2つ隠れている。
画面から解る事は、
PowerPC版Windows NT 4.0(英語版)
Netscape Navigator 3.0 (32ビット版)
日本語表示
この3点である。「ん！？」考えてみるとちょっと変だ。
まず、PowerPC版Windows NT 4.0でx86版Win32アプリケーションが動いている。RISC版Windows NT 4.0は、
386コードセット（386エンハンスド・モード専用を含む）で書かれたWin16アプリケーションに対応したのは知っているが *1 、
Win32までその対応範囲を広げたとは聞いていない。もちろん、Netscape Navigator 3.0のPowerPC版が出たと言う話も無い。
更に、IE 3.0のようにInternational Extensionsを持たないNetscape Navigator 3.0で日本語を表示している。
何だこれは！？
さてRISC派（？）にとって一番問題になるのが黄色い部分であり、市場に山ほどあるx86版Win32アプリケーションは
RISC版Windows NTで動かない。これが理由でRISCマシンはサーバーやグラフィック系など、ごく限られた用途だけで使われてきた。
しかし、今回の"Win32 x86 Emulation on RISC"モジュールを使うとこの制限が無くなり、一般的なx86版Win32アプリケーションを
RISCマシンで動かす事が可能になる。
「これは凄い！！」と、早速手持ちのPowerPCマシン *2 に組み込み実験した。試したアプリケーション（全て32ビット・アプリケーション）は
以下の通りで、どうやら作動原理は"APIまではx86エミュレーション、API下はRISCネイティブ"で動いている様だ。

4 ：

パクリ

5 ：

>>2
いまでも、Itanium2用があるだろ。

6 ：

Itanium からはとっくに撤退済みですよ〜

7 ：

>>6
次やらないと言っているだけで直近のWindows 2008 Server R2のは出している。というか、x86の方が先に切られてる。

8 ：

iOSやAndroidの台頭に危機感を持っているんやな

9 ：

ＰＳ３でＷＩＮＤＯＷＳ動くようにしろよ

10 ：

まあWindowsアプリでユーザーを囲い込みたいだけなんですがね
　Windowsはアーキテクチャの垣根を取り払います！
　↓
　日本メーカーWindowsに対応
　↓
　世界標準の互換機以外には対応してやらねーよｗｗｗｗ
　RISCプロセッサにもNT！
　↓
　ワークステーションユーザーがNT購入
　↓
　x86版以外はもう出さねーよｗｗｗｗ
　ケータイ機用プロセッサにWindowsが対応！
　↓

11 ：

えらそーなこと言うのはNetBSDくらいに多くのアーキテクチャに対応してからにしてくれ。

12 ：

MSの囲い込み戦略のせいで、PCは全部x86かx86-64になっちゃいましたね
MSの囲い込み戦略のせいで、Macも全部x86-64になっちゃいましたね
MSの囲い込み戦略のせいで、スパコンもほとんどがx86-64になっちゃいましたね

13 ：

偉そうにx86エミュレータの話されてもなあ
結局、MSはAlpha版の開発を途中で辞めちゃったくせに
windowsxpがx86以外で動くのかよ？

14 ：

http://ja.wikipedia.org/wiki/Windows_xp#.E3.82.A8.E3.83.87.E3.82.A3.E3.82.B7.E3.83.A7.E3.83.B3

15 ：

>>12
＞MSの囲い込み戦略のせいで、Macも全部x86-64になっちゃいましたね
これは腐林檎が見捨てたからだろｗ
なんでもMSのせいにすればいいというものではないぞｗ

16 ：

MSの囲い込み法は売れそうなものはみんなサポート。
RISCのデスクトップOSでの失敗が86だけになった原因。
ゲーム機ではRISCが採用されている。

17 ：

売れそうなH.264はVC-1と名前を変えてサポート

18 ：

>>15
モトローラが糞CPUしか作れなくなってたから仕方が無い

19 ：

どうせNT4のPowerPC版みたいに飽きてすぐ放棄するんだろな。

20 ：

PowerPC自体がダメダメだったから。

21 ：

それもいいけど、モバイルデバイス用のOS、
カーネルだけでもデスクトップ機と共通にしろよ…
いまやMSだけだろ、カーネルが別なのは。

22 ：

WindowsCE系のAPIの互換性を強化する方向でもよかったんじゃ

23 ：

APIが共通だとどれだけ競合に対して優位に建てるか分からんよな。
ただ、互換性追求じゃいつまでたっても溝は埋まらないから、
カーネルとコンポーネントの共通化をすべき。

24 ：

x86バイナリは実行できたとしても結局エミュレーションになるから、
既存のx86バイナリのアプリケーションはぶっちゃけ眼中にないだろ。
AlphaやPowerPCの時代と今回で決定的に違うのは、
メインであり続けるx86/x86-64環境でも既にCLI(.NET)ベースへの移行がほぼ完了している点だな。
ひらたく言うなら、現在CLIベースで書かれているWindowsアプリケーション、
これから作成されるWindowsアプリケーションは、単一パッケージのまま自動的にx86でもx64でもARMでも動作する。
x86バイナリだから、他のアーキテクチャでは動作したとしても速度が…という時代ではもはやない。

25 ：

ARMのOfficeはもう動いている。

26 ：

能書きなどどうでもいい
サクサク動くかどうかだ

27 ：

CE程度には動くだろうね。

28 ：

>>24
> これから作成されるWindowsアプリケーションは、
> 単一パッケージのまま自動的にx86でもx64でもARMでも動作する。
Officeさんがネイティブなのにかw

29 ：

>>28
MS OfficeのARM版はCESでデモしてたね。

30 ：

NVIDIAのARMコアってどうなん？

31 ：

Macの次期CPUになります。

32 ：

>Officeさんがネイティブなのにかw
これからの話ならARM版を出せば済むんじゃね

33 ：

マイクロソフトの囲い込みってゴミだよな

34 ：

Appleの囲い込みは綺麗な囲い込み
あれだけ他社の囲い込みを口汚く罵っていた連中が
Appleのやる事だけは諸手で万歳、というダブスタにはマジで反吐が出る。
あいつら全員林檎の工作員だったのか…と思うともうな

35 ：

あれだけAppleの囲い込み口汚く罵っていた連中が、マイクロソフトの囲い込みを「例外でOK」と感じる気持ち悪さ
宗教だろうな

36 ：

ARM版Windowsって、スレートPC用か？
ただ、UIどうすんだろ。
普通のPCと同じUIを兼用だと一般人に普及しないのは実証済みだし。

37 ：

サードパーティの開発者にも１つのソフトにつき、通常のPC用とスレート用別々にUIを作らせるとか？

38 ：

iOSのパクリか

39 ：

DirectX等を使うとなるとC++じゃないと・・・

40 ：

>>39
C++ならCPUあまり関係ないだろ

41 ：

XNAがあるじゃん。

42 ：

Windows Phone 7 のアプリが貧弱なので、iPhone の人気アプリの画像を撮ってきてはめ込み合成で
実際にはないアプリをあるように見せかけた、バードカフェ並みの偽装をするあのマイクロソフトが
パクらない訳がない。

43 ：

サードパーティの機能を勝手に自分の特許で申請したAppleがなにか物言いをつけるに違いない。

44 ：

WindowsのARM版出荷開始！→市場を奪われたWindowsPhone終了

45 ：

WindowsARM版が奪うWindowsPhoneの市場などちっぽけなものだろ

46 ：

>>38
Mac OS XとiOSの関係みたいにアプリの互換性が無いサブセットOS作るなら名前変えないと一般消費者は混乱する。
「wOS」とか。
でも、だったらWP7で良い様な。やっぱアプリの互換性持たせてくるんだろうな。
そうなると>>37のアプローチが必要になる気がする。

47 ：

>>36
上位のフレームワークだけ別にしないといけないけど、
Windows Mobileとの関係とか不透明なのはいつも通りだよなあ。
>>44
いやいやw
本来統一されてこないと、タブレット時代を乗り越えられないんだが…
>>46
CEとかMobileとかPhoneとかEmbeddedとかむしろありすぎて混乱しているという…

48 ：

.netでつくればいい。
タッチ用に作れば、たいていマウスで操作できる。

49 ：

MSとしては、これからは.NETで作ってもらうという姿勢。
過去の遺産とパフォーマンス命のものだけCPU別。

50 ：

.NETで書けばMacでもネイティブに動くもんな

51 ：

.NETなら、Windows、Linux、Mac、iPhone、Android、Windows Phone全部動く。
プログラミング言語も多い。

52 ：

いや、Windows以外じゃ動かないよ。
ライブラリが全く揃ってない。

53 ：

>>52
ライブラリって何のライブラリだ？

54 ：

>>44
アタマが悪すぎるぞｗ

55 ：

またアップルの真似かよ

56 ：

WindowsPhone終了！？
　↓
【WP7】WindowsPhone7総合 Part3
http://hibari.2ch.net/test/read.cgi/smartphone/1293285074/

57 ：

.NETアプリなら・・・とか言ってる人多いけど、
実際にアプリ作ったことあってそういう事言ってるの？
現状の.NETって足りない機能いっぱいで、
少し凝った事しようとしたらWindowsのAPIを叩かないといけないのに？
Officeが、いつまで経っても.NETアプリにならない理由がそれだよ。

58 ：

>>57
レイヤーの概念なくプログラミングしているからだろ。
それから、Officeは、COMベースのC++で書かれた巨大な既存アプリかつパフォーマンスが命のアプリ。
同一バイナリでクロスプラットホームにする必要なし。

59 ：

マイクロソフトが.NETを否定かよ

60 ：

>>58
レイヤーの概念ってｗ
.NETで出来なきゃ、他の手段使うしかないだろ。
何が言いたいんだお前はｗ

61 ：

信者同士で叩き合うなｗ

62 ：

>>60
Windows APIを叩いているところをカプセル化しろ

63 ：

>>62
だーかーらー、
カプセル化するのは当たり前。
そのカプセルの中身は.NETで作れないでしょ？
結局、そのアプリは .NETで作ることができないんだよ。
こんな状況でARM版Windowsは.NETアプリだけですよ〜
とかできないでしょ。

64 ：

> そのカプセルの中身は.NETで作れないでしょ？
> 結局、そのアプリは .NETで作ることができないんだよ。
その理屈だと、「C++で作ることができない」も
あてはまるよなw
すべてのアプリは、アセンブラじゃないと作ることができない。

65 ：

>>64
あてはまらない。
君、プログラミングの基礎も知らない素人でしょ？
相手して損した。

66 ：

>>65
えとさ、お前、何も反論してないよ。
違うというだけで、その理由が何も書かれてない。
たとえば、LinuxはC言語で作られていると言われているが
実は一部にアセンブラが存在している。
お前はコードの100%を○○言語で作っていなければ、
○○言語で作ったと言えないといっているが、
実際には互換性を保つためレイヤを薄く保っていれば、
その部分を除いて.NETで作っているのであれば、
それは.NETで作ったと言っていいんだよ。
実際LinuxがC言語で作られていると言われているのだって
同じ理由なんだから。
さあ、君のターン(笑) なんか言ってね。

67 ：

>>63
カプセル化したところをARM版に書き直せないのならそうだが、そういうことは考えにくい。

68 ：

Windows崩壊

69 ：

>>66
頭が悪すぎるな。
もう一度 >>57- からレス読み直してこい。
現状のWindows APIを使う.NETアプリ（単純なソフト以外全部）は、
そのままではARM版Windowsでは走らないと書いているんだ。
それを頭の悪いお前が理解できずに、トンJンな回答をしてるだけ。
理解できてないから、お前のことを素人と言っているんだよ。

70 ：

Appleのロゼッタと同じ仕組みか？
http://www.apple.com/jp/rosetta/

71 ：

>>69
>>3読んでみ。
> 「これは凄い！！」と、早速手持ちのPowerPCマシン *2 に組み込み実験した。試したアプリケーション（全て32ビット・アプリケーション）は
> 以下の通りで、どうやら作動原理は"APIまではx86エミュレーション、API下はRISCネイティブ"で動いている様だ。
Windows APIがARMで実装されていれば、
.NETからWindows APIを呼び出すだけだ。

72 ：

ロゼッタよりもNT4.0の方が先に作られてますよ。

73 ：

>>71
もっとよく読めｗ
x86エミュレータを走らせているだろ。
非力なARMでそんなもん走らせる気か？

74 ：

>>73
エミュレータなのは、APIまでって書いてあるだろ。
APIまでってことは.NETアプリの部分はエミュレータじゃない。
.NETアプリは、Javaと同じで中間コードになってるから、
ARMで動かす場合は、ARMネイティブに変換されるんだよ。
つまり、
・.NETアプリ部分・・・ARMネイティブにされる
・API部分・・・もとからARMネイティブ
お前のほうが素人じゃんかw

75 ：

>>69
.NETオンリーはお前ルールだから。
そもそも、今の.NETでWindows APIを直接叩くことはあまりないのだが、どのAPI使っているんだ？

76 ：

>>75
.NETオンリールールが俺ルールなのは認める。
というか、.NETアプリにすれば全て解決みたいな人が多かったから>>57
みたいな事書いたんだし。
あと、API叩くとかは・・・たとえばドラッグ＆ドロップをアプリ内で使用したい場合どうします？

77 ：

どうします？って聞いているのは、
お前がなにも知らないからだよなw
質問してないで、こうこういう理由で
だめですって言ったらどうだ？
知らないから言えないんだろう？
.NETですべて解決。これは正しい。
・.NETアプリ部分・・・ARMネイティブにされる
・API部分・・・もとからARMネイティブ

78 ：

> あと、API叩くとかは・・・たとえばドラッグ＆ドロップをアプリ内で使用したい場合どうします？
なんの問題もなくできるんじゃね？
なんか問題があるという根拠でもあんの？
なぁなぁ。

79 ：

>>77-78
結論から言うと、.NETではできない んだよ。
ウソだと思うなら調べてみなさい。ド素人さん。

80 ：

http://msdn.microsoft.com/ja-jp/library/system.windows.forms.control.dragdrop(VS.80).aspx
じゃあ、.NETのドラッグ&ドロップのコード出したら、
お前どうすんの？

81 ：

相手を素人呼ばわりするやつほど・・・ってやつだなw
言っとくが俺はプロだよ。
お前が素人なのは誰に目にも明らかだが。

82 ：

>>76
COM関係は.NETオンリーではできないことが多い。たとえばCOMコンテナ・サーバーは作れない。
Office製品群は例外の一つ。
しかし、そういうのは必要ないアプリが大半。

83 ：

APIが必要！とかいうからなんのことかと思ってみれば、
ドラッグ&ドロップは.NETでできないとか言ってるし。
中学生でも相手にしてんのかね。
お前が買った初心者本に書いてないだけじゃねーの？

84 ：

>>80
ちゃんと動くコードだしてね。
そこに貼ったURLのだけでは実現できないから。

85 ：

実現できるから、使い方のコードが乗ってるんだろ・・・。
ちゃんと動くコードを作るのは、お前の仕事だってw

86 ：

>>85
ほら、逃げてないで、ちゃんと動くコードを出してみなさい。
.NETだけで出来ると言った、君の仕事だよ。

87 ：

http://school.topposystem.co.jp/moe/Form/Form_DragAndDrop.htm
完全なソースコード有り。
ってかいてあるぞwwww
バカへのレスにぴったりだなこれw

88 ：

MSのすごい所の一つははサンプルが沢山用意されているところ。
Events Explorer のドラッグ アンド ドロップのサンプル
http://msdn.microsoft.com/ja-jp/library/ms771747(v=VS.85).aspx

89 ：

ほらよ、ばーか
ドラッグ アンド ドロップのサンプル
Visual Studio 2005 その他のバージョン
Download sample
このサンプルには、Windows アプリケーション内のフォームのドラッグ アンド ドロップ機能に関する、次の 3 つの例が含まれています。
http://msdn.microsoft.com/ja-jp/library/5a37ax35(v=VS.80).aspx

90 ：

>>86
完全に追い詰められたな！
これからどうするんだよ、お前！
括弧　笑い　括弧

91 ：

>>86の人気に嫉妬w

92 ：

WindowsCE6.0+初代Tegra(ARM11)上でPC版と同等と思われるFireFoxを
動かしているデモだが普通に快適に動いてるっぽいな
http://www.youtube.com/watch?v=YcU6i-cEk10&feature=related

93 ：

非力といっても、10年前のx86と比べれば強力。

94 ：

WindowsのAPIを叩く必要がある場合はx86でないとダメ、とかお笑いだな。
ARM版Windowsならその”WindowsのAPI"もARMのネイティブコードで動いてるのに、
CLI(.NETアプリケーション)からWindowsのAPIを呼び出すために
x86のバイナリコードを経由する必要は全く無い。
まあ、x86バイナリをエミュレーション実行する必要は無くとも、
クロック当たりで半分の性能もない、おまけに動作クロックも低いARMで
x86と同じ.NETアプリを実行するのは、苦行以外の何物でもないとは思うけどな。
しかしAndroid端末をつついて、ひと通り環境構築した後でつくづく思ったのは、
「これがPCだったら、1からマーケットやポータルサイトを漁ってアプリ探しする必要も無かったのにな」
「結局やってる事は劣化PC。これが素のPCなら、余計な面倒など無いのに…」
って事だった。
WinCEやWinMobile、Androidは勿論だが、iPhoneやらiPadやらも、所詮はガジェットオタの玩具だよ。
PCがこのサイズになれば、そりゃ誰だってPC使うわ…二度手間・三度手間を喜んで漁るのはオタクだけ。

95 ：

信者乙

96 ：

>>64
アホ丸出し。

97 ：

>>96
理由を書かないと、馬鹿に見えるのはお前の方だぜ。

98 ：

>>94
> 「これがPCだったら、1からマーケットやポータルサイトを漁ってアプリ探しする必要も無かったのにな」
PCだったら素のWindows入れたらなんでもできんの？

99 ：

ニュー速に行ったら、
x86のソフトがそのままARMで使えると思ってる
もしくは
x86エミュをOSの機能と思ってる
バカに煽られた

100read 1read

1read 100read