>>799
あのレベルの使い勝手をローカルアプリで押し付けられたらかなり迷惑だな

WinRT:Win32のオブジェクト指向による代替
http://www.infoq.com/jp/news/2011/09/WinRT-API

>>802
>全Metroアプリケーションはデジタルサインされなければならない。

ごめ、送信しちゃった
>>803はstore経由じゃないと配布できないって事かな？

Storeに載せる場合ってことでは？

Microsoft、Silverlightなどすべてのプラグインを捨てる
http://www.infoq.com/jp/news/2011/09/Metro-Plug-ins

>“ディスクトップ”モードではFlashもSilverlightも今まで通り問題なく使えるという点には注目しておきたい。
>また、ディスクトップモードはFirefoxやSafari、Chromeのような他のブラウザに切り替えることもできる。
デスクトップだよねｗ

MSはまたこけるのか・・・

> Metroスタイルのブラウザはスクロールバーやウィンドウ枠などの基本的な要素を必要としない、
> フルスクリーンで利用するInternet Explorerの実装であり、Windows 8ではほとんどの人が利用する。

ウソだろ。

これって要するにブラウザ独占したいってこと？

>>809
Windows 8はデスクトップPCじゃ使わないって事なんだろ

>>810
Metroスタイルのブラウザ、エンジンはChromeとか出来るでしょ。

別にflash欲しけりゃデスクトップ用のIE10実行するればいいだけじゃん

>>812
Metro内部で既存のプログラム（特に画面周り）は動作しないので、
ChromeをWinRTで作り直さない限り無理。

>>809
それは、Phone7とかでもあったパノラマビューだからだよ。
枠って概念がなくなって横にはみ出てもOKって話。

>>811
デスクトップはもちろん、タブレットやPhoneでも同じOS使うんだろ。

というかSilverlightは終わりだよ。
ガスリーが責任者外されてAzureの責任者になった時点で気づけよ。

WPFの立場はどうなるんだよ

>>816
もっと終わってるだろ。
そもそもbuild windowsのカンファレンスとかで出されてる図にしろWPFなんて出て来てないだろ。
かろうじてSLが出てきてる程度だし。

それに非同期通信系のセッションも多い。
WinRTに標準でReactiveExtensionより高機能な非同期通信ライブラリが入るしな。
WPFだったらそもそも非同期書かなくてもいいんだからさ。

>>816
デスクトップアプリケーション用。

Metro以外は糞！
って状況にならない限り生き残る。

WPF -> デスクトップアプリ用（にMSはしたい）
WinForms -> オワコン（にMSはしたい）
Silverlight -> ブラウザ実行環境（プラグイン）としてのSLはオワコン。WP7とWinRT用のコーディングモデルとして発展する

と、ここまで考えたのだが、WinRTでつくあったアプリってWin8とのデスクトップモードでも動くの？

WPFはとうとう一つもアプリケーションが登場することなく
metroにとって代わられるのか

