NetBSDでPC98エミュレータ

Windows 10を使っていたころに、T98-NEXTというPC98エミュレータを使ってWizardryを遊んでいました。「PC-9800シリーズエミュレータの現況」という記事によると、PC98エミュレータは他にもあるようです。しかしMicrosoft Windowsなら選択肢は多いかもしれませんが、非Windowsでは選択肢が限られると思います。

 

ちょっと検索したら、次のような記事が見つかりました。これらの記事では、NP2kai（Neko Project II 0.86 kai）を使って、ソースからビルドしているようです。OSにはUbuntuを使っているようなのですが、私はNetBSD/i386を使いたいのです。

• 令和の時代にLinuxにPC-98x1エミュレータを入れる
• Ubuntu 22.04で98エミュレータを動かす

 

上述した記事を参考にすれば、NetBSD/i386環境であっても、ソースからビルドできるのではないかと思います。ビルド環境を整えたり、ビルドしてみてエラーが出るかもしれませんし、何かと手間がかかるだろうとは思います。もしかしたら何の苦労もなくビルドできてしまう可能性もありますが、そう簡単ではないだろうと予想しています。

 

自前でビルドする前に、ちょっとパッケージを確認したら、なんと「emulators/xnp2」がありました。これは「Xnp2 is a port for UNIX with X11 of "Neko Project II" PC-9801 emulator.」だそうです。自前でビルドしなくても、既にパッケージが用意されていました。

 

このパッケージをインストールしてみようと思います。このPC98エミュレータでWizardryを動かしてみようと考えていますが、問題なく無事に動いてくれるか心配です。もしトラブルようであれば、デバッグすることになるかもしれませんので、自前でビルドできる環境を整えておく必要が出てくるかもしれません。 

モバイルSuicaを使ってみる

スマホにモバイルSuicaの設定を済ませたので、実際に利用してみました。何かトラブルが発生するのではないかと戦々恐々だったのですが、何事もなく、あっさりと利用できました。あまりにも何も問題がないので、驚いています（問題がなくて、あたりまえだとは思いますが）。

 

強いて言えば、スマホケースにストラップを付け、胸に下げているのですが、そのため改札を通る際に、多少腰をかがむ必要があるくらいでしょうか。

この調子なら、Smart ICOCAのクイックチャージのサービスが終了しても、モバイルSuicaに移行出来そうです。

/var/spool/clientmqueue

FreeBSD/amd64を使用して自宅のメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSでメールを読んでいます。メールを送る時はmewを使うか、場合によってはMicrosoft Windows上のThunderbirdを使用しています。数日前、procmailを呼び出すのに、.forwardで指定するのを止めて、.fetchmailrcに変更したところでした。

 

procmailの呼び出し方法を変えただけなので、これまでと同様にメールが振り分けられるはずです。実際その通りなのですが、FreeBSD/amd64自身のrootが送信したメールが見当たらないことに気づきました。root宛のメールは、aliasesでローカルユーザに渡しています。

 

まず最初に確認するのはログファイルです。/var/log/maillogを除くと、エラーが記録されています。同じようなエラーが何度も出力されているようです。目視した限りでは、次のエラーでした。

1. alias database /etc/mail/aliases.db out of date
2. get_error=error:0A000126:SSL routines::unexpected eof while reading
3. info=Bare carriage return (CR) not allowed

 

1番目のエラーは、Webを検索すると「FreeBSD: サーバーOS更新 12.3 → 12.4」という情報が見つかりました。newaliasesすれば良さそうです。

 

2番目と3番目は手強そうなので、Geminiに助けを求めました。Geminiは、「その問題なら、こうすれば解決しますよ」とか気軽に応答するのですが、なかなか解決に至りません。しかも提示された解決策を試みるとエラーが出るので、それを報告すると、「すいません、間違っていました。本当は、この方法です」と別な方法を示してきます。生成AIの回答らしいと言えば、そのとおりです。その分野のエキスパートに尋ねても、やっぱりこうなるかもしれません。生成AIなら、現実の人間と違って、何度訊き返しても嫌がったり怒り出したりする心配がないのは、メリットのような気がします。

 

Geminiとの対話を2時間ほど費やしたあげく、なんとか解決に至りました。いろいろ試したし、試行した内容を取り消したりもしたので、混乱しましたが、次のような対策を講じました。

