過去の桐井戸端ＢＢＳ　（桐談義・その他）

9164	不正な処理で落ちてしまう。（Re#6113:桐ｖ5 と SiS620）＋桐ｖ８とWin９８ＳＥ	hidetake	2000/12/29-21:13
http://www.fuku3.com/~habata/kbbs/kakov5/06113.htm で問題なった、「不正な処理」で桐が落ちてしまう件について、 同じ現象が IBM ThinkPad1124 でも発生いたしました。 440MX チップで Celeron 450MHz の機種です。 今回は多少時間があったので調べてみました。 なんと、落ちるのは「検索」コマンドでした。 それも表の開き方で落ちる場合と落ちない場合があり、 「更新=禁止」で開いた表で「検索」コマンドを実行すると 「不正な処理」で落ちるようです。 取りあえず「更新=許可」に変更して簡単なテストだけ動作確認いたしましたが、 もしかしたら、ほかの部分でも不具合が発生するかも知れません。 これから、ますます、この手の問題は増えるのかも知れません？ EMS と違ってもっと難しい問題かも知れません。 また、桐５は使っているリリースが私自身も含めて１０なのですが、 ひょっとして１１にすれば問題が出ないのかも知れません・・・ みなさんも、お気をつけ下さい！
9165	Re:Re#6113:桐Ver5 と SiS620	hidetake	2000/12/29-21:16
記事番号9164へのコメント >同じ現象が IBM ThinkPad1124 でも発生いたしました。 OS は Windows98 SE です。
9166	桐Ver8 でもＷｉｎ９８ＳＥで「不正な処理」は良くあります。	KH	2000/12/30-00:08
記事番号9165へのコメント hidetakeさん今晩は。ちょっと話しが外れますが、Ｗｉｎ９８ＳＥがでてきたので、コメントさせて頂きます。 　桐８ｓｐ６、Ｗｉｎ９８ＳＥでもよく「不正な処理・・・」は私の場合でます。 他のソフトを使った後に桐を立ち上げた場合は良くあります。 桐立ち上げででますから桐を立ち上げられない事がしばしば。 再起動して桐から立ち上げ直して作業します。 桐終了後他のソフトは問題ありませんから 桐から他のソフトに与える影響は極めて少ないのではないかと憶測しています。 問題の他のソフトですが、どうもＩＥ５、画像を扱うソフト等が考えられますが確証はありません。 Ｗｉｎ９８ＳＥはプレインストールのままの状態。 でも、「Ｗｉｎ９８」のマシンはないとは言い切れませんが、ほとんどこの現象は起こらないのです。 ＳＥのマシンは常駐ソフトのせいかと思い、かなり切ってしまったのですが、 「システムリソースが足りない」は減りましたが、「不正な処理は・・・」はたいして減らないような気がします。 私の勝手な憶測なのですが、「Ｗｉｎ９８ＳＥ」のせいと言う事は考えられませんか。 話しがＶ５からＶ８と飛躍してしまいましたがゴメンなさい。
9168	Re:桐Ver8 でもＷｉｎ９８ＳＥで「不正な処理」は良くあります。	Ogo	2000/12/30-01:39
記事番号9166へのコメント >　桐８ｓｐ６、Ｗｉｎ９８ＳＥでもよく「不正な処理・・・」は私の >場合でます。他のソフトを使った後に桐を立ち上げた場合は良くあり >ます。 V5 は DOS ソフトですから、V8 とは全く原理が異なります。 この V8 の問題はいかにも「DLL 地獄」が原因という感じに読めます。 参考情報 http://www.asahi-net.or.jp/~ki4s-nkmr/mswatch29.html の 2000/10/03 付け記事や http://www.galliver.co.jp/writing/vmx/sxs2k/ VisualBasic だけでなく、 MFC なんかの根本的な Windows の根幹そシステムの部分で MS は同じ間違いを繰り返しているから（ OS, MS-ie, MS-Office は全て新バージョンや 新サービスパック等が出る度にこの問題を引き摺っている）。
9169	Re:桐５の動作不良の可能性の１つ	Ogo	2000/12/30-01:48
記事番号9165へのコメント 多分、関係ないと思います。 が、私の経験を１つだけ。 DOS 上で何も問題なく動くものが、 Windows 上では落ちることが繰り返されました（私の場合は「整列」で発生しました）。 で、結局のところ、問題は桐５自身にありました。 と言ってもプログラム内容（Ｋ３の責任）ではありません。 実は DOS マシンで使っていたものを桐５のプログラム一式とデータベースシステム一式を、 ファイルコピーして Windows 環境に移行させたのですが、 その際に、どうも桐５の構成ファイルの中のどれかが壊れていたみたいなのです。 この場合は、桐５そのものをもう一度インストール フロッピーからインストールし直したら、ウソの様に問題が消えました。 まぁ、そんな笑い話もあったということで。
9170	Re:桐Ver8 でもＷｉｎ９８ＳＥで「不正な処理」は良くあります。	KH	2000/12/30-09:52
記事番号9168へのコメント >V5 は DOS ソフトですから、V8 とは全く原理が異なります。 > >この V8 の問題はいかにも「DLL 地獄」が原因という感じに >読めます。 > >参考情報 >http://www.asahi-net.or.jp/~ki4s-nkmr/mswatch29.html >の 2000/10/03 付け記事や >http://www.galliver.co.jp/writing/vmx/sxs2k/ > >VisualBasic だけでなく、 MFC なんかの根本的な Windows >の根幹そシステムの部分で MS は同じ間違いを繰り返して >いるから（ OS, MS-ie, MS-Office は全て新バージョンや >新サービスパック等が出る度にこの問題を引き摺っている）。 Ogoさん、おはようございます。 いつもいつも適切なアドバイスどうもありがとうございます。 Ｖ５のここに書き込むこと自体変だったんですが、 ついついＷｉｎ９８ＳＥが出てきたので、甘えてしまいました。 またよろしくお願いします。
9171	Re:「DLL地獄」（ねっ、ほりかわさん）	Ogo	2000/12/30-13:41
記事番号9170へのコメント >この V8 の問題はいかにも「DLL 地獄」が原因という感じに >読めます。 >VisualBasic だけでなく、 MFC なんかの根本的な Windows >の根幹そシステムの部分で MS は同じ間違いを繰り返して >いるから（ OS, MS-ie, MS-Office は全て新バージョンや >新サービスパック等が出る度にこの問題を引き摺っている）。 桐８の System フォルダに 「MFC42.DLL」と「MSVCRT.DLL」という２つのファイルがあります。 これを初めて見た時にはぶっ飛んだ。 この２つは Windows の System フォルダに入っているはずで、 Windows 自身の標準的機能を供給するものだからです。 そんなものを何ゆえに桐は自前のフォルダの中に重複して保持しているのか。 こんなことが考えられます。 １．この２つのファイルは最初の Win 95 の時には存在しなくて、 途中の MS-ie や MS-Office または Micorosoftの Visual C の 特定バージョン以降で作成されたソフトが、後から追加でインストールして Windows に機能拡張するようになっている（ C で作ったソフトを稼働させるのに DLL が必要なんて、マイクロソフトはどこまで行ってもアホウだと思う）。 ２．と言うことは、Windows のこの拡張機能を使うためには、 このファイルを持っていないマシンで使うためには桐のインストール時に 一緒にインストールする必要がある。 ３．しかし、この２つを桐インストール時に一緒にインストールするのなら、 それは Windows の System フォルダにされるべきものである。 ４．それなのに、桐８の System フォルダに保持するという仕様になっているのは、 明らかに同じ名前のファイルをWindows の System フォルダにあるものとは別に （重複して）持つように考えて意図的に行っている。 ５．理由は１つしか考えられない。 マイクロソフト配布の「MFC42.DLL」と「MSVCRT.DLL」には同名の異バージョンの DLL が幾つもあって、 それぞれ挙動が違う（上位互換性さえもいい加減）ので、プログラミング時の環境とユーザーの環境の同一性が 保証されない以上、この２ファイルは自前で用意したものを使うよう強要して Windows の System フォルダを 無視するように意図しているのでしょう。 ６．ところが、「DLL地獄」はそんな甘いものでは無かったようで （自前のフォルダに DLL を置いて解決するようならせいぜい「DLLトラップ」でしょう）、 そこまでの工夫をしても、Windows 自身が無理やり WindowsのSystem フォルダに存在するファイルを 使ってしまう事があるというのが、ソフトウェア開発側の努力を水泡に帰す「マイクロソフト仕様」なのです。 つまり、桐８起動以前に何かのソフト（叉は OS 自身）がWindows のSystemフォルダにある 「MFC42.DLL」か「MSVCRT.DLL」を一度でも呼び出した場合、この両ファイルがキャッシュに固定的に保持されてしまい、 桐８が同名の（別フォルダの） DLL を呼び出しても、桐８の System フォルダに存在する DLL ファイルではなく キャッシュ内の Windows の System フォルダにあるバージョンの DLL しか利用できなくなる （５．に照らし合わせて見れば、桐８が正常起動できない筈です）。 と言う現象で、桐８に於けるＫ３の「DLL地獄」回避策は、 見事に失敗しているということだと思われます。
9178	Re:「DLL地獄」（ねっ、ほりかわさん）	ほりかわしんじ	2000/12/31-18:36
記事番号9171へのコメント どうもお世話様です。 Ogoさんに（ねっ、ほりかわさん）」なんて書かれてしまいましたので・・・つい。 このリプライはリプライと言うほどでもありません。 何も意味をなさないと思います。 Ogoさんのと少し重複しています。 MSさんはサードパーティでのMFC42.DLLの再配布を認めていますし， 手持ちのものが最新版だったらsystemのMFCの上書きを許可しているようです（うろ覚えです）。 上書き以降MFCのリビジョンに影響受けるソフトもあると聞いています。 ソフトによってはリビジョンを限定しているものもあります （現在はあまりないでしょう）。 そんなこんなで桐のインストール時にsystemフォルダにあるMFCを勝手に上書きしても良いかという議論も当然あるとおもいます。 自前で用意している理由はOgoさんの言われている通り。 他の行儀の悪いアプリケーションのせいで最悪桐までが起動出来ないことへの回避作程度のことはあると考えられます。 とりあえず起動し直し最初に桐を起動すれば問題はとりあえず回避させられるということです。 === 「不正な処理を〜」の類の話ですがほりかわの経験的なものを述べさせて頂ければWindows自体が 不安定な動作に陥った環境で使っていないかというものです。 互換性のないドライバとか互換性のないハードウェアを使っているとかです。 デバイスマネージャあたりで？マークのついているものを調べてみる必要があるでしょう。 もちろん作法の悪いアプリの問題も少なくはありません・・・当たり前すぎるような話しで少し恐縮。 今年はこの掲示板でみなさんにもお世話になってしまいました（感謝）。 来年もご指導下さるようどうぞよろしくお願いします。 以上
9179	Re:「DLL地獄」（ねっ、ほりかわさん）	Ogo	2000/12/31-20:09
記事番号9178へのコメント >Ogoさんに（ねっ、ほりかわさん）」なんて書かれてしまいま >したので・・・つい。 スミマセン、元文はもう少し続きがあって、そこの内容こそが（ねっ、ほりかわさん）だったのですが、 ちょっと公開で書くにのはまずそうな内容だったので、幅田さんにお願いしてその部分をバッサリ削除してもらったんです。 (^^; - - - MFC インディペンデントにするのなら、ＭＳの開発ツール（ Visual Studio とか）を使わなければ、 かなり汎用性は上がるんじゃないのですか？ MFC のバージョンによりソフトが正常稼働しなくなる現象は NetscapeCommunicator や NiftyManagerでも公に アナウンスされていたことですし、こんな根本的なことで同じ過ちを繰り返す環境に依存するのはバカバカしい気がしますよね。 プラットホームの不具合に対応修正したところで、プラットホーム側が新たな不具合を持ち込むのですから （しかも特定のアプリケーションの勝手な都合でプラットホームの方を変更してしまうわけで）、 とてもまともな神経じゃ相手にできない気がします。 - - - 来たる 2001 年度も、ユーザーとＫ３との橋渡しとしての重要な役割をよろしくお願いします。 _m_(__)_m_

戻る