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