++C++; // 未確認飛行 C ブログ

http://ufcpp.net/

Archive for 9月 2011

フリーズしないアプリケーションの作り方

leave a comment »

@IT 向けに書いた記事が公開されました。

これもまた、裏ではいろいろと思うところあり。

タイミングよかった

いやー、題材が題材だけに、C# 5.0 とか .NET Framework 4.5、VS11 の正式版が出る頃に出そうかなーなどと思って書き貯めてあった文章だったり。

諸事情あって、実は意図せず今月完成させて出すことになって、今日の公開だったわけですが、意図せずいいタイミングになったなぁ。

BUILD での発表内容がもうほんと非同期処理だらけで。「WinRT では50ミリ秒以上かかる処理は非同期APIにします」とか、C# 5.0 の async/await 構文の再説明も多々入っていたり。

ついかっとなってやった。後悔なんてあるわけない。

まあ、非同期処理は一応、年々ホットな話題になってきているので、他にも記事はあるにはあります。

ただ、自分的に納得のいくものがないというか、「非同期処理なんてどうせレベル高い人向けのものだから、わかりやすい説明とかしないでいい」と言わんばかりのものだらけなのが納得いかず。難しいものを難しいまま書いてる記事とか見るとイラっとして、ついかっとなって自分で書いた。後悔はしていない。

なんというか、図が全然ないとか、いまいちきれいな分類がなされてないとか、そもそもなぜ必要か理由が抜けてるとか。そういうのを抜かない丁寧さは大事だと思うのに、ほんと、非同期処理がらみの記事できっちりしてるものを見たことがなく…

特に、C# 5.0 で入る async/await 構文なんかは、「今までレベル高い人だけが触っていたものを、もう少しレベル低めの人でも触れるようにしよう」というものなので、丁寧な説明を要するわけで。

かぶった

「他にも記事はある」というか、書いてる最中、100％かぶった記事が公開されて焦ったり…。しかも、MSDN マガジン。

テーマはおろか、Task クラスから始めて、Parallel クラス、C# 5.0、Dataflow ライブラリを説明と、構成まで完璧にかぶりましたとも。びっくりするレベルで。

まあ、でも、上記の理由（丁寧さの問題）があるので気にせずそのまま書くことに。

難しいことを簡単に

簡単なことを簡単に説明しても役に立たないだろ。難しいこと難しいまま書いても読んでもらえないよ。

などと、常日頃から思っております。難しいことを簡単に説明できなきゃいけない。

でも、テーマが「難しいこと」な時点で編集部の方々に敬遠されがちなんですよねぇ… さんざん言われていますとも、

  • 「えっ、LINQ までやるの？」
  • 「非同期をテーマにすると、予想以上に引きが弱い」

等々。

ページビューによって広告収入が決まるんで、編集さんとしては正しいご意見。難しいこと難しいまま書く人が多いんだもん、そりゃ PV 取れない。

しかし、レベル高い記事ほど PV 取れないとなると、ウェブからレベル高い記事が消えるよなぁと、常々懸念しております。

なんとしても、レベル高めの記事で PV 取らなきゃいけない。それには、ただ難しいこと書いていてはダメで、難しいことを簡単にかかなきゃいけない。

まあ、前の「データ処理」（要は LINQ）とか今回の「非同期」とかで、そこそこちゃんとブックマークついているようなので、ひとまずは安心。

（自分の場合は、自分自身が twitter とか ufcpp.net とかから宣伝かけれるんでチートといえばチート、フェアな数字でもないんですが。あと、対外的に「難しいことを簡単に」であることに加えて、まあ商売ですんで、制作的には「見合ったコスト」で書けなきゃ意味なく。この点はまだまだ改善の余地あり。）

（あと、「非同期」という言葉がよくわからなさすぎて良くないという説も。今回の記事も、タイトルからは非同期の文字を外すことに。それは多分、効果あったと思います。「フリーズしない」の方がやっぱりパッと見でイメージ伝わる。）

今のページビューと、これからと