>>820
VisualStudio2010(´･ω･`)

10年くらい前のCPU（Athlon-1GHｚ）を使っております。
このXPマシンにSilverLightﾀｿをインストールしようとするとインストールの段階で
弾かれてしまうのですがこれをなんとか穏便にインストールする方法はないでしょうか？

>>821
2011もそうなのかな
http://www.infoq.com/jp/news/2011/09/VS-11

XAML+C#で作れればいいのであって、WPFやSilverlightの名前には拘らないよ。

vs2010, 2012やoffice2007, 2010, 2012もwpfで作っているのに終わらないよ。
xamlとc#をこれから主流にするわけだから、slやwpfは安泰だよ。

wpfは難しいから技術者が追いついていない。

Officeは.NETじゃないぞ(使ってはいるらしいが)
Officeなんてその機能に比べればUIを何で作るかなんて瑣末なことなんだから
.NET使うのはともかくわざわざWPFなんて高レベルなもの使う理由がない
VSがWPFなのはそりゃユーザーが.NET開発者なんだから.NETで拡張しやすくしないとな

>>811
マウスとキーボード付いたマシンでもMetro使うのか？
今までのデスクトップじゃないの？

Metroは普及するだろうな、タッチベースの新アプリとWindows Phoneの世界で
Metro上ではwin32も.Netも使えないようだし.Netのときのような中途半端なランタイム扱いではないネイティブのものである
ある意味Longhornでとん挫したWinFX構想が予期せぬ形で実現したとも言える
Silverlight使いにとっては類似技術のMetroでよりメジャーな舞台に出られるわけでSilverlightを選択したことは良い選択だったと言えるだろう

Silverlightも似たようなもんだが、Windows名前空間以下の結構粒度の大きいAPIがすべて
ネイティブで実装されてる時点でかなり残念な形だと思うよ
結局WPFというほとんどマネージコードで作られた挑戦的なものが
Silvelrightのようなマネージコード率WinForms以下のやり方に負けたってこと

.NETからP/Invokeなしで使えるっていってもCOMでしょ?
さすがに今のCOMそのままじゃないだろうけど
MSは.NETの立ち位置をC++と同等に引き上げると言ってるけど、
どっちかというとC++に.NETと同等の使いやすいAPIを提供したってことだよね

http://www.microsoft.com/taiwan/silverlight/desktop_d_1440x900.htm

はい。終了のお知らせが出ちゃいましたっと。

http://www.infoq.com/jp/news/2011/09/Metro-Plug-ins

>>832
悲観するほどのことかね
WinRT向けの開発をする際にsilverlightやWPFのノウハウが
まったく使えないのならそういう表現もいいかもしれないが
実際のところは使えるんだし

>>828
「メジャーな舞台に出られる」ってのはほんとにそう思うわ。

SilverlightのOOBでMetro互換のAPIをサポートしてほしい

Silverlightアプリで少数行書き換えるだけでMetroアプリとして動くってことはWinRTと.NETではほとんどの名前空間とかクラスとかメソッドとか同じってことかの？
でもしたらガベコレとかどうなんのとか、よくわかんね。
WinRTも.NETとガベコレとか同じようなことするんだけどManagedでないってことか？
開発生産性のいい方法として残るならいいけどHTML5+JSでアプリ作ってくれとか簡便な(´・ω・｀)

>>836
Windows上でHTML5+JSは無視していいってのが今回の発表で良かったとこだね

>>836
ただのCOMだよ
リソース管理は各言語の処理系任せ
.netはCLRに細工するんだろ

CLR 側に入ってる小細工、メタデータの読み出し部分だけみたいよ。
前よりCOMアクセスがシンプルになってるだけ。

WinRT 内はネイティブで、その中ではメモリ管理は参照カウントみたい。

Windows 8が普及するまでは業務アプリはSLがベスト、
Macユーザーも考慮する場合はそれ以降もSL。
SLの戦線離脱は当分先ではないかな？

つーか、7の後継である限りはWindows8はそれなりには売れるだろうけど、
これ搭載したタブレットが成功するかどうかと、それ以外のノートPCなどの
比較的タッチ操作向きの分野で、新インターフェースが受け入れられるか
どうかが問題なんだけどな。

C++コンポーネント拡張：新しいCOM
http://www.infoq.com/jp/news/2011/09/C-Component-Extensions

>>788, >>779 みたかんじ、
WPF/SL/C#+XAML(@WinRT)は、
表示プラットフォームが違うだけ。

Desktop App(Win7後方互換)
Browser
WindowsPhone
MetroStyleApp(Win8)

数千円のWin8アップグレードかWin7でMetroが動かなければ、
いきなりデスクトップ市場で売れる訳ないし、
アプリの売り手からしても、小規模のユーティリティアプリで、広告付きか数百円の市場しかない。

iOS5とOSX Lionと同じで、
タブレットPCとスマホ取りに行ったらこうなったんだろう。

さしあたって現実的に見えてるのが iOS5 やら Honeycomb の競合ってだけで、
MS の場合は Kinect とか NUI とかの方向の進化もありうるからなぁ。

それこそタブレット市場以上の冒険だけど、
そっち方面が実を結べば、普通にデスクトップPCでもメトロが有効かもしれない。

【SCE】PlayStation Suite SDKのプログラミング言語にC#採用【PSVita】
http://jin115.com/archives/51811583.html

>>843　3段目は何が言いたいのかわからん。マーケットが小さいということを言いたいのはわかるが。

（・３・）エェー!?
Some minor departures in WinRT versus BCL support: For example, WinRT IInspectables don't have .Equals, .Hashcode, .ToString, operator overloads etc. unlike System.Object;
Also WinRT does not support struct member functions so we've created some *Helper types to help app authors port existing code.

>>847
その書き方だと、次のβまでには対応しそうじゃない？

>>847
それ書いてる通りWinRTの話。
当たり前だけどWinRTとは別に.netのライブラリの体系があって、
それはだいたいsilverlight相当。
WinRTを呼び出すときはうまいことマッピングしてくれて、
IIterableがIEnumerableに化けたりする。

http://www.microsoft.com/taiwan/silverlight/desktop_e_1920x1080.htm