「Windows Server 2008」は「Vista」と同じバージョン

先月より公開されたWindows Server 2008の評価版を使ってみたところ、意外な点を見つけたので報告する。

それは、OSのバージョン情報である。
なんとVistaと全く同じなのである。しかも、VistaのServicePack1が公開されたばかりなので、2008の評価版(製品版と同等)にも既にServicePack1が適用済みになっているのだ。

詳しくは下図をご覧いただきたい。
msinfo32.exeを実行して表示させたものである。

１．Vista(ServicePack1適用済)


２．Windows Server 2008(製品版の評価使用中)


こうなると、プログラム上でバージョンチェックする際、プロダクト名まで調べないとVistaか2008か判定できないことになる。

「Windows Vista Service Pack 1」の効果

最近公開されたVistaの「Service Pack 1」だが、具体的に何が変わったかを実感することがほとんど無いなか、唯一私が効果有りと実感したのがエクスプローラの画面の自動更新処理である。これによりWindowsXPと同等になった。

具体的に言うと自作のフリーソフト「ファイルとフォルダの神隠し(�U)」でVistaだけがファイルとフォルダの属性を変更させても即時に非表示とならなかった。わざわざ右クリックして「最新の情報に更新」をクリックしなければならなかったのが、SP1を導入することでその必要が無くなり即消えるようになった。
きっとこれはバグだったのであろう。

その後日(4/13)、更にSP1の効果を実感する事件(?)があった。これも自作のソフト「メルプリ�T」での不具合に対しての実感である。これも一気に解決した。
実はこの問題点は先の「ファイルとフォルダの神隠し」の不具合以上の致命的ともいえる障害だった。ソフトを起動して常駐後、30分から１、２時間経過すると突然画面が乱れて制御が効かなくなってしまうのである。通常ならデスクトップ下部にあるタスクバーが突然上部に移動したり、ソフトの一部しか表示しなくなったり、マウスの動きに合わせて画面が乱れ飛ぶ始末なのである。(下図参照)

１．正常な画面


２．乱れた画面


原因はまったく見当がつかなかった。それがServicePack1を適用した途端に直ってしまったのである。内部的なことは判らないが明らかにバグが解消され、既存アプリケーションの互換性が高まったと言って良いだろう。Vistaを実務で使うにはServicePack1は必須といえる。

既存アプリのVista対応・改造計画：追加「マニフェストファイルの組込」

