Windows XP がもたらす Visual Basic デベロッパーへの福音

[アーティクル]
10/20/2021

～第 2 回: 新しいサイドバイサイド技術～

Shozo Arai (荒井省三)
マイクロソフト株式会社
デベロッパー・マーケティング本部

February 7, 2002

はじめに
COMCTL32.DLL バージョン 6
ActiveX DLL でのサイドバイサイドの利用
まとめ
次回について

はじめに

前回は Windows XP の視覚スタイルの概要と Visual Basic 6.0 を使って視覚スタイルを利用した Visual Basic アプリケーションの作成方法と問題点を説明しました。今回は、視覚スタイルの裏側で活躍している COMCTL32.DLL バージョン 6 や Windows 2000 から更に進化したサイドバイサイド技術の説明と Visual Basic で作成する ActiveX DLL において、どのような恩恵があるかを説明いたします。

COMCTL32.DLL バージョン 6

Windows XP では、COMCTL32.DLL のバージョン 6 が新しく導入されています。この COMCTL32.DLL を使って視覚スタイルを表示しています。テーマの切り替えは、テーママネージャ Uxtheme.dll を通じて COMCTL32.DLL のバージョン 6 とバージョン 5 を切り替えることで行っているのです。COMCTL32.DLL のバージョン 5 (図 1 ) とバージョン 6 (図 2 ) について説明します。Windows 2000 のコントロールでは、

図1. Windows 2000 のコントロール

図 2. Windows XP のコントロール

USER32.DLL、WIN32.SYS や COMCTL32.DLL バージョン 5 にコントロールが組み込まれています。Windows XP では、USER32.DLL、WIN32.SYS や COMCTL32.DLL バージョン 5 に含まれているコントロールを統合した COMCTL32.DLL バージョン 6 が存在します。Windows XP では、明示的に COMCTL32.DLL バージョン 6 を使用すると宣言しない限り、COMCTL32.DLL バージョン 5 が使用されます。このように、COMCTL32.DLL の複数バージョンがサイドバイサイド技術を使って共有されています (Windows 2000 では、EXE 名 .local というファイルを配置することでサイドバイサイドを実現していました。詳しくは「アプリケーションで共有するサイドバイサイドコンポーネントの実装 (拡張)」をご参照ください)。この技術は、.NET Framework をフルサポートすることを目標に DLL Hell の解消、バージョン競合の解消、容易な配置、容易な環境設定 (NoMore リブート) をサポートすることを前提にしています。この目標を達成するために Windows XP では、COMCTL32.DLL バージョン 6 や GDI + 等を共有アセンブリとして組み込んでいます。共有アセンブリのインストール場所は「%SYSTEMROOT%\WinSxS」です (通常は、C:\Winnt\ WinSxS です)。共有アセンブリと従前の %SYSTEMROOT%\SYSTEM32 にインストールされる共有 DLL の主要なものを表1に抜粋します。

配置場所

サブディレクトリー又はファイル名

説明

WinSxS

Manifests

共有コンポーネントのマニフェスト

x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_x-ww_1382d70a

COMCTL32.DLL V6コンポーネント

x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.0.0_x-ww_8d353f13

ＧＤＩ＋コンポーネント

x86_Microsoft.Windows.CPlusPlusRuntime_6595b64144ccf1df_7.0.0.0_x-ww_2726e76a

VC++のランタイム

x86_Microsoft.Tools.VisualCPlusPlus.Runtime-Libraries_6595b64144ccf1df_6.0.0.0_x-ww_ff9986d7

x86_Microsoft.Tools.VisualCPlusPlus.Runtime-Libraries.Resources_6595b64144ccf1df_6.0.0.0_ja-JP_8a84acaa

System32

COMCTL32.DLL

COMCTL32.DLL　V5コンポーネント

MSVCRT.DLL

VC++のランタイム

表1.共有アセンブリの抜粋

共有アセンブリが導入されたことにより、VC++ のランタイムや COMCTL32.DLL を原因とする DLL の競合は解決されます (思い起こせば、IE3.X がリリースされたときの問題が解消されるのです)。このサイドバイサイドの仕組みをご覧になられた方は、「あれ？」と思われたかもしれません。「マニフェスト」「アセンブリ」という用語をどこかでお聞きになられた方達も多いことと思います。そうです、.NET Framework の配布単位がアセンブリと呼ばれ、アプリケーションの自己記述情報 (バージョン情報や関連モジュール情報等) がマニフェストと呼ばれていたのです。このサイドバイサイド技術は、Windows 2000 と Windows 98 Second Edition に始まり、.NET Framework 向けに進化し、Windows XP で Platform 向けに最適化されて進化してきたのです。