開発者の収益性という面でみると、一番コスト・メリットのバランスがいいのは「平均的なレベルの1歩だけ先を行く」なんですよね。はっきり言って、最新技術追いすぎてもコスト高。

それもあって、ニュース性の高いものならともかく、僕が書くような教科書的色合いの濃い記事は、最新なもの使うより、今、現場で一番使われているであろう枯れたものが使われがちなんですよねぇ。

  • GUI のサンプルはやっぱり Windows フォームでしょうか？
  • Task クラスは .NET 4 に限られるので、Thread クラスを使った例を。
  • データベースは DataSet、取得側のダウンロード形式は CSV、サーバー間連携は FTP でファイル アップロード、etc.

ただ、でも、そういう記事は5年10年という期間で、人を育てるんですよね。

その5年・10年とみられるものに、今現在の最大多数であっても、減少トレンドがはっきり表れているものを書いていいのか。それでも、ページビューのために最大多数なレガシーを書くべきなのか。

とかあるので、自分の場合はサンプル コードとかには絶対最新のライブラリしか使わないわけですが。ただ、記事の収益性を軽んじては絶対いけないと思うので悩むんですよねぇ、最近。これも、「新しいことを、既存技術者にもわかりやすく」と「見合ったコストで」をちゃんと気にしていかないと。

Written by ufcpp

2011年9月30日 at 16:26

カテゴリー: .NET, コンピューターとインターネット, C#

Tagged with , ,

WinRT に関する誤解

with one comment

まあ、ます先に、ダウンロード リンク一覧を

で、やっぱいろいろと誤解されてるなぁ。

【×】 HTML5＋JavaScript で書かなきゃいけないのかな

今現在、.NET のスキルを持っている人が HTML5 で Metro アプリを書くメリットはほとんどないと思います。

逆に、今現在、HTML5 のスキルを持っている人なら、HTML5 で書く。

「両方できるけどしいて言うなら？」と聞かれたなら、まあ…

Anders Hejlsberg の Future directions for C# and Visual Basic で、Anders が、「JavaScript にあってうれしいものは、全部 C# にもあってうれしいよ」みたいなことを言った瞬間、会場が大喝采。

そして、WinRT は非同期 API だらけになります。処理に50ミリ秒以上かかる（可能性のある）ものは、基本的に非同期 API しか提供されないそうです。そのタイミングで、C# 5.0 の async が来る。.NET にだけ強いアドバンテージがあります。

【×】 Metro 版 IE でプラグインが使えないのは Adobe 排除だ

Adobe とマイクロソフト、密にやり取りして、Metro 版 AIR を作ってるんですって。

ブラウザー プラグインの時代は終わった（実際に終わるのはだいぶ先のことだと思いますが）ってことですかねぇ。

デスクトップ版の Silverlgiht も、どんどん Out of Browser 方面で強化されてますし。要は、デプロイが楽な Windows デスクトップ アプリ扱い。

ちなみに、デスクトップ版の IE は今までどおりです。ある日突然ブラウザー プラグインがなくなることはありえないです。

余談になりますけど、Youtube は普通に HTML5 video タグで動画が見えるみたいですねぇ。

【×】 C++/CLI かよ。WinRT は CLR か？

違うよ、全然違うよ。

WinRT はネイティブです。

.NET 側/ JavaScript 側から見て

.NET 側から見ると、普通に .NET のクラスに見えるネイティブです。

今までの P/Invoke とか、COM の ref Type.Missing 地獄がないのがいいところ。

なんかところどころ、規約ベースの暗黙的な型の置き換えやってますねぇ。WinRT 側だと IVector っていうインターフェイスが、.NET 側からは .NET 標準の IList に見えたり。

.NET 側で作ったクラスを C++ や JavaScript 側から使いたければ、いくつかのルール守れとか。ちなみに、ルールは例えば、

  • public なクラスは sealed にしろ
  • public なプロパティ、メソッドなどで使う型は WinRT 上で定義されているもの（と、それに暗黙的に変換できるもの）だけにしろ
  • 構造体使うなら、public なフィールドだけにしろ

