Windowsアプリケーション開発用言語の事実上の業界標準がVisual C++だ。WindowsアプリケーションといえばWord、Excel、PageMaker、Designer程度と数も少なかった頃から、それらの開発に使われてきた。新しいWindowsがリリースされるたびにVisual C++も新しくなり、最新のVisual C++.NETではWindows XPに完全対応した。さらにXML Webサービスにも対応するなどVisual C++は進化を続けている。

■Windows 2000/XPで導入されたユーザインターフェイスや
2038年問題にも対応できるMFCライブラリ 7.0を搭載

　Windowsアプリケーションの開発者にとっての興味は、Visual C++ 6.0との違いだろう。最新のWindowsであるWindows XPでも、Visual C++ 6.0で作成したWindowsアプリケーションのほとんどが問題なく動作する。Windows 98/Me/2000での確実な動作も考えればVisual C++ 6.0を使い続けるのが適当かもしれない。しかし、Visual C++.NETにはWindows 2000/XPで導入された新しいユーザインターフェイス（図1〜2）に対応したMFC 7.0（Microsoft Foundation Class 7.0）が搭載されている。Internet Explorer 6などすでにMFC 7.0を利用しているアプリケーションもあるのでおなじみの方も多いと思うが、一般ユーザでもVisual C++.NETを使うことでMFC 7.0を利用したWindowsアプリケーションの作成が可能となる。

図1 Windows 2000以降に搭載されている新しいファイルオープンダイアログ

図2 Windows 2000以降に搭載されている新しい印刷ダイアログ

　また、MFC 7.0には2038年問題に対応するための64ビットの日付時刻関数が搭載されている。以前のバージョンのVisual C++を含む多くのCの処理系では、1970年からの経過秒を32ビットで表現しているため、2038年1月18日19:14:07（日本時間では2038年1月19日12:14:07）でプログラムが停止したり日付が戻ったりするという現象が発生する。これが2038年問題だ。2000年問題の再来を防ぐため今から64ビットの日付時刻関数を使っておくことをお勧めする。64ビット版の日付時刻関数を使えば3000年12月31日まで大丈夫だ。さらに、MFC 7.0にはDynamic HTMLの表示や編集を行うためのクラスも追加されている。


■MFC 7.0ではMFC 4.2は非互換
MFCライブラリ名を、これまでとは別の名前で提供

　Visual C++ 4.2以降、MFCライブラリはmfc42*.dllで提供されていた。Visual C++ 5.0とVisual C++ 6.0ではそれぞれMFC 4.21、MFC 6.0と機能が拡張されてきたが、MFC 4.2との上位互換性が保たれており、ファイル名「mfc42*.dll」に変更はなかった。このため、最新のMFCアプリケーションを動作させるにはmfc42*.dllを最新のものにしておく必要があった。

　バージョンを確認しないでmfc42*.dllを上書きしてしまい、アプリケーションが動作しなくなるといった現象を経験したユーザもいるに違いない。ところがMFC 7.0ではMFC 4.2との互換性がなくなったため、「mfc70*.dll」というファイル名で別にMFCライブラリが提供されるようになった。次のバージョン以降ではmfc70*.dllの名前が変わらず機能が追加されてゆくのか、新たな名前のDLLが提供されるのかは気になるところだが、Visual C++.NETであらたに作成したアプリケーションはmfc70*.dllを使うことになり、mfc42*.dllのバージョンを考慮しなくてもよくなった。


■グラデーションやアンチエリアスをサポートした
新しい描画エンジンGDI+に対応

　Visual C++.NETはグラデーション、アンチエリアスやアルファチャンネルをサポートした新しい描画エンジンGDI+にも対応している。アンチエリアスはWindows XPの新しいフォントスムージング技術に利用されている。アルファチャンネルはフェード効果などで半透明な描画（図3）を実現するために使われており、どちらもWindows XPの新しいGUIの特徴だ。

　GDI+はWindows XPに標準搭載されている機能であるが、Windows 98/Me/NT4.0/2000でもgdiplus.dllを同時に配布することでその機能を使うことができる。

図3 アルファチャンネルを使った半透明の描画の例

■ .NET Frameworkへの対応
Windows＆Webアプリケーション開発環境へ

　Microsoftが提唱する.NET Frameworkは、Windowsばかりでなくインターネット上の分散アプリケーションのプラットホームでもあり、その開発ツールであるVisual Studio.NETは、これまでのWindowsアプリケーション開発環境からWindows＆Webアプリケーションの開発環境となった。

　Visual C++.NETにもこれまでのバージョンと同じWindowsアプリケーション・クラスライブラリなどの作成機能に加えて、Webアプリケーション・Webサービスなどの作成機能が追加されている。新規に作成できる主なプロジェクトは以下のとおりだ。

表1　作成可能なプロジェクト ATLサーバWebサービス ATLサーバを用いたXML Webサービス ATLサーバプロジェクト ATLサーバを用いたWebアプリケーション ATLプロジェクト Active Template Libraryを用いたWindowsアプリケーション Managed C++Webサービス Common Language Runtimeを利用するXML Webサービス Magaged C++アプリケーション Common Language Runtimeを利用するWindowsアプリケーション Managed C++クラスライブラリ Common Language Runtimeを利用するクラスライブラリ MFC Active Xコントロール MFCを用いたActive Xコントロール MFC DLL MFCを用いたDLL MFC ISAPI DLL MFCを用いたISAPI DLL MFCアプリケーション MFCを用いたWindowsアプリケーション Win32プロジェクト コンソールアプリケーションなどのWindowsアプリケーション

■ISAPI DLL開発を簡略化するATLサーバを搭載
サーバサイドWebアプリケーション構築の簡略化

　これまでVisual C++を使ったサーバサイドのWebアプリケーション作成には、ISAPI（Internet Server Application Programming Interface）DLLを作成し、WebサーバであるIIS（Internet Information Server）に組み込む必要があった。VBScriptやJavaScriptを使いASP.DLLを利用するActive Server Pagesに比べてISAPIによるサーバサイドWebアプリケーション作成は難しく、気軽に取り組むことができるとは言い難い。しかしながら、VBScriptやJScriptでは十分な処理速度を得ることはできず、やむを得ずISAPI DLLの開発に取り組んだ開発者もいるのではないだろうか。

　そんなWebアプリケーションの開発者には朗報だ。Visual C++.NETにあらたに搭載されたATLサーバはISAPI DLLの1つであり、Visual C++.NETで作成したWebアプリケーションDLLとの橋渡しをする機能を持っている（図4）。これを使うことで、Webアプリケーション開発者は面倒なISAPI DLLの開発から解放され、Webアプリケーション独自の機能の部分だけに集中できる。ASPでは十分な処理速度を得られないサーバサイドWebアプリケーションをこれまでより短期間で構築できるようになるだろう。

図4 ATLサーバの仕組み。ユーザが作成するのはWebアプリDLLだけでよく、ISAPI DLLの開発からは解放された