« January 2004 | Main | March 2004 »

2004.02.29

Win32 API と .NET Framework の対応置き換えマップ

MSDN で Win32 API と .NET Framework の対応置き換えマップのの日本語版 が公開された。以前に紹介したもの の翻訳だが、便利。
自分ではいらない、と思っていたが、つい最近発見があった。マルチモニターに対応するコードを書く時、Monitor あるいは Display で検索していたがクラスが見当たらなかったので、P/Invoke でコードを書いていた。が、クラス名は Screen であった。Win32 API では GetMonitorInfo など「Monitor」を使っていたのだが、おそらくスレッド同期の Monitor クラスと混同しないため、名前を変えたのだろう。やっぱりちゃんと対応置き換えマップを最初に見ておくべきだったと反省。

| | Comments (8) | TrackBack (0)

2004.02.27

GC と Memory Leak

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 にはもう一つ問題があるのだが、それは次回に送ろう。

| | Comments (118) | TrackBack (1)

2004.02.26

IPv6 訂正

IPv6 と NAT について少し訂正。まず Global Use アドレスを持つことに対して、おそらく ISP には追加コストはかからないので、有料にする必然はあまりなさそう。IPv6 に対する投資コストをどう回収するかだけですね。
それとファイアウォールの懸念はそのままなのですが、IPv6 NAT というものはなく、IPv6 NAT を通して IPv6 をどう通すか、という話を少し混乱して理解した模様。Teredo (英語) の話をきちんと理解していなかった。簡単に言うと Teredo は、IPv4 NAT の先にある IPv6 マシン同士を P2P で接続するための技術。NTT コミュニケーションズの m2m-x に近いような気もする。
なんだか要素要素は理解しても、頭の中で有機的につながっている感じがしない。技術者的に有機的に知識が働くためには、やっぱり使ってみないとだめなのかなという気もする。

| | Comments (2) | TrackBack (0)

2004.02.25

Bluetooth in XP SP2

いつの間にか XP SP2 における変更点の文書 (英語) が更新されていて、Bluetooth の記述が入っている。2/20 更新というから、つい 5 日ほど前だ。
SP2 では、

  • PAN (パーソナル ネットワーク)
  • HCRP (ハードコピー印刷)
  • ダイアル アップ
  • HID (Host Interface Device と書いてあるが、おそらく Human Interface Device = マウス / キーボードなどの間違いと思われる)
  • Object push
  • Virtual COM ports
がサポートされ、Bluetooth コントロールパネルが追加されるとのこと。ヘッドセットがないのが個人的には残念。あと別筋からは、クラスドライバ化は行われないだろうとのこと。つまり、追加でプロファイルを書くのはあまり容易にはならないらしい。IDF で実際にチップまで動いている Wiress USB / UWB の方がどうも分がありそうな気もする。
ところで Windows の開発、特にネットワーク・IE 関連の開発をしているなら、英語ではあるが上の文書は読んでおいたほうがよい。XP SP2 ではセキュリティ強化のため、ある程度の互換性を犠牲にしても変更を入れる、という従来の SP では考えられない施策が取られている。
PC を使う側にとってもそうだが、ソフトを作る側にとってはより深刻に、安全にお金がかかる時代なのだ。

| | Comments (2) | TrackBack (1)

2004.02.22

NTT コミュニケーションズ m2m-x

IPv6 Business Summit で NTT コミュニケーションズの実証実験 が展示された模様。あまり詳細は書いていないが、SIP を使った IP 電話と同じようなアーキテクチャで P2P を提供し、家電同士をつなごう、というもの。ネット家電と NAT については前に少し書いたが、この m2m-x は正しい方向だと思う。NAT やファイアウォール超えについての一つの回答で、SIP 的なアーキテクチャを取ることは現時点でのベストな解だと思う。
NAT / ファイアウォール越えの時にどうやって外からつなぐかの詳細は見当たらないが、その辺が IPv6 のみで動くトリックなのだろう。IPv4 NAT では構造的にできないような気がする。IPv6 NAT についてはまだ勉強不足でよく分からない。
プッシュ型配信や NAT の先にあるデバイスへの接続の話は実際に数件来ていて、そろそろ勉強しないとまずいのだが、、、

| | Comments (411) | TrackBack (1)

Visual Studio "Whidbey"

Visual Studio の次版である "Whidbey" のスケジュールが流れ始めている。

  • Beta 1 は 6 月
  • Beta 2 は Beta 1 のフィードバック次第
  • Beta 2 には VS.NET であったような "live license" が含まれ、Beta 2 で作成したソフトを特定の制限つきでリリースすることができる
  • リリースは年内
というのが基本線の模様。
正直、Beta 2 とリリースは目標レベルで、Beta 1 の反応次第、というところだろうが、Beta 1 が 6 月であれば年内リリースは難しいだろう。よくて RTM が年内、そこから生産に入り、手に入るのは来年だろう。それでも "live license" を Beta 2 に入れる、という決断に、マイクロソフトの力の入れ方を感じる。実際 Whidbey には期待が大きい。近いせいもあるが個人的意見としては Longhorn よりも期待している。
さらには Technology Preview を検討 (英語) という話も米MSの社員から流れている。テストや安定化のプロセスを省いた定期的なビルドを提供しよう、という話。これは大いに歓迎したい。米MSの Whidbey サイト にはまだこの話は書いていないようだが、MS が新しい方向性を試行していることを歓迎したい。

