99/1/30 Macintosh トラブル Data Archives

[ 99/1/30]

●メーラの 2000 年問題対応状況

木本氏から各メールアプリケーションの西暦 2000 年問題対応状況について貴重なレポートをいただいた．

メールソフトウェアの中には，送信時に 2 桁の西暦で日付をつけるものがあります． ( RFC 822 を見ると「2 桁」とあるが，実は RFC 1123にて，「4 桁」に修正されている．) 送信時に 2 桁の西暦で送るメールソフトウェアはそんなに多くないのですが，そういうメールを西暦 2000 年以降に受信したときに処理を誤るメールソフトウェアが，けっこう，多いのです．

2 桁の西暦のメールを受信するとき，メールソフトウェアによっては 2000 年のメールを 1900 年と解釈しようする（実際にはアンダーフローして 1944 年くらいになる）ものもあれば， 1999 年のメールを 2099 年と解釈しようとする（オーバーフローして 1919 年くらいになる）ものさえ実在するのです．

木本はメールの読み書きにはマッキントッシュを使っているので，マッキントッシュ上のメールソフトウェアをいくつか調べてみました：

×「送信時に 2 桁の西暦をつけてしまう」

・Claris Emailer の 2.0v2 まで (2.0v3 へのアップデータで修正)

・クラリスメール (Lite 版含む) 全てのバージョン (修正の見込みなし)

・Cyberdog の全てのバージョン (修正の見込みなし)

×「受信した 2 桁の西暦を誤変換する」

・クラリスメール Lite (修正の見込みなし)

・++Mail for Mac 3.0.3 (開発元は問題を認識しているが修正時期は表明していない)

・ Musashi 3.0.2

・ Postino 1.3 (次期リリースで修正の予定)

・ PinkRabbit for Mac Beta 1 「正規版」 (次期バージョン以降で対応の予定) ・ PostPet 2001 2.0

◯「送信・受信ともに問題なし」

・Netscape Communicator for Mac 4.5

・OutLook Express for Mac 4.5

・PowerMail 2.3.1

・ARENA Internet Mailer 1.0.5

・Eudora-J 1.3.8.8r6

・Eudora Pro 4.0.1-Jr1

・Dolphin 2.0

なお，本項目の主旨とは離れるが， Macintosh のメーラとして多大のご貢献をいただいている Eudora-J は 1.3.8.8r6 になって中田氏によって添付書類のエンコード形式について BinHex4.0 以外に待望の MIME Base64 ほか対応となっている．

● Blue & White G3 ： Adaptec 3940UWD で起動できない

高橋氏から Adaptec 3940UWD が Blue & White G3 で起動できなくなるとお知らせいただいた．

氏の新型 G3 / 400 に Adaptec 3940UWD をスロットに挿しただけで起動しない状態だそうだ． 3940 のボードを挿しただけで起動しないので，HDD とかに問題があるとは思えないとのこと．（起動ディスクは純正の2940U2Wにつながっている純正のハードディスク）

● Blue & White G3 ： Mac OS すべてのセットで赤×マーク

TIL: 58263 : Power Macintosh G3 (Blue & White): Graphics Accelerator shows red "X" on startup

Blue & White G3 で機能拡張マネージャを Mac OS すべてにした場合，起動時のアイコンパレード中に ATI 関連アイコンに×マークがつくことが上記 Tech Info Library に述べられている．どうも機能拡張マネージャのセットにミスがあったようだ．

Mac OS すべてのセットで ATI 関連で落とされた機能拡張があるためと説明している． Mac OS すべての表示でパッケージ表示とし， ATI 関連パッケージでチェックが入っていない機能拡張をオンにする回避法が書かれている．

●スマートメディアのファイル作成日付： Exif フォーマット

99/1/28 項目 "スマートメディアのファイル作成日付" に関して，塚原氏から有益な情報をいただいた．

この問題はスマートメディアのデジタルカメラ等で撮影した撮影データの作成日時が撮影日時が実際の撮影日付と異なる場合があるというものであるが，塚原氏の情報によれば，最近のデジタルカメラでスマートメディアを採用しているカメラの画像ファイルフォーマットは，ほとんど Exif だそうである． Exif フォーマットである場合，ファイル内部に撮影日時が記録されているようなので，そのデータを取り出すことができると思われる．

そのためのツールが存在しているので，そのツールを使用することで問題を回避できるのではないかということである．以下で入手できるツールによって撮影日時を表示することができたりする．

List Date,Time(Exif) (原幸久氏作)

ChangeFName 0.3.2 (青木康雄氏作)

後者のツールではファイル名が "yymmdd-hhmmss.jpg" と付け替えられるそうだ．残念ながら私のオリンパス C-1400L では私が使い方をよく分かってないせいか，できなかった．上記ユーティリティには対応しているカメラが書かれていて，私のものは該当してない．

塚原氏からは Exif フォーマットに関して以下の場所をお教えいただいている．

リコー「Exif」
ディヂタルスチルカメラ用画像ファイルフォーマット規格 (Exif) Ver2.1
1996/10/26-11/2: Exif file format
Exif ファイル形式の解析