等々。

C++/CX

C++ 側、パッと見、C++/CLI に見えるデモ コード、実は C++ Component Extension （C++/CX）っていうらしい。

仕組み的には、ビルド時に標準 C++ なコードを生成するような感じで、WinRT の呼び出しコストはほとんどない（単に仮想関数呼ぶだけというレベル）とか。

TOOL-690: Under the covers with C++ for Metro style apps を参照:

image

ほぼ C++/CLI だけど微妙に“似て非なる”感あるのが嫌すぎるものの、.NET のクラスを呼び出すようなコストがかからない点は素敵。

WPF とはなんだったのか

ずっと WPF やってきた人間からすると、WPF で苦しみもがいて頑張ってたことが、ようやく実を結びそうだなぁという感慨深い気持ちなわけですが。

知らない人から見たら、「また既存技術捨てて新しいもん作るのかよ」にしか見えないのかなぁ。残念。

Windows 8 でしか動かないんだったら WinRT なんて流行るわけないよ

そんないきなりの置き換えを狙ってるわけないし。

各社 HTML5 推しだけど、IE6 がいまだ数％現役なのと一緒で、「WinRT 推しだけど、延々と Win32 が残る」みたいなもんだと思えば。

つくづく、iPhone の良さは、Mac 低迷期に既存のしがらみ捨てて作り直されてるとこだなぁと思う。

Written by ufcpp

2011年9月17日 at 14:54

カテゴリー: .NET, C#

Tagged with ,

Windows 8、WinRT

with one comment

BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。

そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。

WinRT

開発者的に気になっていたのは、うわさのWinRT。

コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。

Metroアプリ vs 既存デスクトップ

開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。

  • Metro アプリ
    • タブレット向け、タッチUI
    • たぶん、ARM版で快適に動かそうと思ったらこっち
    • App Storeで配布できるのはこっちだけ
    • WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える）
    • 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相当のクラスいろいろ取り入れた感じ）
  • 既存デスクトップ
    • まんま、今まで通り
    • Win7タブレットを触ったことがある人なら、タッチに向かないことはご存じのとおり
    • OSのかなり低層に触れてない限り、XPとかのアプリもバイナリそのままで動くのではないかと
    • App Storeで配布できない（そもそもARM版で動くの？動くには動くみたいだけど、快適か？過去のアプリがどこまで互換性ある？）
    • .NET Framwork 4.5が出ました
      • WPFも強化されています

WinRTと.NET Core

さて、そもそもWinRTとは

  • Win32の置き換えで、COM（の焼き直し）なネイティブAPI
  • .NETから見ると、普通に単なる.NETのクラス ライブラリに見える（P/Invoke不要）
    • ちなみに、名前空間はWindowsから始まる
  • HTML5＋JavaScriptなMetroアプリからも呼べる（まあ、昔でいうActiveXみたいな状態）
  • クラスやメソッドの設計もかなりきれい。たとえばUI層なら、WPFを再設計した感じ
    • どのクラスがどの名前空間にあるかはかなり再整理されてる
    • たとえば、INotifyPropertyChangedはWindows.UI.Xaml.Data名前空間
  • UIはXAMLで記述
    • C++からもXAMLが使える
    • コピペで動くレベルでかなりSilverlightなXAML
  • サンドボックス化されてて、App Storeに登録するにあたって「このアプリはネットワークを使います」みたいなのが全部申告される

それで、ですよ。問題は、実は .NET Framework が2系統に分かれます。

  • .NET Core: WinRT、つまり、Metroアプリから使える .NET
    • パッと見た感じ、今現在 Portable Library で使える範囲（どこまで一緒かは要検証）
      • async/awaitは使える状態になってる
    • Metroアプリ ＝ .NET Core + WinRT なので、感覚的には非常に Silverlight for WP7 に近い
    • WinRTとの連携のために、メタデータの読み込み部分あたりに手が入ってるっぽい
  • .NET Framework 4.5: デスクトップ版。
    • 要するに、現在の .NET Framework の新バージョン
    • 仮想マシン的には .NET 4 のものと一緒。ライブラリの追加
      • async/awaitのための拡張（Task.GetAwaiterとか）
      • TPL Dataflow 追加
      • その他、WPF, WCF, WF なども色々更新あり