VistaではUAC(ユーザーアカウント制御)のため例え管理者としてログインしている場合でも標準ユーザーとしての権限でしかプログラムが実行されない。そこで管理者モードで実行できるように昇格させるためにマニフェストを用意することを以前紹介した。
このマニフェストはプログラム本体とは別ファイルになっているので、うっかりしてプログラムだけ移動したりすると使えないという問題が発生する。そこで今回はこれをプログラム内部に組み込む方法を紹介する。
VB6で作ったプログラムでもVB.NET(VB2005)で作ったプログラムでも同じ方法である。
但しVS.NET(VS2005)の開発環境が必要なのでVB6しかない方は諦めて(^^;

で、方法はというと下のURLにあります。

.NET TIPS ：「マニフェスト・ファイルをアプリケーションに組み込むには？」

やはり引用先まで毎回見に行くのも面倒なので、手順のみ紹介します。

１．「ファイルを開く」で組み込み先のEXEファイルを選択


２．EXEファイルを右クリックして「リソースの追加」を選択


３．「インポート」から予め作成しておいたマニフェストファイルを選択し、リソースの種類を「RT_MANIFEST」と入力


４．IDを101から1に変更し、保存。


以上で完了。

あと訂正ですが、以前VB6でマニフェストを使うにはネイティブコンパイルをしておかないと駄目だと紹介しましたが、P-Codeコンパイルでも問題無く動きました。
(でも変だなぁ、その当時は確かにP-Codeでは動かなかったと記憶しているだけどなぁ・・・・。)

既存アプリのVista対応・改造計画：追加「文字化けの解消」

VB6で作った自作ソフトがVistaで動作上は何の問題もないが、フォントの一部が文字化けしてしまうのに気がついた。運用環境だけでなく、VB6の開発環境でさえそうなる。

「管理者として実行」すれば文字化けしないが、UACダイアログが起動時に毎回表示されるのは煩わしい限りだ。
いろいろ試行錯誤してみると、フォントを標準(規定)の「MS Pゴシック」から「MS ゴシック」にすると文字化けしなくなるのに気が付いた。文字化けしたコントロールを一つ一つ「MS ゴシック」に変更したところ文字化けは解消された。

これが原因かと考えてみるがフォントファイルは「MS Pゴシック」も「MS ゴシック」も一つのファイルでそれ自体に差異があるとは考えられない。また、この調子ですべてのソースを変更するのも面倒だ。

一体何が原因なのか。散々調べ上げた挙句ようやくわかった。

結論はこうだ。
コントロールのフォント指定でCharset=128が無いと文字化けするということだ。
規定の「MS Pゴシック」から「MS ゴシック」に変更すると自動的にCharsetを含む「BeginProperty Font」セクションが追加される。
フォームのソースファイル(.frm)を見るとわかるが、規定フォントの場合この「BeginProperty Font」セクション自体が無い。

つまりコンテナであるフォームのフォントを継承していると考えられる。であればコントロールを一つ一つ変更しなくてもフォームのフォントにCharset=128を追加することで文字化けが解消できるのではと考えたところ大正解。いっぺんに文字化けは解消した。


１．文字化けしている様子。


２．フォームのフォント指定ダイアログを表示して「OK」するだけで「BeginProperty Font」セクションは作成される。


３．「BeginProperty Font」セクション


４．文字化けが解消された様子。

VistaでInternetExplorerのURLを取得する場合の注意

以前、既存アプリケーションのVista対応について6回にわたって注意事項や対策を紹介したが、今回はその番外編である。

前回、いろんな対策があるが一番手っ取り早いのはビルトインユーザのAdministratorでログオンさせれば、これまで同様に使うことが可能だと紹介した。しかし、Administratorであるがゆえに問題が発生する場合があることも最近わかった。この問題について私がMicrosoftへ照会し、それについてMicrosoftの公式見解として、同社の了解を得て紹介するものです。

自作ソフトのScreenCutter(シェアウェア版)にはIEの画面をキャプチャーする機能がある。



上記メニューをクリックすると現在IEで開いているURLを全て取得してそのなかからキャプチャーしたいURLを選択することが可能なのだが実はVistaではURLの取得に失敗してしまうのだ。

当初IE7のタブブラウザが問題なのかと思ったがXPのIE7では正常に取得できたのでVista固有の問題だと思い、いろいろ調べ、代替策も探してみたが見当たらず途方にくれていた。そこでMicrosoftに問い合わせてみたところ、VistaのしかもビルトインユーザーのAdministratorでの障害であることが判明した。正確に記すと以下のようになる。

「ビルトインの Administrator アカウントで Internet Explorer を起動している場合に、ShellWindows オブジェクトに Internet Explorer オブジェクトが正しく追加されないという問題」

よって、Adiministrator以外のユーザーであれば何でも良く、AdministratorsやUsersグループのユーザーで確認したところ正常にURLが取得できたのである。

何ともはや・・・・Administratorは万全では無かったというわけである。他に同様のAdministratorの不具合があるのかは不明だが、Microsoftでは次のように答えている。
「Windows Vista では Administrator のアカウントは特殊なアカウントであり、できれば使用されないことが望ましく、Administrator アカウントでは UAC が ON であってもすべてのプロセスは整合性レベル高にて動作することから、実質的には UAC が OFF の場合との差がない・・・云々」(※一部文章表現は当方で編集)

ということで参考にしましょう。

既存アプリのVista対応・改造計画：最終回「おまけ：必殺技の紹介」

これまで５回にわたりVista対応への方法を解説してきたが、そこまで丁寧にやってられないということも実際の現場ではあるだろう。
そこで安直に既存アプリを従来通り動かす方法を最後に紹介したいと思う。
そんな方法があるのなら先に言ってよ、と思う人もいるかもしれない。だが、この方法にはそれなりの問題(代償)もあるので、正しい知識を得て、その上でどうしても必要に迫られて行う場合以外はやるべきでは無いと考えている。そこをご了解願いたい。

方法は２つある。

第１の方法：「Administratorでログオンする」
Windows Vista のBusinessとUltimateのエディションを使っている場合にのみ可能な方法である。
HomeやHome PremiumではAdministrator自体が存在しない(XP Homeではセーフモードで使えた)のでこの方法は使えない。

Administratorアカウントは初期値では無効になっているのでまず管理ツールのコンピュータの管理を開いて有効にする。
Windowsのセットアップ時やユーザーの追加で作成したAdministratorグループのアカウントと違い、ビルトインアカウントのAdministratorだけがUAC(ユーザーアカウント制御)の呪縛から開放されている。しかし、当然ながらその分セキュリティが犠牲になっていることを忘れないで欲しい。

第２の方法：「UACを無効にする」
これは正直なところ最後の奥の手で通常は薦められない。が、どうしても動かしたい(動かせねばならぬ)アプリがある場合にのみ行うべきである。
またUACを無効にするとOSがしつこく警告を出すようになる。これもかなり煩わしい。

UACの無効化はコントロールパネルをクラシック表示にしたときのユーザーアカウントで行う。(下図)





無効になった途端に警告が出る。

既存アプリのVista対応・改造計画：５回目「改造方法」

UAC(ユーザーアカウント制御)のダイアログで止まらずに自動起動させる必要のあるプログラムはどうすれば良いのだろうか。

結論を言えば、そのようなプログラムには管理者権限を必要としない処理だけをさせるようにするしかない。
書き込みは禁止されるが読み込みは問題なくできるのでレジストリに書き込まれた環境設定を読むだけなら管理者権限は必要ないのが幸いだ。
そして、環境を変更する時だけ、つまり環境設定画面で値を修正し「登録」ボタンを押したときにレジストリ等の管理者権限を必要とする書き込み処理を別プログラムに分離し、それにマニフェスト
を付けるのである。ユーザーインターフェースを持たないので、ユーザーからみれば保存時に確認ダイアログがでたような印象を受けるだろう。こうすることで煩わしいダイアログを必要最低限に抑えることができる。下図はこのモデルを表現したものだ。



あと、インストーラーによるプログラムの保存場所は管理者権限を必要とするProgram Filesフォルダではなく、ドライブのルートを使うように変更させるようにする。Oracleなどは以前からドライブのルートにフォルダを作成してそこに一式インストールするがそれと同じである。
これで通常の作業でファイルを書き出す必要がある場合でも問題なく行うことでき、外部プログラムから参照しても問題なくアクセスできる。

※VB6のSetup.Lstファイルを次のようにするとインストールフォルダの初期値が変更できる。

通常の場合
[Setup]
Title=HOGE Ver.1.0.0
DefaultDir=$(ProgramFiles)\hoge
AppExe=hoge.exe
AppToUninstall=hoge.exe

Cドライブのルートに作成する場合、DefaultDirを変更する。
DefaultDir=C:\hoge

既存アプリのVista対応・改造計画：４回目「何が問題なのか：その２」

前回、既存アプリが受ける代表的な問題点をあげた。それに対する一般的な対応策を紹介しつつ、実はそれでも問題が残ることを今回は取り上げる。

マシン固有の情報(HKEY_LOCAL_MACHINEレジストリとProgram Filesフォルダ、他にWindowsフォルダも同様)への書き込み制限を解除して書き込み可能にする方法は２つある。

一つはプログラムの互換性プロパティを開いて管理者権限を付与するもの。(下図参照)



管理者権限でログインしている筈なのに何故また管理者権限を付与する必要があるのかと思うかもしれない。UAC(ユーザーアカウント制御)では管理者でも通常は一般ユーザ(Usersグループ)で動いているのである。
Vistaでは下図のようなダイアログを頻繁に見るようになるが、これこそ管理者権限に格上げする表明なのである。



もう一つは、上記プロパティの代わりにマニフェストとよばれる外部ファイルを配置するものだ。
hoge.exeというプログラムがあるとしたら、マニフェストはhoge.exe.manifestという名前になる。(プログラムファイル名).manifestが命名規則になっている。これをプログラムと同じフォルダに配置する。
内容は以下の通り。ファイル名のところを変更するだけで他は共通で使える。(※注)


※requireAdministrator が管理者権限で実行することを要求する。

この処置を施すことで従来通りの動きが保証される。だが、これがまた別の問題を生むのである。
管理者モードに格上げされるのは自動ではない。必ず前述したダイアログで待ったが掛かる。
前回紹介した私のオンラインソフトのExit-Winやメルプリ�Tなどは、Windows起動時に自動で起動し常駐するのが通常の使い方である。それなのに人手を介さないと先へ進まないのでは全く使い物にならない。

そこでどうするか。私の考えた一つの方法を次回紹介したいと思う。

※注：VB6のプログラムでもマニフェストは使えるが、ネイティブコンパイルしたEXEでないと使えないので注意。私のオンライソフトでネイティブコンパイルしたのは実は一つもない。というのもVB6のネイティブコンパイルはほとんど効果(速度)が期待できない中途半端なものだからだ。むしろファイルサイズが大きくなって起動に時間が掛かるマイナス面の方が大きいとさえ言える。(これはVB5が出た当時からの私の認識である)

既存アプリのVista対応・改造計画：３回目「何が問題なのか：その１」

「Vistaでは改造しなくてはならない程の問題があるのか？」と疑問に思う人のために２つの例を紹介しておこう。

既存のアプリをそのまま使った場合にVistaでは一体どのような問題が発生するのか。
私の作ったオンライソフトにExit-Winという定期的にパソコンをシャットダウンさせるものがある。
このソフトには自動ログオンという機能があり、電源を入れたらログオン操作をしなくても自動的に指定したユーザーでログオンが完了するのであるが、これがVistaでは効かない。だが、Windows起動時に起動させるという機能は問題なく使える。どちらもレジストリを操作して実現する機能だが、一方が出来るのに何故他方は出来なくなるのか。
別の例をあげよう。メルプリ�Tという自動でメールを受信し条件にあったメールのみを自動印刷するソフトの場合では、受信したメールの添付ファイルを参照しようとすると、それが見えない。印刷は問題ないのでファイルが無いわけではないのだが、XPまではちゃんと参照できたのにVistaではそれが出来ない。この機能にレジストリは一切関係ない。

それぞれの原因を解説すると、最初の問題はレジストリに関するもので「自動ログオン」の機能で使われるレジストリはHKEY_LOCAL_MACHINEにある項目であり、「Windows起動時に起動」で使われるレジストリはHKEY_CURRENT_USERにある項目である。
つまり、VistaではHKEY_LOCAL_MACHINEへの書き込みが禁止されているのである。しかもエラーは返らないので正常に処理されたと思ってしまう。
次の問題はフォルダに関するもので、一般的なインストーラーを使った場合、アプリケーションは既定フォルダである「Program Files」にインストールされる。ところが、インストール後アプリからは「Program Files」フォルダ内の書き込みが禁止されてしまう。そして、レジストリの時と同様エラーにはならなず、正常に書き込み終了するのである。

どちらも書き込み禁止なのにエラーにならないのは何故か？
それは特殊な場所にリダイレクト(転送)されているからだ。

下の図はMicrosoftの文書「Windows Vista Application Development Requirements for User Account Control Compatibility」(英語)。訳すと「ユーザアカウントコントロールの互換性のためのWindows Vista アプリケーション開発要件」にあったものをそのまま引用した図である。



この図にある通り、プログラム上から確かにそれぞれの指定場所に書き出したとしてもOSが自動的にリダイレクトしてしまう。プログラム内部で処理する限り、別な場所に書かれたとは全く判らない。読み込みも自動的にリダイレクト先から読まれるので全くエラーすることなく処理は終わるのである。
しかし、別のプログラムからその場所を参照しようとすると話は別で、本来あるべきところに書き出されていないので問題が起きるのである。

HKEY_LOCAL_MACHINE内に書き出そうとした内容はHKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE内に出力される。

\Program Files\(AppName)内に書き出そうとしたファイルは
\Users\(UserName)\AppData\Local\VirtualStore\Program Files\(AppName)内に出力される。

これを見ると、マシン固有のデータを直接いじることが出来ない。全て個別のユーザーデータとして覆い隠されてしまうことがわかる。

既存アプリのVista対応・改造計画：２回目「開発環境での不具合−SendKeys」

MicosoftがVistaではVB.NETとVB.NET2003をサポートから外し、VB6をサポートすると発表したことは以前にも紹介した。しかしVista上で動かしたところVB6の開発環境で変な現象を見つけた。

VB6のTipsの中でもよく紹介されるものに、テキストボックスでEnterキーを押したら次のテキストボックスにフォーカスを移動させるものがある。DOS時代のアプリの操作性を再現するためである。
この方法には KeyPressイベント内で SendKeys "{TAB}" を実行することで可能だが、どういうわけか作成したプログラム(EXE)では問題ないのに、開発環境で動かすとエラーになる。

下図１・２・３を参照

図１：フォームにテキストボックス２つとコマンドボタン１つ


図２：実行させ、テキストボックスでEnterキーを押すとエラーが発生


図３：デバッグしてみるとSendkeysのところでエラーしたのがわかる。


この点について、Microsoftのサポート技術情報に同様の問題がOffice2003のVBAで発生することが載っていた。(手持ちのOffice2000でも同じ現象を確認した。)
http://support.microsoft.com/kb/931136/ja

Sendkeysは外部のアプリケーションを操作するときにも使う。
私のオンラインソフトScreenCutterではキャプチャーした画像をOutlookExpressに添付画像として自動で貼り付ける機能に利用されているが、これがVistaではうまく働かなかった。悩んだ挙句 Win32APIのkeybd_eventを使うことで正常に動作するようになったが、先に述べたようにSendkeysを使ってもEXEからでは外部アプリの操作は大抵のものはちゃんと動くのだ。

既存アプリのVista対応・改造計画：１回目「前置き」

いよいよVistaが市場に出回る。昨夜のNHK・クローズアップ現代ではエンドユーザーの立場からVistaへの乗り換え問題とXPのサポート期限問題を扱っていたが、開発者の立場からも重大な問題がある。
一言で言えば、それは、既存アプリの動作保証問題である。これまで、のほほんとほとんど注意を払ってこなかった私のようなオンラインソフトプログラマーにとって死活問題とまでは行かないまでも(^^;かなりの労力と注意を強いる問題といえる。実際、昨年末から正月休みの間、私はほとんどこれに掛かり切っていた。
そして、一応満足のできる対策と方針をまとめることができた。
これより数回に分けてその方法を紹介していきたいと思う。すでにいろんなIT関連サイトでもVistaの仕様の問題を扱っているが、ここでは具体的・実践的な対応を紹介する。別にVista対応のロゴマークを取得するのが目的ではなく、これまで通り、アプリケーションがVista上でも支障なく動いてくれるのを唯一の目的としている。またできる限りユーザーを煩わせない方法で対応させることに力を注いだ。
内容は私の公開しているオンラインソフトを実例にとって話を進める。
VisualBasic6のプログラムを扱っているがVB.NET、VB2005でも同様に起きるものであるから参考になると思う。

VistaがそれまでのWindowsと大きく異なること

先月21日に開発者向けにVista日本語版(正規版)のダウンロードが可能になった。
これまでBeta2、RC2と使ってきたが所詮正規版でなければ本当の検証にはならないのでさっそくインストールしてみた。
検証が必要なのは仕事で開発したプログラムではなく、オンラインソフトの方である。仕事で使う方は無闇矢鱈と新OSに移行することはない。まして業務アプリを稼動させているPCであれば尚更だ。

オンライソフトは不特定多数のそれも個人ユーザーによって利用されることが多いので、プリインストール版が発売されたら即影響が出る。
ただWindowsXPまでは、ほとんど気にしていなかったし不具合もほとんど無かった。
ところがVistaのBeta2を使ってみてこれまでと全く違う動きに不安になった。セキュリティーがXP(SP2)以上に強固になっている。Administratorアカウントは最初から無効になっているし、設定変更にいちいち確認ダイアログボックスが出る。(ユーザーアカウント制御(UAC)と呼ばれるもの：下図参照)



これによりオンラインソフトの一部の重要な機能に問題(障害)が起きることが判った。

ツールと呼ばれるソフトウェアは、OSの使い勝手を良くする目的で作られる。
面倒な操作をしなくてもほぼ自動で事が済むという便利な機能を持つものだ。ところが、これらは悪意をもって使えばウィルスと同等なものになる。よってMicrosoftがセキュリティの強化でウィルスやワーム対策に力をいれた結果、便利なツールも同様にダメージを受けることになる。
仕方が無いと言えば仕方ない。でも、かなりのアプリケーションが影響を受けるだろうなぁ・・・。