| | Comments (0) | TrackBack (1)

2004.02.21

Intel の 64 ビット x86

先日 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 に急速に追いつくだろう。

| | Comments (0) | TrackBack (0)

IPv6 と NAT 越え問題

自分でずっと疑問に思っているのに誰も書いてくれないことの一つにこれがある。
情報家電にすべて IPv6 アドレスを割り振れば、NAT 越え問題が解決し、通信しあえる という話だ。
技術的に割り振れるだけのアドレス空間ができたところで、果たしてそうなるだろうか。
疑問の一つはセキュリティだ。うちでも時々ファイアウォールのポートを開けることがある。そうすると、即座に1日で10件程度のアタックが来る。だから、インターネットからアクセスできるPCの管理には非常に気を使う。すべての家電にグローバルアドレスが割り振られたところで、NAT やファイアウォールを外す気は少なくとも今のところは全くしない。
もう一つは費用だ。IPv4 のグローバルアドレスをもらうには、ISP にそれなりの費用を払う必要がある。IPv6 では無制限で無料にするのだろうか。無料でなければ、ユーザーはそれを負担するのだろうか。
IPv6 には期待はしているし、米国防総省のコミットなどもあるから普及する気はしているが、IPv6 推進派が「すべての家電にグローバルアドレスを」と言う度になんだか怪しい気がしてしまう。
グローバルアドレスを振ることは、NAT 越えを簡単にするわけではない。NAT をなくしましょう、と言っているわけだ。しかしそこに、セキュリティと費用の問題の回答は出ていない。
IPv6 と NAT 越えは別の議論でなければならない気がする。IPv6 はそのメリットがコストを超えれば普及するだろう。でもその時、NAT は残ると思う。少なくともファイアウォールは残る。自由な通信とセキュリティは相反する問題だ。
私自身はそれほど IPv6 に詳しいわけではないので、できれば IPv6 に詳しい人に、NAT 越え以外の IPv6 のメリットを教えて欲しいと思っている。
そして開発者としては、ネットワーク系の開発をする際に、IPv6 が使えたとしても NAT やファイアウォールを念頭に置いた設計を続けていこうと思っている。単一の解があるわけではなく、やさしいものでもないが、そうしなければいけない気がする。
こういう疑問を持っているのは私一人ではない気がする。上の記事のトラックバックにも セキュリティを気にする声 がある。これが IPv6 の不勉強による誤解であるなら、IPv6 に詳しい方に答えていただきたいものだが、、、自分で勉強しろということか。

| | Comments (1147) | TrackBack (3)

2004.02.19

Bluetooth 続きと UWB

Bluetooth に大きな期待 を書いたが、実はちょっと怪しげな雰囲気も流れ始めている。UWB (Ultra Wide Band) の標準化が遅々として進まないことに業を煮やし、MBOA が UWB SIG を旗揚げした。この記事はこれを若干ネガティブに捕らえているが、賛同者に Intel を含む相当数のメーカーが入っていることから、IEEE がやるよりもスムーズに進んでしまうかもしれない。2005 年に製品が出荷し、ドライバなどのサポートが順調に進めば、Bluetooth は厳しくなる。
まずスピードが違う。数百Mbps と、今の USB 2.0 程度のスピードが出る。次に UWB では上位層に USB, 1394 といった既存のプロトコルを載せる。チップの価格がどれくらいになるか分からないが、Intel がチップセットに載せてしまえば、USB のように一気に普及する可能性もある。既存のプロトコルが乗ればドライバの変更も小さく、かつ使い勝手もよくなるだろう。Bluetooth はドライバの不備と使い勝手の悪さを問題として持っており、これを解決できないうちに UWB が普及してしまえば将来はない気がする。この辺は、モバイルに最適化するためにゼロから再設計してしまった WML が普及し損ねて、HTML との互換性を保った i-mode の cHTML が普及したあたりに近い感覚がある。
とはいえ、今日段階では UWB は使えないので、とりあえず 5000 円ほどで PLANEX の USB Bluetooth アダプタ を買ってきた。使い勝手は大体想像通り、いまいち。圏内に入っても、手動で起動してやらないと接続してくれない。これは話を聞いていたので驚かなかったが、それにしてもいまいち。それでもないよりは便利。
意外だったのは、iPAQ h2210 の Bluetooth 設定ソフトがマイクロソフト製でなかったこと。CE 4.2 はプロトコルスタックとしては持っているはずだが、設定ソフトなどは持っていないのか。使い勝手の悪さはその辺にも起因しているのかもしれないが、きちんと作れば使いやすくなるのかどうか、そこまで Bluetooth プロトコルの知識がないので、、、結局マイクロソフトも様子見なのかもしれない。
DV でのみ 1394 が使われていて他が USB になってしまったように、2005~2006年あたりには携帯のヘッドセットだけが Bluetooth で、残りは UWB になってしまうかもしれない。
それでもとりあえず今のところ、コードレスマウスをノート PC につなぐのに Bluetooth がほしいんですけどね。

