Windowsの最近のブログ記事

Mac 上の Windows11 で日本語ON/OFF をコントロールする

(2025年4月24日 21:03) | 個別ページ | コメント(0) | トラックバック(0)

macOS では、日本語入力の OFF/ON はスペースキーの左にある「英数」キー（日本語OFF）と、右にある「かな」キー（日本語ON）で行う。例えば「かな」キーを押せば必ず日本語入力になるし、「英数」キーを押せば必ず日本語入力は OFF になる。Windows のように「あれ？今日本語入力だっけ？」と悩むことはない。

Windows だとよくあるでしょ？半角で入力しようと思って「半角/全角｜漢字」キー押したのに、すでに半角だったので全角になっちゃったなんてこと（笑）

Mac のキーボードには「半角/全角｜漢字」キー、「カタカナ/ひらがな｜ローマ字」キーというものは存在しない。
Windows の「半角/全角｜漢字」キーのように、日本語入力を交互に OFF/ON 切替するのは、Ctrl キー＋スペースキーで行う。

で、うちの MacBook Air では Parallels Desktop 20 for Mac という VMシステムの上で Windows11 Pro を動かしているのだが、当然、「半角/全角｜漢字」キーがないので日本語入力への切り替えがキーボードでは行えない。マウスでタスクバー上の IME の文字アイコンをクリックして切り替えるとかしないといけない。不便・・・

というわけで、macOS を使っているときと同じように「英数」「かな」キーを使って日本語入力を切り替えられるようにする。

方法は簡単で、Windows11 の「設定」画面を開き、「時刻と言語」→「言語と地域」→「オプション」（日本語のオプション）→Microsoft IME」（オプション）→ 「キータッチのカスタマイズ」で、「キーの割り当て」をONにし、

無変換キー→「IME－オフ」
変換キー→「IME-オン」
Ctrl + Space →「IME－オン/オフ」

を選択するだけである。これで、macOS 同様、「英数」キー、「かな」キーで日本語入力の OFF/ON が可能となる。

ネット上でググると、IME のバージョンを古いものに戻さないとダメという話が見つかるが、あれは古いバージョンの Parallels や Windows OS での話。俺環境は、2025/4/23 現在で最新の macOS、Windows11、Parallels となっているので、上記のような対応でばっちり。わざわざ IME を古いバージョンに戻す必要はない。

ちなみに、ちなみに、「以前のバージョンの Microsoft IME を使う」を ON にしていると、「キータッチのカスタマイズ」で「キーの割り当て」機能が使えないので、すぐに「以前のバージョンを使う」は OFF にしよう。

なんか、根本的にマイクロソフトは考え方がおかしいのでは？

shinoda

(2025年4月15日 12:38) | 個別ページ | コメント(0) | トラックバック(0)

また Windows にやられた。

もう、このクソ OS、というか Microsoft のやり方、セキュリティに対する迷走具合はどうにかならないのか？

あるインターネットに接続しない（Windows Update時に一時的に、ネットワークから切り離しPC単体で接続される）閉じられたネットワーク内で運用されているシステムがあり、その中でゲスト接続（パスワード認証を行わない）によるファイル共有が行われている。

これが Windows11 端末で、Windows Update 後、突然共有が出来なくなったのだ。

パスワードのないユーザなのに「パスワードを入れろ」と聞かれる。

「危険な運用を Windows が止めてくれたので良いじゃないか」「そもそもパスワード無しのファイル共有なんて危険すぎる」と言う人もいるだろうが、まあ、アホである（笑）

そういう運用が許される環境は存在するし、それが「いきなり OS の仕様変更で勝手にできなくされる（必要もないのに）」ことこそ大問題なのだ。

そもそも、回避する方法があるんだから、「突然接続できなくなって、現場を混乱させてでも優先すべきセキュリティ対策」でもなんでもないのである。現場をバタバタさせるだけだ。

で、「ネットワーク資格情報の入力」を回避する方法（Windows11 Pro の場合）

グループポリシーエディタ（gpedit.msc）で、「ネットワーク」→「Lanman ワークステーション」で、「安全でないゲストログオンを有効にする」を「未構成」「無効」になっていれば「有効」にするだけである。

ちなみに、この「パスワード無しのゲストログインでファイル共有しているシステム」は俺が作ったシステムでもなんでもなく、たんに「使用しているだけ」なので、俺に「そもそもそういうシステムの設計が・・・」とか意見言われても仕方ないぞ。