今の、Out-of-browser Silverlight VS WPF な構図とあまり変わらなかったり。

今から備えるMetroアプリ

WPFやSilverlightで、Portable Library使ってモデル書いてれば、かなり低コストで移行可能かと。

Windowsフォーム？てめぇはダメだ。（モデルに関してはそこまでダメでもないけども。）

Portable Libraryを使った開発については以下のスライド参照（Silverlightを囲む会で発表したもの）。

経験的には、コピペまで認めるなら、90％くらいコード共有可能。

これからのXAMLアプリ？

さて、ここからは推測まじり。

WPFとSilverlightとWinRTとWindows Phone 7と。9割方コピペで作れるXAMLファミリーがまた増えました。

まあ、世の中いきなり移行できるものなら幸せですよ。

WinRT は今のところ、Metroアプリ専用、つまり、ターゲットはタッチ操作UI。

（今の開発者プレビューで、「今のままだとマウスで使えた代物じゃねーよ」ってフィードバックが入りまくって、製品版までには、マウスとキーボードでもMetroアプリを快適に使えるようになる可能性も高いですが。）

据え置きPC

当然、現状のPCはマウスとキーボードが前提で、タッチ操作に最適化されたアプリだとかえって使いにくい。

なので、当面、引き続き普通にデスクトップ アプリ（WPF とか、OoB Silverlight とか）を書くことになると思います。そして、WPFとSilverlight、どっちがいいの？という悩みも消えません。両方に対して、引き続き改善が入っています。

とはいえ、Metroアプリがあることによって、タッチ操作な新入力デバイスが流行ってくれるかも。それに、Kinectにも期待。

タブレットPC

Atom搭載なタブレットは、たぶん、Metroアプリもデスクトップ アプリも両方動きます。

ただし、デスクトップ アプリの場合、右クリックがない前提でアプリを書かないと、タブレットでの利用はきつい。マウスでも使えて、タッチでも使えるぎりぎりの妥協案はリボンUIかもしれない（リボン化された Explorer を見ていて）。

ARM版は、ひょっとしたら、Metroオンリーで考えたほうがいいのかな？

タブレットPCからリモート デスクトップ接続

今後、増えていきそうな利用方法として、外出時にはノートPC持たず、タブレットのみ持ち歩き、そのタブレットからリモート デスクトップ接続して仕事ってのが考えられます。

サーバーOSであるWindows Server 8にすらMetro UIが搭載される理由。

こういう利用方法を考えると、「据え置きPCがターゲットだから、マウス前提でいいや」とは言いづらくなると思います。上記のとおり、マウス前提なんだけども、ぎりぎりタッチ操作できるUIを考えなきゃいけないという極めて面倒な事態に…

携帯電話

今回の発表を見て一番不透明（言及なし）なのはこれ。

Metroアプリは、Windows Phone 7アプリを参考に作られてるっぽい雰囲気なので、Windows 8上で現状のWindows Phone 7アプリを動かすのもそんなに苦ではなさそうな。

マイクロソフトの出している求人情報によれば、今、Windows Phone 8 と Windows 8のアプリ開発モデルの統合を研究中だそうで、Windows Phone 8が出るころには本当に統合されるかも。

ちなみに、上記の WinRT の説明のとおり、Windows Phone 7 のアプリから WinRT への移植はかなり簡単だと思います。

Windows 7以前

WinRT、Windows 8の上に載っている形になっているので、Windows 7にも拡張ランタイムとして載せれそうなもの。というか、うわさだと載せる？

Visual Studio 11

で、Visual Studio も開発者プレビューが出たわけですが。

