Windowsの最近のブログ記事

Guest ユーザのパスワードを空にする

shinoda
(2021年1月 2日 20:35) | | コメント(0) | トラックバック(0)

お客さんのところで利用しているシステムでは、サーバ側から匿名ログインでクライアントPCの共有フォルダに一時ファイルを書き込む設定になっている（その是非については、セキュリティはしっかり確保できている前提なので、ここであーだこーだという知ったかぶりのご指摘は無用です（笑））。

しかし、なぜか 32bit 版の Windows 10 Pro では「パスワード保護共有を無効にする」の設定にできないので、代わりに Guest ユーザのパスワードを空にしておく必要があるんだけど、何かの拍子に（大概、Windows Update のときだが）空にしていたパスワードが勝手に再び設定されてしまう。

そんなときはサーバ側で「ホルダーがネットワーク上に見つかりません」のエラーとなってしまうので、Guest ユーザのパスワードを空に設定し直す必要がある。
んが、俺、日頃あまり Windows の設定まわりとか触ることがないので、急にそうなると「Guest ユーザのパスワードって、どこで設定するんだっけ？」となるのだ。（Windows は UNIX 系の OS と違って、一般のユーザと Guest ユーザなどの特別なユーザの設定画面を分けてたりするんでね。バカだね。一元管理できるようにすればいいのに。何の問題があるのかね？）

ということでメモっとく（笑）

(1) ファイル名を指定して、lusrmgr.msc（ローカルユーザ・グループ管理画面）を開く

(2) ユーザ→Guest を選ぶ

20210102_lusrmgr1.jpg

(3) Guest の「他の操作」をクリックし、「パスワードの設定」を選ぶ

20210102_lusrmgr2.jpg

(4) 「復元できない情報の損失が・・・」と脅されるが、気にせず「続行」する

(5) 「Guestパスワードの設定」画面でパスワードを設定（何も入力せず、空で）

(6) 「パスワードは設定されました。」と表示されればOK。lusrmgr.mscを閉じよう

これだけ。

この状態でもう一度「パスワード保護共有を無効にする」の設定にして（いや、多分こんなことをする必要はないんだけど念の為（笑））、サーバ側からクライアントの共有フォルダにパスワードなしで（入力画面も開かず）ログインできるか確認する。

うまくいったかの？？？

LINEの「雪が積もる」という遊び心は不要です

shinoda
(2020年12月27日 10:27) | | コメント(0) | トラックバック(0)
朝、ある結社の連絡に PC 版の LINE を使うと、なんか下の方に白いノイズ状の画像の乱れが・・・

20201227_line.jpg
ありゃ、なんかビデオカードのドライバのバグかなんかか？とか思い、一旦 LINE を閉じて再起動してもいつの間にか出てきている。

メモリ不足の誤動作？と思ったけど、まだメモリの空きは 19.5GBもある。（32GBに増設してるんでね）

「なんやねん！！わけわからん。一番下の文字が読みづらいっちゅうの！！」と憮然としつつ LINE を使っていてやっと気づいた。

「ああ、降った雪が積もっているのか・・・」

スマホ版でも冬になると画面のバックで雪が降るが、PCの場合はさらにそれが積もるという遊び心いっぱいの演出が・・・