1. /etc/mail/ホスト名.submit.mcに「FEATURE(`msp', `[127.0.0.1]', `MSA', `E')」を追加した。
2. /etc/mail/ホスト名.mcに「DAEMON_OPTIONS(`Name=IPv4, Family=inet, Modifiers=b')」と変更した。IPv6の方も同様に変更した。

 

このように変更してsendmailサービスを再起動すると、溜まっていたメールが流れる「はず」だったのですが、溜まったままでした。Geminiも半ばお手上げ状態で、スプールにあるメールを「tr -d '\r'」しながら、senmailに渡し、強制的に配送しました。これが成功したので、スプールにあるファイルは物理的に削除しました。

 

そもそも、何故このような事態に陥ってしまったのか、その原因は不明です。前回と今回の問題解決において、Gemini（というか生成AI）の威力を実感しました。それと同時に、間違い（勘違い？）を含む回答もしてくるので、Geminiの回答を鵜呑みにするわけにはいかないだろうと思います。そういう意味で、Geminiの指示に淡々と従うわけにはいかないでしょう。生成AIがあれば、何も勉強しなくても万々歳とはならないと思います。 

BIMI-Indicator

自宅では、FreeBSD/amd64を使用してメール環境を構築しています。fetchmailで取り込み、procmailで振分け、GNUSで読んでいます。つい最近になって、ふと気づくと/var/spool/mqueueに配送できなかったメールが溜まっていることに気づきました。

 

溜まっているファイルを確認したら「SMTP error: 552 5.6.0 Headers too large (32768 max)」というエラーが記録されています。他のファイルも同様でした。このメッセージを手掛かりにWebを検索してみたのですが、解決に至る情報がみつかりませんでした。そこでGeminiに助けを求めてみました。

 

Geminiとの対話では、このメッセージを提示するところから始めました。これだけの情報では、一般論しか返ってこないので、対話を繰り返しながら、問題が解決できるような方向に話を進めました。解決策は幾つかあるようです。これまでは、上述したように、fetchmailで取り込み、.forward経由でprocmailを呼び出して振分けていました。.forwardを利用することでsendmailが介入することになりますが、問題となっているメールには「BIMI-Indicator」という巨大なヘッダがついていて、これが根本的な問題だろうと思います。

 

メッセージが指摘するように「Headers too large」なので、sendmailが「32768 max」という制限をかけているのを緩和するのも一つの方法です。他の方法として、fetchmailから直接procmailを呼び出すこともできて、そうすれば.forwardを使わないので、sendmailが介入することもありません。こちらの方法を採用することとして、.fetchmailrcに設定を追加しました。

 

対策を講じたことで、問題は解決したようです。

 

本来であれば、巨大な「BIMI-Indicator」というヘッダをつけている送信元が対処して欲しいところです。サイトのメールサーバの設定によっては、32kで制限をかけているところがあるでしょうから、そこでも問題が発生しているのではないかと思います。

Windows11のメディアプレイヤーでCD情報が表示されないのはspecificationなのかundocumented featureなのか

2025年12月初め頃から、Windows11のメディアプレイヤーにおいてCD情報が表示されなくなっているという報告がありました。Microsoftからは公式アナウンスが出ていないようなので、偶々何かの調子が悪いだけなのか判断できませんでした。2026年に入ってからは、Web上に次のような情報があります。あいかわらずMicrosoftから公式発表がないので、憶測でしかありません。

• 仕様が変わった？ Windows Media Playerやメディアプレーヤー、CDの楽曲情報取得が不可能に 
• Windowsメディアプレイヤーに異変→まさかの機能終了に惜しむ声「やっぱり不便」「乗り換えですかね…」 

 

なぜMicrosoftが公式に何も発表しないのかわかりませんが、そもそも「仕様」だったのだろうかという疑問をもちます。MicrosoftがWindowsを開発するにあたり、社内的には何らかの仕様書が存在する（はずだと思いますが、さすがに）のでしょうけれども、それが外部に伝わることはありません。私自身としては、Microsoft Windowsの一人のユーザとして、「Windows仕様書」というものは、これまでに見たことがありません。「ウィンドウズの使い方」のような文書なら見たことがありますが、それは「仕様書」というほどのものではなくて、「このような使い方がありますよ」という簡単な説明でしかありません。

 

メディアプレイヤーを使うとCD情報が表示されるということは、昔から気付いていましたが、それが「仕様に基づく」のか「偶々そうなっているだけ（実は何かのバグ？）」なのか、はっきりした説明を受けたことはありません。暗黙のうちに、CD情報が表示されるのが「仕様ではないか」と思い込んでいただけなのかもしれません。むしろ「undocumented feature」だったのかもしれません。

 

「仕様」だったのであれば、Microsoftに対して正式に説明を求めることができるとおもいます。しかし「undocumented feature」なのであれば、Microsoftに問い合わせても「そのような挙動が過去にあったとしても、メディアプレイヤーの機能の一部ではありません」と回答されて終わりになってしまうでしょう。

 

遥か昔にTK-85で8085を学んでいたころ、16x16のマトリクスで示されている命令一覧において、空白（未定義）となっているところにも、面白い動作をする「未定義命令」が隠してありました。しかし正式な命令として仕様書に記載されていたわけではありませんから、正式に問い合わせても（そんなことをした経験はありませんが）、正式に「知りません」と回答されるのがオチでしょう。

 

閑話休題。メディアプレイヤーが、今後もCD情報を表示しないのか、突然復旧するのか、皆目見当もつきません。僕個人の対策としては、Apple iTunesをインストールすることにしました。Windows10の頃には使用していましたが、Windows11に移行するにあたり不要かと考えていました。手持ちの音楽CDをメディアプレイヤーで再生できないわけではありませんが、CD情報が出ないのは、多少気になります。そのためだけにiTunesを利用するつもりです。 

 

 

findコマンドのオプション「-newerXY」

U*IXでは、BSD系でもLinux系でも、階層的なディレクトリ構造を辿ってファイルを見つけるには、findコマンドを使うのが標準的です。もっともオプションの指定方法が独特なので、昔から使い慣れているオプション以外は、よく知りませんでした。それでも、今まで特に困ったこともなかったのですが、これまで使ったことのない便利なオプションが（何時の間にやら）追加されていたことを知りました。

コマンド実行時点を基準に、指定した日付よりも以前とか以後のファイルを見つけるには、オプション「-mtime」を使えばよいと思っていました。また指定されたファイルを基準に、それよりも新しいファイルを見つけるには、オプション「-newer」を使えばよいと思っていました。これだけでも不自由はないのですが、オプション「-newer」では基準となるファイルを用意しておく必要があるので、もっと便利な方法がないだろうかと思っていました。

 

Webを検索したら、オプション「-newerXY」というものがあるようです。これは何だろうと調べてみたら、いくつか記事が見つかりました。

• findコマンドで期間を指定した検索をする 
• find コマンドがめっちゃ便利だった話 

 

このオプションは昔は無かったと思うので、いつの間にか追加されたのだと思います。これを使えば、オプション「-newer」のようにファイルを用意しておかなくても、特定の日時を基準にしてファイルを見つけられるようになります。素晴らしい。

 

findに限らず、よく利用しているコマンドにおいては、使い慣れたオプション以外に何があるのか改めて確認したりすることがありません。もしかすると便利なオプションが増えているかもしれないので、ちゃんとマニュアルを確認しておく必要があると思いました。

NHKラジオに「Enjoy Simple English」という英語教育番組があり、数年前から聴いています。テキストも購入しています。2025年10月から2026年3月までの放送は、2021年度上半期の再放送です。

 

2025年1月15日放送は、「Marie the Scientist」というシリーズにおける「Why Do People Die?」という内容でした。この冒頭は、次のように始まります。

Narration (Marie): Dear Diary, Today, Ms. Sato, our homeroom teacher, didn't come to school. So Mr. Fujita taught our class. Haruto asked Mr. Fujita ...

Haruto: Do you know where Ms. Sato is?

Mr. Fujita: She had some bad news. Her mother died last night.  

 

この部分は、学級担任の佐藤先生の代わりに藤田先生が現れたので、ハルトが「佐藤先生は、どうしたんですか？」と聞いているところです。このような状況は、学校に限らず、何処ででもあると思います。

 

ただし、ここで気になるのが「Do you know where Ms. Sato is?」という英語表現です。直訳すれば「佐藤先生が何処に居るか、知っていますか？」となるでしょう。意訳すれば「どうして来ないんですか？」とかなるところでしょう。

 

以前にも紹介したことがありますが、Japan Timesの週刊ST（2012年4月6日号）の連載「English across Cultures」（青山学院大学名誉教授 本名信行）の中に、次のような記述があります。

一つの例を挙げましょう。ある会合に、出席する予定だった人が来ていなかったとします。後日、その人に尋ねるとき、日本人は「私はあの会合に行きましたが、あなたはどうして来なかったのですか」と言います。これを英語にすると "I went to the meeting. Why didn't you come?" となります。ところが、ネイティブスピーカーは、こういう状況では、"I was there. Where were you?" というような言い方をします。同じ状況を、ネイティブスピーカーは動きではなく、存在としてとらえるのです。

 

これはまさに、上述した会話と同じ状況です。日本語でも英語でも、発想は「何某は何故居ないのか？」であったとしても、言葉で表現すると、日英で異なってしまうようなのです。この事実は、日本人が英語を学ぶ際に引っかかるところだと思います。日本人の表現を英語に直訳しても、それが英語圏で通じないということはないでしょう。しかし英語圏の表現の仕方を踏まえて英語で表現すれば、よりスムースな会話になると思います。

 

英語を勉強する中で、このような日英の表現の違いというものは、気にしなければならない必須事項ではないと思いますが、注意を払っておく方が良いのではないかと、私自身は考えています。本件に限らず、日英の表現の違いがあると思いますので、英語に接する際には注意してみていこうと思います。