そして、ここまで読んでもまだそういう意見を持っている人間は、「世の中にはそういう仕様でも、適切な環境設定さえされていればなんの問題もないシステム」が存在することを知ろうな。世間知らずめ（笑）

環境変数でのプロキシ設定の話

shinoda

(2025年2月10日 12:45) | 個別ページ | コメント(0) | トラックバック(0)

お客さんのところで Node.js 関係のインストールをしようとすると、

PC> fnm install 22
error: can't get remote versions file: error sending request for url (https://nodejs.org/dist/index.json)
PS C:\Users\Masanori Shinoda> fnm install v22.13.1
Installing Node v22.13.1 (x64)
error: Can't download the requested binary: error sending request for url (https://nodejs.org/dist/v22.13.1/node-v

となる。これは Node.js のインストールファイルをローカルに取ってきて先に進めたが、corepack を使って pnpm をインストールしようとして失敗。

PC> corepack prepare pnpm@latest --activate
Internal Error: Error when performing the request to https://registry.npmjs.org/pnpm; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting
＜以下略＞

なんでエラーになってるのかわからないので、試しに npm を使って pnpm のインストールを試みると、

PC> npm install -g pnpm@latest
npm error code ETIMEDOUT
npm error errno ETIMEDOUT
npm error network request to https://registry.npmjs.org/pnpm failed, reason:
npm error network This is a problem related to network connectivity.
npm error network In most cases you are behind a proxy or have bad network settings.
npm error network
npm error network If you are behind a proxy, please make sure that the
npm error network 'proxy' config is set properly. See: 'npm help config'
npm error A complete log of this run can be found in: C:\Users\hogehoge\AppData\Local\npm-cache\_logs\2025-02-03T07_41_09_310Z-debug-0.log

https://registry.npmjs.org/pnpm へアクセスできないので、proxy の設定をちゃんとしろ的なことを言われているね。

確かに、ブラウザではプロキシ設定を行っているので、上記 URL にも到達できる。

コマンドプロンプトからコマンドでインストールを試みたり、Visual Studio からコマンドを実行したときには到達できないようだ。

そこで、環境設定で、システム環境変数 HTTP_PROXY と HTTPS_PROXY にプロキシサーバを（ブラウザで指定しているプロキシサーバに）設定してやればうまくいった。

・・・が、今度は Sourcetree でローカルサーバから最新ソースをプルしてくるときに、

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks fetch --no-tags origin
fatal: unable to access 'http://hogeserver/dev/Proj0991/': The requested URL returned error: 503

というエラーが発生するようになった。

ああ、ローカルサーバまでプロキシ経由になっちゃってる・・・ってことで、環境変数 NO_PROXY にローカルサーバを設定してやる。

（例） NO_PROXY localhost,127.0.0.1,hogeserver,192.168.

これでばっちりであった。

Windows が「ださい OS」と言われるわけ

shinoda

(2024年11月21日 21:47) | 個別ページ | コメント(0) | トラックバック(0)

Windows はとにかく糞 OS である。

まあ、コンピュータに詳しい人ほど Windows 嫌いは進むんだけど（だいたい、Windows しか知らない中途半端な知識しかない小僧に Windows ファンが多い（笑））

なにがダサいかというと、その「自分優先」の設計思想だ。

今日ももう一時間近く仕事にならない。

WindowsUpdate のために Windows Modules Installer Worker といううんこのようなプログラムがディスクをがりがり読み続け、他のアプリがディスクを読むことができず固まり、まったく仕事にならない。

ファイルエクスプローラーで右ボタンメニューを出すだけで数分かかる・・・

日本語変換も固まったり・・・

Windows Modules Installer Worker というウジ虫みたいなプログラムが最優先でディスクをがりがり読んでいるせいだ。