11って数字は内部バージョン番号ですね。2005→8、2008→9、2010→10。なので、次は11。2011年中に出るって意味ではないです。時期はいまだ名言されていないので、2012とも限らず。まあ、大方の予想では2012年の春から夏にかけてだと思われていますが。

VS11単体ダウンロードもできるみたいですね。MSDNサブスクライバー向けにはすでにダウンロード提供されていて、一般にも数日中に公開予定。

Windows 7にもインストール可能です。ただし、この場合はMetroアプリの開発はできないみたいです。WinRTを触ってみたければ、Windows 8でないとダメっぽい。

普通に、次期バージョンのC#（async/await）を試してみたいだけとかならWindows 7へのインストールでいいと思います。

Written by ufcpp

2011年9月15日 at 18:30

カテゴリー: .NET, C#

Tagged with ,

C#でゲーム開発

leave a comment »

また思い切ったなぁ。

まあ、アメリカだと日本ほどXboxもXNAも不人気ではないというか、普通に任天堂/Sonyといい勝負ですしねぇ。

そういや、最近、Unity もすごい勢いで利用者伸びてるそうで。 GREE のせいか！まあ、タイミングが良かったんでしょうねぇ、日本展開してた時期に、ちょうどスマートフォンが伸びてたんで。

Unity、クロスプラットフォームでやってるとやっぱりプラットフォームごとの癖でかなり悩まされるんですけども、まあ、ないよりはだいぶマシですねぇ。

あとは、Windows Phone 7どうなるかなぁ。普通に初代Xboxよりハードウェア性能よく、Xboxに載ってるCPUよりは、WP7のARMの方がまだ.NETの仮想マシンと相性よく。それでXNAが動くんだから、普及さえしてくれればいいゲーム機だと思うんですけども。

 

コンシューマー機が支配的だったころ、やっぱ日本でゲーム作りって言ったらNintendo DSだったわけで、メモリ4MB環境でC言語で組み込み開発な感じでした。

それが、急激にスマートフォン市場が伸びたとはいえ、ここまで一気にC#みたいな高水準言語が伸びるとは、2年も前には想像しなかったですねぇ。

もちろん、実機の方じゃなくて、社内ツールなんかでは結構C#使われてたんですけどもね、日本のゲーム会社でも。

意外と知られてない？

そういや、Twitterで話題に出てたんですけど、意外と知られてないようで:

UnityはMono

UnityはMonoを使っているっての、意外と知られていないとか。

MonoはクロスプラットフォームなC#クローンです。

C#は当然まあ、Mono版C#なわけですけども、JavaScriptもいわば、JScript.NETみたいなものだそうで、Mono。

C#は標準化されてる

なんか、マイクロソフトだからというだけでクローズドなイメージ持たれるようですが、C#はいろんなとこで標準化されています。

というか、あれだけプロプライエタリであることが警戒されると、何やるにしてもまず仕様をオープンにして、標準化しないと誰も使ってくれないんで、2000年代に入ってからは逆にむちゃくちゃオープンな会社。

一方、Javaの方こそ、標準化一切してないんですよねぇ。そのくせ、いろんなベンダーがJava実装持ってる（元締めたる、旧SUN、現Oracleによる検証があるんだっけ？）のが恐ろしい限り。

Written by ufcpp

2011年9月15日 at 16:22

カテゴリー: C#

F#たん（魔法バージョン）

leave a comment »

余りにも久々過ぎて。

というか、C#たん、C++たん、VBたんはすでに魔法少女（あくまで少女と言い張る所存）版があるのに、F#たんだけまだだったなぁと。

設定とかラフ絵はあったんですよ、ずっと。ええ。

F#たん魔法版

作画: Paese

  • いわゆるシステム言語は重火器、LL系は近接格闘武器なイメージだったり。
  • で、ネイティブは古風な杖なのに対して、.NET系は近代兵器。
  • そしてなんか、F#はインタラクティブ シェル持ってたり、LL的な雰囲気多少あるので、色々中間辺りのイメージになってビーム サーベルに。
    • Iron○○系の言語キャラも作るなら、超振動ナイフとかパイルバンカーとかリボルバーナックルとか中二っぽいのにしたい。
  • 最初のイメージは、きゃしゃな感じの女の子が長刀持って構えてるような。
    • 多分わかりやすく言うと魂魄妖夢。
    • 自分のイメージではアルカナハートの朱鷺宮神依
  • そして、基本的にセーラームーン張りに「元の服の延長」な魔法服にしてあるので、セーラー服＆ニーソっぽい和風鎧。

