| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 |
面白いかもしれない。MS のファイル共有は Messenger はまだいいけど FolderShare は微妙だし、また一つファイル共有? と思っていたがそういうわけではなさそうだ。
An early look at Live Mesh for Developers の「Watch demo now」をクリックするとデモが見られる。Channel9 の Ori Amiga ビデオでは画面がよく見えなかったが、こちらの方が分かりやすい。ファイル共有、デスクトップ共有などのアプリケーションはあくまで実装の一つで、Live Mesh はプラットフォームだ、と Live Mesh の blog で言っているので、それなら、ともう少し見てみる気になった。
Silverlight が Flash に対する回答だとすれば、Live Mesh が AIR に対する回答になるのかもしれない。
WPF の ListBox は非常に強力で、ListBoxをカスタマイズして都道府県の地図を選択するUIを作成する なんてことができてしまったりする。配列データを表示する際には ListBox を使うと、データの追加処理や選択処理を全部やってくれるので便利だけど、まだ慣れないのか後で気がつくことが多い。
今回は Marquee。テキストの配列を受け取って、順次右から左にスクロールして表示する。最初 Canvas で考えていたけど、ListBox の親クラスである ItemsControl を使ってやる話が Web でちらほらとあり、そちらで挑戦。
WPF 流に慣れるまでに少しかかるけど、慣れれば便利。
WPF/XPS の縦書き Metrics を検証 から、キャノンの FontGallery など他数種のフォントを試して、TrueType および TrueType 出身の OpenType はだいじょうぶそうなことが確認できました。
とすると、Morisawa やおそらく他の Type 1 出身の OpenType が駄目なのは単なるバグではないかと。
互換性問題上厄介なバグを残してしまいましたが、WPF もどこかではもっときちんと縦書きをやる、という話もあるようだし、少なくともそこでは直るんでしょう。
WPF 縦書き対応 と Font BlackBox の計算 とを組み合わせてみる。
MS Gothic
Meiryo
イワタ楷書
BlackBox が微妙に下にずれているのはご愛敬。
IsSideways なんて、縦書きとは無関係のプロパティだと主張しているようにも見えるが、縦書き用のテーブルを見て Baseline をきちんと中央に合わせているのが分かる。GSUB を見て自分で GlyphIndex を置き換えてやれば、「ー」や「。」も正しく表示される。
しかし。
Baseline が合っていない。TrueType 系 OpenType はだいじょうぶだけど、Type 1 系 OpenType は駄目、ということかもしれない。
OpenType Specifications に日本語フォントの作り方が書いていないのでフォントのつくりに差が出てしまったか、WPF が Type 1 系に十分対応していないか、あるいはその両方の組み合わせか。
Word はしかしこのフォントでも正しく縦書きできる。それを XPS で保存しても正しく見える――と思ったら、XPS の中は Glyphs ではなく PNG 画像だった。WPF/XPS では対応しきれないフォントだとどこかで判断して、回避しているようだ。
フォントによって BlackBox の縦位置が正しく取れない問題 は、計算方法が違っていたらしい。だいたいにおいて高さが正しい BlackBox を取れていたのだから、TopSideBearings と BottomSideBearings を疑ったのは間違いだった。
DistancesFromHorizontalBaselineToBlackBoxBottom を使って BlackBox の下座標を取ることで、以前は BlackBox が上にずれていた英文フォントや一部の日本語フォントも正しくなりました。
あとは Vertical Origin が取れればそれなりの縦書きを実装できそうなのだが、これが見つからない。
IsSideways で正常に縦書き表示できるフォントの TopSideBearings と BottomSideBearings は正常に取得できる。
こうなってしまうフォントもある。このフォントでは IsSideways だけで縦書き仕様としてもうまく行かない。
GSUB の処理をアプリで回避したけど、縦書き用 GPOS が処理できていないのか。あるいはフォント側の問題で、GSUB/GPOS ではなくて cmap を使ってレンダリングしてやらなければいけないのか。
Meiryo は縦書きできるけど、TopSideBearings と BottomSideBearings が怪しい。
FamilyTypeface.DeviceFontCharacterMetrics から Unicode code point を使って CharacterMetrics が取れる、と書いてあり、ここには vertical origin はないものの、他の縦書きに必要な情報は取れそう、と思ったものの。
嘘です。FamilyTypeface.DeviceFontCharacterMetrics.Count は常に 0 のようです。他にも困っている人がいるみたい ですが。
WPF の縦書き、さらに続く でそこそこ表示できるようにはなったものの。
フォントによってはだめな場合がある、ということは、縦書きメトリックスの処理が XPS にきちんと入ってない、ということなんでしょうね。
横書きや BiDi では XPS が TrueType/OpenType のメトリックスを読んである程度までは並べてくれて、そこから上はアプリが処理、とわかれているのだから、本来であれば 中さんのおっしゃるよう に、XPS でももうちょっとサポートしてほしいのは確かです。
横書きでも、Word が XPS のレイアウトエンジンをそのまま使わずに、文字を分割してレイアウト位置を微調整することがある。どこまでが XPS で、どこまでがアプリケーションあるいはフレームワーク、という線引きはいつでも難しいけれど、横書きと縦書きで線引きの場所が違う、というのは、力の入れ具合の不足感を感じてしまいます。
縦書きって、BiDi のようにその国の人なら毎日必ず使うものではないので、という優先度なんでしょうが、やっぱりそれ抜きでは日本語組版を語れないかと。
句読点がこんな形の縦書き画面ショット だけ掲載しても後味が悪いので、さらに実証実験を続けます。
まず Word でメイリオを指定して、縦書きにして XPS で保存します。その中を覗くと、メイリオの句点「。」の縦書き用グリフインデックスが 9236 であることが分かります。
あとは、TextBox の Visual Tree を解析して GlyphRun を作る時に、「。」の場所だけ GlyphIndices を置き換えてやります。結果がこちら⇒
さて。できることは分かりました。句点の位置が少しずれただけだけど、先の画面での不思議な落ち着かなさがなくなりました。
あとは、フォントから GSUB を読み取って、vert か vrt2 のテーブルに従って GlyphIndices を置き換えてやれば、すごく基本的な縦書きの表示まではできそうです。
問題は、これらのテーブルを読み取るための API が WPF にはないので、自作するか、Uniscribe を触ってみるか、というあたりで迷い中。
気がつけば、Microsoft Typography Specifications にはこれだけの言語のフォントの作り方がある のに、その中に日本語の縦書きについては記述がないですね。WPF 1.0 で縦書きを忘れられたのはこの辺から来ているのでは、という気もします。
WPF の縦書きの続き にさらに続く。XamlPad で覗いてみる。
TextBoxView が TextFormatter.FormatLine を呼んで、帰ってきた結果の TextLine が GlyphRun を生成しているらしい。
LineServices は MurrayS が言っているように OS などに依存しない構造 なので、LineServices の callback を実装している TextLine あたりが Uniscribe で言うところの "Shaping" をしているのだろう。
WPF でまともに縦書きを実装するのがとても大変、というのはよくわかった。Wrapper をかませて、ちょいちょい、と遊ぶレベルでは実現できそうにない。
幸い、日本語の縦書き Shaping は、ほかの言語と違ってレイアウトに変更が出ない。固定幅フォントを使っている限り、縦書き用のグリフに置換しても文字の送りが変わらないからだ。
Visual Tree を VisualTreeHelper で覗いて、同じ構造を作りつつ、グリフ置換をすれば、なんとか縦に表示することはできそう。
とはいえ、グリフ置換をするためのテーブルを取得する API は WPF にはない。作るか、Uniscribe を使うか、というあたりで、これもなかなか難儀。まだ迷いは続く。
BiDi の Shaping をしっかりやったものを WPF 1.0 (.NET 3.0) にきちんと入れてきたんだから、日本の縦書きの Shaping なんて大したことないと思うですけどね。
WPFの縦書きの続き。
Word の XPS 出力はきちんと縦書きになっていた。XPS には縦書き、というか、縦書き用にグリフを反時計回りに90度回転する、という IsSideways がある。これで文字を回転しておいて、行を逆に時計回りに90度回転すれば、縦書きになるでしょ、という仕様。
しかし日本語には、「、」や「ー」などのように縦書きになると位置や形が変わる文字がある。XPS の IsSideways はそれは解釈してくれない模様。アプリがやれ、という話らしい。FontVariants に Ruby があったり、EastAsianLanguage に異体字があったりするので、どちらかに入りそうなものだが、これがない。ルビ専用グリフをやる前に縦書き用グリフじゃないの、と思うが、ないものはない。
だから、XPS の仕様書で句読点の位置がおかしいのにはそれなりに理にかなっていて、XPS 1.0 ではそこまで自動では面倒見ませんよ、という話らしい。Glyphs には Unicode 文字列を指定するモードとグリフインデックスを指定するモードがあるので、Unicode 文字列じゃなくて縦書き用のグリフを指定してくれれば表示できます、というお話。Unicode 文字列で動いているアプリを縦書き対応するには、グリフインデックスを取れ、というお話。Word は元々自前でフォントを読み込んでグリフインデックスで指定しているから、縦書きできる。横書きは Unicode 文字列でも動くようになっているのになぁ。
で、フォント周りのクラスを覗くと、通常の文字コードからグリフインデックスへの変換はサポートされているのだが、縦書き用グリフインデックスが取れそうにない。ぎょぎょ。フォントファイルを直接読め、という話か。フォント周りのクラスは、FontFamily と Typeface が主だったクラスのようだが、他に FamilyTypeface, GlyphTypeface というのがある。この辺の関連はいまいち不明。でもどこにも見当たらない。
フォントまわりを一旦あきらめて少し上のレベルを探ると、WPF の組版関連は結構なボリュームがあり、またレイヤーに分かれている。レイヤー毎に同じようなクラス名があるのでややこしい。
最終的にどちらも TextFormatter に落ち着くらしい。これが TextRun とか TextSpan とかの組み合わせで組版結果を表現するようだ。ここから TextLine.Draw で DrawingContext へ。だから縦書きの出力をしたいなら、まず TextFormatter に手を入れることになりそうだが、この辺は abstract と internal 実装でしっかりガード。でも中で TextBox と RichTextBox は実装が分かれていて、RichTextBox は LineServices/PTS を使っているらしい。だったらその中は縦書きをサポートしていそうなものだが、上と下に繋がっていない、ということらしい。
さて。とても困った、ということが分かった。縦書きだけやりたいなら WPF を諦めて GDI に戻る。でもやりたいのは OpenType を使った縦書き。GDI/GDI+ ベースの Windows Forms では OpenType を上手に扱えない。GDI/GDI+ ではプロの印刷品質も出せない。
Mac + PostScript/PDF を使えよ、というお話？
まさかないとは思いませんでした。どうした、がんばれ、日本のMS。
XPS にもないとなると大変だなぁ、と思ったけど、XPS にはある模様。でもこのサンプル画像はひどいね。できてないじゃんと思わせる。
Word で縦書して XPS で保存したらできた。ので、とりあえず XPS はだいじょうぶなのか。
GlyphRun.IsSideways プロパティは WPF で定義されているので、ここまで自分で落としてやれば描画できるらしい。ほんとかな。Word の出力した XPS を解析してみるか。
前のエントリーで紹介した Adam Nathan の Windows Presentation Foundation: Unleashed
発売は US で 4 月、と言うのでまだ先のようだが、.NET 3.0 WPF の Software Architect。.NET 2.0 では Lead Developer として ASP.NET Web Forms, Windows Forms, CodeDOM, RegularExpression などを手がけていたらしい。Forewords (序文) by Don Box and Chris Sells というのは箔付け? という感じだが、単なる仲良しなのだろう。
Channel9 を改めた探したら古いビデオしか見つからなかったが、Architect らしい話が見られる。Visual Composition Tree だけを別のマシンに持ってくる Terminal Server の話などは、Longhorn Server を楽しみにさせてくれる。本が届くのが楽しみだ。
Windows Vista の歌が聞きたければ、新しいビデオ Don Box and Chris Anderson というのもあるが、これは勉強にはならない :-)
WPF、どこかでやらなきゃと思いつつ、予約していた Windows Presentation Foundation: Unleashed
実際に取り掛かってみると、予想通りそれなりの苦戦。予想以上ではなかったので、よしとする。細かい問題は以後書いていくとして、まずはおおざっぱな感触を書いておこう。
それなりに不足もあるが、V1 製品としてはよくできていると思う。Orcas の .NET 3.5 でもう少しスマートになることを期待しつつ、今後は徐々に開発の比重を WPF に移していくつもりである。
削除の確認画面でのデフォルトボタンはどちらでしょう?
少し前に SONY の HDD レコーダーを使っていて、[キャンセル] がデフォルトになっていたので非常にうっとおしかった。多くの場合において、その機種は [キャンセル] をデフォルトにする。
設計者の気持ちは分かる。取り消せない動作においては、「ファイルを戻せなんて怒られたら」と思ってしまう。デフォルトを [キャンセル] にするべきだ、という blog を見ればなるほどな、と思う。
Windows ではどうか。Explorer でファイルを選んで削除すると、[はい] がデフォルトだ。ごみ箱に行くので取り消しは効くが、ごみ箱に行かない削除の仕方 (ファイルを選んで Shift+Delete) でも [はい] がデフォルトだ。ほんとうに削除したい時にはこの方が正しい。
おそらく確認画面の意味をどう捉えるかによるのだろう。確認画面で間違い操作を防げるケースというのは実はかなり少ない。これは、確認画面を設計しているときには分からないが、日常で使っている自分を振り返る、あるいはビデオに撮影してみてみれば分かるだろう。メニューを選んだ直後に「あ、間違えた」と思った時には救える。それ以外の時には、デフォルトがどちらであろうと、もう指が操作を覚えている。デフォルトが [キャンセル] なら、削除を選んでから TAB を押して ENTER。結局救えない。確認画面が終わってから間違いに気が付くこともある。それはもう自己責任。
だいたいにおいて確認画面のメッセージは読まれない。読んでくれるなら、ウィルスはここまで拡散していない。[OK] か [はい] をクリックするか、ENTER を押すだけだ。ENTER を押す人は、デフォルトが [キャンセル] だと、いつまでたっても操作が進まない。Word 6.0 で印刷レイアウトから下書きに切り替える場合、図が表示されなくなる。「図が消えた」という文句を恐れた設計者が確認画面を入れたところ、出荷してみたら「下書きに切り替えられない」という電話が殺到した。それだけメッセージを読まずに ENTER を押す人が多い、ということだ。
もちろん操作の重要性にもよるだろう。ミサイル発射ボタンのデフォルトは [キャンセル] であってほしい。しかし設計者には、「確認画面を入れたい」「デフォルトをキャンセルにしたい」という誘惑に駆られたら、今一度レビューをしてほしい。この確認画面はほんとうにユーザーを助けるのか。自分が文句を言われないようにするためだけではないのか。レビューすれば、そのほとんどが [はい] をデフォルトにする方が正しいだろう。そしてそのほとんどにおいて確認画面は不要だろう。コスト的に可能であれば、それでも [キャンセル] を選んだ場合に、ユーザビリティや実ユーザーを訪問してどう使われているか見てみれば、自分の設計力が上がることは間違いない。
サービスを提供する側が、文句を言われるのを事前に防ぐために冗長さを追加していくのであれば、どこぞの政府と同じになってしまう。自己責任は信頼と教育によるものだと思う。ユーザーを信じ、万が一文句が来たらきちんと説明する。そして 99% のユーザーにとって正しいものを設計する。
そういう設計者が増えてほしいと切に願う。
以前話題になって沈静化してしまった Microsoft の腕時計 SPOT の第 2 世代版 が出たらしい。最初の時もそうだが、今回も基本的には腕時計としての評価がほとんどで、その点についてこの製品がブレークする気配は残念ながらまったく感じられない。
しかし中長期に見た場合、この製品が面白い点が 2 つある。
一つは携帯製品マーケットとしての腕時計の可能性。現在携帯電子製品としては携帯電話に集中しつつある。しかし、先日腕時計を忘れて外出した際、時間を見るのに携帯電話を使うことの面倒さを実感した。携帯電話の裏面の小さいディスプレイ
や
ノート PC のサブディスプレイ は、腕時計が担って行くのかもしれない。まだ完成度は低いが、これを示唆する製品として
CITIZEN i:VIRT や
セイコー Bluetooth Watch
などがある。これが イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき
もう一つはこの製品が .NET MicroFramework を使っている点だ。.NET MicroFramework は、.NET Compact Framework よりもさらに小さく、電源消費も抑えて、腕時計で使えるレベルを目指した OS だ。今の PDA 市場が中期的に UMPC と携帯電話に吸収されるであろうことに異論は少ないと思うが、その携帯電話よりも小さいデバイスとして新しい市場ができてくるのではないかと思うのだ。
| 現在のセグメント | 将来のセグメント | MS の Platform |
|---|---|---|
| PC | PC | Windows XP/Vista + .NET Framework |
| PDA | UMPC | |
| 携帯電話 | Windows CE + .NET Compact Framework | |
| 携帯電話 | ||
| 腕時計 | .NET Micro Framework |
.NET Compact Framework の 2.0 での追加機能を見ていくと、PDA として高機能を目指す機能がほとんど見当たらない。機能は高くなってきているが、あくまで MS の携帯電話用プラットフォームである SmartPhone に主眼が置かれている。PDA の上位層は UMPC が吸収していくと MS が予想しているからだと思われる。
現在の .NET MicroFramework はまだ余り情報が公開されていないが、MS のサブディスプレイ技術である Windows SideShow [Windows SideShow Team Blog (英語)] でもこれが使われるらしく、腕時計やリモコン用のアプリケーション開発も遠い未来の話ではなくなるかもしれない。
アプリケーション開発者の一人としては大きな楽しみである。
CompareOptions の IgnoreNonSpace を指定すると、「リーグ」=「リーク」になってしまう。濁点、半濁点が Unicode で diacritics として規定されているから正しい動きなのだろうけど、「Cafe」=「Café」くらいの働きしかないかと思っていたからちょっと驚いた。
探してみると、mono の日本語作業をされている ものがたり さんが CompareInfo とか Access のソート順 などについて書いている。
Globalization 周りは特にドキュメントに「日本語の場合」みたいな記述がないので、きちんとテストしてから書きましょう、という教訓。
Windows Vista February CTP が出ていたので、Toshiba M200 に入れてみた。
DWM は相変わらずオンにならない。GPU が認識されていない。いろいろな話を総合すると
で、nVIDIA driver 87.15 を入れてみるが、認識されない。M200 の BIOS も上げた方がよい、とあったので、M200 BIOS 1.80 にしたが変わらず。
諦めつつあると、手動で GeForce FX 5200 (LDDM) を選べば動くとの情報があり、やってみると動くようだ。ドライバを変更してから画面を 32bpp に変えると、無事 DWM に切り替わった。もたつきはあるし、安定度も落ちた気がするが、DWM オンで Aero に Side Bar が入るとだいぶ変わった感じがする。でも Tablet の回転はまだできない。ドライバとの相性か、機能が入っていないのか。
しかし今までの CTP と比べると格段に機能が入ってきて、使っても楽しくなってきた。製品版ではさらに性能は上がるだろうし、video driver の問題もあるとは思うが、やはりもたつきがつらい。M400 がほしくなる。ヘビーノート派なので、光学ドライブ内蔵が嬉しい。東芝さん、今度こそ Bluetooth 付きで国内版お願いします。
「入れるな」とは書いてあったが、さらに Office 12 Beta 1 をインストール。しばらく置いておいたら OS ごとハングするくらいの安定度になってしまったが、次の仕事に向けていろいろと調べる環境がやっとできた感じだ。
以前に触れた Media Foundation API だが、すでに reference が Windows SDK に入っている模様。
どこまで最終版なのかはっきりしないけれど、Vista もそろそろ API close の季節だし、根本的な構造はこれで行く、ということなのだと思う。より多くの情報が出ていてマーケットも広い WPF (Windows Presentation Foundation, a.k.a. Avalon) に注目が集まっているが、DirectShow も少し手がける身としてはこちらも気になる。
DirectShow との大きな違いとして何点か読み取れる。
DirectShow は、ビデオファイルを再生するくらいなら動いてくれるけど、もうちょっと難しいことを仕様とすると結構大変だったので、"significant architectural change" と言っている MF には期待が高いのだが。
ちなみに微妙な点が 2 点。
Vista の次の CTP は数日中とも噂されている。WPF などはこれの上に実装されるので、もうそろそろこの辺が固まっていないと困るだろうから、あとはドキュメントが充実してくればもう少し見えてくるかもしれない。
IE7 における RSS サポートの全貌が見えてきた。
API が出てくるのは想定していたが、そのサポート範囲は思っていたよりもだいぶ厚い。
更新があったら知らせて、読む時にはサイトに行くのかと思っていた。WinFS になればそこに入れるのかな、くらい。
でもしっかり store も持っている。フォルダ構造で RSS feeds を管理して、それぞれに対して 過去記事をどれくらい取っておくかを指定する画面 もある。「Keep all items」もあるので、全部取っておけるらしい。
う～ん、おもっていたよりずっとよい。基本サポートだけだったら足りない部分を作って行こうかと思っていたけれど、足りない部分を探す方が大変かもしれない。
Dispose を呼ぶべきか、Close を呼ぶべきか という深遠（？）なテーマについて記事が。
ということらしい。
自分としては Exception が気になる。Dispose は finalizer からも呼ばれたりするので、原則 throw してはいけないと思っている。しかしファイルシステムの flush 操作など、Close は throw することがある。
Dispose は try/catch して best effort でエラーを食うような実装をしているけれど、正しいのかなあ。その辺の記述は見当たらない。
QWERTY キーボード付きらしい。HTC Apache reference platform ベースと思われる。W-ZERO3 を意識してのことか。
量販店では売らない、という話も。ちょっとマーケットを読み違えているのでは、という気もするが、 台数の規模が違うのだろうか。
NTTドコモ、Windows Mobile搭載の台湾HTC製端末を導入へ
「2006 年下期の導入に向けて、検討が進められている」との話なので、HSDPA にも対応か。
米 Cingular Wireless の HCT 製スマートフォンは先ごろ発表されたりしている ので、これと同じか、後継機種かもしれない。
下り最大 3.6Mbps の HSDPA は 2006 年 4 月以降に開始 なので、HSDPA が出た時点で買い換えるか、Windows Mobile を待つか、ちょっと悩ましそうではある。
数箇所で話題になっている
Microsoft ACE (Award for Customer Excellence nomination) からメールが来た。こんなものをくれるそうな。
ブログで、こういうものって本体である microsoft.com のドメイン名を使うべきでは、と誰かが言っていた。Google してみると、「これって新手のフィッシング？」という人が多数。
確かに不安になる。検索して大丈夫そうなので少し安心したが。
こんなものをもらうのは久しぶり。少しうれしい。
Vista/WPF 世代においての graphics API は徐々にその姿をあらわにしつつあるが、DirectShow に関しては情報が少ない。ここのところやっているプロジェクトが DirectShow を使っているので結構気にしているつもりだが、ほとんど見つからない。
Larry Osterman のブログ記事 Where does WASAPI fit in the big multimedia API picture? は Vista の新しい audio API に関する記事だが、その中で少し触れられていた。
For Vista, we’re adding a new high level multimedia API called Media Foundation, or MF. MF is intended to fix some of the limitations in the DirectShow architecture that really can’t be solved without a significant architectural change.
"Media Foundation" という名前は今までの PDC などでは出てきていない気がする。Beta 2 あたりから入ってくるのだろうか。
DirectShow の置き換えは何かあるだろう、とは思っていたが、こうして近づいてくる気配があると、楽しみである。
以前 .NET の memory model は x86 よりも弱く、x86 で動くコードが他の CPU では動かない可能性があることについて書いたが、.NET 2.0 の memory model に関する記事が MSDN に掲載された。
やはり IA64 をベースにした memory model では正しいコードを書けるプログラマーがいなくて、x86 より少し弱めの memory model に実装しなおしたらしい。これで Thread.MemoryBarrier を忘れたコードは、ECMA では許されなくても .NET 2.0 では IA64 でも動作するはず。
IA64 はプログラマーに負担をかけすぎで、無理ではないかと思っていましたが、やっぱり言語やコンパイラのレベルでガードが入りました。しかしこれで、しかも x64 がある現在、IA64 のメリットって何？ という状態になってしまいましたね。まあ、もともと普及しないと思ってはいましたが。
追: ココログって古い記事は消えていくんですね。初めて知りました。。。
Windows Vista (Longhorn) の PDC CTP build 5219 が MSDN に上がりましたね。
i845 のマシンに入れているので Aero は堪能できませんが、とりあえず Beta 1 をアップグレードしてみます。
Asynchronous Design Pattern Overview は .NET 1.x で定められた非同期のガイドラインだが、BeginInvoke/EndInvoke による実装では使いづらい場面もある。また AsyncCallback が呼ばれるスレッドについて規定がないので、実装に迷う。
Component 用と銘打ってはあるが、新しい Implementing the Asynchronous Pattern for Components では event を中心とした新しいモデルを提供している。Event のスレッドについても、.NET 2.0 で新しく導入された AsyncOperation と AsyncOperationManager を使って上げろ、と書いている。
この AsyncOperation は、これも .NET 2.0 で新しく導入された SynchronizationContext を使って同期を図る。
SynchronizationContext は、Windows Forms 環境内では Control.Invoke を使い、それ以外では ThreadPool を使って Send/Post の概念を実装する。.NET 1.x における ISynchronizationObject は、インターフェースとして仮想化されているとは言え、実質 Windows Forms 以外の実装がなかったので、一歩進んだと言えそう。Avalon を睨み、message queue を一段隠蔽したのか、という気もするが、Avalon でも message queue は完全には消えないので不明。
AsyncOperation では SynchronizationContext の Post しか利用できないので、event を上げておいてその event handler の処理が終わってから何かすることができない、というのがちょっと使いにくい。その場合には SynchronizationContext を直接使え、ということか。
Delegate の調査 ついでに長年の疑問を調べてみる気になった。
Handler += new EventHandler(OnEvent); Handler -= new EventHandler(OnEvent);
それぞれ new しているのでちょっと不思議な感じだが、実際にはこれで追加した event handler が削除される。
文法としては new でも中でちょっと違うことをやっているのかと思っていたが、IL を見てみると、普通に newobj している。Delegate クラスが Equals メソッドを実装して、その内容で比較するからこのコードで動くのだろう。しかし
EventHandler h = new new EventHandler(OnEvent); Handler += h; Handler -= h
これだと newobj は 1 つになるので、ヒープにはちょっと優しい。でも個人的意見かもしれないが、readability が悪い。
これくらいコンパイラが最適化してくれればいいのに、と思うが、VS 2005 Beta 2 で Release ビルドしても最適化はされない。Readability を落としてでも取るほどのメリットではないと思うので、これからも上の書き方をすると思うが、多用する時にはちょっと気持ちが悪いかも。
delegate に複数回同じ event handler を追加しても無視される、と何かで読んだ気がしてずっとそう思っていましたが、.NET 2.0 で違う挙動に出会い、改めて調べたら、.NET 1.x でも追加した回数だけ呼ばれることが判明。やっぱり疑問はきちんと自分で解いておかないとだめだと反省。
class Program {
static event EventHandler Handler;
static void Main(string[] args) {
Handler += new EventHandler(OnEvent);
Handler += new EventHandler(OnEvent);
Dump();
}
static void Dump() {
if (Handler == null) {
Console.WriteLine("Empty");
return;
}
Console.WriteLine("# Handlers={0}",
Handler.GetInvocationList().
Length);
Handler(null, EventArgs.Empty);
}
static void OnEvent(object sender, EventArgs e) {
Console.WriteLine("OnEvent");
}
}
結果は
# Handlers=2
OnEvent
OnEvent
しっかり 2 回呼ばれてしまいました。こう書けば安全か。
Handler -= new EventHandler(OnEvent); Handler += new EventHandler(OnEvent);
CLRProfiler の Beta 2 version が出ている模様。元の CLRProfiler が .NET 2.0 で動かずちょっと残念、とか思っていたのですが、download サイトで検索しても出てこないのにこの URL をたたくとダウンロードできる。
なぞ。でも動くからいいか。
MSDN にもう掲載されました。8/3 と言われていましたが、ちょっとフライング？ とりあえずダウンロードをかけて、入れて見ます。
MS から新しい recommendation が出ています。
う～ん、今までの recommendation から InvariantCulture を多用していたなあ。セキュリティは難しい。
以前に紹介した .NET and COM ですが、PDF 版の販売を開始した模様。
これは便利。思い本を取り出さなくてもいいし、ノートで持ち歩けるし、検索もできるし。
日本の amazon.co.jp では見当たらず。
WinHEC で配られた Longhorn build 5048 は MSDN では公開されないことになった。残念。だが、分かる気もする。
Longhorn は .NET だ、と言っても、あくまで上位 API の話。ドライバはもちろん unmanaged。ということは、どこかで線を引かなければならない。
カーネルはすべて unmanaged として、user をすべて .NET 化、というのも形としてはきれいだが、互換性を考えるとありえそうにない。ほとんどの人が使う API の直下まで unmanaged にするのがパフォーマンス的には一番よさそう。それが 前出の Avalon の構成 になっているのかもしれない。
WinHEC はあくまでハードウェア開発者向け。ハードウェアとドライバの API を固めて、開発にかかれるようにするのが最大の目標。なので、5048 はその部分に注力してあって、上のほうは固まっていないので、混乱や不要な落胆を避けるために配らない、というのは理にかなっている。
理にはかなっているが、、、残念。
Longhorn Graphics のコンポーネント図が The Future of Windows' Graphics Technology (Extreme Tech) に掲載されている。Avalon は DirectX API ベースで書かれているのかと思っていたが、ちょっと違うらしい。
前出の MIL の最上位 API が WGF 1.0 かな？ Direct3D 10 は WGF 2.0 らしい。1 つのバージョンの OS に 2 つのバージョンの API が初出ってのも珍しい。上の記事の 5 ページ目に WGF 2.0 のコンポーネント図が掲載されているが、Avalon も pixel shader は使えるような気がするので、ちょっとこの関係が分からないが、おそらくは WGF 2.0 はハイエンド グラフィックス向けでメインストリームではない気がする。
4 ページ目の図も含めて XP Avalon がどうなるのかがやっぱりよく分からない。Avalon と MIL あたりを DirectX 9 の上で動かしてしまう、ということか。WGF 1.0 あたりは DirectX をベースにしていそうだから可能なのかもしれないけど、考えるだけでも大変そう。
Aero は GDI ベースか と以前に書いたが、どうも MIL ベースらしい。
Mr. Avalon と言われる Chris Anderson が自身の blog に MIL Information というのを書いている。また同じ Chris Anderson の MSDN の Avalon の記事 にも MIL という単語が登場する。
この辺から総合すると、MIL の下半分は MILCORE.DLL であり、これが Direct3D 上で実装され、unmanaged の描画 API を提供するようだ。その上に PresentationCore.DLL があり、これが managed な Avalon API の下層部分を提供する模様。Aero は Avalon には依存しないが MIL には依存する模様で、これなら XP では実現できなかったビジュアルを実装できそうだ。GDI ベースだと貧弱ではないかとかパフォーマンスで心配があったりとかの心配は杞憂に終わりそうな感じである。
いまだに不明なのが、GDI/USER の位置づけ。先日も友人と、Avalon 時代に message pump がどうなるのかという想像をしていたが、これがいまだに分からない。PDC の頃のアナウンスでは GDI/USER は Direct3D の上にエミュレーションとして実装されるような話がされていたが、NT 4.0 以降この辺はカーネルの中に入っているので、PDC 後にアナウンスされた XP Avalon でそこまでの変更ができるのか、不透明だ。もちろん MS 謹製なので、カーネルごと入れ替えてしまうという荒業は可能ではあろうが、それはそれで大変そう。
WinHEC も始まったし、そろそろ次の Longhorn CTP ビルドが出ると思うので、楽しみである。
Visual Studio 2005 (Whidbey) Beta 2 の英語版がリリースされたので、今までの Beta 1 のコードを移し始めた。
Generics の IEnumerable<T> が IEnumerable から派生するようになったのは各所で話題になっているが、他にもいくつか小さい修正がある。そこはすんなり行ったものの、とりあえず 1 つ目の大きな課題は Uri クラスにあった。
.NET 1.x の Uri クラスは拡張が一切できなかったが、Whidbey Beta 1 では factory パターンで自分で Uri のサブクラスを作れるようになっていた。これを使って SIP URI の解析を入れていたのだが、これが refactoring されたようで、factory パターンごとなくなっていた。
UriParser クラスから派生させて解析部だけ書けるようにはなっているようだが、変更が大きい。SIP URI は他の URI に比べて仕様が込み入っているので、コードを変えるとなかなか厄介だったりする。
Unit Test に NUnit を使っているが、実行中にふっとウィンドウごと消えたりしてしまうようで、Beta 2 なりの対処が必要なようだ。
.NET 1.x で日付や時刻を XML に入れる場合、結構な確率で問題に出会う。私が Visual Studio .NET 2002 のベータ版で最初に作ったのが XML Web Service だったため、いきなり問題にぶつかり、米 MS に報告したが、問題が大きすぎてもう直せない、という結果に終わった。これが、Visual Studio 2005 / .NET Framework 2.0 では修正される。
.NET の BCL (Base Class Library) チームが 1 日 blog day を取って書いた記事群 のひとつに、What are the new DateTime features in Whidbey がある。VS 2005 の機能リストに DateTime の修正が上がっていたので期待していたが、この記事にはかなり詳細が書いてある。
問題は、DateTime がタイムゾーンにかかわる情報を持っていないが、XML の dateTime は持っている、という違いに起因する。このため、DateTime を XML Serialize/Deserialize する場合、.NET 1.x はそれが常にローカル時間であると仮定した。これにより、以下のような問題が起こる。
修正した、というので、64 bit だった DateTime が大きくなったかと思っていたが、もともと DateTime の 64 bit のうち 2 bit が未使用で、そこを使ったという。 性能に影響を与えずに修正された、というのは非常にうれしい。
Aero は Longhorn のシェル。Avalon は USER/GDI を置き換える API。Is Aero Dead? という記事から、ちょっと驚きのニュースが。
Avalon のパフォーマンスが問題か。だとすると、Mac の QuickDraw GX の二の舞の可能性もありそう。
Aero は Avalon に依存しないとして、USER/GDI ベースで書かれるのか、DirectX ベースになるのかは記事からは不明。
Whidbey Beta 2 が 3 月末には間に合わない という記事が出ました。英語版 3 月末という噂がありましたが、こういう記事が出るということは、ほんとうだったんでしょうね。
どれくらいの遅れかについてははっきり書いていませんが、4 月とのこと。がんばっていただきたいです。
We have fixed this bug and you should see results in our Release Candidate build. The fix will not appear in Beta2.
とあるので、すでに Whidbey の Source Tree は Beta 2 用にスプリットしたみたいですね。
ASP.NET の PUM で情報を漏らすことで有名な（笑） ScottGu が、 Whidbey Beta 2 は 6 月、という発言。
Go-live license については再確認してくれていますが、これがほんとうだと、RTM は年末ですね。
Visual Studio 2006 に名前が変わる日も近い?
UPDATE: 菊池さんのコメントのとおり、古い記事を見ていました。Beta 1 が 2004 年の 6 月、というだけですね。Beta 2 は今までの話どおり、3月ないし4月か。失礼しました。
試験用のサーバー証明書などを使った場合、WebRequest や WebClient を使った HTTPS 通信ができない場合がある。
そう質問されて、前に何かの記事でそういった場合の対処を読んだ気がして、ICertificatePolicy を使ってみたら、と伝えたら、できたとの話。
Framework が大きくなるのはよいことだが、Learning Curve の問題は常に付いて回る。
DirectShow の資料を探してきたが、ないなあと思い続けてきた。
前に一度探した時には洋書で一冊だけあったが、付属 CD に DirectShow 6 が付いている、というので年代を感じてやめてしまったが、またふと思い出して探してみるともう一冊見つかった。
Programming Microsoft Directshow for Digital Video and Television
年末に読めれば、と思ったが思ったより時間がかかり、今日届いて半分くらい読んだところ。あまり期待していなかったのだが、結構よく書いてある。内容は DirectX 9 にまで言及してあり、MSDN のドキュメントよりはずっと読みやすい。
プロジェクトを一緒にやっているメンバーにもぜひ読んでほしいのだが、残念ながら彼らはこのボリュームの英文はちょっと無理かもしれない。日本がソフトに遅れているのって、英語力の問題が大きいよなあ、と改めて思う。
.NET で XML を操作するには XmlDocument と XPathNavigator という 2 種類の異なる API がある。
XmlDocument はいわゆる W3C の XML DOM をベースにした API モデルで、慣れている Developer は多い。それなのにわざわざ異なる XPathNavigator を導入したのは、MS の XML チームが XML DOM API では現状以上にパフォーマンスをあげるのが難しいと判断し、
としてきたためである。しかし XPathNavigator は読み込みしかできないため、将来においても XML に対しての変更が要らない時にしか使えなかった。
.NET 2.0 ではこれを解消するため、XPathNavigator が改良され、変更もサポートされた。これでようやく移行するのか、と思いきや、新しい話が入ってきている。
XmlDocument is (once again) the preferred store for XML (英語)
VS 2005 の開発当初の考えでは XmlDocument の性能がそのデザインから来る問題で頭打ちになっている、というものだったので新しい API を作ったが、開発後半になっていろいろ計測し調査してみたら、当初思っていたほどでもなかった。だから今後は、開発者の慣れや互換性に優れる XmlDocument を推奨 API として、開発の力点を入れていきます、というものだ。これにより XPathNavigator はメンテナンスフェーズに入り、徐々にフェーズアウトされることになる。
.NET 1.x のドキュメントでは XPathNavigator が推奨されていながらも、制限もあり、XML の読み込み時にはどちらを使うべきか迷う局面が多かったが、方針がすっきりしたことになる。推奨、というので XPathNavigator を使っては見たものの、使い勝手に問題があったり、変更のニーズが出てきてしまい困ったり、ということが実際にあったので、この決定はうれしい。
しかし、.NET 2.0 の開発期間中にすでに XPathNavigator に割いてしまった労力をたとえば XSLT 2.0 に向けられていたら、、、というのは言ってはいけないんだろうけど、思ってしまう。
大きなプロジェクトがあるので、C# プログラマーを募集してみたが、どこに聞いても見つからない。C# ってもうちょっと市民権を持ってきていると思っていたのだが、ここまで少ないのはちょっと意外。Web とか見ていると、結構いそうなんですけどね。
考えてみれば、そもそも周りにも少ないかも。う～ん。われこそは、という方は、メール、いただけませんか。
ちょっと古いネタですが、受信トレイに眠っていたのを先ほど見たので。
Anders Hejlsberg - Programming data in C# 3.0
Anders は Borland で Delphi を設計した後、MS に来て C# を設計した人です。
このインタビューで言っている「汎用言語と DB 言語の関係問題」は最近ホットなようで、いろいろなところで見かけます。簡単に書いておくと、今日現在まで COBOL を除いてほとんどの言語では DB は外部ライブラリだったが、言語に統合するべきではないか、という話。数年前に Microsoft Research で X# (Xen) という言語が発表されていたが、それが C Omega という言語に発展し、C# 3.0 で検討されているらしい。
C Omega はまだちゃんとトラックしていませんが、X# は XML と DB を言語に統合したらどうなるか、という研究を C# をベースにしていた言語で、データレイヤーを SQL で組むことが嫌いな私にとってはすばらしい話。
数年のうちには、先端の言語はこうなるだろうな、という気がします。そのデータをどの言語で書いたかで処理方法が決まるのはおかしいと思う。DB に入っていれば SQL で探せるけれど、それを XML DOM にロードしたら XPath で、配列にロードしたら foreach で、というよりも、場所に拘らず同じ方法で探せれば、というのが C# 3.0 では実現しそうな気配。
不勉強がばれて XQuery の話 にコメントを付けられてしまいました。のでとりあえずもうちょっとちゃんと勉強することに。
XQuery 本はいくつか出ているようだけど、評判が一番よさそうな Xquery: The Xml Query Language (洋書) を注文。読んだらまた感想書きます。
前に書いた「数冊読んだ IPv6」ですが、IPv6―次世代インターネット・プロトコル はちょっと発刊も古く、読み物としては面白いけど、という話。
ちゃんと勉強するなら IPv6エッセンシャルズ の方が良いです。いわゆるネットワーク本なので気合は必要ですが、幅広く網羅していて、かなり新しい話にも付いていっている。関連技術を一通り網羅して概説が付いているので、例えばトンネリング技術っていっぱいあるけどどこから調べ始めよう、みたいな時に便利。IPv6 の参考書みたいな感じ。
Microsoft の WebData チーム XML Lead Program Manager の Mark Fussell が .NET Framework 2.0 の XML において XPath 2.0/XSLT 2.0 のサポートを行わないことを表明した ことがちょっとした波紋を呼んでいる。
XSLT 2.0 と XQuery 1.0 は、8割方同じことをするために2つの流派がそれぞれの仕様を定めたようなものだ。そしてそのどちらがより優れているかは、人によって意見を異にするかもしれないが私は XQuery だと思っている。
XSLT は今日現在ほかによい代替技術がなく、ほとんどの PC に入っていることから実際に私も使っている。どちらかというとかなりヘビーに使っている。しかし XSLT にあまり将来は見えない。Mark と同じチームの Arpan Desai も 述べている が、XSLT には 2 つの大きな問題がある。
MSDN からダウンロードできる Longhorn M7.2 には DWM が入っているという話。
DWM (Desktop Window Manager) というのは PDC では DCE (Desktop Composition Engine) と呼ばれていた、画面上のウィンドウやコントロールを管理するモジュール。Avalon が GDI の置き換えなら、DWM は USER の置き換えと言える。
が、これはデフォルトでオフになっている。まだ buggy だし、パフォーマンスも悪い。オンにする方法は英語のサイトにはいくつかリークされている。
cd \windows\i386
sbctl start
WinHEC で公開された Longhorn M7.2 が MSDN でダウンロードを開始した。PDC 版よりいろいろ入っている模様で、ダウンロード中。
合わせて Reflector が 4.0 になり、Framework のバージョンを選ばなくなったので、より簡単に Longhorn や Whidbey で使えるようになった。Reflector はさらに Add-in をサポートしている。
先日書いた PINVOKE.NET を Visual Studio.NET から使うための Add-In もリリース。Wiki & コミュニティパワーで、いつの間にかボリュームがすごくなっている。
今日の Blog はなんだか後で試してみたいモノを書き留めておくようなものになってしまった。
P/Invoke と呼ばれる .NET の Interop 技術は、.NET コードと非 .NET コードを混在させる場合に使う。Java プログラマーから見れば汚く見えるのかもしれないが、常に現実を見据える MS らしい技術の一つで、私が .NET を好きな理由の一つでもある。
P/Invoke の1つの問題は、その宣言を書くのがけしてやさしい作業でないこと。問題は、例えば Win32 API 用の宣言を MS がリリースすればよい、というレベルでは収まらない。というのは、P/Invoke は .NET の型と C の型のマッピングを取るため、1つの API でも複数の .NET からの呼び出し方がありうるからだ。
そして MS が達した結論がコミュニティを利用することだった。CLR チームの主要メンバーの一人である Adam Nathan はそのためのサイト PINVOKE.NET を立ち上げた。ちなみにこの人の .Net and Com は Interop を使う人にとって必読書と言える。翻訳がないのが日本のプログラマーにとっては残念だ。MS はお金を出しても、これの翻訳を出すべきだと思う。
これは Wiki ベースで、P/Invoke に必要となる宣言をドキュメントとしてコミュニティでまとめ上げるためのサイト。現段階でも Adam Nathan が入れた相当数の宣言が入っている。同じ API でも違う形の呼び出し方を自分で書いてテストした人は、ここに追加すれば、他の人が参照できる、という、いわゆる Wiki の仕組み。昨今の MS のコミュニティに対するスタイルの変化から、こういうことができるようになったのは大いに歓迎したいと思う。
ダウンロード後も往生際悪く迷っていたのだが、結局入れることにした。今作っているソフトが IE に思い切り依存しているため、入れてみて動かない、となったら対応を余儀なくされるなぁ、と思っていたのだが、これはやっぱり対応しておくべきでしょう、という気持ちに傾いてきた。
で、まずは 前述 の東芝 Dynabook SS M200 Tablet PC にインストール。サブマシンから、というのもあるが、XP SP2 には Lonestar のコード名で開発中の Windows XP Tablet PC Edition 2004 が入っている。日本ではあまり記事を見ないが、英語圏の記事はすこぶる評判がよろしい。
さきほど入れ終わって、開発中のコードを軽く流すと、嬉しい事に一通り動くようだ。いや、よかった。
そして、Lonestar。少しペン入力をしてみた程度だが、これはかなりよい。入力パネルがぐっと使いやすくなり、精度も上がっているようだ。枠なしモードでの日本語入力にも対応するなど、なかなか気合が見られる。しばらく使ってみる気になった。
IE の強化についてはもうずいぶん記事が出ているので省略するが、とりあえず開発中のコードに仕事がどんと増えるわけではないことがわかったので、メインの開発マシンにも入れてきちんと使っていくことにして、今インストール中。Visual Studio .NET が壊れたらどうしよう。
自動更新も賢くなったようで、裏できれいに動いてくれる。そういえば当初 Windows Installer 3.0 が入る、という話だったが、その後あまり話を聞かない。セキュリティ中心になりすぎて話題に上らないだけだろうか。
ちなみに、サーバーが重くダウンロードもかなり遅かったが、インストールにもかなり時間がかかる。ベータではなくもうRC1なので、これは出荷版もこのままだろう。
Windows XP SP2 に HTTP.SYS が入る、という話が Blog であった。MS の記事は、Breaking Changes (下位互換性がなくなる部分の変更) についてフォーカスして書いてあるので、説明が見当たらず真偽のほどが定かでないが、事実であればこれはうれしい。
今の Windows XP でサーバー機能を実現しようとすると、ソケットベースで作るか、IIS に依存するかがもっとも考えられる選択肢となる。将来の拡張のため HTTP プロトコルの上に載せたい、と思ったら IIS に依存するしかないが、IIS は標準ではインストールされないし、「使わないものは入れない」というセキュリティポリシーにも引っかかる。
HTTP.SYS はこれを解決する。HTTP.SYS は Windows Server 2003 で追加された HTTP 用のドライバで、カーネルドライバとして動作する。これを使うと、IIS に頼ることなく、API ベースでソケットを作るように HTTP サーバーを作れる。Winodws Server 2003 の IIS 6.0 もこれに依存しており、IIS の一部が API として切り出された、と言ってもいいだろう。
MS としてもこれは重要だったのだと思われる。IIS 6.0 では、パフォーマンス向上のためにカーネルドライバとして切り出した、と説明していたが、今後の SQL Server 2005 (Yukon) や Indigo など、HTTP / Web Service として動作するソフトが増えるに従い、それらのソフトが IIS に依存することを避けなくてはならない。Web Service の実現のために IIS を入れるというのは抵抗が大きい。SOA ベースの疎結合サービスを考えると、ソケットベースでなく HTTP の上に載せて行きたいが、自身が出しているセキュリティポリシーに背反していることを HTTP.SYS で解決するわけだ。
IIS に依存することはもう一つ、開発コスト上大きな問題となる。IIS のサブシステムとしてプロトコルハンドラが動作するため、こちらのアプリとは別プロセスになってしまう。アプリの持っているデータを HTTP で出すために、IIS 上で動作するプロトコルハンドラとプロセス間通信をしなければならない。
その HTTP.SYS が Windows Server 2003 にしかないことはその利用価値を大きく下げていたが、XP SP2 に入れば利用できるアプリは大きく増える。うちでもつい先日クライアントに小さいサーバー機能を載せたくて、しかし IIS を入れたくないのでソケットベースで作ったところだった。HTTP.SYS があれば、HTTP ベースで作ることができる。
XP SP2 はセキュリティも大きく強化されるので、今まで作っていたソフトも対応を余儀なくされそうだが、それでも楽しみなソフトの一つだ。
英語の開発者Blogの間ではかなり書かれているが、MSDN Universal Subscription を持っている人向けに Visual Studio 2005 (Whidbey) Technology Preview のダウンロードが始まった。今ダウンロード中。。。VS 2005 Developer Center に情報が出始めているし、IDE Enhancements for C# Developers なんてビデオもあるようで、これまたダウンロード中。。。
VS 2005 の強化項目は多いのでとても紹介しきれないが、PDC 版に入っていなかった Windows CE 用の .NET Compact Framework の強化が入っている模様。画面ショット が掲載されている。
VS 2002/2003 の .NET CF はかなりがっかりするものだった。特に
.NET GC & Interop クイズ の解答。
問題は Work メソッド内にある。Work メソッドが NativeMethod.WorkOnHandle を呼び出す時に
GC と Memory Leak の件はやはりフレームワークのバグで、KB の処置を施したら直った。以前は一日走らせていると100MB程度までメモリを食っていたのが、すっきりと直った。すっきりと直ったので、一週間ほど休暇をとることにした。
ので今日は休暇の前にちょっとプログラミングのクイズ。Interop で OS から handle を取得してラップするクラスがあるとする。
public class Wrapper : IDisposable {
IntPtr _handle;
public Wrapper(IntPtr handle) { this._handle = handle; }
public ~Wrapper() { this.Dispose(); }
public void Dispose() {
GC.SupressFinalize(this);
if (this._handle != IntPtr.Zero){
NativeMethod.CloseHandle(this._handle);
this._handle = IntPtr.Zero;
}
}
public void Work() {
NativeMethod.WorkOnHandle(this._handle);
}
}
このクラスはある特定の条件で動作しない。その条件と直し方は？
GC などで言語やランタイムが簡単になると、それより下のレイヤーと強調して動くのはそれまでよりも難しくなる。それは仕方のないことか、それとも GC がもっとこなれてくるまでの移行期間の問題なのか、10 年後にこんな問題を考えて対処していたことをどう思うか楽しみでもある。
MSDN で Win32 API と .NET Framework の対応置き換えマップのの日本語版 が公開された。以前に紹介したもの の翻訳だが、便利。
自分ではいらない、と思っていたが、つい最近発見があった。マルチモニターに対応するコードを書く時、Monitor あるいは Display で検索していたがクラスが見当たらなかったので、P/Invoke でコードを書いていた。が、クラス名は Screen であった。Win32 API では GetMonitorInfo など「Monitor」を使っていたのだが、おそらくスレッド同期の Monitor クラスと混同しないため、名前を変えたのだろう。やっぱりちゃんと対応置き換えマップを最初に見ておくべきだったと反省。
GC (Garbage Collection) の世界では Memory Leak は発生しないというのが神話だということは、Java や .NET で少しプログラミングすれば分かるだろう。しかし意外にこの話は、時折浮かんでくる。
Memory Leak というのは、ユーザー的立場からすればそんな初歩的なバグは早く直しなさい、という感じだと思うが、開発側からすれば頭の痛い問題だ。
原則は、きちんと対処をしたコードを書く。しかしバグやセキュリティホールがなかなかゼロにならないのと同様に、Memory Leak もゼロにはならない。GC はこの問題を改善するために生まれた。GC が実装されているプラットフォームでは、Memory Leak は発生しにくくなり、かつ開発者は複雑なメモリ管理機構を実装せずに、他のより上位の実装に集中することができる。
しかし逆に GC はまだ新しいテクノロジーであるせいか、一度発生するとトラックするのが難しい。私がやっているプロジェクトでも、恥ずかしい話だが、Memory Leak が抑えられないのが1件ある。DataTable.Select メソッドが Memory Leak を引き起こす KB (英語) を発見し、この修正を入れてしばらくまた様子を見てみることにした。
GC の世界では、使われなくなったメモリは自動的に削除される。「使われなくなった」の定義は、「参照されなくなった」だ。どこかに参照が残っていれば、論理的には使われなくてもメモリとしては生き残ってしまう。理想の世界では、使われなくなったオブジェクトは参照もなくさなければならない。これは GC が勝手にやってくれるわけではなく、開発者の責任だ。しかし GC でないメモリ管理を考えれば、使われなくなったメモリは開放しなければならない、それは開発者の責任だ、ということと大きく違いはない。
GC は、明らかにメモリ管理を楽にしてくれる。しかし、メモリ管理の最後の責任が開発者に残っている、ということを忘れてはならない。
GC にはもう一つ問題があるのだが、それは次回に送ろう。
Visual Studio の次版である "Whidbey" のスケジュールが流れ始めている。
先日 Intel の 64 bit x86 について少し書いた が、大方の予想通り IDF で発表された。2004 年第 2 四半期にはリリースするという。先日発表された新しい Pentium 4 である Prescott は、現状の Northwood の倍以上のトランジスタを搭載してるそうで、64 bit 拡張の基本部分は Prescott に入っているという見方は間違いがないだろう。
1999 年か 2000 年ごろには本気で取り組み始めていた らしい。取り組みの開始は思っていたよりも遅かったようだが、2004 年第 2 四半期と言えば最大で 4.5 ヶ月以内ということだ。これは思っていたよりも早い。Intel の危機感が感じられる。
HP, Microsoft, IBM が賛同 (英語) と言っているので、AMD に急速に追いつくだろう。
技術が進んだことで、分野間の壁がなくなってきていて、いろいろな判断が難しくなってきている。PC と 家電 もその一つだが、今私がコンサルティングしているところでは組み込み系 OS の議論が盛んになってきている。
Windows CE と Linux を検討していたところへ、XP Embedded も検討候補に加えるよう進言した。コストは上がるが、開発コストは下がる。短期に半分研究目的であれば最適解かもしれない。技術的には OQO のような XP 搭載 PC が作れてしまう。
CE.NET もばかにしたものではない。CE.NET の悲劇は、Pocket PC が CE.NET の全機能を含んでいないので、Pocket PC の機能をベースにみなが CE.NET を理解してしまっているところかもしれない。実は CE.NET の API はかなりのものである。この話はまた次回に譲るが、API だけで比べてしまえば CE.NET も XP に遜色ないものを備える。たとえば Pocket IE は貧弱だが、CE.NET は IE6 も持っている。Pocket PC が IE6 を省いた構成にしているだけだが、これは意外に知られていない。
しかし一番の問題は開発環境であろう。MFC, ATL, .NET と揃った XP に比べ、CE.NET は弱い。Compact .NET Framework はより小さいデバイスへ向かう方向のようで、組み込みで CE.NET を使うためにより .NET Framework に近い Compact .NET Framework というものはマイクロソフトのターゲットに入っていない模様である。技術的に見れば、マイクロソフト的にはそこは XP Embedded を使って欲しいということなのかもしれない。しかしハードやライセンスのコストも含め、XP Embedded と CE.NET の差は大きい。CE.NET なら Linux の競合になれるが、XP Embedded は精神的にも難しい面が多い。コスト面と機能面で Linux と渡り合え、開発環境が優れています、という組み合わせがないのが現状だ。
Visusl Studio .NET の次版である Whidbey では Compact .NET Framework の開発環境も拡充されるとのことだが、どこまでのものになるかは未発表のため詳細が不明である。これも調べが進んだらブロッグしてみたい。
Intel の 64 ビット拡張 の詳細が少しずつ出てきている。PC Watch の記事 が詳しい。
メモリ空間はリニアになるのはほぼ決まったらしい。妥当だろう。実際今の IA-32 も物理アドレスとしては 256GB までサポートしている。これで足りないケースというのは本当に一部だろう。
64 ビット拡張でより期待されているのは論理アドレス空間だ。もっとも高速なファイルの読み書きはメモリマップだが、現在の32ビット仮想アドレス空間ではメモリマップを使ってしまうと1～2GB程度のファイルにしかアクセスできない。論理アドレス空間が広がることによって、大きなファイルを扱うプログラムをより自然に、かつより高速にすることができる。なので、「40bit物理アドレスにマップするなら、それ以上の仮想アドレスは必要ない」という PC WATCH の意見には合意できないが、それでも AMD64 の 48ビット (256TB) は当面じゅうぶんだろう。
英語版のMSDNに .NET Framework の持つ 3 種類のタイマーについての記事 が掲載された。まったくもって分かりにくく、かつ API に互換性のないという不思議な 3 種類のタイマーを概説している。
でも確かサービスなどのメッセージポンプを持たないプロセスで使えるのは System.Threading.Timer だけだったと思うのだが、それは書いていない。
.NET になってスレッドプログラミングはずいぶんやりやすくなったが、冷静に考えると今までがひどすぎただけかもしれない。メッセージポンプとCOMのアパートメントモデルから抜け出せるにはあと何年かかかるのだろうか。Longhorn はそのほとんどをマネージドの API として提供する。どこまで改善してくるか期待したい。
HP iPAQ Pocket PC h2210 を注文した。正直かなり GENIO e400 に惹かれていた。なによりあの薄さ。でも高い。価格はほぼ同じだが、GENIO はクレードルが別売。しかも Bluetooth が付いていない。Bluetooth が付いていたら、クレードルくらいの価格差でも買ったのに。東芝のBluetooth SD カード もあるが、1万円くらいするようだ。クレードルと合わせると2万円弱の価格差になってしまう。
GENIO e400 は Intel PXA 263 300MHz を使っているとのことだがこのプロセッサは見たことがない。調べてみると、PXA 255 系にメモリを直付けして薄くするためのプロセッサのようで、ベンチマークでは少し速い との噂もある。その分が高いのだろう。iPAQ h2210 は PXA 255 だが、400MHz 動作だ。速度としてはいい勝負ではないだろうか。
ほんとは キーボード付きの iPAQ h4350 が欲しかったが、日本では発売されない模様。残念。
一週間ほどで到着するらしい。Pocket PC 2003 は 2003 に比べてマイナーチェンジだが、ベースになっている OS が Windows CE 3.x から Windows CE.NET (4.x) に上がる。CE は 4.x になって割と大きく変わっており、プログラマーとしては楽しみな限りだ。
PCのセキュリティが問題になっており、Windowsにバグが多いとか、Linuxの方が多いとかという議論になっているが、どうも焦点がずれている気がする。
平和な村の時代には、家のドアに鍵はなかった。古代にはドアすらなかった。でも今は、ピッキング防止の鍵がしっかり付いている。泥棒に入られて、「この家は鍵が弱いから悪い」と政府が鍵メーカーに言うだろうか？ 文化人類学の専門家ではないが、ある程度以上の文明には犯罪が付いて回るもので、犯罪者はゼロにはならないという前提で、家の鍵のような各個が行う犯罪防止と、警察のような公的な防止機構とが必要になってくるものなのではないだろうか。
PCは、村の時代を過ぎてしまった。それはさびしいことではある。現代でも都会に犯罪が多いことを嫌がる人が多いと聞く。しかし残念ながら後戻りはできず、またインターネットには都会も地方もない。
だから、犯罪者がいて、泥棒に入られる可能性がある前提で考える必要があると思う。
マイクロソフトの動きはその考えを感じさせる。Windows XP SP2でパーソナルファイアウォールがデフォルトでオンになる。RPCも制限される。これらの取り組みが家の鍵になるのだろう。Linuxはまだそれほど多くの攻撃を受けていないのでその辺の歩みは遅い。しかし数が増えれば攻撃を受け、同じ対処をしていくだろう。
警察としての機構も少しずつだができていくだろうが、こちらの方が歩みは遅いかもしれない。公的立場の方々の多くの意見がWinodwsの脆弱性についてしか語っておらず、Linuxにしても何も変わらない事に気が付いていない。脆弱性の問題ではなく、PCの文化レベルの進化過程なのだ。
犯罪者をしっかり検挙し、最低限のフィルターをIXやISPレベルで行う。村にだって自衛団や消防団ができるのだ。ISPだって法律を待たずにフィルターを入れるべきだと思う。@nifty でもスパムフィルターを始めたよう に、ISP でのフィルターはやっと市民権を得始めた気がする。まだ足りないと思う。ISP はある種水や電気のような公共サービス的な側面を持つと意識して、そのサービスを受ける市民の安全のためにより必要なフィルターを入れていくべきだろう。
ISPによって差は出るだろう。NYと東京の犯罪発生率が違うように。それはそれでかまわないと思う。努力の足りないところは淘汰されていくだろうから。より安全な地域があるように、より安全なISPもありえると思う。
最近になって64ビットPCが必要になる場面が増えてきた。そのほとんどはメモリ容量の問題だ。今の32ビットx86ではプロセスあたりのメモリ空間が4GBに制限される。このうち1～2GBをOSが使うので、アプリが使えるのは2～3GBだ。大きなシステムのDBサーバーとしてはこれは心もとない。
だがItaniumを採用する気にはならない。AMDのx86 everywhereに強く惹かれる。Itaniumは将来おそらく、Intelの失敗の一つとしてリストアップされるだろう。8ビットから16ビット、そして32ビットへ遷移する時も、RISCが激しく追撃してきた時も、Intelが勝つことができたのはx86に固執したからだ。Intelはそれを忘れ、64ビットではItanium、組み込みではXScaleと3つのアーキテクチャラインを出している。
AMDはIntelのこの失敗を冷静に見据え、64ビットから携帯・組み込みまでx86アーキテクチャにする、という「x86 everywhere」戦略を取った。Opteronの今の成功はこの戦略が正しいことを示している。
しかしIntelは今までの失敗の時にもあったように、社内的には複数の選択肢を平行で開発しているのだろう。そしてどこかの時点で64ビットx86を出してくると思っていた。それが遅ければ遅いほど、AMDにとっては逆転のチャンスだ。
しかしそれは私が思っていたより早そうだ。インテル、64ビット戦略を変更--新「CT」チップでOpteronに対抗 の記事では、Intel製の64ビットx86を2月半ばにも公開するらしい。チップのリリース時期はおそらくその発表を待たなければならないが、今年の後半には64ビットの開発環境が揃う。Windows がItanimumとOpteronで走り、.NET Framework の64ビット版もリリースされる。それに間に合うなら、このCTチップはOpteronの強敵となろう。
それに間に合わないとなると、最初の数年はItaniumが大幅に落ち込み、Opteronの独り舞台となるように思える。
上の記事では、Itanimum対CTとなっているが、その図はありえないと思う。Itanimumには将来はない。Opteron対CTになるだろう。そしてそれはIntelの初動ミスにより、32ビットのIntel対AMDとは逆の図になるかもしれない。
3年前、.NET を始めたころに Win32 API と .NET Framework の置き換えマップ があれば、と思っていたが、MSDN で公開された。英語だが、API のリストなので十分だろう。
.NET をこれから始める人には役立つのではないだろうか。.NET は java と比べてもクラスの数が格段に多い。とっかかりで一番困るのは「～をやるのにどのクラスを使えばいいか」ということだろう。Win32 に慣れている人なら、このマップで探せるだろう。
SPOTというコード名でマイクロソフトが開発していた腕時計が米国では発売になった模様。Fossil や MSN Direct などにページができてる。早々と 基板の写真 まで公開。以前のニュース によればシチズンもパートナーに入っているので、日本でも出ないかなぁ。FM受信なので、ハードは作れても、コンテンツが難しそう。
知っている人が意外に少ないようだがこのSPOT、TinyCLRという.NET Frameworkの機能縮小版をそのまま実行するチップが乗っているという話。CLRというのは、Javaで言うVMのようなもの。なんだか面白げである。
Windows CE ベースの携帯電話 SmartPhone も日本ではちっとも出る気配がない。日本の独自仕様の多さと政官にがっちり守られた領域で売り込みに苦労しているのか。
絵文字などの日本独特の小技はもちろん日本の携帯の方が得意だが、Outlook ときれいに同期してくれて、ミーティング中は自動的にマナーモードになるなど、PC 中心の生活を送っている私にとってはかなり理想の携帯なんだけど、市場が見込めないのかなぁ。
「プログラマー」と言っているので、たまにはその話をしよう。
うちは .NET 系の仕事がほとんどだが、Pocket PC の .NET Compact Framework という仕事が1件ある。Pocket PC / Windows CE の開発は、Visual Studio .NET 2003 と .NET Compact Framework がリリースされて大きく改善された。足りない部分もたくさんあるが、Windows 版と同じ Visual Studio .NET で、同じ言語で開発ができるメリットは大きい。Compact Framework 用に書いても少しコードを入れ替えるだけで PC で動作するので、ロジックの確認などは Pocket PC を使わなくてもできる。以前と比べて、開発効率は格段に上がった。
ただしパフォーマンスの問題は頭に入れておかなければならない。このソフトは座標計算とグラフィックスを多用するのだが、PC 上で動作を確認してから Pocket PC へコピーして実行したら、PC では 0.1～0.2秒で終わる画面描画に 50 秒ほどかかってしまった。ハングしたか、と思ってデバッガで見たら、ちゃんと走っているのだ。
多くの Pocket PC が利用する Intel ARM 系には浮動小数点プロセッサがない。割算命令もない。20 年ほど前の PC だと思えばいいだろうか。
早めに気が付いたので、浮動少数演算を固定少数演算に切り替え、設計を変えて割算を減らしたが、それでも10～20秒程度かかる。CPU は 400MHz で動作していると言っているが、400MHz の PC の CPU に比べ、メモリアクセスが遅く、またビデオも遅い。
最後には描画量そのものを減らし、スレッドを作って裏で描画をかけて体感速度を上げるなどの技巧を入れ、2～3秒まで持っていった。PC 用に作るよりもコードがずいぶん増えたが、こんな携帯デバイスでありながら、スレッドの API まで含めてきちんとそろっているあたりが Windows CE / .NET Compact Framework の利点ではある。
大変ではあったが、20 年ほど前の PC-9801F という 8MHz で動作する PC で CAD を作っていたころを思い出して、なんだか楽しくもあった。
.NET プログラミング | パソコン・インターネット | ファッション・アクセサリ | マネージメント | 家電的生活 | 携帯・デジカメ | 本
Recent Comments