過去の桐井戸端BBS (桐談義・その他)
9164 不正な処理で落ちてしまう。(Re#6113:桐v5 と SiS620)+桐v8とWin98SE hidetake 2000/12/29-21:13
http://www.fuku3.com/~habata/kbbs/kakov5/06113.htm
で問題なった、「不正な処理」で桐が落ちてしまう件について、
同じ現象が IBM ThinkPad1124 でも発生いたしました。
440MX チップで Celeron 450MHz の機種です。

今回は多少時間があったので調べてみました。

なんと、落ちるのは「検索」コマンドでした。
それも表の開き方で落ちる場合と落ちない場合があり、
「更新=禁止」で開いた表で「検索」コマンドを実行すると
「不正な処理」で落ちるようです。

取りあえず「更新=許可」に変更して簡単なテストだけ動作確認いたしましたが、
もしかしたら、ほかの部分でも不具合が発生するかも知れません。

これから、ますます、この手の問題は増えるのかも知れません?
EMS と違ってもっと難しい問題かも知れません。

また、桐5は使っているリリースが私自身も含めて10なのですが、
ひょっとして11にすれば問題が出ないのかも知れません・・・
みなさんも、お気をつけ下さい!

9165 Re:Re#6113:桐Ver5 と SiS620 hidetake 2000/12/29-21:16
記事番号9164へのコメント
>同じ現象が IBM ThinkPad1124 でも発生いたしました。
OS は Windows98 SE です。

9166 桐Ver8 でもWin98SEで「不正な処理」は良くあります。 KH 2000/12/30-00:08
記事番号9165へのコメント
hidetakeさん今晩は。ちょっと話しが外れますが、Win98SEがでてきたので、コメントさせて頂きます。

 桐8sp6、Win98SEでもよく「不正な処理・・・」は私の場合でます。
他のソフトを使った後に桐を立ち上げた場合は良くあります。
桐立ち上げででますから桐を立ち上げられない事がしばしば。
再起動して桐から立ち上げ直して作業します。
桐終了後他のソフトは問題ありませんから
桐から他のソフトに与える影響は極めて少ないのではないかと憶測しています。
問題の他のソフトですが、どうもIE5、画像を扱うソフト等が考えられますが確証はありません。
Win98SEはプレインストールのままの状態。

でも、「Win98」のマシンはないとは言い切れませんが、ほとんどこの現象は起こらないのです。

SEのマシンは常駐ソフトのせいかと思い、かなり切ってしまったのですが、
「システムリソースが足りない」は減りましたが、「不正な処理は・・・」はたいして減らないような気がします。
私の勝手な憶測なのですが、「Win98SE」のせいと言う事は考えられませんか。

話しがV5からV8と飛躍してしまいましたがゴメンなさい。
9168 Re:桐Ver8 でもWin98SEで「不正な処理」は良くあります。 Ogo 2000/12/30-01:39
記事番号9166へのコメント

> 桐8sp6、Win98SEでもよく「不正な処理・・・」は私の
>場合でます。他のソフトを使った後に桐を立ち上げた場合は良くあり
>ます。

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:桐5の動作不良の可能性の1つ Ogo 2000/12/30-01:48
記事番号9165へのコメント
多分、関係ないと思います。
が、私の経験を1つだけ。

DOS 上で何も問題なく動くものが、 Windows 上では落ちることが繰り返されました(私の場合は「整列」で発生しました)。

で、結局のところ、問題は桐5自身にありました。
と言ってもプログラム内容(K3の責任)ではありません。

実は DOS マシンで使っていたものを桐5のプログラム一式とデータベースシステム一式を、
ファイルコピーして Windows 環境に移行させたのですが、
その際に、どうも桐5の構成ファイルの中のどれかが壊れていたみたいなのです。

この場合は、桐5そのものをもう一度インストール
フロッピーからインストールし直したら、ウソの様に問題が消えました。

まぁ、そんな笑い話もあったということで。

9170 Re:桐Ver8 でもWin98SEで「不正な処理」は良くあります。 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さん、おはようございます。
いつもいつも適切なアドバイスどうもありがとうございます。
V5のここに書き込むこと自体変だったんですが、
ついついWin98SEが出てきたので、甘えてしまいました。
またよろしくお願いします。

9171 Re:「DLL地獄」(ねっ、ほりかわさん) Ogo 2000/12/30-13:41
記事番号9170へのコメント
>この V8 の問題はいかにも「DLL 地獄」が原因という感じに
>読めます。

>VisualBasic だけでなく、 MFC なんかの根本的な Windows
>の根幹そシステムの部分で MS は同じ間違いを繰り返して
>いるから( OS, MS-ie, MS-Office は全て新バージョンや
>新サービスパック等が出る度にこの問題を引き摺っている)。

桐8の System フォルダに 「MFC42.DLL」と「MSVCRT.DLL」という2つのファイルがあります。
これを初めて見た時にはぶっ飛んだ。
この2つは Windows の System フォルダに入っているはずで、
Windows 自身の標準的機能を供給するものだからです。

そんなものを何ゆえに桐は自前のフォルダの中に重複して保持しているのか。
こんなことが考えられます。

1.この2つのファイルは最初の Win 95 の時には存在しなくて、
途中の MS-ie や MS-Office または Micorosoftの Visual C の
特定バージョン以降で作成されたソフトが、後から追加でインストールして
Windows に機能拡張するようになっている( C で作ったソフトを稼働させるのに
DLL が必要なんて、マイクロソフトはどこまで行ってもアホウだと思う)。

2.と言うことは、Windows のこの拡張機能を使うためには、
このファイルを持っていないマシンで使うためには桐のインストール時に
一緒にインストールする必要がある。

3.しかし、この2つを桐インストール時に一緒にインストールするのなら、
それは Windows の System フォルダにされるべきものである。

4.それなのに、桐8の System フォルダに保持するという仕様になっているのは、
明らかに同じ名前のファイルをWindows の System フォルダにあるものとは別に
(重複して)持つように考えて意図的に行っている。

5.理由は1つしか考えられない。
マイクロソフト配布の「MFC42.DLL」と「MSVCRT.DLL」には同名の異バージョンの DLL が幾つもあって、
それぞれ挙動が違う(上位互換性さえもいい加減)ので、プログラミング時の環境とユーザーの環境の同一性が
保証されない以上、この2ファイルは自前で用意したものを使うよう強要して Windows の System フォルダを
無視するように意図しているのでしょう。

6.ところが、「DLL地獄」はそんな甘いものでは無かったようで
(自前のフォルダに DLL を置いて解決するようならせいぜい「DLLトラップ」でしょう)、
そこまでの工夫をしても、Windows 自身が無理やり WindowsのSystem フォルダに存在するファイルを
使ってしまう事があるというのが、ソフトウェア開発側の努力を水泡に帰す「マイクロソフト仕様」なのです。

つまり、桐8起動以前に何かのソフト(叉は OS 自身)がWindows のSystemフォルダにある
「MFC42.DLL」か「MSVCRT.DLL」を一度でも呼び出した場合、この両ファイルがキャッシュに固定的に保持されてしまい、
桐8が同名の(別フォルダの) DLL を呼び出しても、桐8の System フォルダに存在する DLL ファイルではなく
キャッシュ内の Windows の System フォルダにあるバージョンの DLL しか利用できなくなる
(5.に照らし合わせて見れば、桐8が正常起動できない筈です)。

と言う現象で、桐8に於けるK3の「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 インディペンデントにするのなら、MSの開発ツール( Visual Studio とか)を使わなければ、
かなり汎用性は上がるんじゃないのですか?

MFC のバージョンによりソフトが正常稼働しなくなる現象は NetscapeCommunicator や NiftyManagerでも公に
アナウンスされていたことですし、こんな根本的なことで同じ過ちを繰り返す環境に依存するのはバカバカしい気がしますよね。

プラットホームの不具合に対応修正したところで、プラットホーム側が新たな不具合を持ち込むのですから
(しかも特定のアプリケーションの勝手な都合でプラットホームの方を変更してしまうわけで)、
とてもまともな神経じゃ相手にできない気がします。

- - -

来たる 2001 年度も、ユーザーとK3との橋渡しとしての重要な役割をよろしくお願いします。

_m_(__)_m_

戻る