享(サム本人) 的个人资料古川 享 ブログ照片日志 工具 帮助
11月1日

IME 2007の甲斐減少は、買い減少に修正されました。ありゃっ

MS IMEの誤変換に関して、以下のようなエントリを記しました。
℃トウのご変換、館無料」「IME 2007の甲斐減少
いただいたコメントの中に、マイクロソフトの佐野さんから「MS IME 2007の辞書が壊れている可能性があります。」とのご指摘とその
修正方法修正モジュールのダウンロード先を教えていただきました。サポートページはこちら、そこでさっそく試してみたところ、誤変換として指摘した8割ほどの奇妙な変換結果は改修されました。修正前には、次候補を何回押しても正しく変換されず、学習もせず呆れていたのですが、突然お馬鹿な変換結果が全てリセットされ出火時の、出荷時の、ありゃまだおかしいのかな、出火時、学習しないじゃん、修正後も”次候補”も学習せず何回変換しても"自候補”、...いくつかの誤変換は改善されているようなのですが、相変らず、誤変換の振る舞いはみられるようですが....現在確認中です。

原因は、パソコンがフリーズしたりブルースクリーンを表示したときに、電源スイッチを”長尾氏”、うーん”名が押し”、”長押し”するとハードディスク内の辞書ファイルを壊す可能性がありますとのこと...この手の”書き込みバッファをフラッシュするかどの時点で書き込むか”、という基本ロジックはかって私がプログラマーだったころ、アスキーの仕事として中島聡さんたちと書きあげたPC-8001、PC-8801、if800の8ビットOS、CP/M80のBIOSで既に解決していたプログラム手法なのにねぇ(1980年から82年のこと)

教えて頂いた辞書の修復をすると、IMEの学習履歴はすべてリセットされるそうなので、再度学習登録を試みますが、”葬式”は最初から正しく変換するようになったものの、”層式会場”は未だに変、編、変、何度入力しても”編”....これをMS IMEの買い減少と、怪現象と入力したら、”甲斐減少”といつも変換していたのに、改修後は、いつも”買い減少”になるのは、改修されたと見るべきか、お馬鹿ではなくなったのに、小馬鹿にされているのか理解不能であります。

本部ログ(もとい、本ブログを本とブログをそれぞれ変換しても”部ログ”になるのはなぜだ、今までブログという単語はBUROGUから変換できたのに、辞書の修復をしたら、必ず”部ログ”と変換されてしまいます。) 

めちゃくちゃな変換結果に悩まされている方、是非上記の修正モジュールをお試しください。

情報提供をありがとう、マイクロソフトの佐野さん....でも、この情報がMS IMEの開発者やサポート部門ではなく、全く関係ない部署の個人の善意でしか改修方法を教えてもらえないのは、如何なものかと思うのであります。

では、ふるかわでした
P.S. 朝日新聞に全面広告でマイクロソフトの社会貢献プログラムの宣伝が出ていました。朝日新聞の1面で広告を打てば3000万円以上のコストがかかると思うのだけど....社会貢献プログラムをしていますとお金をかけて自社で宣伝する前に....それぞれのプロジェクトに本当は幾らの予算を割いているのと改めてマイクロソフトに問いかけたい....実際の支援に割く予算に対して、その活動の広告宣伝に何倍もの予算を割り当てるのは、如何なものかと喧嘩をふっかけて圧殺された私としては、このような広告宣伝を見るにつけ微妙....実際にUpプログラムに取り組んでいる誠実な社員たちのために、それを受益される方々のためにこそ、お金を使ったほうが良いと思います。さりげなく、こんなこともやっているんですよ、と一番良い場所に社長の写真をはめ込んで自己アピールしている姿は見たくないなぁ、その社長の写真のスペースできっと百万円分くらいの紙面コストがかかっているのではないかな?現在の社長がアメリカ本社に帰る前に、自分の成し遂げたことをアピールするために3000万円も広告宣伝に使うのなら...早く樋口さんに権限移譲をして、代表取締役社長として樋口さんの采配で「新しいマイクロソフトにリセット起動」のために尽力いただいた方が良いと思いますよ!!!
樋口さんの就任に関して
MSの記者発表、関連記事その1その2その3その4

评论 (2)

请稍候...
很抱歉,您输入的评论太长。请缩短您的评论。
您没有输入任何内容,请重试。
很抱歉,我们当前无法添加您的评论。请稍后重试。
若要添加评论,需要您的家长授予您相应权限。请求权限
您的家长禁用了评论功能。
很抱歉,我们当前无法删除您的评论。请稍后重试。
您已超过了一天之内允许提供的评论数上限。请在 24 小时后重试。
因为我们的系统表明您可能在向其他用户提供垃圾评论,您的帐户已禁用了评论功能。如果您认为我们错误地禁用了您的帐户,请联系 Windows Live 支持部门
完成下面的安全检查,您提供评论的过程才能完成。
您在安全检查中键入的字符必须与图片或音频中的字符一致。
享(サム本人) 在此页禁用了评论功能。
相当G.O.R.Nさま、コメントありがとうございます
 