馬鹿なの？そんなバックグラウンドのプログラム、ユーザの操作に影響をださないように自身のプライオリティは低めに設定しこっそり走らせろよ。それを、我れが我れがとシステム（OS）が占有して・・・だっせえなあ、Windows。どういう馬鹿が設計したらこんな糞バランスの OS が出来上がるんだろ？(^^;;;

とりあえず、ユーザにストレスをかけない OS の正しい動きについては macOS を参考にしなさい。（もちろん macOS にも不味い部分はあるが、Windows の糞具合と比べたら相当マシな OS である）

unzip の日本語ファイル名問題、なんとか解決

shinoda

(2023年11月 5日 00:38) | 個別ページ | コメント(0) | トラックバック(0)

随分前に作った Linux（CentOS）上で動くプログラム。

LZH ファイルを解凍し、そのファイルをほげほげするのだが、さすがにもう Windows 上で LZH ファイルを作るのもきつくなってきた・・・ということで ZIP ファイル対応を依頼されたのだが（例えば、7-Zip なんかでも LZH 形式には対応してないからな(^^;）・・・ハマった(^^;

yum で入れた unzip は -O オプション（アーカイブ内のファイル名のエンコードが指定できる）が使える（以前のバージョンではパッチを当てないと駄目だった）ので、例えば unzip -Ocp932 -l exsample.zip で、exsample.zip の中の「かわいい中年男性一覧.csv」みたいなファイル名は取ってこれるんだけど、これをディスク上に解凍するとファイル名が化けまくる・・・

ちなみに、プログラムは EUC-JP で書かれている。なにせ、もう、18年前に初版公開したプログラムだからな（笑）。

これ、lha コマンドは EUC-JP でファイル名を出力するパッチが当たっていたので問題なかったんだけど、unzip は「サーバの locale のエンコードでファイル名が作られる」ため、実行サーバの locale である UTF-8 のファイル名となる。

他のプログラムにも影響あるから、なんとか EUC-JP でファイル名を設定してほしいなあ。

しかし、unzip にそのようなオプションはない。結局、unzip を実行する前に、locale を EUC-JP にする形でなんとかなった。

（例）
export LC_CTYPE=ja_JP.eucJP; /usr/bin/unzip -OCP932 -d /tmp exsample.zip

このプログラムは実行後シェルを閉じるので、LC_CTYPE の設定を投げっぱなしだが、同一シェル内で他のコマンドなど実行するのなら、

export LC_CTYPE=ja_JP.UTF-8

で locale を元の UTF-8 に戻すこと。

Windows でどうしてもプロセスが殺せないとき...結局再起動

shinoda

(2023年6月13日 11:25) | 個別ページ | コメント(0) | トラックバック(0)

今日、急に Windows 10 Pro で音が出なくなった。

とりあえず、コマンドプロンプトから

C:\>net stop "Windows Audio"

C:\>net start "Windows Audio"

C:\>net stop AudioEndpointBuilder

C:\>net start AudioEndpointBuilder

てな具合にオーディオ関係のサービスを再起動したらしばらくは調子よかったんだけど、また音が出なくなった。

C:\>net start "Windows Audio"
システムエラー 1068 が発生しました。

依存関係サービスまたはグループを起動できませんでした。

という具合に起動もできない。

調べてみると、AudioEndpointBuilder が「停止処理中」のまま固まっていた。

こうなると、タスクマネージャーからも殺せないし、サービスの再起動もできない（停止処理中だから起動ボタンとかも無効化されている）。

コマンドプロンプトから強制的に殺してみる。プロセスIDを調べて、taskkill コマンドで強制停止。

C:\>sc queryex AudioEndpointBuilder

SERVICE_NAME: AudioEndpointBuilder
TYPE : 30 WIN32
STATE : 3 STOP_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x160
WAIT_HINT : 0x1388
PID : 7312
FLAGS :

C:\>taskkill /pid 7312 /f
エラー: PID 7312 のプロセスを強制終了できませんでした。
理由: 実行中のタスクのインスタンスがありません。

ありゃあ・・・いわゆる「ゾンビプロセス」になってるんか？

UNIX や Linux ではゾンビ化したプロセスも殺せる（消せる）が、Windows は駄目なんかな？

WMIC コマンドを使ってみる。

C:\>WMIC PROCESS WHERE "ProcessId = 7312" GET Name,ProcessId,CommandLine /FORMAT:LIST

CommandLine=C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted -p -s AudioEndpointBuilder
Name=svchost.exe
ProcessId=7312

なるほど。ちゃんとまだ 7312 プロセスは認識されてるな。まあ、ゾンビだからな。早速、プロセスの削除。

C:\>WMIC PROCESS WHERE "ProcessId = 7312" DELETE
インスタンス \\DESKTOP-5077EPO\ROOT\CIMV2:Win32_Process.Handle="7312" を削除しています
エラー:
説明 = アクセスは拒否されました

駄目だこりゃ。

もう、こうなると再起動しかないということか。Windows 格好悪いなあ。

時々、技術者の中でも「UNIX 系 OS より Microsoft Windows が好きだ！Windows は優れた OS だ！」という奇特な意見を聞くことがあるが、ゾンビ化したプロセスを消せない OS って・・・

わざわざ 32bit版 Office をインストールする

shinoda

(2022年5月20日 10:01) | 個別ページ | コメント(0) | トラックバック(0)

32bit 版の ODBC ドライバー経由で DB に接続する Access アプリを仕事で使わないといけないんだけど、メインのノートパソコンの Office は当然 64bit 環境なので、Access でデータソースの新規作成をしようとしても 32bit 版の ODBC ライバーが一覧に出てこない。

64bit 版Access で 32bit 版ODBCドライバーって使えないのかぁ～。上位互換で可能なのかと思っていた・・・

というわけで、新しい MS-Office 買ってきて、32bit版を新規インストール。

DVD版を買ったので、ドライブに DVD を突っ込むと「Setup.exeを実行するか？」と聞かれたので Yes とすると、いきなりインストールが実行された。64bit版の・・・

途中で 64bit/32bit のどっち？って聞かれるのかと思ってたわ・・・

そういえば昔の話だが、Office って 64bit版の開発が遅れてて、64bit の Windows OS にインストールするときも、勝手に 32bit版が選ばれるので、あとでもう一度 64bit版を入れ直したりってことがあったな(^^; 今は勝手に 64bit版が選ばれるのね（笑）

インストールを途中で止めると中途半端にファイルが残ったりしそうなので、最後までインストールしてからアンインストール。改めて、Setup32.exeを実行し 32bit版 Office をインストールした。

で、無事 32bit版 ODBC ドライバーが使えることを確認。

でも、よく調べたらこの DB、64bit版の ODBC ドライバーもリリースしてるんで、それ使えばいいんじゃない？とも思ったのだが、アプリのメーカーの動作保証対象が 32bit版なので仕方ないのである・・・(^^;

JPEG画像をフォトビューアー表示に変更する

shinoda

(2021年11月 8日 22:23) | 個別ページ | コメント(0) | トラックバック(0)

Windows10 では、画像ファイル（JPEG とか PNG とか）は「フォトアプリ」ってやつで開くけど、これ、使い勝手が悪い・・・というか、なんか仕様が変やな。

例えば JPEG 画面を表示していても、時々、「現在サポートされていない形式であるか、ファイルが破損しているため」という理由でフォトアプリが落ちる（画面が勝手に閉じてしまう）のである。

クラウド上のストレージに置いたでっかいファイルを見てるときに発生しやすいかな？

まだデータ受信中なのにファイルチェックを行い、当然まだ不完全な状態のファイルを「壊れている」と誤解してるみたいだなあ(^^;。そんなのもうバグやで、バグ(^^;

Microsoft って OS も作ってるから技術力が高い会社って素人さんは思ってそうだけど、業界内での技術的評価は決して高くない。基本的に「井の中の蛙」的に自社技術・自社だけの常識を集積してきた会社なので、こういう初歩的なバグも「Microsoft の仕様です」と恥ずかしげもなく言い切るのである。

というわけで、この「フォトアプリ」というバグ含みの糞アプリを使うのをやめ、昔の Windows で画像ビュワーとして使われていた「Windows フォトビューアー」で画像表示を行うようする。

・・・が、これが実はレジストリを触ったりけっこう大変らしい。そのあたりを自動でやってくれるのが「Restore Windows Photo Viewer to Windows 10/11」というフリーソフト。

ダウンロードした RestoreWindowsPhotoViewerSetup.exe を実行しインストールしたら即起動。

特に設定等触らずそのまま「Restore Windows Photo Viewer」ボタンを押す。これで「画像（フォト）の既定のアプリにフォトビューアーが選択できる状態」になったので、設定画面から追加。

「既定のアプリ」で「フォトビューアー」のところが「フォト」になっているので、ここで右ボタンクリックでプログラムの一覧を表示し、「Windows フォトビューアー」を選択する。フォトビューアーのアプリが「Windows フォトビューアー」に変更された。

「フォトアプリ」でエラーになっていた画像もちゃんと表示される。

Windows Update KB5004296 成功せず

shinoda

(2021年9月 7日 18:01) | 個別ページ | コメント(0) | トラックバック(0)

mouse computer のノートPCで Windows Update に失敗する。

Windows Update の画面でインストール 100%になるのだが、再起動時に「更新プログラムを構成できませんでした　変更を元に戻しています　コンピュータの電源を切らないでください」と自動修復が走ってしまい、Update 前の状態に戻されてしまう。

OS のバージョンは Windows 10 Home（21H1）。

失敗している Update は KB5004296 である。

で、こういう時はどうするのかというと、「Microsoft Update カタログ」からアップデートファイルをダウンロードして、それを PC 上で実行してやると・・・うまくいくことがある。

https://www.catalog.update.microsoft.com/home.aspx

まず、上記サイトにアクセスし、KB5004296 などで検索。そうしないとえらい量のアップデートファイルが一覧表示されて、目的のファイルを探すのが大変だぞ（笑）

うまくいっていないアップデートファイルが見つかったらダウンロード。拡張子が MSU のファイルが落ちてくるのでダブルクリック。Windows update スタンドアロンインストーラー（Wusa.exe）が実行される。

「更新プログラムのダウンロードとインストール」という窓が開きインストールが始まるので、あとは終了するのを待つだけ。

しかし、この画面で表示される処理状況を知らせるインジケーターはかなりいいかげん。いや、まあ、アプリケーションが表示するインジケータなんかだいたいいい加減なんだけど、その中でも群を抜いていい加減だ。

なので、「え？まだこんだけ？」とか心配しないように。最後に一気に動くから（笑）

インストールが終了したら「再起動」だ。

これでだいたいうまくいく。

わくわくと画面を見つめる俺の目に飛び込んできたのは、「更新プログラムを構成できませんでした」の文字。青いバックが目に染みる・・・

Windows が悪いのか？mouse computer が悪いのか？

どちらにしてもがっかりである。

こういう場合はもう手の打ちようがないので、そのまま次の大型アップデートを待つしかない・・・かな？

Becky!が起動しない・・・という話題に見せかけて Windows を嗤う

shinoda

(2021年9月 7日 06:13) | 個別ページ | コメント(0) | トラックバック(0)

PCの保守をさせてもらっている会社で使われているメールソフトが、Becky! Ver2 である。

Becky! 懐かしい！まだ生き残っていたか。

1990年代から 2000年代にかけて、それなりのユーザを獲得していたメールソフトやね。

その Becky! が起動しなくなった。

ネットワークドライブをメールフォルダにされているのだが、Becky! が起動したままでルータを切ったら、Becky!が「応答なし」の状態で固まってしまって強制終了。そしたら二度と起動しなくなったのである(^^;;

一回だけスプラッシュ画面が表示されたが、それ以降はうんともすんとも。

まあ、これは Becky!あるあるで、起動時に作成された

becklock.$$$
becklock.nam

というロックファイルが残っているためである。

メールフォルダ内を探していき、AddrBook フォルダ内にこれらのファイルが残っているのを発見。日付がその日の朝になっていたので、朝イチで Becky! を起動したときに作られたものだろう。これを削除したら Becky! は復活した。

で、問題は「メールフォルダ内を探していき」の部分である。

UNIX なら find / -name 'becklock.$$$' -print とかすれば一発でヒットするのに、Windows ではファイルエクスプローラーの検索窓に becklock.$$$ と打ち込んでもヒットしないのだ。

「ああ、$はエスケープしないとだめか」と becklock.\$\$\$ としても駄目。「ドットもか」と becklock\.\$\$\$ としてももちろん駄目である。なのでフォルダをひとつひとつ見ていった。

なんか、Windows 独自のエスケープの仕方があって、'~'（チルダ）を使ってアレコレする。

あまりの独特すぎて説明するのが面倒なので、気になる人は自力でググっていただきたい。

無事、Becky! の起動に成功した俺が思ったのは、ただただ「Windows はどこまで自ら糞 OS の道を歩み続けるのかのお」ということであった・・・（笑）

« UNIXやLinux | メインページ | アーカイブ | データベース »

Windowsの最近のブログ記事

Mac 上の Windows11 で日本語ON/OFF をコントロールする

なんか、根本的にマイクロソフトは考え方がおかしいのでは？

環境変数でのプロキシ設定の話

Windows が「ださい OS」と言われるわけ

unzip の日本語ファイル名問題、なんとか解決

Windows でどうしてもプロセスが殺せないとき...結局再起動

わざわざ 32bit版 Office をインストールする

JPEG画像をフォトビューアー表示に変更する

Windows Update KB5004296 成功せず

Becky!が起動しない・・・という話題に見せかけて Windows を嗤う

検索

このアーカイブについて

2025年4月: 月別アーカイブ

カテゴリ

月別アーカイブ

Windowsの最近のブログ記事

検索

このアーカイブについて

2025年4月: 月別アーカイブ

カテゴリ

月別 アーカイブ

月別アーカイブ