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

米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

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

これが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ネイティブ"で動いている様だ。

パクリ

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

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

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

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

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

まあWindowsアプリでユーザーを囲い込みたいだけなんですがね

　Windowsはアーキテクチャの垣根を取り払います！
　↓
　日本メーカーWindowsに対応
　↓
　世界標準の互換機以外には対応してやらねーよｗｗｗｗ

　RISCプロセッサにもNT！
　↓
　ワークステーションユーザーがNT購入
　↓
　x86版以外はもう出さねーよｗｗｗｗ

　ケータイ機用プロセッサにWindowsが対応！
　↓

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

MSの囲い込み戦略のせいで、PCは全部x86かx86-64になっちゃいましたね

MSの囲い込み戦略のせいで、Macも全部x86-64になっちゃいましたね

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

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

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

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

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

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

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

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

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

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

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

APIが共通だとどれだけ競合に対して優位に建てるか分からんよな。

ただ、互換性追求じゃいつまでたっても溝は埋まらないから、
カーネルとコンポーネントの共通化をすべき。

x86バイナリは実行できたとしても結局エミュレーションになるから、
既存のx86バイナリのアプリケーションはぶっちゃけ眼中にないだろ。

AlphaやPowerPCの時代と今回で決定的に違うのは、
メインであり続けるx86/x86-64環境でも既にCLI(.NET)ベースへの移行がほぼ完了している点だな。

ひらたく言うなら、現在CLIベースで書かれているWindowsアプリケーション、
これから作成されるWindowsアプリケーションは、単一パッケージのまま自動的にx86でもx64でもARMでも動作する。
x86バイナリだから、他のアーキテクチャでは動作したとしても速度が…という時代ではもはやない。

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

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

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

>>24
> これから作成されるWindowsアプリケーションは、
> 単一パッケージのまま自動的にx86でもx64でもARMでも動作する。

Officeさんがネイティブなのにかw

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

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

Macの次期CPUになります。

>Officeさんがネイティブなのにかw

これからの話ならARM版を出せば済むんじゃね

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

Appleの囲い込みは綺麗な囲い込み


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

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

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

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

iOSのパクリか

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

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

XNAがあるじゃん。

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

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

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

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

>>38
Mac OS XとiOSの関係みたいにアプリの互換性が無いサブセットOS作るなら名前変えないと一般消費者は混乱する。
「wOS」とか。

でも、だったらWP7で良い様な。やっぱアプリの互換性持たせてくるんだろうな。
そうなると>>37のアプローチが必要になる気がする。

>>36
上位のフレームワークだけ別にしないといけないけど、
Windows Mobileとの関係とか不透明なのはいつも通りだよなあ。

>>44
いやいやw
本来統一されてこないと、タブレット時代を乗り越えられないんだが…

>>46
CEとかMobileとかPhoneとかEmbeddedとかむしろありすぎて混乱しているという…

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

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

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

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

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

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

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

またアップルの真似かよ

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

.NETアプリなら・・・とか言ってる人多いけど、
実際にアプリ作ったことあってそういう事言ってるの？

現状の.NETって足りない機能いっぱいで、
少し凝った事しようとしたらWindowsのAPIを叩かないといけないのに？

Officeが、いつまで経っても.NETアプリにならない理由がそれだよ。

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

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

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

信者同士で叩き合うなｗ

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

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

こんな状況でARM版Windowsは.NETアプリだけですよ〜
とかできないでしょ。

> そのカプセルの中身は.NETで作れないでしょ？
> 結局、そのアプリは .NETで作ることができないんだよ。

その理屈だと、「C++で作ることができない」も
あてはまるよなw

すべてのアプリは、アセンブラじゃないと作ることができない。

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

>>65
えとさ、お前、何も反論してないよ。
違うというだけで、その理由が何も書かれてない。

たとえば、LinuxはC言語で作られていると言われているが
実は一部にアセンブラが存在している。

お前はコードの100%を○○言語で作っていなければ、
○○言語で作ったと言えないといっているが、
実際には互換性を保つためレイヤを薄く保っていれば、
その部分を除いて.NETで作っているのであれば、
それは.NETで作ったと言っていいんだよ。

実際LinuxがC言語で作られていると言われているのだって
同じ理由なんだから。

さあ、君のターン(笑) なんか言ってね。

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

Windows崩壊

>>66
頭が悪すぎるな。
もう一度 >>57- からレス読み直してこい。

