Vistaについて、登載される予定の機能からプログラマーの視点まで視野を広げてあれこれ書いたものです。Vistaについていろいろ考えてみましょう。開発に時間がかかってるの、たいして進歩していないだのとマイナスな評価をうけることも多いようですがそこのところを考えてみましょう。開発が遅れに遅れているのは有名で、2004年にはリリース予定だったものが未だにβ版なんです、これが。なんでこんなことになったのかを考えてみると答えは簡単で、「予定がもともと無理だった」に尽きます。Microsoftがどういうつもりで2004なんて無謀な日付を出してきたのかはわかりませんが、Mirosoftの発売日が延びることは今に始まったわけじゃないので別に今更大騒ぎすることもないのかもしれません。OSには毎回適当な名前がついておりますが、それほとは別にバージョンと呼ばれている物があります。マーケティング関係で真剣に名前を考えている人がいるのでしょうから適当といっては怒られちゃいますね。NT系と3.1系は全然違うものから来ていて、開発チームも違うので別々にならべました。ここで、コンシューマ向けをぱっと見ると、Win95→Win98→WinME→WinXPと2-3年でアップデートされているような気がします。ここから2004年の登場ってのが本当なような気がしてしまったのでしょう。んがしかし、よく見てください。バージョンアップには2種類あって、マイナーアップとメジャーアップがあります。上のWin95→WinXPまで全部マイナーアップデートなのです!さらによく見ると、メジャーアップデートはWin3.1→Win95の3年、WinNT4.0からWin2000の4年と来ているわけで、WinXP→WinVistaの4年というのもぜんぜん普通だということがわかりますよね?次回はVistaの性能について書こうと思います。ちなみに、私はゲイツ氏に忠誠を誓ったMicrosoft信者なんでそこのところはご了承を。Vistaは、あんまり性能が向上していないというウワサが飛び交ってます。いいますか、搭載させるハズの目玉の機能が次々に延期やキャンセルされてしまったらしいのです。Longhornの目玉の新機能は、インターフェースのAvalon、ファイルシステムのWinFS、新APIのWinFXなどだと私は思います。AvalonはLonghornが遅れすぎたのでWinXPでも提供されるとかで、WinFSはこれ自身が遅れすぎて実装を延期、さらにWinFXは全面的に移行するとかなんとか言っていたのだけれどもなんだか影が薄くなっています。Longhornが登場当初から持っている独自の新機能ってのはあんまりないらしいのです。ジョンアップでものすごく進歩していたかというとそうでもありません。いうか、「どこが大きく変わった?」と聞かれても、「どこというか、そこはかとなく進歩した程度」としか答えられないのではないでしょうか。Win95→Win98なんて、安定性やら対応機器が増えた程度ですし、WinMEに至ってはDOSを廃止したとかでしょうか。WinXPの時は大きく変わったと言われていますが、それもそのはずでWin3.1系からWinNT系に乗り換えたのですから変わっても当然です。それでもフル32bitになっているという点を除いて、なんか重大な機能が追加されているというワケでもなかったと思います。今までもWindowsはマイペースに、それでいても確実に進歩していたというワケで、突然今になって大幅な進歩を求めるというのもナンセンスでしょう。OSの新バージョンがでると新機能とは別にして、安定性が向上して、新機能への対応が行われることが通例です。これで良いのではないかと私は思うのです。ことで、2回にわたってMicrosoftを擁護しまくって続きはまた次回へ。次回あたりは各機能を見ていきましょう。今回はインターフェースのAvalonについて少し考えてみましょう。これ、WinVistaを待たずしてWinXPにも提供されるとかいう話なんですが、実際どの程度提供されるのかは謎です。いずれにせよWinVistaにはフルスペックなのが提供されると思います。これって、今で言うDirectXでGUIを描画するような仕組みになると言われています。今はウィンドウとか陰と反射を画像でうまく表現して3D風に描画してますが、これはれっきとした2Dです。これを本当に3Dで描画させてしまおうというのがAvalonです。GUIが3Dになると聞くと、どうもデモ等で使われるアングルを変えてとかウィンドウを回転させるとか普段は滅多に使わないような機能が浮かびますが、こんなものは最初おもしろがって使ってしばらくするとお蔵入りというのがほとんどのパターンでしょう。実は3D化されるだけで一般的に利用価値のあるメリットもあります。今の方式だと、重なったウィンドウは上だけ描画されますし、仮に下も描画したとしても上書きされるだけで意味ありません。ところが、ここを3Dで描画するとウィンドウ同士が重なっていてもウィンドウはそれぞれ全体が描画されて、それを重ね合わせて表示します。従ってウィンドウの切り替えなどで隠れている部分が表示されていてもチラツキがなく素早く描画できるようになります。現在のグラフィック機能には3Dゲーム用の高性能なグラフィック機能が搭載されているのですが、3D演算部と2D演算部はまったく別で3D演算部が強化されても2D描画が改善することはほとんどありません。現在は2Dは性能向上の限界が来ており3D演算部の向上が焦点となってます。高価なグラフィック機能を搭載していたとしても、3Dゲームでもしなければ、標準GUIではその性能を発揮することができないのです。ここは悩ましいところで、2D演算部はもう充分な性能があるので性能強化が行われていないとも言えるので、3D化してわざわざ高価な3D機能を必要条件とするのはムダとも言えなくもなりません。安定性に関することでもメリットがあります。4.0では速度が重視されるグラフィック関係の機能を高速化させるために、それまでのWinNT3.51によりもハードウェアを直接に近い形で実行するように変更しました。これにより描画速度は向上しましたがGUIまわりの安定性は低下してしまいました。今回DirectXを介するようになったことで、OSの中枢となるカーネルはより安定性が向上することになるのです。Avalonは今までのWindows史上初めて2Dから3DへのGUIへの変更であり、さらにWin95から10年以上慣れ親しんだあのGUIから新GUIへの移行という大きな役割を持っているのです。次回辺りは他の機能も見てみることにしましょうか。今回はWinFXについてです。いうか、この辺はあんまり話題にあがらなくなってるんですけどどうなったんでしょうね。普通な方々はWindowsがアプリケーションにどんな役割を果たしいるのかあまり知らないと思うのでその辺を少しご説明いたします。Windowsを含むOSはパソコン(ハードウェア)とアプリケーションの中間に挟まって仲介を行います。例えるなら中間管理職みたいな感じです。社長(まぁ本来は企画部の人がするんでしょうけど)が企画を打ち立てますよね、ここでどんな手順でその企画を実現するのかを考えて、実際に部下に指示を与えるのが中間管理職ですが、こんな感じです。ここで社長がアプリケーションで、部下がパソコン(ハードウェア)です。APIと呼ばれるAPIを提供しています。一例をあげるなら『CreateWindow』という関数をアプリケーションが実行することでウィンドウが作成されます。細かいことは全部Windowsがやってくれます。実は多くのアプリケーションが似たようなウィンドウの形をしているのは、同じ関数を使ってWindowsに作らせているからなのです。Win32APIと呼ばれるようになりました。APIと呼ばれてます。Windowsにアプリケーションが使う新機能が搭載されると、それを使うためのAPIが追加されます。APIはWindowsがバージョンアップされる毎にすこしずつ数を増えていき、今やウン万あるとかなんとか。新旧入り乱れてもはや収集のつかない状況になっているのです。普通に考えれば全部を体系的に整理してあらたに作り直そうじゃないか!となりますよね。実際にはもうちと複雑なんですがまぁ簡略化すればそんな感じです。APIの関係についてお話します。体系的に整理されたAPI、WinFX。すばらしい発想に見えますが、実は良いことづくめではないのです。今までのプログラマー(アプリケーションの作者)はウン万あるこのAPIを全部でないにしろ沢山覚えてしまってます。これから新しいのを覚えるなんてまっぴらと思う人も少なくないでしょう。実はWindowsは昔から古いユーザーを非常に大切にしていて、古いもののサポートがとてもよいのです。APIもサポート続行することになります。そのサポート方法が問題になります。APIに変換して実行するという方法です。これによりOSのコアが実行するのはWinFXのみになり安定性は向上します。APIは内部で変換する分実行速度が遅くなります。APIを使うアプリケーションはないので、ほとんどのアプリケーションが遅くなることになりWindowsVistaの乗り換えの妨げになるかもしれません。APIはOSの内部で。いう方法も考えられます。この場合は上と全く反対の利点と欠点が生まれます。これから積極的に推し進める側のAPIが遅くなるというものナンセンスなものですし、ごちゃごちゃになってしまったAPI群をそのまま残すというのも不安が残ります。Microsoftはどういう選択をしたかというと、両方をそのまま実装する方法をとりました。昨今はパソコンの性能が向上して速度はそれほど問題ないとはいえ、APIレベルでジワジワと時間がかかればアプリケーションからするとかなりの速度的ペナルティになると考えたようです。APIが今まで通りちゃんとサポートされるという点でしょうか。今まで通り使えるなら、今使っている多くのプログラマーがそのままWin32APIを使うのではないかという点です。あらたにプログラミングを始めたプログラマーがWinFXを使い始めたとしても、その人達が大勢大規模なプログラムプロジェクトに参加するほどに育つまでは、WinFXは微妙な立ち位置になってしまうのです。APIよりも体系的に纏めたものを作る試みはすでに行われていて、クラスという技術を使ったMFCとよばれるものがあります。APIを使ったプログラミングを、クラスを使って体系的にまとめて、多くの部分を自動化したものということらしいです。APIにはウィンドウを作るならばCreateWindowでできますが、終了操作とか、ファイル開くとかがいちいち記述する必要があります。そこでクラスこの辺を全部自動でやってもらって、必要な部分だけ自分で書き加えるというのがMFCということです。超多忙なマンガ家を例にするならば、背景とかエキストラは全部アシスタントが書いてくれて、先生はキャラクターの重要な部分だけ書くとか。そんなわけで標準的なプログラムを作るのには大幅な労力の削減に繋がり企業なんかでは便利な限りです。APIよりも面倒だったりするのです。正確に言うと、みんな自動でやってくれるので、自分が作ったプログラムでも内部でどんな風になっているのかよく分からないので、いざ手動でやるときにどこを変更すれば良いのか分からないというのが原因らしいのですが、まぁいずれもプログラマーの腕次第ですけれども、MFCが爆発的に普及したわけではないと考えると良いことづくめではなのかもしれません。Microsoftは、体系的に関数を纏めるのをさらに発展させて、C#という新たな言語まで作ってしまってます。次回は言語についてもちっと語ってみましょう。2006年02月05日プログラムの言語でもっともポピュラーと言えるのがC言語です。ちなみにWindowsもC言語で書かれているそうですよ。C言語は高速で汎用性が高いのがウリで現在まで幅をきかせていますが、なによりもほとんど全部プログラマーが面倒見るというのが特徴だと思います。思い通りに動かせる反面、思い通りに動かすのにはかなりのスキルが必要になります。メモリ系の処理はCはとても面倒です。C言語よりも新しい言語で有名なものとしてJavaという言語があります。Javaは後発なだけあってCよりも進んでいます。メモリの管理はシステムが適切にやってくれるとかで、関数等も体系的に纏められているのでプログラミングはCに比べるとシンプルにできるようです。Javaのもう一つの利点として、プラットホームに依存しない言語であるところです。用プログラムとLinux用のプログラムは別々に作る必要があります。ところが、Javaは各プラットホーム上で実行されたJava仮想マシンとよばれるシステム上で実行されるので実行環境に依存しないのです。Windows上でもLinux上でも、Javaのプログラムから見ればJava仮想マシンというシステム上で実行されているので同じように振る舞うことが出来るのです。これのおかげでiアプリは異なるOSを積んだ携帯電話でも同じものが実行できるのです。逆にそれが災いして速度が遅いという欠点もでてきたわけです。これだけメリットがありながらC言語に幅をきかされているのは、速度が遅いのとCでできてもJavaでできない事があるのが致命的になっているようです。Basicという言語も有名です。これはとにかくとっかかりが優しい言語で、Windowsの簡単なプログラムを作るのにはもっとも楽な言語とのことですが、あまり複雑になると面倒らしいですね。そんな既存の言語を知った上で、CをベースにJava風のプログラマーに優しい機能を満載したのがC#といったところでしょう。Javaの体系的に纏められた関数や、メモリ管理を適切にやってくれる所なんかはC#でも採用しているらしくて便利なようです。Flameworkってのがあるんですが、これこそJavaで登場した仮想マシンと同じようなものです。今はほとんどWindowsしか対応していませんが、Linux等でも実装する活動をしているようです。この.NET上で各プログラムが実行されるので、.NETに対応した環境では同じプログラムが動くという代物です。別々にLinux用とWindows用、MacOS用とそれぞれのバージョンがあるプログラムが一つのプログラムで対応できるようになるというモノなわけです。新しく登場したJavaが完全にC言語を置き換えなかったことを考えると、動作が遅いのとCにできてJavaにできないことがあるのが原因と言えます。逆に言えば、Windowsが完全に.NETFrameworkをベースにしてしまえば、動作の速度も差が縮まりますし、出来ないこともなくなります。Frameworkをベースにするつもりだったようです。Framework用の新しいAPI群というわけです。APIの雲行きが怪しくなってきたという話を次回あたりにしましょう。FrameworkはJavaの仮想マシンと同じような概念ですが、Javaの仮想マシンは言語に依存する(要するにJava専用)わけですが、.NETは基本的にCやC#を筆頭に他の言語にも対応します。Microsoftご推奨なんで、Windowsの全面的なサポートが約束されており、Cで出来るけどJavaにはできないようなこともおそらく無くなる方向でしょう。なると、問題になるのは速度となります。仮想マシンはOSの上を走るので、仮想マシン上を走るアプリケーションは仮想マシンの分動作が遅くなります。そこでOSのベースそのものを.NETにしてしまえば、速度低下を最小限に抑えることができるというのが前回までのあらすじですね。そこでVistaでは全面的に.NET化を行おうと初期の草案で考えていたようです。ところがで、APIの時もお話しましたが、APIのような基本部分に関わる箇所が遅くなると、それが若干であっても積もり積もってユーザーには大変遅く感じられるようになります。ただでさえ、アンチMicrosoft派が、遅いだの重いだの騒いでいるのに、これ以上速度が遅くなると何を言われるか分かりません(笑)。アプリケーションの開発がやりやすくなれば値段が下がったりより品質の高いものがリリースされるわけで、最終的には我々に返ってくるわけですが、少なくとも今すぐにメリットがないものなだけに消費者には理解してもらえない可能性が高いです。なると、.NETをベースにする計画は撤回されてしまったようです。Frameworkが登載される予定なので現行OSのように後から付け足したよりかは動作速度はマシになるでしょうが、ベースはあくまで今までのWindowsと同じ感じです。APIがそれぞれ別個に搭載されるという新旧入り乱れたトンデモなシステムになってしまいそうな感じです。APIに対するアドバンテージがそれほどないと、将来的に今まで以上に混乱を期すことになってしまいます。APIが混乱の原因となっては目も当てられません。個人的にはIEやWMPなど無料ソフトが威力を発揮すると考えています。Flamework上で実行させる今までのOSと、ベースが.NETになっている新OSとでは後者の方が動作速度が速くなるわけです。そこでOSの乗り換えを促すという寸法です。それでも現時点では無理かも知れませんね。APIの浸透にはCへの対応が不可欠だと思います。MicrosoftはC#への移行を促していますが、言語の変更は開発者に大きな負担になります。APIレベルの名称の変更だけならば言語の変更ほど大きな負担にはなりません。FXへの書き換えはどうやれば良いのかのツールチップがでるくらいの配慮があればだいぶ楽ですね。APIよりも便利な関数を増やしたり、バグを減らすなどの付加価値を加えれば移行にそれほど時間はかからないと思います。次のメジャーアップデートは4年くらい後ですから、その頃には.NETをベースにしても全然問題なくなっているのではないでしょうか。