古川享(サム本人)です。
> CP/M-80 の事例はいささか例としては不適当だろうと思います。
かどうかは、以下のコメントをご査収されたうえでご判断ください。25年ほどプログラミングから離れているので、的を得た表現になっていないかもしれませんが、お許しを...
CP/M80はコントロール・プログラム for マイクロプロセッサとよばれたモニタープログラムであり、まともなマルチタスクOSとしてのメモリ管理もインタラプトによるIO処理もしてくれませんでした。そこで中島聡氏、増川美樹氏と私はマルチタスク・カーネル別途ゼロから中島氏が開発し、その他IOドライバを含むBIOSを増川美樹氏と私が動作させてその管理下の下で、画面の表示タスク、キーボードやシリアル入出力、印刷、IEE488、ディスクの書き込みタスクをマルチタスクで動作させ、そのタスクの一つとしてCP/M80とそのアプリケーションを動作させるBIOSを提供していたのです。
当時のCP/M80は128バイトのセクター処理しかしなかったために、256バイト/セクターや高速書き込み読み出しのためにブロッキング・デブロッキングする際に書き込みバッファをどの時点で書き込むかを失敗するとディスクを壊すということが発生しました。8インチのフロッピーはそれを避けるためにメディアをレリースするボタンをロックすることにより防御していましたが、5インチや3.5インチのフロッピーはいつでもメディアを引き抜くことができたので、バッファに残ったデータを書き込む前にメディアを抜くか、PCの電源スイッチをオフにした瞬間にいつでもフロッピーを壊す危険をはらんでいました。それをさけるために、読み出しにはブロッキングをするが書き込みの際には128バイトの書き込みごとにブロッキングなしで256バイト/セクターの書き換えを毎回するというオマヌケなBIOSがほとんどでした。そのセクター単位の書き込みを改善して256バイト/セクターや512バイト/セクターをクラスター単位で処理するように考慮したのが当時のMS-BASICのFAT(ファイル・アロケーション・テーブル)の冥利なのだけれど、CP/M80はそんなことに対する配慮はありません。
マルチタスク・カーネルが管理していたステータスは、連続してキーボートが入力しているときは、フロッピーの着脱や電源スイッチに手が届いていない、連続した読み出しをトラックバッファに用意して、書き込みバッファとの対比をしながらディスクからの再読み出しにかかる時間を防ぐ、次セクター、次トラックの事前読み出しをして次の読み出しに備える、書き込みが発生したときにに偶数セクターで終わった時にはすぐにそのセクターを256バイト単位で書き込むもしくは効率よくトラック単位の書き込みをするが、もし奇数セクター(128バイト)単位の書き込み命令で終わっているときには、画面の書き込みタスク、キーボードの入力が途絶えた隙にバックグラウンドで書き込みに入る....とうわけで、いつ何時でも電源を切ってもディスクは壊れないというわけではありませんが、アプリケーションが暴走してもバックグラウンド・タスクで安全にディスクの書き込みを終了するぐらいの策は既に取られていたということであります。さらに、PC8031というPC8001用のディスクは相手方に8bitのCPUと書き込みバッファ、と同上マルチタスク・カーネル、さらに別電源を搭載していたので、CP/M80による通常の書き込みバッファの安全な書き込みのみならず。ディスクのコピー中にPC-8001の電源をオフにしても、安全にディスクコピーを終了するという機能を64Kbのメモリで実現していたのであります。時代の進歩に合わせて、インテリジェンスも増し、キャッシュも複雑化していることは判りますが....、
 
現代の複雑化したキャッシュをどう活用されるか、どのレベルのCPUやOSがどのようなファンクションコールを持っていたかは、お客様にとってはどうでも良いことで、8ビットの時代にもマイクロ・カーネルをゼロから書き起こしてでもユーザーの利便性を追求する姿があって、その時体験した「お客様にとって、アプリケーショにとって、ディスクのバッファは効率よく読みだされバッファリングされるべきか、そのバッファはどの時点でフラッシュ(廃棄)もしくはディスクに書き込まれるべきか...」という命題にチャレンジしてそれなりの解決をしていたのでありました。 そのレベルのことがちゃんとなされていたら、MS IMEの辞書を壊すことこもなかっただろうし、意味もなく「汎用ボリュームのために取り出せません」なんてお馬鹿なメッセージも表示しない環境を作れるのではないでしょうか?
 
では、ふるかわでした
11 月 4 日
直哉发表:
ポイントは何点かありますが。CP/M-80 の事例はいささか例としては不適当だろうと思います。
一見すると適切なようにも聞こえますが、今日のシステムの場合、キャッシュはあちこちのところでされます。ハードディスク自体でもキャッシュされています。従って、8bit PC 時代のように、一つのアプリケーションは全てを統べという一種、平和な時代とは異なります。また、現在のシステムは8bit CPU 時代よりも CPU の処理速度は長足の進歩を遂げましたがメモリ、ディスクといったデバイスは CPU と同じスケールの進歩を遂げたわけではありません。結果的にディスクは相対的に遠くなったと思います。そうなると、想定されていなかったタイプの問題が出てくるのは必然です。
実際、オープンソースの日本語変換システムでも辞書や学習データのファイルが何故か壊れるという話は出ており単純な問題ではないのではないかと思います。いずれにおいてもファイルシステム的にはファイルは正常なままです。つまり、ファイルの大容量化といろいろな要因が重なって。ファイルシステム的には正当でもアプリケーションから見て壊れたファイルというのはできやすくなっていると思います。学習データなどは入力に伴ってリアルタイムに更新されるファイルですから問題は起きやすいのではないかと思います。
私見ですが、Windows Vista で追加された、トランザクション付きのファイル I/O 機能はうまく使えばこういった問題に資するのではないかと考えています。ただ、無論、Windows XP には未実装のI/O function ですからアプリケーションでの利用はうまくする必要があると思いますが。
11 月 4 日

引用通告

此日志的引用通告 URL 是:
http://furukawablog.spaces.live.com/blog/cns!156823E649BD3714!8325.trak
引用此项的网络日志