現状のWindows APIを使う.NETアプリ（単純なソフト以外全部）は、
そのままではARM版Windowsでは走らないと書いているんだ。
それを頭の悪いお前が理解できずに、トンチンカンな回答をしてるだけ。
理解できてないから、お前のことを素人と言っているんだよ。

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

>>69

>>3読んでみ。

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


Windows APIがARMで実装されていれば、
.NETからWindows APIを呼び出すだけだ。

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

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

>>73
エミュレータなのは、APIまでって書いてあるだろ。

APIまでってことは.NETアプリの部分はエミュレータじゃない。
.NETアプリは、Javaと同じで中間コードになってるから、
ARMで動かす場合は、ARMネイティブに変換されるんだよ。

つまり、
・.NETアプリ部分・・・ARMネイティブにされる
・API部分・・・もとからARMネイティブ

お前のほうが素人じゃんかw

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

>>75
.NETオンリールールが俺ルールなのは認める。
というか、.NETアプリにすれば全て解決みたいな人が多かったから>>57
みたいな事書いたんだし。

あと、API叩くとかは・・・たとえばドラッグ＆ドロップをアプリ内で使用したい場合どうします？

どうします？って聞いているのは、
お前がなにも知らないからだよなw

質問してないで、こうこういう理由で
だめですって言ったらどうだ？
知らないから言えないんだろう？

.NETですべて解決。これは正しい。
・.NETアプリ部分・・・ARMネイティブにされる
・API部分・・・もとからARMネイティブ

> あと、API叩くとかは・・・たとえばドラッグ＆ドロップをアプリ内で使用したい場合どうします？

なんの問題もなくできるんじゃね？

なんか問題があるという根拠でもあんの？

なぁなぁ。

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

http://msdn.microsoft.com/ja-jp/library/system.windows.forms.control.dragdrop(VS.80).aspx

じゃあ、.NETのドラッグ&ドロップのコード出したら、
お前どうすんの？

相手を素人呼ばわりするやつほど・・・ってやつだなw

言っとくが俺はプロだよ。
お前が素人なのは誰に目にも明らかだが。

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

APIが必要！とかいうからなんのことかと思ってみれば、
ドラッグ&ドロップは.NETでできないとか言ってるし。

中学生でも相手にしてんのかね。
お前が買った初心者本に書いてないだけじゃねーの？

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

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

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

http://school.topposystem.co.jp/moe/Form/Form_DragAndDrop.htm
完全なソースコード有り。

ってかいてあるぞwwww

バカへのレスにぴったりだなこれw

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

ほらよ、ばーか


ドラッグ アンド ドロップのサンプル
Visual Studio 2005 その他のバージョン
Download sample

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

>>86


完全に追い詰められたな！


これからどうするんだよ、お前！



括弧　笑い　括弧

>>86の人気に嫉妬w

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

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

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使うわ…二度手間・三度手間を喜んで漁るのはオタクだけ。

信者乙

>>64
アホ丸出し。

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

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

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

つうかマイクロソフトのアナウンスほど当てにならんものは無いのにな（失笑）
Vistaの時、お蔵入りした機能の数々やminiwinやらmidoriやら・・・やつら必要に応じて意味もなくでかいアドバルーンを上げるから。
ARMサポートとか言うのもiPadに対抗するための方針だろうから、PCユーザーなやつらには何ら実質的な恩恵は無い。
だってお前ら「低消費電力・低発熱の静音PCクレクレ」って言ってる一方で「ゲーム用途には非力過ぎ」とか言って
結局i5、i7マシン選んでんじゃん。バカ。

ゲームなんかやらんでしょふつう

x86だろうがARMだろうが
マイクロソフトは.NET グーグルはWEBでプラットフォームの統一をはかるようだけど
アップルはどうするんだろうね
まあアップルで統一ってことなんだろうけど

Cocoa / Objective-Cでしょ

AppleはObjective-Cでネイティブ

>>100
iPad対抗ならWP7でやるだろ
向こうもiPhoneOS使いまわしてきてるし

対ChromeOS用と考えるほうが自然
ChromeOSが売れなければ無かった事になりそうな計画だわ

やっぱ普通のPCと同じフォームファクターになるのかね。
タブレットとしては一部の需要以外に対しては筋が悪すぎるUIだし。

>>106
ブラウザ起動するなら
UIなんて関係ないじゃないか