いらんちゅうねん！！(^^;

なんか雪に見えなくて汚いし、一番したの発言の発言時間が雪とかぶって読めんやん！
（一応、雪の上にマウスをもっていくと、積もった雪が減っていくんだけど(^^;）

いや、ほんと。過剰な演出はマイナスであるという良い見本やなあ(^^;

「回復ドライブを作成できません」と言われた時の対応

shinoda
(2020年10月30日 06:02) | | コメント(0) | トラックバック(0)
今まで USB メディアに回復ドライブなんか作ったことがなかったんだけど、最近 PC 保守を引き継いだお客さんのところで、大型アップデートのあとは必ず最新の回復ドライブを作るということなので、俺の PC でも作ってみることにした。

スタートメニューの検索で「回復」と入力したら、「回復ドライブ」プログラムが出てくるので実行する。
「システムファイルを回復ドライブにバックアップします。」にチェックの入った画面が開くので、右下の「次へ」ボタンを押す。

すると、「この PC では回復ドライブを作成できません」とエラー画面が表示される。なんなの、これ？

20201029_win10_1.jpg

Dell のサイトを見ると、C:\Recovery\OEM ディレクトリの下の install*.* ファイルを削除しろとある。

そこで、

C:\Users\shino>cd C:\Recovery\OEM

C:\Recovery\OEM>dir install*.*
 ドライブ C のボリューム ラベルは OS です
 ボリューム シリアル番号は D439-7DDF です

 C:\Recovery\OEM のディレクトリ

2020/10/24  18:21    <SYMLINK>      install.swm [\\?\GLOBALROOT\Device\Harddisk0\partition5\Image\install.swm]
2020/10/24  18:21    <SYMLINK>      install2.swm [\\?\GLOBALROOT\Device\Harddisk0\partition5\Image\install2.swm]
               2 個のファイル                   0 バイト
               0 個のディレクトリ  829,255,151,616 バイトの空き領域

C:\Recovery\OEM>del install*.*

とかやってみたけど意味無し(^^; 状況変わらず。
Dell のサイトには、「それでだめなら、diskpartを使うやり方を調べてやってみろ」的な一文が(^^;;; なんやねん、冷たっ！！(^^;

というわけで、ここからは「WE FIGHT TOGETHER」というサイトの「Windows10の回復ドライブが「このPCでは回復ドライブは作成できません」と出てリカバリーに苦労した時のメモです」というページを参考に作業を行った。た～さんありがとう。

まず、Windows 回復環境 (Windows RE) の状態を調べる。

C:\Users\shino>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:

    Windows RE の状態:         Disabled
    Windows RE の場所:
    ブート構成データ (BCD) ID: 434b37be-15ad-11eb-b5ee-f37a9dc3604d
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0

REAGENTC.EXE: 操作は成功しました。

Disabled になっている。これを Enabled にしないといけない。
Enabled にするには、/enabled オプションを付けて reagentc を実行するんだけど、Enabled にはできず・・・

C:\Users\shino>reagentc /enable
REAGENTC.EXE: ブート構成データを更新できません。

どうも原因は、Windows Update のあとで Disk 交換（まあ、厳密には追加だけど（OS ドライブを変更した））をしたせいなんかな・・・？
Windows RE なんて言葉自体初めて聞く俺にはよくわからないんだけど(^^;、あるはずの Windows REイメージの場所が未登録状態になっているのが Enabled にならない理由のようである。確かに、reagentc /info で見たとき、「Windows RE の場所」が空白になっている。

というわけで、ディスク上に「回復ディスク」のパーティションは存在しているので、このパーティションを「Windows REイメージの場所」として登録してやればいいみたいなんだけど、そのためにはまずこのパーティションにドライブ文字（ドライブレター）を付けてやらないといけない。

20201025_disk.jpg

この、GUI 画面ではこのパーティションにドライブ文字を付けることはできなかったので、diskpart コマンドを使って行う。

C:\Users\shino>diskpart

Microsoft DiskPart バージョン 10.0.19041.1

Copyright (C) Microsoft Corporation.
コンピューター: DESKTOP-5077EPO

DISKPART> select disk 0

ディスク 0 が選択されました。

DISKPART> list partition

  Partition ###  Type                Size     Offset
  -------------  ------------------  -------  -------
  Partition 1    回復                 990 MB  1024 KB
  Partition 2    システム               250 MB   991 MB
  Partition 3    予約                 128 MB  1241 MB
  Partition 4    プライマリ              930 GB  1369 MB

DISKPART> select partition 1

パーティション 1 が選択されました。

ドライブ文字の割当を行う。重複していなければ何でもいいが、今回は「WE FIGHT TOGETHER」の記事に従って O（オー）ドライブで。

DISKPART> assign letter=o
Windows 回復環境 (Windows RE) 
DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。

DISKPART> list volume

  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0     D                       DVD-ROM         0 B  メディアなし
  Volume 1     O                NTFS   Partition    990 MB  正常
  Volume 2     C   OS           NTFS   Partition    930 GB  正常         ブート
  Volume 3         ESP          FAT32  Partition    250 MB  正常         システム
  Volume 4     F   DATA         NTFS   Partition    226 GB  正常
  Volume 5                      NTFS   Partition    990 MB  正常
  Volume 6         Image        NTFS   Partition      9 GB  正常
  Volume 7         DELLSUPPORT  NTFS   Partition   1321 MB  正常
  Volume 8         ESP          FAT32  Partition    250 MB  正常         非表示
  Volume 9     E                FAT32  リムーバブル        57 GB  正常
  Volume 10    G                FAT32  リムーバブル        28 GB  正常

DISKPART> list partition

  Partition ###  Type                Size     Offset
  -------------  ------------------  -------  -------
* Partition 1    回復                 990 MB  1024 KB
  Partition 2    システム               250 MB   991 MB
  Partition 3    予約                 128 MB  1241 MB
  Partition 4    プライマリ              930 GB  1369 MB

DISKPART> exit

DiskPart を終了しています...

reagentc コマンドを使って O:ドライブの下の \recovery\WindowsRE ディレクトリを「Windows REイメージの場所」として登録する。

C:\Users\shino>reagentc /setreimage /path o:\recovery\WindowsRE
ディレクトリは次に設定されています: \\?\GLOBALROOT\device\harddisk0\partition1\recovery\WindowsRE

REAGENTC.EXE: 操作は成功しました。

まだ、この時点では Disable のまま。

C:\Users\shino>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:

    Windows RE の状態:         Disabled
    Windows RE の場所:
    ブート構成データ (BCD) ID: 434b37be-15ad-11eb-b5ee-f37a9dc3604d
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0

REAGENTC.EXE: 操作は成功しました。

reagentc コマンドで enable にする。これで、「Windows RE の場所」に「\\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE」というパスが設定される。

C:\Users\shino>reagentc /enable
REAGENTC.EXE: 操作は成功しました。


C:\Users\shino>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:

    Windows RE の状態:         Enabled
    Windows RE の場所:         \\?\GLOBALROOT\device\harddisk0\partition1\Recovery\WindowsRE
    ブート構成データ (BCD) ID: eb75ec5d-19df-11eb-b6a2-4cebbd6dd75a
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0

REAGENTC.EXE: 操作は成功しました。

「回復ディスク」のパーティションに O: ドライブを割り当てたのは、reagentc コマンドでパスを指定するときのためだけなので、割当を削除する。

C:\Users\shino>diskpart

Microsoft DiskPart バージョン 10.0.19041.1

Copyright (C) Microsoft Corporation.
コンピューター: DESKTOP-5077EPO

DISKPART> list volume

  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0     D                       DVD-ROM         0 B  メディアなし
  Volume 1     O                NTFS   Partition    990 MB  正常
  Volume 2     C   OS           NTFS   Partition    930 GB  正常         ブート
  Volume 3         ESP          FAT32  Partition    250 MB  正常         システム
  Volume 4     F   DATA         NTFS   Partition    226 GB  正常
  Volume 5                      NTFS   Partition    990 MB  正常
  Volume 6         Image        NTFS   Partition      9 GB  正常
  Volume 7         DELLSUPPORT  NTFS   Partition   1321 MB  正常
  Volume 8         ESP          FAT32  Partition    250 MB  正常         非表示
  Volume 9     E                FAT32  リムーバブル        57 GB  正常
  Volume 10    G                FAT32  リムーバブル        28 GB  正常

DISKPART> select volume o

ボリューム 1 が選択されました。

DISKPART> remove

DiskPart はドライブ文字またはマウント ポイントを正常に削除しました。

DISKPART> list volume

  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0     D                       DVD-ROM         0 B  メディアなし
* Volume 1                      NTFS   Partition    990 MB  正常
  Volume 2     C   OS           NTFS   Partition    930 GB  正常         ブート
  Volume 3         ESP          FAT32  Partition    250 MB  正常         システム
  Volume 4     F   DATA         NTFS   Partition    226 GB  正常
  Volume 5                      NTFS   Partition    990 MB  正常
  Volume 6         Image        NTFS   Partition      9 GB  正常
  Volume 7         DELLSUPPORT  NTFS   Partition   1321 MB  正常
  Volume 8         ESP          FAT32  Partition    250 MB  正常         非表示
  Volume 9     E                FAT32  リムーバブル        57 GB  正常
  Volume 10    G                FAT32  リムーバブル        28 GB  正常

DISKPART> exit

DiskPart を終了しています...

ここまで行って再び「回復ドライブ」プログラムを実行すると、今度はちゃんと先にすすめる。

20201029_win10_3.jpg

しばらく待つと、無事、USB メモリの選択画面も表示されたのであった。ふう。
多分、OS の入ったドライブのクローンをとってそのまま載せ替えではなく、今回の俺のように追加した場合などはこういうことが発生するかもしれない。

Windows10 Pro バージョン20H2へのアップデートで出てきた問題

shinoda
(2020年10月26日 12:09) | | コメント(0) | トラックバック(0)
Windows 10 Pro のバージョン 2004 から 20H2 へのアップデート（いわゆる秋の大型アップデート）を、先週末にお客さんの PC で実施した。

その時に発生したトラブルのメモ。（3点だけだが）

1. 20H2にアップデート後、共有設定が勝手にリセットされていた

お客さんで使われているシステムは、サーバ機（サーバOSではなく、普通の  Win10 Pro）とクライアント（こちらも Win10 Pro 機複数台）間で、お互いの共有フォルダを「パスワード無し」で読み書きできないといけない。
（このことに関して言いたいことがある人もいるだろうが、様々な物理的な要因で安全は確保されており、この共有による「安全上の問題」は存在しないことを書いておく）
しかし、20H2 へのアップデート後、全ての PC でこの設定がリセットされていたのだ。そのため、システムの一部機能が正常に動かなかった。
具体的には、「すべてのネットワーク」のパスワード保護共有の設定で「パスワード保護共有を無効にする」（匿名アクセス可能）にチェックを入れていたのだが、これが全て「パスワード保護共有を有効にする」に変わっていた（戻っていたというべきか）
そのためパスワード要求が発生し、サーバとクライアント双方でファイル共有が行えなかった。
もう一度、「無効」に設定し、問題は解消された。

2. 上記の設定が行えない端末が一台

上記のパスワード保護共有の問題で、「パスワード保護共有を無効にする」の設定に戻せない PC が一台あった。（チェックしても、勝手に外れちゃう）
これは唯一 32bit 版の Win10 Pro が動いている PC でだけ発生した。結局、「Guest ユーザのパスワードを空にする」必要があった。もともと匿名アクセスは可能にしていたので、Guest ユーザのパスワードは空だったはずだが・・・

3. なぜか管理者権限でプログラムが実行されない

管理者権限ユーザでログインし、プログラムを実行すると、管理者権限がないため一部の OCX ファイルの読込ができずエラーが発生する。
右ボタンメニューから「管理者で実行」を選べば、正常に実行される。

ログインユーザのユーザアカウントの種類を確認すると「アカウントの種類」は「管理者」になっている。「？？？」と思いながらそのまま「OK」ボタンを押し、再びプログラムを実行してみたらちゃんと実行された。
なんなの、もう！？(^^;;;
これも 32bit版 Win10 Pro 端末で発生した。しかし、このプログラム自体、この端末でしか実行しないので、64bit版でどうなのかは未確認。

ということで、匿名アクセスを利用していたり、管理者権限でプログラムを実行する必要ある人以外にはあまり関係ない話だけど、俺が遭遇した Windows10 Pro バージョン 20H2 へのアップデートで発生した問題でした。

Windows10 の「勝手に再起動」は実行された

shinoda
(2020年6月14日 03:31) | | コメント(0) | トラックバック(0)
ほんの 2日前に"Windows 10 の「勝手に再起動」を止める"というエントリーを書いたばかりなんだけど・・・

今夜、勝手に再起動された！！

22時くらいから寝落ちして、夜中の 2時に目が覚めたので実際に何時に再起動したのかはわからないが、多分、アクティブ時間の終了する 24時なのだろう・・・
つまりローカルグループポリシーエディター（pgedit.msc）で設定した「スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない」を有効・・・は Windows 10 によって無視されてしまったということだ。

どこまでもゲスな OS め・・・。そもそも Microsoft は「もう！Windows はセキュリティが甘いって散々悪口言われて悲しい！あ、そうだ、Windows Update のあと強制再起動しちゃお！そしたら危ない状態で放置されることがなくなるから、皆『さすが Windows』って呼ぶようになるぞ！」という小学生が考えるような論理でこの仕様を決めたのだろう。あるいは、仕様を決める権限をもったじいさんが呆け始めてるか・・・

それくらい「勝手に再起動する OS」という存在はヤバい。ありえない。「しつこく再起動を促す」は「あり」。「勝手に再起動」は「ない」。「いや、ありでしょう？」と言うエンジニアは思慮の足りない馬鹿である。

というわけで更に調べてみると、上記の「自動に再起動しない」の設定の説明に「更新を有効にするには、コンピューターを再起動する必要があります」とあった。
あれ？(^^; 確かに「有効」に設定後、再起動はしていない。これ、Windows Update の「更新」のことだと思ったんだけど、「自動に再起動しない」の設定を「更新」したときのことなんかな？(^^;
まあ、そうであれば今夜勝手に再起動されたので、次回以降はこんなこともなくなるだろう。

20200614_windows2.jpg

それともうひとつ。
「[自動更新を構成する]ポリシーが無効になっている場合は、このポリシーは効果はありません」とある。「自動更新を構成する」はなんの設定もしていない「未構成」状態だった。「未構成も駄目」なときは「無効または未構成」と説明されるので「無効になっている場合」という説明であれば「未構成」は関係ない気もするが・・・

一応、これも「有効」にし、「自動ダウンロードしインストールを通知」にしておいた。
先程、「いくつかの更新プログラムが必要です。インストールするには、このメッセージを選択してください。」のメッセージが出たから、この設定は PC を再起動しなくても大丈夫なんだろう。

さて、これでどうなるか？
まあ、今のところ「インストールを止めている」状態だから再起動はないけど・・・
これで更に再起動するようなら、Dell に「おたくのパソコン、変じゃない？」と言うてみるか（笑）

Windows 10 の「勝手に再起動」を止める

shinoda
(2020年6月12日 09:34) | | コメント(0) | トラックバック(0)
さっさと調べて対応すればよかったのだが、なんとなくほったらかしにしてて二度も痛い目にあった「Windows 10 での Windows Update 後の勝手に再起動問題」。

今年の 3月頃、やっと Windows 10 Pro を導入したんだけど、こいつ、「再起動しますか？」と聞くこともなく勝手に再起動しちゃうのね。「アクティブ時間」外であれば。（ちなみに俺は 6:00～24:00 をアクティブ時間に指定している）

俺は自宅でプログラムを作るのが仕事で、特に仕事の時間を決めているわけではなく、いや、「ビールは 18時以降」と決めてるけど、ビールを飲んだあともプログラミングは続けて、「できるところまでやって寝落ち」が基本なのだ。
そのため、参照している資料は開きっぱなしだし、テキストエディタで入力したメモが未保存のまま、いや、時にはプログラムソースもまだ保存しないまま気を失っていることもある（笑）

Windows 7 の場合は、「今すぐ再起動するか？」と確認があり、「する」を選ばないかぎり（ほっておけば）再起動はされなかったからよかった。ところが、Windows 10 の場合は「アクティブ時間であれば返事がなくても再起動する」のである。

・・・って、多分、みんな何年も前から Windows 10 だから知ってるよね。俺がやっと今頃になって 10にしただけでね（笑）

で、二度も「記憶を頼りに再ソースコーディング」という苦労を経て(^^;、やっと「勝手に再起動、止めなきゃ」となったのである。なぜなら、昨日から「アクティブ時間外になったら再起動するぞ」という脅しが表示されるようになったからである(^^;

20200611_windows_update.jpg

で、騙されちゃうのが、Windows 10 って右ボタンクリックで開く「設定」の中に Windows Update って項目あるじゃん。なので、ここを重点的に調べていたのだがわからん。騙された。間違っていた・・・(^^;
「勝手に再起動を止める」には gpedit.msc（ローカルグループポリシーエディター）を起動し、左ペインから「コンピューターの構成」→「管理用テンプレート」→「Windowsコンポーネント」→「Windows Update」を選択。で、右側のペインから「スケジュールされた自動更新のインストールで、ログオンしているユーザーがいる場合には自動的に再起動しない」を選択し、これを「有効」にするのだ。

これで、大丈夫なはず。
とりあえず、昨夜は再起動は行われなかった。
しかし、「操作を複雑にする」ことが「安全」だという間違った認識をしている Microsoft 製品だ。どんなドンデン返しがあるかもわからず、まだ不安である（笑）

＜追記＞
駄目だった・・・。詳細は"Windows10 の「勝手に再起動」は実行された"にて。

Windows 10 に Python で FeliCa カード読み込み環境設定

shinoda
(2020年6月 5日 11:20) | | コメント(0) | トラックバック(0)
以前このブログでも何度かエントリーを書いた SONY RC-S380 で FeliCa カードを読み込んだ情報を Python で利用する話。

Windows 7 Professional で開発をしてたんだけど、今回、環境を Windows 10 Pro に移した。

その際、ちょっと Windows 7 の時何をやったかすっかり忘れてて、うろ覚えでセットアップして「プチはまり」をしたので環境構築についてメモっておく(^^;

ちなみに、Python 3.8.3 はすでにインストールされている。

1.WinUSB ドライバのインストール

https://zadig.akeo.ie/ からダウンロードした zadig-2.5.exe を使って WinUSB のインストールを行う。

RC-S380 を Windows 10 に接続したときに自動でインストールされた sonynfcport100c(v1.5.7.2)を WinUSB(v6.1.7600.16385)に Replace する。

・・・が、これ、本当に必要だったのか？Windows 7 のときには必要だったが、Windows 10 だと sonynfcport100c ドライバがインストールされているので、WinUSB ドライバを入れる必要があるのかどうなのか？

もし、このページを見てセットアップをしようと思っている人は、一度、この作業無しで RC-S380 が読めるか試してみてほしい。俺は面倒臭いので試さないけど（笑）

2.pip のバージョンアップ

必須ではないが、モジュールのインストールの度にワーニングが出るのでバージョンアップしておく。

コマンドプロンプトで、
python -m pip install --upgrade pip

3.nfcpy モジュールのインストール

コマンドプロンプトで、
pip3 install nfcpy

libusb1  1.8
ndeflib  0.3.3
nfcpy    1.0.3
pip      20.1.1
pyDes    2.0.1
pyserial 3.4
などがインストールされる。

4.libusb-1.0.dllのインストール

から最新版ダウンロード。
今日時点の最新版は、

ダウンロード後、展開したファイルを、Windows システムフォルダにコピー。

・64bit版
展開場所\MS64\dll\libusb-1.0.dll → C:\Windows\System32 にコピー

・32bit版
展開場所\MS32\dll\libusb-1.0.dll → C:\Windows\SysWOW64 にコピー

余談だが、64bit プログラムを格納する場所が System32 だとか、このわかりづらい構成はどうにかならんものか？(^^;＞Windows

以上で、Windows 10 でも、Python プログラムの中から FeliCa カードが読めるはずだ。

ちなみに、作成したプログラムの中で HTTP プロトコルを使ってサーバにカード情報を飛ばしているので、requests モジュールも pip でインストールしないといけないのだが、これは、まあ、俺独自の話なので（笑）

結局、Excel 2003 が起動してしまう

shinoda
(2019年9月 7日 10:46) | | コメント(0) | トラックバック(0)
いつも持ち歩いている Macbook Pro には VMware Fusion の上で Windows 7 を動かしていて、そこで使っている Microsoft Office は 2003 である。

お客さんの中に、昔うちで Access と Excel を使って作ったシステムの利用者さんがいらっしゃり、そのバージョンがずっと 2003 のままで動いているので、メンテナンス用に残しているのだ。

しかし、他のお客さんから Excel で資料をもらうと、最近は大概 .xlsx ファイルである。無理やりな方法はなくもないが、基本的に Excel 2003 では開けないので、Excel だけ 2010 を入れている。

で、Macbook はこんな感じなのだが、自宅で仕事で使っている PC は（2、3台あるが）全部 Microsoft Office 2013 である。
そのため、自宅では .xls ファイルも 2013 で開くので、それで上書き保存などしてしまうと（マクロなどが含まれていると特に）、.xls ファイルなのに 2003 ではエラーが出て開けなくなってしまうのである。

そこで、Macbook でも .xls ファイルの起動ソフトを Excel 2010 にしたいのだが、これがうまくいかない。

Microsoft Office の「バージョンの異なる Office が同じレジストリエントリを利用する」という謎仕様のためである。

例えば「ファイルを開くプログラムの選択」で「参照」ボタンを押し、「C:\Program Files\Microsoft Office\Office14\EXCEL.EXE」を指定しても、選ばれている Excel のリンクを変更することはできない。EXCEL.EXE はあくまで最初にインストールした EXCEL.EXE が正（レジストリに登録されている）なのである。

で、コマンドプロンプトで、

"C:\Program Files\Microsoft Office\OFFICE14\EXCEL.EXE" /regserver

と実行すると、2010 に規定の EXCEL が切り替わるはずなんだけど、「最初に Office 2003 をインストール→ Excel 2010 だけ更にインストール」という入れ方の場合は駄目なのか、全然切り替わらなかった・・・

まあ、先に Excel 2010 を立ち上げて、それから .xls ファイルを開けばいいんだけど、面倒くさいんでねえ。ファイルをダブルクリックで、ちゃんと Excel 2010 が起動するようにしたいわ・・・

方法を御存知の識者の方がいらっしゃたら、ぜひご教示を。

Windows で、とりあえず「令和」対応をする

shinoda
(2019年4月15日 16:42) | | コメント(0) | トラックバック(0)
Windows 7 Home + MS Aceess 2003 というレガシーな環境で、新元号「令和」対応をしないといけないんだけど、VB モジュールで

Format("令和01年05月01日", "yyyy/mm/dd")

こんな風に Format 関数の結果をセットしてみても、2019/05/01 が返ってこない（Null になる）。

Windows の開発環境に詳しい方に聞いてみると、サポートの切れている MS Access 2003 でも、Format 関数は OS のレジストリを見るので、 OS がサポートされていれば大丈夫。ただし、まだ「令和」関係の Windows Update は提供されていないとのことだった。

そうか、もう「令和」関係の Update は出てて、Office 2003 系はサポート外だから駄目って話なのかと思ってた。
そうか、そうか、まだ Update が出てないだけなのね。

「とりあえず手動でレジストリに令和の情報を登録すれば正しく Format 関数も動きますよ」ということだったので、ググってみると、


こういうページがあった。

その中に書いてあるとおり、コマンドプロンプト画面で、

REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras /v "2019 05 01" /t REG_SZ /d "令和_令_Reiwa_R"

を実行。「この操作を正しく終了しました。」のメッセージを確認後、念の為 MS Access 2003 の画面を再起動。
見事、Format("令和01年05月01日", "yyyy/mm/dd") で 2019/05/01 が返ってくることを確認した。

やっと、自宅の Windows 機復活

shinoda
(2019年3月15日 14:37) | | コメント(0) | トラックバック(0)

マウスが使えないと復活作業もしづらいんで、新たに PS/2接続のマウスを買ったり（家にひとつくらいあると思ってたんだけど見つからず(^^;;）と無駄な出費もしたが、やっと復活しホっとしている。

まあ、ショートカットキー調べてマウス無しで作業する面倒臭さを考えたら、そりゃマウス買った方がええからのお。金で解決じゃ。（ま、1,100円だけど（笑））

20190314_usb.JPG
結局、日本 ASUS のサイトから、ASUSTeK H81M-E 用の最新の USB ドライバを落としてきてインストールしたらすぐ復活した。

もしかしたら、前回、H81M-E 用のドライバ（オーディオとか、ネットワークとか）をまとめてインストールし直したのだが、その時、USB コントローラのドライバのインストールを途中で終わらせちゃったのかもしれない。
インストーラの動きを見ていると、先に古いドライバを削除していたので、ここで何らかの理由で終わらせちゃったとか。（記憶にはないが(^^;）

とりあえず、USB 接続している HDD や DVD ドライブが接続されたので、USB ポートは無事復活した様子。リブートしてみたけど大丈夫みたい。まだ、USB マウスは接続してみていない。
このまま PS/2 マウスでもいいんだけど、残念ながらホイールが反応せんのよね(^^; HID準拠じゃないんかいな？

＜追記＞
何をしたわけでもなく、ただ Windows を再起動したら、なぜかホイールが使えるようになった。
まあ、それがまさに Windows なんだけど、なんだかなあ(^^;
« UNIXやLinux | メインページ | アーカイブ | データベース »

検索

このアーカイブについて

このページには、過去に書かれたブログ記事のうちWindowsカテゴリに属しているものが含まれています。

前のカテゴリはUNIXやLinuxです。

次のカテゴリはデータベースです。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。


2021年1月: 月別アーカイブ

カテゴリ

月別 アーカイブ

電気ウナギ的○○ mobile ver.

携帯版「電気ウナギ的○○」はこちら