Written by ufcpp

2011年9月11日 at 17:20

カテゴリー: C#たん

BUILD での注目点

with one comment

BUILD 直前ですね。

ということで、先週あたり、色々と「BUILD での注目キーワード」みたいなまとめ記事が色々出たわけですが。

これらを荒く日本語でまとめてみようかと。

（そういや、超前倒しで IS12T が発売されてるものの、本来は Windows Phone 7.5 も BUILD 近辺でリリースのはずよなぁ。）

Windows 8: 今までにわかっていること

ARM-based チップセットのサポート

かなり初期から言われていたわけですが、ARM サポートが入ります。あと、システム オン チップのサポートが入ります。つまるところ、小型軽量タブレット、車載コンピューター、テレビなどへの組み込みが期待されます。

新しい“Immersive” Metro スタイル UI

スタート スクリーンが Metro スタイル（Windows Phone 7 と同系統の、タイルを基調とした UI）になるそうで。タブレットなどのタッチが基本のデバイス向け。

既存のデスクトップと両方が提供されていて、既存アプリは既存デスクトップ上で動くそうです。「どうして2重に UI を用意するのか？」というと、タブレットからのリモート デスクトップ接続とかを想定しているそうで。

新しい UI の方を “Immersive” と呼ぶそうです。新しい Windows API にも Windwos.UI.Immersive っていう名前空間があるようです。単語の意味的には「没入型」。そのまま横文字でイマーシブって言う方がいいのかな？

既存デスクトップでも、スタート メニューとかのボタンのデザインは Metro 的なフラットなデザインになる模様。角丸、立体、半透明が飽きられて、一周回ってシンプルに。

Internet Explorer 10

標準で10。

ブラウザー自体は 9 の延長で、HTML 5 対応の強化が主なはず。

それよりは、“Immersive” スタート スクリーンから HTML5 ページに直行（見た目上、ネイティブ アプリと HTML5 アプリに区別ない）できるとか、HTML5 側から Windows API 触りやすくしてあるとか、HTML5 が Windows 8 アプリ開発手段の一部に組み込まれるという辺りが注目点。

Windows Explorer がリボン UI に

リボンには賛否両論あるものの、初心者向けにはやっぱり「見える位置にボタンがないといけない」ようで。MS Office も、なんだかんだ言ってそれなりに 2007、2010 に入れ替わっていますし。

ただ、ディスプレイが横長化してる今、作業領域の縦幅が縮まるのがうっとおしいという問題は認識しているようで、リボン UI を付ける代わりに、ヘッダー・フッターの類を横に移して、作業領域の縦幅は増やしたそうです。

ファイル コピー/移動の速度、UI 改善

非同期に、いくつものファイルを同時に、それも1個10分以上かかるようなコピーをする人、思った以上に多いそうで。

複数のコピーを行った時のパフォーマンスが改善したのと、コピー中の進捗表示 UI が見やすくなりました。

標準で VHD と ISO イメージのマウントに対応

API 的には Windows 7 にも機能は付いているようですが。仮想ドライブ アプリ販売者への配慮か、Explorer 上でマウントする機能は付けておらず。

MSDN サブスクリプションとかで、アプリを ISO イメージで配るくせに。

Windows 8 ではついに標準でマウント可能に。

Hypter-V 搭載

メモリ 4GB 必要だそうですが（最近の機種だと当たり前のように積んでますが）、ついにクライアント OS でも Hyper-V が利用可能に。

32ビット OS も64ビット OS もインストール化。仮想マシンに対する割り当てメモリ量を動的に変更出来たり。仮想マシンが直接物理マシンのリソースにアクセスできるので高速。メモリ 4GB 環境でも、2・3個の仮想マシンは立ち上げ可能。