Googleの勝ちなんだけど

Blu-rayがBlue-rayでないのは、
Blue-rayだと青色光となって
商標登録できないかららしい。

何言ってんだお前ｗ
馬鹿かｗ

いずれはWindowsAppStoreみたいなのをやるつもりだな。

　こないだアップルに対し「AppStore」という名称について文句つけてたし・・・

>>111
15年越しのつぶされたプロジェクトの復活も近いか。

>>112
マイクロソフトってアップルの真似しかしないなｗ

>>113
どう考えても、i-mode、そうでなくてもMSやNintendoの方が早いんだが。

>>114
マイクロソフト？
ないよｗ

「Mac App Store」はソフトウェア産業を21世紀へと誘う
http://plusd.itmedia.co.jp/pcuser/articles/1101/14/news090.html

>>116
これがApple信者というやつか
革命的とか大げさもいいところだろ

アップデートを自動でお知らせしてくれるのはうれしい

>結局、MSはAlpha版の開発を途中で辞めちゃったくせに

もともとWindows-NT(今のWindows7の元）はDECのAlphaも
ターゲットに開発したOSだったしな。
ＭＳはDECの吸収合併、消滅とともに、サポートを辞めて
しまった。
Alphaは将来有望な64bitアーキテクチャだったのに。

DECのAlphaエンジニアはその後、IntelやAMDに入り、
皮肉にもx86の性能を飛躍的に向上させた。

過去に有望と言われたＣＰＵアーキテクチャ

DecのAlphaの技術⇒x86-64に活かされた
HPのPA-RISCのアーキ⇒IntelのItaniumに統合

x86-64にAlphaの技術は活かされて今でも主流だが、
優れたPA-RISCは糞アイタタニウムにより潰されたな。

Pentium Proで、RISCプロセッサの性能を抜いてしまったから。

PenProの段階では、まだ漸く並んだというレベル。
橋頭堡は確保したが、まだまだFPUが遅いｗとか突っ込まれていたし。

MMX/SSEが載って、Xeonになってからが本領発揮だった。
それで、並み居る32bitRISCワークステーションは死亡宣告。

慌てて各社64bitへ逃げ出す事になる訳だが、成功できたのはSparcくらいだった。
32bitに留まって"逃げ遅れた"所は、片っ端からx86ワークステーションに喰われて終わった。

嘗てはワークステーションがメインフレームを殺す、と気を吐いていたSunも、
x86ワークステーションの躍進であっという間にシェアを落とし、
今では二束三文で買収したDB屋が解体中。

そして、皮肉なことにメインフレームはまだ生き延びている。多分、これからも生き延びる。

パクリ

Windowsとは関係ないが、俺が使ってきた携帯電話のCPUは超エッチばかりだ。

超日立だろ.....

>>94
.NETからP/InvokeでAPIを使うケースならたいていの場合はうごく
(呼び出し側がIntPtrでポインターを定義してないと動かないこともある）
だが、C++/CLIでラッパーを書いて、そのラッパーがネイティブコードを呼び出しているパターンだと１００％動かない
あと、COMで書かれたコンポーネントもARM向けのやつがなければ動かないこともあり得る
x86からx64に移行しようとたんだが、x64対応のCOMがなくてその部分だけ一から書き直しなんてこともあったな…

>x86からx64に移行しようとたんだが、x64対応のCOMがなくてその部分だけ一から書き直しなんてこともあったな…
1から書き直さなくてもソースからリビルドすりゃ済む話なんじゃね
つうかCOMって実行環境はx86/x64関係ないんじゃね原理的に

あれもDLLだから影響受けるよ
DCOMなら何とかなりそうだが

COMならDCOMでなくてもいたける。

パクリか

>>127
COMがサードバーティだとそうもいかない

pure .NETだけでいいじゃん。

ARMを叩いてた信者がARMを絶賛ｗ

Intelとは最近仲が良くないからね。仕方ない。

アップルにCPU回した時からintelはあまり先のこと考えてないなとは思ってた

アップルはインテルもAMDもARMも買収できる金を持ってる
さて、どこを買収しようか
3ついっちゃうか

マジ？

パクリ

なんで

>>136
他人の投資で稼いだ「時価」を使ってくだらない買収したら駄目でしょ

>>140
それはインテルもAMDもARMもくだらない企業と言う意味か?

マイクロソフトはアップルを真似ることで保っている