● StuffIt (英語版）でのトラブル

斉藤氏は StuffIt deluxe5.0.2（英語版）ほかで次のような経験をされた．

「 StuffIt Browser での日本語ファイルの文字化け」

StuffIt deluxe5.0.2 で日本語名のファイルを圧縮し， StuffIt Browser でファイルを見ると，文字化けしたように見えます．しかししばらくして再びStuffIt Browserで見ると，正常にファイル名があらわれる．

「古いバージョンの .sit ファイルが捨てられない」

StuffIt のバージョン 5 より古いバージョンで圧縮した .sit ファイルを，（StuffIt deluxe 4.5.1J, Lite3.6, DropStuff4.5J など）ゴミ箱に入れ，空にしようとすると「ロックがかかっている」，「ゴミ箱を空にできません」というメッセージが現れ，捨てられないことが起きる． shift 起動すると捨てられた．ただし，再現性はなかった．

二番目の事項は氏の環境によるコンフリクトかも知れないともお書きである．

● Internet Explorer メモリリークの MacFixIt への Microsoft からの説明

MacFixIt 99/1/27 に先日私も書いたメモリリーク（ Internet Explorer の使用メモリが増加し，終了後も解放されない． 99/1/22 項目「 Internet Explorer： Finder の強制終了？メモリリーク」参照）に関して Microsoft から説明が投稿されている．

詳しくは MacFixIt をご覧いただきたいが，アプリケーション使用メモリは連続したメモリ空間が必要だから Internet Explorer が終了して解放したメモリがそれより少なければアプリケーションは起動できないというごく月並みの一般論と，関連したページがひとつでも開かれている限り関連ページのキャッシュ等が解放されないからだというような内容．

● MacFixIt による ATM とアピアランスの問題の指摘

MacFixItは 99/1/27 記事で， TrueType がない場合，アピアランスコントロールパネルの "なめらかな文字で表示する" 機能がオンになっていると ATM フォントで障害が発生するとしている．例えばクラリスホームページで文字表示に時間がかかるようになるといった障害が発生するという．回避法は "なめらかな文字で表示する" オプションを切るか， TrueType を入れるかするとしている．

私はクラリスホームページを持っていないので（デモ版で試すことはできるだろうが）よく分からない．この問題は MacFixIt の作者の Ted Landau 氏自らの環境で発生しているようなのであながち否定できないのだが，私の環境では他の場面等では気が付かない．

● Illustrator 8 のメモリバグについての MacFixIt への投稿

MacFixIt 99/1/27 への投稿によれば， Adobe Illustrator 8 には Adobe も確認したメモリに関するバグがあると述べられている．

高解像度の EPS ファイルを配置したファイルを閉じた場合にメモリが (アプリケーションヒープに?) 解放されず，その結果メモリ不足になるという．

私の環境では書かれているような症状などの異常は確認できなかった．

●よもやま：西暦 2000 年問題

西暦 2000 年問題は最近になって "Y2K" と表記されることが多くなった．これは "Year 2000" （000 を K で表す）のことである．（ "K" はコンピュータの世界では 1024 であるのに対し "k" を 1000 として区別する慣行であるが，Y2K と表記されているようである． Apple でも "68k" とは書かず "68K" と表記するようだ）

Macintosh に関しては OS のレベルでは 2000 年問題はない．ただし，使用しているソフトウェアに関しては上記のように各ベンダーが対応しなければならない．これらのことについては Macintosh と西暦 2000 年問題というページを 96 年に作成したことがある．手前みそになるが，これはMacintosh に関する 2000 年問題について明示的に書かれた最初の文書ではないかと思っている．

西暦 2000 年問題は主に COBOL で書かれたものに問題が起こり，その一部は 99 年から既に問題が起きると予想されていた．（ COBOL では 99 が終了命令となるがこのことは直接関係ないだろう）また， 2000 年が特殊な閏年であることも問題を複雑にしていた．しかし，当初予想されていたソフトウェアプログラムの問題だけでなく，プログラム組込みチップや BIOS といったハードウェアの問題が発覚し，現時点では完全な対応は絶望視されている．軍事衛星に組み込まれたチップの誤動作をどのように防ぐかよい知恵はない．ただし，障害が発生するとしてもそれがどの程度のものかについては未曾有の大災害と見る見方と案外大したことはないという見方が交錯している．

未曾有の大災害が起きるとするものの主な予測は，石油パイプライン，航空管制，航空機船舶の航法システム，軍事兵器関連，医療，通信，銀行オンライン，ガス，水道，電気，原子力，交通物流などに致命的な障害が発生するというものである．大したことはないというものは基幹となるところが修正されれば，電気炊飯器やビデオデッキのタイマーが動かないとしてそれがどうしたというようなものだ．

それがどの程度であるかは分からないが，2000 年問題は必ず起こる．問題の解決を難しくしている要素は世界的レベルで起きるということである．いくら日本国内で対策をしても日本に入ってくる石油がなくなればどうしようもないというわけだ．

Macintosh の OS に 2000 年問題がないとしてもネットワーク環境でそのような問題が生じたときには「 Macintosh は関係ない． Windows は問題出るだろ」と言っているどころではなくなるだろう．上記のような深刻な事態が起きないとしてもコンピュータはネットワーク環境なしでは考えられなくなっている．ネットワークに障害が発生した場合， Macintosh だけが動いていても無意味だ．

私は 2000 年の正月には絶対に飛行機にだけは乗らないでおこうと思っているが，正月には電気ガス水道が停止し， PowerBook で数時間のバッテリ駆動でしかコンピュータが使えない事態だってありえる．電気炊飯器が機能しなくても正月だからお節料理や餅があるのでしばらくはしのげるだろうという冗談はさておいて，予想される最悪の事態の深刻さに私たちも気が付かなければならないのだ．

[その他]
Yosemite User's Group

(C) Akiyama Satoru