AppX パッケージ

Windows Phone 7 の xap ファイルのような、アプリのパッケージ化・配布手段を提供。

Windows Phone 7 の xap （Silverlight か XNA、いずれにせよ、.NET アプリ）と違って、ネイティブ アプリや HTML 5 ベースのアプリもパッケージ化可能。

【真偽不明】Windows Phone 7 アプリはそのまま Windows 8 で動くというような話もあり。

【リーク情報】Windows App Store

多分、そのための AppX パッケージ。

まあ、Windows Phone 7 でマーケットプレースやってるわけで（あれ自体も、Xbox Live マーケットプレースの延長）。

物理メディア通してパッケージ売りする時代でもないですしねぇ。

【リーク情報】 “Protogon” ファイル システム

データベース的な、トランザクション、行・テーブルなどの概念を NTFS 上で行うようなファイル システムっぽい。

一度お蔵入りした WinFS（Vista のとき、昔同じようなことしようとしてて、結局辞めた）の再来。WinFS は NTFS を置き換える勢いで作ろうとしてて、パフォーマンス的な問題から失敗してたけども…

【リーク情報】 Windows Live Online ID と、クラウドを使った設定の同期

OS のユーザー設定の類をクラウド使って複数マシンで同期可能に。

Windows Phone 7 でもそうですけど、Window Live ID を Windows 8 に紐づけて使うことになりそう。

まあ、このご時世、当たり前といえば当たり前。

【リーク情報】 History Vault バックアップ

OS の状態を、任意の時点でバックアップを取って、その状態に復帰できるみたい。

色々とあったバックアップの仕組みを統合、使いやすい UI 付けたもの。

他

  • USB 3.0 標準サポート
  • Dolby サラウンドに OS レベルで対応するのやめる（Dolby が OEM メーカーに直接提供という形態に変更）
  • Media Center 版あり。ただし、初期リリース時のラインナップにはなく、後から。
  • Xbox LIVE 搭載
  • PowerShell 3.0 搭載
  • 【リーク情報】マルチ モニター対応の改善（タスク バーとかが2画面に渡れる）
  • 【うわさ話】 “Chatter” （標準搭載のビデオ チャット機能？）
  • 【リーク情報】システム リセット（工場出荷状態に戻す機能）

【この記事の後で出た公式情報】ブート高速化

「電源オフ」を選んでも、OS カーネルの使ってるメモリをハイバネーションすることで、3～7割起動が高速になるとか。

OS の使ってるメモリだけなので、アプリまで含んだハイバネーションよりはずいぶんデータ量が少ないし、ハイバネーションなので通電切っても平気。

従来の完全再起動もオプションで選択可能。

BUILD で外せない 10 のキーワード

（いくつかは上記と被るものの）

AppX

アプリのパッケージ化・配布の新手法。

Windows Phone 7 のパッケージの延長にあるもので、理論上は Windows Phone 7 のアプリが Windows 8 で動いてもおかしくない。（けど、実際にどっちでも動くアプリができるのは Windows Phone 8 世代でかも？）

で、Windows 8 にも Windows App Store が付くわけですが、こちらも Windows Phone 7 のマーケットプレースの延長っぽい。

Jupiter

新 UI API。

XAML ベース、つまるところ、WPF 風。WPF や Silverlight との違いは

  • ネイティブ
  • 基本中の基本となる層だけ

ネイティブ アプリでも、WPF 的な、GPU を使った描画や、いろんなメディアを同じモデルで利用するのができるように。

詳細分からないものの、WPF や Silverlight はこれの上に載ることになる？

UI 以外にも、Windows API 自体がモダンな構造で書き直されてるみたいで、windows.ui.directui とかの名前空間が付いてたりするみたい。WinMD っていう型システム／メタデータ（COM の再設計？）を持っているようで、.NET との連携も強化（というか、.NET 側からは普通に .NET の型に見える仕組み）付き。

