WinRTスレ (Metro, .NET Core, C++/CX)

1 ：11/09/24 〜 最終レス ：11/12/09

ネイティブで実装され、.NET, C++/CX, JavaScriptから利用可能な
Windows用 次世代API Windows Runtime (WinRT) を語るスレ。
The Windows Runtime
http://msdn.microsoft.com/en-us/library/windows/apps/hh464942(v=VS.85).aspx
Windows Developer Preview downloads
(Windows Developer Preview with developer tools English, 64-bit (x64) に開発ツールが含まれている)
http://msdn.microsoft.com/ja-jp/windows/apps/br229516/

2 ：

誰が使うん？

3 ：

遅い。1週間早ければ乙だった。

4 ：

VistaとかXP用の開発環境も出てくるということは
WinRTってWin32のただのラッパーなのか

5 ：

VisualStudio11はWin8以外でも動くけど、
WinRTアプリはWin8でしか開発できないよ。

6 ：

とおもったら>>1のやつはWindows8のリンクじゃん

7 ：

Windows8からはWin32よりもWinRTを直に呼び出す方が速い
Win32はわざと遅くするみたいな小細工してくるんだろうな
あーやだやだ

8 ：

「50ms以上かかるAPIはすべて非同期になります(ｷﾘｯ」
C++やJavaScriptでも使えるけど、非同期APIとか面倒すぎて
C#のasync,awaitがないとやってられない

9 ：

これ使うメリットって
Win7以前で動かないのと、公式ショップでしか配れない以外に
何かあるの？

10 ：

>>9
メトロ大好きっ子向け
将来的には
http://www.youtube.com/watch?v=DQdGvfV4WnU&feature=player_embedded
みたいなのを目指してるんだけど、まだ理想に追いついてない感じ

11 ：

それはメリットじゃなくてデメリットじゃないのか？
メリットは高速なWPFってとこかね。
WPFは便利なんだけど、パフォーマンス面で問題が出てたから。

12 ：

WPFってなんでとろいの？

13 ：

>>8
そのためのライブラリがC++やJSにも導入されている
JSだとPromise、C++だとPPL。
俺は使ったことないが、Dev Centerのサンプル見るとどちらもラムダを主軸としたものに見えるから
.NETのTPLと似たようなものだろうが
async/awaitは糖衣構文でフラットに書けたりする分有利ではあるな。

14 ：

>>13
C++ のやつは C# でいうと event-driven async pattern。
JS のは、C# でいうとろの Task.ContinueWith つなぐタイプ。
C# 5.0 で導入される async/await と比べるとだいぶやっぱ使いにくい。

15 ：

>>14
なるほ
まあ他はライブラリの中async/awaitだけ言語拡張だしなぁ

16 ：

これは流行らんな

17 ：

>>12
理由は色々あるが、その一つにオブジェクト大量生成によるGCの負荷がある
(Templateの仕組みにより、どうしてもオブジェクトが大量に生成されてしまう)
実装がネイティブになることで、この点は解決されるだろう

18 ：

WPFはImageコントロールがUIスレッドをブロックしたり、
実行時にBinaryXAMLの読み込みが必要以上に頻発したりと、
どうもおかしな実装が多かった
ネイティブにしたところで、同じような実装なら遅いままだろうなぁ・・・
ちゃんと、パフォーマンスを考えて、まともな実装をしてくれるといいんだけど

19 ：

Win8でしか動かないってのがなあ

20 ：

わざわざ旧OSで使いたがる人がそんないるとは思えんけどね。
さしあたりメインターゲットはタブレット機辺りだし、これから出てくるのは
基本8搭載でしょ。

21 ：

所詮MSがAppStoreで儲けるための布石でしかないからね

22 ：

Win8メトロ切ったら快適だわw

23 ：

Metroアプリが旧デスクトップ上にウィンドウ表示できないとビジネスアプリなんかに使えないよ。

24 ：

タイルをデスクトップに置けたり、MetroアプリをZune Softwareみたいな形式で使えたら面白そうだとも俺も思ったが
そもそも、ここはWinRTスレだ。

25 ：

タブレットではメトロアプリしか使えないとか
そんな感じになるのかな？

26 ：

価格が安い代わりにメトロしか動かせないエディションとか出るかもね

27 ：

なんだそのゴミパソ

28 ：

Win８上で仮想マシン（スマホもどき） 作って、そこでメトロったらいいのでは？

29 ：

ARM版はメトロしか動かないんじゃないのかな？

30 ：

ARM版タブレットはMetroのみでおｋ
いさぎよいし
Metroの普及に弾みがつく

31 ：

「ARM版Windows 8でデスクトップアプリは動く」とマイクロソフト - CNET Japan
http://japan.cnet.com/sp/allaboutms/35007772/
動くらしいよ。
制限付きそうだが。
旧デスクトップ、エクスプローラなどは切り捨てて、アプリだけ動くでいいのにな。

32 ：

動くのか
CPUエミュとかするんだろうか

33 ：

エミュなんてめんどうなことはやれねー
再コンパイルしてくれって言ってたじゃん

34 ：

やっぱりバイナリ2つリリースしないといけないのか

35 ：

>>34
ちがうよ、3つ。x86とx64とARM。

36 ：

IA-64「」

37 ：

そんなんでARMタブレット売れるの？
そんなに電池の持ちが違うのかな

38 ：

WOW64は無くなるの？

39 ：

そろそろwin32apiなくせよ

40 ：

>>35
さらにARMはCPUによって4バージョンだっけ？

41 ：

>>38
引き続き搭載されると思うぞ。なかったら暴動モノ
>>39
WinRTが活躍すればWin32はレガシとなる。完全に消え去るのはもっと後のことだろうが。

42 ：

レガシーサポートはエンプラ版とUltimateだけでいいよ
値段もぼったくってやれ

43 ：

Win8 タブレット→ほとんど売れず
Windows Phone→Win8ベースになるも、ほとんど売れず
パソコン→Metro上のアプリが増えず、ユーザーもMetroに移行せずの悪循環に陥る
このありがちなシナリオで、Win32が主流のままに5万ペセタ

44 ：

ただでMetroアプリ作れるならお父さん、頑張って小遣い稼ぎしちゃうぞ

45 ：

某所に張られたからか頭おかしいのが増えたな
ここはWinRTスレなんだが

46 ：

>>45
で？

47 ：

ネイティブで実装され、.NET, C++/CX, JavaScriptから利用可能な
Windows用 次世代API Windows Runtime (WinRT)　は不要ですか？

48 ：

Win8でしか使えないんでしょ
当分様子見かな

49 ：

8の時点で使うやつはそりゃ結構いるだろうが、本格的に広がるようになるのはもう一世代後だろうな
MSの新規物はバージョン3からとよく言われてることもあるし

50 ：

そもそもマイクロカーネルは非同期通信が前提なんじゃなかった？
MachはlibcでUNIX的な同期処理しようとするから遅い遅い言われてたような

51 ：

んで、おまいら何か作ってみた？

52 ：

ARM版みないとよくわからんが、結局Win32ラッパなんだな

53 ：

図説の通りならカーネルの上にサブシステムとして乗ってるはずだが今の実装はどうなんだろうな

54 ：

>>52
　　　WinRT は…
　　　　　　 ∧__∧　　　　　　　　　　　　　　　　　　　　∧__∧　　なんでラッパやねん！
　　　　　　( *‘ω‘=m===く|　ﾎﾟｯﾎﾟｺﾎﾟｰ♪　　　　　 (＞＜；)
　　　　　　 (　つ（(ニΦニ)）　　　　　　　　　　　　　　 (つと )
　　　　　　　 v v　　　　　　　　　　　　　　　　　　　　　　v v

55 ：

8のWinRTはネイティブだぞ
7でMetro開発出来ないのはその辺に理由があるんだろ

56 ：

んや、サブシステムでもカーネル側での細工が必要でない限り後からサブシステムは追加可能だぜ
SUAとかあるし。

57 ：

Win32とは別のサブシステムって事は
WinRTアプリからWin32APIの呼出しはP/InvokeやCOM経由でもできないのかな？

58 ：

>>53
実際には図説のとおりではなく、Win32依存らしいよ。
ttp://pc.watch.impress.co.jp/docs/column/config/20110920_478525.html

59 ：

>>58
Win32上のレイヤかー
でもいつものろくでもないラッパーよりは差を吸収してくれそうだな。
Win32をレガシと呼びたいらしいから時代が進んだら依存関係を逆転したりとか考えてそう

60 ：

まぁ、既存コンポーネントの利用を考えればそうなるよな。
サブシステム化はWinRTコンポーネントが充実してからってところかな？

61 ：

>>57
できないらしいぞ
WinRTからWin32はP/InvokeやCOM経由も完全に排除されるらしい
逆もまた無理だそうだ
>>58
山田祥平は何を根拠にマイクロソフトの発表と異なる見解を述べてるの？

62 ：

まあどういった実装でもP/InvokeやCOMは使えないだろうな
そのためのWinRTだろうし、権限管理の観点からもそうだろうし。

63 ：

【山田祥平のRe:config.sys】 【番外編】Windows 8は羊の皮を被った狼か
http://pc.watch.impress.co.jp/docs/column/config/20110920_478525.html
> Windows 8の構造を説明する概念図
http://weekly.ascii.jp/elem/000/000/058/58015/20110920atrs001_cs1e1_1000x.png
> も公開されているのだが、そこでは、WinRTとWin32が、
> あたかも独立して存在するかのように描かれているのだが、実際には依存関係がある。
InfoQ: Windows 8は、Win32 APIを置き換える
http://www.infoq.com/jp/news/2011/09/WinRT
> WinRTは新しいOSレベルのAPIレイヤである。
> これはWindowsの新しいネイティブAPIであり、Win32の上にある新しいレイヤではない。
果たしてどっち？

64 ：

山田祥平が間違っている
いつも想像で適当な記事を書くカスだろ

65 ：

>>61
簡単に言うとこういうこと？
　　　　　　　　Win32　　　　　　　　　　　　　　　　WinRT
　　┗━━━━━━━━━┛　 ┗━━━━━━━━━━━━┛
　　┏━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　　　　　　カーネル

66 ：

>>61
GetCursorPosならちゃんと動いたぞ。
同一プロセスでWin32APIを呼び出しているはずのMS以外のIMEが
不完全ながら動いたという話もあるし、
完全排除は未実装なんじゃないか？

67 ：

Win32上のレイヤーだったら、ARM版Win32の分岐が大変なことになるから
ARM版だけWinRTが独立してると予想してる

68 ：

すでにWin7でWin32 APIは仮想化しているから
WinRTはWin32サブシステムを経由せずに実装を直接コールしているんじゃないかな？
これなら２つの記事がどちらも間違っていないコトになるしｗ

69 ：

ARM版デスクトップアプリは機能限定Win32で作るの？

70 ：

Dependency Walkerで見る限りはWin32の関数を一部呼び出してるよ

71 ：

ARMはどうせタブレットしか出ないでしょ
デスクトップスタイルは要らないと思うんだがなあ
マイクロソフトさん考え直してよ
名前もwin8tabletとかにしちゃってさ

72 ：

タブレット側はスマートフォン側と共有で良かったのにな
戦略的には分かるが

73 ：

WinRTでデスクトップアプリ作れたら問題なかった
Win9ではウィンドウにメトロ表示出来るようになりましたとかウリにしそうだが

74 ：

それは無いんじゃないか
メトロ上にウィンドウが立ちあがったら
それこそ２ｃｈに画像貼られて馬鹿にされるレベルだと思うが

75 ：

タスクマネージャとかTopMostなウィンドウはMetroよりも前面に出てくるけどね
そうじゃなくて逆にデスクトップにウィンドウとしてMetroアプリが出てきたらってことだろうよ。

76 ：

>>69
Win32 APIをフル実装するよ　＞ARM版Windows 8
Win16やWin32sやWin64 APIのサポートはしないだろうけど

77 ：

アルファ版windows2000思い出すな…

78 ：

>>63
C/C++/C#/HTML/Javascriptができる俺はこの先も飯にありつけるな

79 ：

WinRTはWin32の次世代版でしょ
Win32でできることはWinRTでも当然できる
より簡潔に書け、さらに新しい機能を盛り込んだ内容となっている

80 ：

>>79
> Win32でできることはWinRTでも当然できる
本気でそう思ってんのかw

81 ：

まあ、少なくとも version 1状態の今のWinRTはできないことだらけだろ。
実装が間に合ってないものはいずれたされるだろうけども、セキュリティの都合であえてできなくしてることも多いだろうし。

82 ：

>>79
どちらかというと逆。

83 ：

>>1
悪評高いAPIって言う呼称やめたんだなｗ

84 ：

WinFSと名前似てるけどなんか関係あんの？

85 ：

…こういうコトかな。
仮想コンソール環境への第一歩。
・ 従来の開発者の場合
[ 従来の開発者 ] → [ WindowsAPI ] → [ ブリッジインターフェイス ] → [ 新型インターフェイス ] → [ OS ] → [ PCハードウェア ]
・ 新規開発者の場合
[ 新規開発者 ] →　……………………………………………………→ [ 新型インターフェイス ] → [ OS ] → [ PCハードウェア ]

86 ：

って言うコトで、あんまり小さい部分にこだわってると切り捨てられる可能性が出てくる。

87 ：

要するに、アーキテクチャを意識しないでアプリを走らせる様にする事？

88 ：

んで、仮想コンソール環境にはもう一つオマケがある。
[ 新型インターフェイス ] → | → [ インテル系CPU ] → | → [ OS ] → [ PCハードウェア ]
.　　　　　　　　　　　　　　　　 | → [ ARM系CPU ]──→.|
.　　　　　　　　　　　　　　　　 | → [ nVIDIA系CPU ]─→ |
新型インターフェイスの部分がCPUの違いを吸収すると言うコト。

89 ：

>>87
実際にはメーカー間の取引条件にしてあんまり変わらないかもな。

90 ：

普及させる気あんのかね、これ

91 ：

普及って言うより、旧世代の技術を吸収しながら再統合するにはこういう方法しかないだろうな。
重厚長大になりすぎてスリム化が必要なとき。

92 ：

最終的にAppleのエコシステムをパクりたいMSが、
全Metroアプリをマーケットプレイスで一元管理するための布石だからな

93 ：

ARMでWin32フル実装なら.NETも全部乗るってこと？

94 ：

これ見る限り.NETが終了に見えるんだけど
http://weekly.ascii.jp/elem/000/000/058/58015/20110920atrs001_cs1e1_1000x.png

95 ：

その図ってIE、Win32、.NETが並んでる時点でおかしいだろ

96 ：

>>93
全部載るよ。
というか再コンパイルなしでも動作する可能性が非常に高い.NETアプリを対応させない理由がない。
>>94
それを言うならWin32も終了じゃないか。

97 ：

IEはシェルなんだよ！ の頃を思い出したｗ

98 ：

>>94
え、名前が変わるくらいで今までとまったく同じように開発出来てるよ。

99 ：

Desktop appsのやっつけ感が半端ない

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
・　次のスレ
19: なぜC+のmain関数はどのクラスにも属していないのか (69)
20: くだすれPython(超初心者用) その12 (136)
21: C#, C♯, C＃相談室 Part69 (8)
22: ●●●●TCL/TKなら俺に聞け 2●●●● (845)