WinSxS にインストールされる共有アセンブリは、.NET Framework と同様にストロングネームを必要とします。インストールするには、Windows Installer でインストールを行う必要があります。このように共有アセンブリは厳密に管理されますので、DLL の競合が発生する可能性を低くすることが可能になるのです。後は、皆さんが配布されるアプリケーションのインストールフォルダに共有コンポーネントも一緒に配布して、アプリケーションマニフェストを配置すれば DLL Hell から脱出することが可能になります。今後は、%SYSTEMROOT%\SYSTEM32 フォルダに共有コンポーネントを配布しないようにすれば良いのです。ここまで読まれた方たちは、「関数をエキスポートできるダイナミックリンクライブラリは Windows 2000 でも実現されていたし、COM に関してはどうなんだ？」という疑問を持たれたことと思います。Windows 2000 では DLL/COM リダイレクションがありましたが、Windows XP では更に進化した COM のサポートがあります。

ActiveX DLL でのサイドバイサイドの利用

これから Visual Basic で作成する ActiveX DLL のサポート (COM のサポート) がどうなったのかについて説明していきたいと思います。手始めに、簡単な ActiveX DLL (リスト 1 ) と利用する Visual Basic アプリケーション (リスト 2 ) を作成してみます。このアプリケーション (Project1.exe) を実行した様子を図 3 に示し、レジストリの情報を図 4 に示します。

Public Function Add(ByVal lngA As Long, ByVal lngB As Long) As Long

'   ActiveX DLLの例

'   加算結果を戻すメソッド

'

    Dim lngResult As Long

    lngResult = lngA + lngB

    MsgBox "結果=" & CStr(lngResult), vbOKOnly, "Side-by-Side Comへようこそ"

    Add = lngResult

End Function

リスト 1. ActiveX DLL (プロジェクト名: ComTest、クラス名 : SideBySide)

Private Sub Command1_Click()

'   ActiveX DLLを利用するアプリケーション

'   ProgId=ComTest.SideBySide を使用する

'

    Dim objComTest As ComTest.SideBySide

    Dim lngResult As Long

    Set objComTest = New ComTest.SideBySide

    lngResult = objComTest.Add(CLng(txtA.Text), CLng(txtB.Text))

    txtResult.Text = CStr(lngResult)

    Set objComTest = Nothing

End Sub

リスト 2. ActiveX DLL を利用する Visual Basic アプリケーション (プロジェクト名 : Project 1 )

図3. Visual Basic の ActiveX DLL を実行したところ

図4. ComTest.SideBySide のレジストリ登録情報

図 3 と図 4 を見れば、VB で作成した ActiveX DLL の動作としては当たり前の動作をしていることをご理解いただけることと思います。それでは、コマンドプロンプトで「Regsvr32.exe /u ComTest.dll」を実行し、その結果のレジストリ登録情報を図 5 に示します。

図5. ActiveX DLL を削除した状態のレジストリ情報

図 5 を見ると、きれいにレジストリの登録情報が削除されていることがわかると思います (Windows 2000 までは、レジストリにキーのみのゴミが残っていたことをご存知の方も多いかと思います)。これで、さきほどの「Project1.exe」を実行しても、実行することはできなくなります (図 6)。この動作は、レジストリに ActiveX DLL の登録情報がありませんので当然のこととご理解いただけると思います。

図6. Project1.exe の実行時エラー

次に、アプリケーション　マニフェストをリスト 3 のように記述します。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 

    <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" 

                      name="Microsoft.SidebySide.Test" type="win32" /> 

    <description>サイドbyサイドのテスト(XP)</description> 

    <file name="ComTest.dll"> 

        <comClass  

            clsid="{12A129C3-E5E5-4635-894F-BE4EAB24CA68}" 

            progid="ComTest.SideBySide" /> 

    </file> 

</assembly>

リスト 3. ActiveX DLL で使用するアプリケーション　マニフェスト

マニフェストに記述したクラス ID は、レジストリエディタか OLE VIEW (Visual Studio6.0 に付属) で調べることができます (筆者の環境では、OLE VIEW で調査しました。レジストリエディタでは、HKEY_CLASSROOT\Prog Id\CLSID キーで調査します)。これで、ActiveX DLL を使用するアプリケーション「Project1.exe」を実行してみます (図 7)。

図7. マニフェスト記述後の実行例

図 3 と同じように実行できたことが確認できたと思います。この時のレジストリ情報を検索しても、図 5 と同様にレジストリに登録情報を発見することはできませんでした。Windows 2000 の COM リダイレクションでは、.local を配置していましたがレジストリ登録情報を必要としていました。明らかに、Windows 2000 のサイドバイサイド技術より進化しているのが伺えることと思います。

では、ダイナミックリンクライブラリを明示的にマニフェストで指定するにはどうすれば良いのでしょうか。マニフェストの具体例をリスト 4 に示します。このように指定すれば、アプリケーションのインストール

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 

    <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" 

                      name="Microsoft.SidebySide.Test" type="win32" /> 

    <description>サイドbyサイドのテスト(XP)</description> 

    <file name="msvcrt.dll"/> 

    <file name="msvcrt40.dll"/> 

</assembly>

リスト 4. プライベートダイナミックリンクライブラリの指定