MinWin

Windows 8 の、最小限の機能だけに絞ったコア部分。Hyper-V 向け？

全部で 20MB 程度に収まるとか。

Modern

（上記の “Immersive” のことっぽい）

Metro 風、タイル ベースの UI。AppX パッケージ化が必須っぽい。

Protogon

データベース的な、トランザクション、カーソル、行・テーブルとかのコンセプトを持つファイル システム。

RedHawk

「マネージ コードの新しい実行環境」「軽量で、オーバーヘッドを懸念する開発者にアピール」とのことらしいけども、具体的な記述なし。

低フットプリント機器向けの別系統 CLR？ てか、Windows Phone 7 に積んでる奴（.NET Compact Framework の延長）を Windows 8 の方にも載せる（つまるところ、Windows Phone 7 アプリが動く）だけだったりして？

それとも、Client Profile よりもさらに絞った最小セットの CLR？ 「今、CLR が GUI べったりすぎるせいで、Windows Server Core で PowerShell が使えず困ってる、GUI 部分を分離したい」とかいう話もあったはずで。

Silverlight

まあ、先週、5 の RC 版が出たわけですが。

気になるところは、“Immersive” アプリを Silverlight で書けるのかとか、Windows Phone 7 と Windows 8 の両方で動くアプリは書けるのかとか。

Trident

Internet Explorer 10 の新描画エンジン。

Tweet@rama

標準で twitter クライアントが入ってるっぽい？

（単なるデモ アプリだった可能性あり）

UEFI

Unified Extensible Firmware Interface。PC BIOS ファームウェアの置き換えとなる仕組み。

BUILD: 開発者的な見どころ

Visual Studio 2012

（まだ、2012っていう具体的な年号付けてる発表皆無のはずだけど）

公式に言われていることだと、「アプリケーション ライフサイクル管理（ALM）機能を強化します」。とはいえ、詳細はまだ何もなく、BUILD 待ち状態。

あと、グラフィック開発者向けの機能強化が盛り込まれるとのこと。（Gamefest での発表に基づいてるっぽいけど、なんのことだろ？C++ に GPU 利用するための拡張が入ることかな？これだと、GPGPU にも使えるんで、別にグラフィック開発に限らないのだけども。）

Visual C++ Next

ここ数年、.NET の陰に隠れて不遇だった C++ が少し復権する予定。

C++ 12（0x 改め、12）対応とか、GPU 対応拡張とか、ちゃんと C++/CLI で IntelliSense 聞いたりとか、エディターが C#/VB と比べるとかなり低機能だったのがずいぶんマシになったりとか。

Visual Studio LightSwitch

製品化したてほやほやのこの製品ですが。

Windows 8 （や、その後）にどう対応していくかとかの話題出るかな？ LightSwitch は Silverlight を使ってるんで、Silverlight の先行きにも関わるか。

Expression

HTML5 への対応を進めているわけですが、Expression の方も HTML5 への舵きりするのかな？

それか、Web 開発は WebMatrix とかにお任せ？

ASP.NET

まあ、ASP.NET がらみは、情報も頻繁に公開されてるし、NuGet で小出しに最新版提供しているものの。

最近の話題だと、Web Forms のデータ バインディングに型指定入れることで IntelliSense が効くようにするとか。

この辺りの話題、BUILD でも話すかな？

.NET 4.5

リーク情報（リークした Windows 8 OS イメージの解析）によれば、Windows 8 に搭載される .NET Framework のバージョンは 4.5 のようです。

聞き及んでるリーク情報によれば、Task.GetAwaiter とかは入っているようなので、C# 5.0 も Windows 8 標準搭載か。あと、System.Threading.Tasks.Dataflow も入っているようで。

クラウド開発

まあ、Azure がらみのあの更新ペースを見ていればもうねぇ。BUILD でも確実に色々と出てきそうな。

Scott Guthrie が Azure チームに移ったというのもあり。

Written by ufcpp

2011年9月10日 at 20:36

カテゴリー: .NET, C#

Tagged with ,