| | Comments (0) | TrackBack (2)

2004.02.15

CE.NET or XP Embedded?

技術が進んだことで、分野間の壁がなくなってきていて、いろいろな判断が難しくなってきている。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 の開発環境も拡充されるとのことだが、どこまでのものになるかは未発表のため詳細が不明である。これも調べが進んだらブロッグしてみたい。

| | Comments (24) | TrackBack (0)

2004.02.09

YamhillとAMD64の互換性

Intel の 64 ビット拡張 の詳細が少しずつ出てきている。PC Watch の記事 が詳しい。
メモリ空間はリニアになるのはほぼ決まったらしい。妥当だろう。実際今の IA-32 も物理アドレスとしては 256GB までサポートしている。これで足りないケースというのは本当に一部だろう。
64 ビット拡張でより期待されているのは論理アドレス空間だ。もっとも高速なファイルの読み書きはメモリマップだが、現在の32ビット仮想アドレス空間ではメモリマップを使ってしまうと1~2GB程度のファイルにしかアクセスできない。論理アドレス空間が広がることによって、大きなファイルを扱うプログラムをより自然に、かつより高速にすることができる。なので、「40bit物理アドレスにマップするなら、それ以上の仮想アドレスは必要ない」という PC WATCH の意見には合意できないが、それでも AMD64 の 48ビット (256TB) は当面じゅうぶんだろう。

| | Comments (5) | TrackBack (0)

.NET Frameworkの3つのタイマー

英語版のMSDNに .NET Framework の持つ 3 種類のタイマーについての記事 が掲載された。まったくもって分かりにくく、かつ API に互換性のないという不思議な 3 種類のタイマーを概説している。
でも確かサービスなどのメッセージポンプを持たないプロセスで使えるのは System.Threading.Timer だけだったと思うのだが、それは書いていない。
.NET になってスレッドプログラミングはずいぶんやりやすくなったが、冷静に考えると今までがひどすぎただけかもしれない。メッセージポンプとCOMのアパートメントモデルから抜け出せるにはあと何年かかかるのだろうか。Longhorn はそのほとんどをマネージドの API として提供する。どこまで改善してくるか期待したい。

| | Comments (32) | TrackBack (0)

2004.02.06

HP iPAQ Pocket PC h2210

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 になって割と大きく変わっており、プログラマーとしては楽しみな限りだ。

| | Comments (6) | TrackBack (2)

セキュリティーと文化レベル

PCのセキュリティが問題になっており、Windowsにバグが多いとか、Linuxの方が多いとかという議論になっているが、どうも焦点がずれている気がする。
平和な村の時代には、家のドアに鍵はなかった。古代にはドアすらなかった。でも今は、ピッキング防止の鍵がしっかり付いている。泥棒に入られて、「この家は鍵が弱いから悪い」と政府が鍵メーカーに言うだろうか? 文化人類学の専門家ではないが、ある程度以上の文明には犯罪が付いて回るもので、犯罪者はゼロにはならないという前提で、家の鍵のような各個が行う犯罪防止と、警察のような公的な防止機構とが必要になってくるものなのではないだろうか。
PCは、村の時代を過ぎてしまった。それはさびしいことではある。現代でも都会に犯罪が多いことを嫌がる人が多いと聞く。しかし残念ながら後戻りはできず、またインターネットには都会も地方もない。
だから、犯罪者がいて、泥棒に入られる可能性がある前提で考える必要があると思う。
マイクロソフトの動きはその考えを感じさせる。Windows XP SP2でパーソナルファイアウォールがデフォルトでオンになる。RPCも制限される。これらの取り組みが家の鍵になるのだろう。Linuxはまだそれほど多くの攻撃を受けていないのでその辺の歩みは遅い。しかし数が増えれば攻撃を受け、同じ対処をしていくだろう。
警察としての機構も少しずつだができていくだろうが、こちらの方が歩みは遅いかもしれない。公的立場の方々の多くの意見がWinodwsの脆弱性についてしか語っておらず、Linuxにしても何も変わらない事に気が付いていない。脆弱性の問題ではなく、PCの文化レベルの進化過程なのだ。
犯罪者をしっかり検挙し、最低限のフィルターをIXやISPレベルで行う。村にだって自衛団や消防団ができるのだ。ISPだって法律を待たずにフィルターを入れるべきだと思う。@nifty でもスパムフィルターを始めたよう に、ISP でのフィルターはやっと市民権を得始めた気がする。まだ足りないと思う。ISP はある種水や電気のような公共サービス的な側面を持つと意識して、そのサービスを受ける市民の安全のためにより必要なフィルターを入れていくべきだろう。
ISPによって差は出るだろう。NYと東京の犯罪発生率が違うように。それはそれでかまわないと思う。努力の足りないところは淘汰されていくだろうから。より安全な地域があるように、より安全なISPもありえると思う。

| | Comments (351) | TrackBack (0)

« January 2004 | Main | March 2004 »