フォルダにインストールしたダイナミックリンクライブラリを明示的に指定することが可能となるのです。ここまで説明してきたマニフェストに記述するノードを表 2 で説明します。

ノード/アトリビュート名

備　考

AssemblyIdentity

アプリケーション毎に一つ。 dependencyAssembly ノードのノードしては、サイドバイサイド使用のアセンブリを指定します。

version

アプリケーションやサイドバイサイドアセンブリのバージョンで、メジャー.マイナー.ビルド.リビジョンを指定します。

peocessorArchitecture

「x86」か「ia64」を記入します。

name

一意になるアプリケーション名 (組織.部門.アプリケーション名) かアセンブリ名を指定します。

type

アプリケーションタイプを指定します。「win32」

publicKeyToken

16 文字の SHA-1 ハッシュ値を指定します。

language

言語識別子を指定します (DHTML の言語コードです)。「＊」

dependencyAssembly

サイドバイサイド使用するアセンブリを dependencyAssembly ノードを使って指定します。

file

COM やプライベートアセンブリ (MSVCRT.DLL 等) を指定するノードです。

name

ファイル名を指定します。

comClass

COM の場合に、file ノードの子ノードとして COM 関係の情報を以下のアトリビュートで指定します。

description

説明。例えば、「Font Property Page」など。

clsid

クラスＩＤを指定します。

progid

プログラムＩＤ (COM のフレンドリー名)を指定します。

thredingModel

スレッドモデルを指定します。例えば、「Both」など。

tlbid

タイプライブラリＩＤを指定します。

version

バージョンを指定します。

helpdir

ヘルプファイルのフォルダを指定します。

表 2. マニフェストの記述内容の説明 (抜粋)

表 2 で説明したアトリビュートは全てが必須ということではありません。リスト 3 のように省略も可能です。マニフェストの XML のエンコード (<?xml version="1.0" encoding="UTF-8"?>) には UTF-8 が指定されていますが、Windows XP では UTF-8 と UTF-16 がサポートされています (お勧めは UTF-8 ですが)。ここで説明した以外に、COM のサポートがマニフェストにあります。それは、ProxyStub を使用する COM コンポーネントです。ProxyStub を使用する COM コンポーネントの場合には、「comInterfaceExternalProxyStub」ノードを記述することで対応することができます。更に、COMCTL32.DLL のようなコントロールであれば「windowClass」アトリビュートを指定して、特定のウインドウクラスのみを使用させることもできます。これらの指定方法は、ここでは説明を割愛させていただきますので、ご興味のあるかたは MSDN オンラインの記事「How To Build and Service Isolated Applications and Side-by-Side Assemblies for Windows XP」をご参照下さい。

今回のまとめ

如何でしたでしょうか。VB で作成した ActiveX DLL がレジストリを使わないで動作したことをご理解いただけたことと思います。Windows XP のサイドバイサイド技術は、Windows 2000 を第一世代とするならば格段に向上しているのがご理解いただけたと思います。完成した ActiveX DLL と Visual Basic アプリケーションの配布ですが、アプリケーション　マニフェストと一緒にインストールフォルダにコピーするだけで動作します (但し、「VB6.0 のランタイムが配布されていれば」との条件がつきますが)。つまり、.NET Framework が提唱する XCOPY ライクな配布が限定的ながら実現されているのが、ご理解いただけることと思います。つまり、COM や DLL のバージョン毎の整合性の確認の工数を格段に減らす手段ができたということです。

最後になりましたが、XCOPY ライクな配布が限定的と申し上げましたのは、Windows XP で採用されたサイドバイサイド技術で XCOPY ライクな配布が実現できるアプリケーションは、スタンドアロン形式の実行モジュール (EXE) だけになります。Active Server Pages などの世界には、まだ適用することができません。ですが、読者の皆様が作成された過去の Visual Basic アプリケーションを Windows XP へ安全に移行する手段が存在することを本コラムを通じて、ご理解頂けたのではないかと思います。Windows XP へ移行される場合は、アプリケーションマニフェストを記述して、十分なテストを行うことだけです。本コラムは「Windows XP がもたらす Visual Basic プログラマーへの福音」と題してお届けしています。もう皆様には、お解かりのことと思いますが、「福音」とは、視覚スタイルを Visual Basic の生産性を活かして活用する方法とサイドバイサイドを利用しての容易な配布が実現できることを指して名付けました。つまり、DLL Hell の解消が一歩進んだことを皆さんに、お知らせしたかったのです。

次回について

次回で本コラムは最終回になります。第 1 回で視覚スタイルを取り上げ、第 2 回でサイドバイサイドを取り上げました。次回は、.NET Framework を含めて新しい開発環境である Visual Studio.NET とサイドバイサイドの将来性についても触れていきたいと考えております。それでは、次回まで、しばしのお別れです。

Shozo Arai: マイクロソフトのテクニカルエバンジェリストとして、デベロッパー向けに .NET Framework 技術を中心とした啓蒙活動をしています。現在注目しているのは .NET におけるスケーラビリティの向上技術や互換性技術です。

ページのトップへ