● Windows10の1703 (別名 Creators Update) 以降とExcel2000・Word2000・Acces2000のインストールについて

※1803でまたAccess2000が動くようになったもようです。
　もちろん、Exce2000、Word2000も大丈夫みたいです。
　1809もまたヒマを見てテストしてみたいとおもいます。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以下本文です。

★ Win10へのインストールについて

Excel2000・Word2000・Acces2000などの、「Office2000」のWin10へのインストールについては、Excel2000とWord2000はとりあえずは大丈夫なようです。普通に動くみたいです。
マクロもユーザーフォームも一応、テストコードでは大丈夫でした。（厳密に調査するともしかしたらダメなのかも・・・）

しかし、Acces2000が正常動作するのは、とりあえず 1607(別名 Anniversary Update)までのお話となってしまいました。

※ご自分のパソコンのバージョンの調べ方は、「Windowsキー＋R」（Windowsキーを押しながらRキーを押す）をして、「winver」と入力してEnterします。
出てきたダイアログの上のほうに「バージョン ×××× OSビルド ×××××××× 」と出てきたところの「バージョン」のところの数字を見ます。そこが例えば 1703なら1703(別名 Creators Update) です。（下図参照）下図の場合は、1607(別名 Anniversary Update)だ、ということになります。

Win10の1703では、例えばAccessは、メモリリーク？というか、mdbファイルを閉じてもAccess本体EXEがメモリに残るようになってしまいました。

一つでも「テーブル」か「連結フォーム」を開くと、その時点でメモリリーク決定となります。

タスクマネージャなどでMSACCESS.EXEを終了させてからでないと、次のmdbの画面がちゃんと開いてくれません。

（※ 連結フォームではない、ただの「非連結フォーム」の場合はメモリリークとなりません。なので作るフォームをすべて非連結フォームにすれば問題ないのかもしれませんが、それはちょっと面倒です。既存のフォームなら連結フォームも含まれているでしょうし・・・。また、非連結フォームにも何か不具合が出るかもしれません。未チェックです。なので、後述のようにAccess本体のプロセスを消すか、バージョン2003をお持ちならそれで2000のファイルを動かすほうが手っ取り早いです。）

何かレジストリなどの設定を変えれば良いのかもしれませんが、とりあえずその方法が分からないので、できることなら コマンドラインやVBAプログラム等々から消してしまいたいところです。

ただ、バージョン2003は大丈夫なようです。Accessの場合はメモリリークしません（将来の大型アップデートではするかもしれませんが）。

なので、もしOffice2003をお持ちなら、それを使うほうが面倒が無くていいと思います。
もちろん、Office2000で作ったファイルはExcel、Word、Access、基本的には動きます。
（AccessはSendkeysの問題があったかも。あと、カレンダーコントロールの曜日表示がおかしくなります。ただ、基本のVBAは正常に動きます。）

同様に、Office2002（OfficeXP）も行けるかもしれません。
テストしてOKでしたらまたご報告します。
※2017/11/05 追記
Office2002（OfficeXP）もAccessが大丈夫なようでした。テスト用に小さなテーブルとその連結フォームを作って開いてみましたが、終了させたのち、メモリに残ってしまうようなことはありませんでした。
ですので、Windows10の1703以降はとりあえず、OfficeXP以降で大丈夫なようです。（Accessが要らないならOffice2000でも大丈夫っぽいです。）

いずれにしましても、ご自身でも実際に色々と試してください。Windows10の大型アップデートで動くかもしれないし、動かなくなるかもしれません。また、いったん動かなくなっても、「更に次の」大型アップデートではまた動くようになるかもしれません。

どうしてもAccess2000を1703上で使いたい場合は、VMWareなどの仮想マシン作成・管理ソフトの上で、ゲストOSをXPやWindows2000などにして、その中で動かすほうが面倒が無いとは思います。

それもしたくなくて、なんとか1703の上でAccess2000を動かしたい、という場合は、コマンドプロンプトにて「PsKill」コマンドを使うことでメモリから消すことができます（タスクマネージャなどでMSACCESS.EXEを終了させたのと同じ状態にでき、他のmdbが開かない不具合を回避できます）。

コマンドプロンプトでやれる・・・、ということは、「VBA、UWSC、VB、等々からもやれる」、ということになります。

なので、mdbが開くときにプロセス番号を調べて開き、閉じるときまでにその番号をどこかに保存する、という形を取ってもいいかもしれません。それをランチャのような、mdb、あるいはexe、UWSCファイル、等々を作って監視し、mdbが閉じたときを狙って保存されたプロセスID（PID)でKillする、というような形でなんとかなるかもしれません。（やってみてないのでできるかどうかわかりませんが。ただ、タスクマネージャの「PID」の値で、「PsKill.exe」にてKillできることは間違いないです。ldbファイルは残ってしまうかもしれませんけど。）

※「PsKill.exe」は以下のダウンロードファイルの中に含まれています。
https://technet.microsoft.com/ja-jp/sysinternals/bb896683.aspx?f=255&MSPPError=-2147217396
「PSKill.exe」を「C:\Windows\System32」フォルダの中に放り込んであげればOKなはずです。

※参考Webページ「PsToolsを使いこなす」
http://itpro.nikkeibp.co.jp/article/COLUMN/20120601/399943/?rt=nocnt

開いたmdbのプロセスIDの取得は以下のコードを標準モジュールにコピペして、「task_id_get01()」をCallなどで呼び出せばOKです。Excelでも使えます。
もちろん、VBEのイミディエイトウィンドウで「? task_id_get01」でテストもできます。

なお、Declare文（Declare・・・の行）は、Function の塊とは分けて、別の標準モジュールに貼り付けても構いません。どのDeclare文とFunction が関係しているかのコメントさえ書いておけば大丈夫です。

※Declare文・・・「Win32API」という機能を使うための、その準備用の呪文です。

投稿タグ
,