NT 基幹業務に適用の嘘(1998/08/02)
よく、「XXX会社は Windows NT で業務システムを再構築しました」なんてのを見聞きするかと思いますが、あれは、少々大袈裟な表現であることがほとんどです。ホストコンピュータにダム端末がぶらさがっているシステムの場合、端末を Windows NT に置き換えて端末エミュレータを動かしたら、「基幹業務に Windows NT を適用」ということになるわけですね。
一部の銀行で NT 云々という話がありますけど、本当に NT で勘定系システムを構築するような銀行なんてないでしょう。もし、そんな銀行があったなら私なら即刻解約しますね。知らないうちに残高が減っててはたまりませんから。（爆）
Windows 95のメモリ管理バグ(1998/08/08)
出先で「日経バイト」８月号をペラペラ見てたんですが、Windows 98 でシステムダウンする頻度が減った理由らしきものが書いてありましたのでメモってきました。
「各プログラムの処理タイミングによっては、ページがスワップアウトされているのに主記憶上にある、と誤認されるなど、行き違いが起ることがある。こうした問題は、程度の差こそあれどんなOSでも起こり得る。Windows98はこの面でコードの手直しが行われたのだろう」」(技術支援本部デベロッパーサポート部Windowsテクノロジーグループの有働眞澄課長)
これには正直呆れてしまいました。これは完全なバグですよね。搭載メモリが少ないと不安定な理由はこれだったんですね。しかも、「こうした問題は、程度の差こそあれどんなOSでも起こり得る」ですって。そんな重要なバグを抱えたOSなんて聞いたことないですけどね。早急に Windows 95 のパッチを公開して欲しいものです。Windows 98 を買ってくださいなんてのはナンセンスです。
Windows 98を使った感想(1998/08/14)
訳あって Windows 98をインストールしました。まだ少ししか使ってませんが、なんか非常に遅く感じます。NT4.0は、もっとサクサク動いてたのになあ。VB5を入れて作業してたんですが、キャレットの動きが鈍く感じます。ディスプレイドライバがタコなのかなあ。
安定度のほうですが、私の環境ではスタンバイから復帰した後が不安定です。作業中に必ずフリーズします。マシンのマザーは Intel MP440BX という Gateway への OEM版です。SE440BX のカスタマイズ版と考えていいです。ACPIを有効にして（そもそもこの検証のために Win98 を入れた）あります。その他、特に目立った問題はないのですが、久々にOSが死ぬのを見て使うのが怖くなりました。NTはアプリが固まったところでなんとかなりますからね。
やっぱり、私はNTのほうがいいです。落ちないかとヒヤヒヤしながらの仕事はできません。しばらくの間、この環境で我慢するしかないのですけど、落ち着いたらNTをもう一度入れようと思います。
Windows 98は本当に遅い？(1998/08/16)
巷の情報では、Windows 98 が遅いという話は耳にしないので、自分の環境が悪いのだろうと色々とやってみました。
- デフラグをかける確かに若干起動が速くなった感じがしますけど、そんなに劇的なものではありませんね。
- デバイスマネージャー設定チェックドライバ類の設定に問題がないかチェックしました。なぜか、HDDのDMAがONになってませんでした。バスマスタードライバとの関連性はわかりませんけど、ONに変更しました。
- ディスプレイドライバの更新一番疑っていたのがこれです。STB Velocity 128 の最新ドライバをインストールしたところ速くなりました。Final Reality で調べたら Bus Transfer Rate が 2D で５倍、3D で３倍ぐらい向上しました。
インストール当初と比べて、全体的にパフォーマンスはあがりました。ただ、安定度はまだまだ疑問ですね。なんかの拍子にシェルが落ちます。下手するとOSを巻き込んでくれますので不安です。これもディスプレイドライバのせいかもしれないと疑ってます。ドライバを更新してから頻度が上がったような気がするんです。ディスプレイカードを替えるべきかもしれませんね。
Windows 98でハマル(1998/08/17)
US Gateway に新しいディスプレイドライバが登録されていたので、さっそくインストールを試みました。ところが、ドライバ導入後、再起動したところで「ディスプレイの設定ができない」と言われて、ハードウェアウィザードが立ちあがってしまいました。仕方なくハードウェアウィザードをかけてやりましたが、マザーボード関係のリソースが認識されていないようで、それらの検出とドライバのインストールをはじめる始末。ウィザードが終了して再起動したところ、今度はデバイスマネージャーの一覧は「！」の嵐。（涙）その後、色々とやりましたが状況は改善できませんでした。最終的に取った手段は、マザーボード関係のドライバを削除して再起動。Windows 98 の自己治癒能力に賭けてみたわけです。そうしたら、なんとか復旧することができました。
安定度への期待感から、ディスプレイドライバを入れ替えたのですが、スタンバイから復帰後の不安定な状況は変わりません。ディスプレイドライバが犯人でないような気がしてきました。となると何なんだ？OS自体に問題があるのでしょうか？
もう、これ以上詮索しても私自身メリットがないのでやめときます。確かにパーソナルOSとしては、こういうトラブルも経験できてなかなか楽しいOSですね。自分自身が壊れてしまっても、なんとか復旧しようとするところなんか賢いではないですか。しかし、いったい何をやってるのか、やろうとしているのかわからないので手助けのしようがありません。これは、何度も再インストールしないと使えない理由のひとつですね。
盆休み返上の仕事終了(1998/08/22)
やっと、盆休みを返上しての案件も納品を迎えました。神様、仏様、バグがありませんように。（見つかりませんように）
VB5 の仕事だったんで気は楽でした。ただ、RS232C接続の機器制御だったんで色々と面倒なところもありました。実は、ＤＯＳの時代に同様の機器を使ったシステムを作ったこともありまして引き受けた仕事なんです。昔のソースを参考にしようと見てみると、日付が1990年のソースでした。中身を見て、私は自分自身に感心してしまいました。（笑）よくできてるんですよこれが。DOS3.1、MS-C 5.1 で作成されたシステムなんですが、画面制御、ＦＥＰの制御、RS232C制御、入力制御等、きっちりと作りこまれています。よくぞまあ、こんな面倒なことをできたなあと驚きます。疑問なのは、アセンブラを使わずに、やたら MS-C のインラインアセンブラに頼っているところでしょうか。どうせ私のことですから、5.1 でインラインアセンブラがサポートされたから、嬉しがって使ったんでしょうね。（笑）
ソースを見て、現在の自分は当時の自分に負けているのではないかと感じました。まず、パワーが落ちましたね。面倒なコーディングはできるだけ避けたいと考えるようになってしまいました。昔は、こんなことができれば、あんなことができればと、常に向上心を持っていたように思います。今は発想が逆です。出来そうなことでも、こっちに逃げよう、あっちに逃げようと考えてしまいます。こういう発想するから、だんだんと仕事が面白くなくなってきたのかもしれません。昔の自分を思い出し、ちょっと考えさせられました。
クリスタルレポート Ver6.0(1998/08/28)
昨日、宅急便で「クリスタルレポート Ver6.0」が届きました。そんなもん、いつ買ったんだ？私は自問自答しました。（笑）購入した覚えがないんです。確かに VB や VC に付属しているサブセット版は使ってますけど、正式フルセット版は持ってません。さっそく発売元へ電話して確認しました。
私： 本日、宅急便で「クリスタルレポート Ver6.0」が送られてきたのですが、どういった意味合いのものなんでしょうか？ 窓： それは、バージョンアップ版です。 私： クリスタルレポートは、VB,VC にバンドルされているものしか使っていないのですが？ 窓： 申し訳ございません。何かの手違いです。お手元のものはそのままで結構です。お気になさらないでください。氏名と電話番号を教えていただけませんか？
ということで、何か手違いがあったようです。そういえば、最近、日本シーゲートが設立されて、エージーテックが代行？していたサポートが移管されたんです。その際、日本シーゲートへ再登録手続きをしたのですが、その時に間違いが発生したんじゃないでしょうか。
目の前に、サポートが受けられない「クリスタルレポート Ver6.0」が転がっています。（笑）これって得をしたんでしょうか？
Accessの深刻なバグ(1998/08/29)
最近、Access の深刻なバグが話題になっていることを知り、さっそく情報を集めました。現象としては、ユーザーが意図しないレコードが編集されてしまうというものです。結構致命的な問題です。
検証した結果、見事にユーザーが意図しないレコードが編集されてしまいました。画面では正しく編集されているように見えるのでやっかいです。Refresh すると、次のレコードが編集されていることがわかります。この問題の影響が大きいと思われる点は、定石となっている手法で発生することです。
Access をやったことがある人にしかわからない話になってしまいますが、勘弁してください。検索する場合、FindFirst を使いますよね。その時に使うレコードセットは何でしょうか？ Me.RecordsetClone でとったレコードセットを使いますよね。どうやら、これと Bookmark の同期が問題みたいです。再現方法ですが、まず、先頭付近にあるレコードを削除します。次に RecordsetClone で取ったレコードセット(rsClone としますね）を使って、rsClone.FindFirst します。そして、画面の同期をとる（検索したレコードを表示させる）ために、Me.Bookmark=rsClone.Bookmark します。さあ、表示されました。レコード編集します。すると、実際に編集されたレコードが、次レコードになってるんです。編集後に Refresh かけるなり、実テーブルを見ればわかります。ただ、この問題に遭遇するにはひとつ条件があって、削除したレコードから、次に検索するレコードまでのレコード数が多くなくてはいけません。ある情報によれば263レコードより大きい場合だそうです。
こういうコードは、Access でやっている限り、ほとんどの開発者が日常的に使う手法だと思えます。「検索させて画面の同期をとる」というだけです。これ単体の機能で問題が発生することはありません。しかし、削除した後に、これをやると、この問題が出るわけです。ユーザーは正しく編集したと疑いません。画面上は正しいのですからね。さて、この問題、どうやって回避したらいいんでしょうね。
Jetのバグだった(1998/08/30)
Ａｃｃｅｓｓ のバグは、Ｊｅｔ のバグであることが発表されました。これは、Jet を使う全てのアプリケーションに影響が出るという意味です。VB で作ろうがVC で作ろうが、Jet を使っている限り影響が出るということです。この問題に対するＭＳの見解は「そういうコーディングをすることが悪い」と言っています。記事はこちらです、 http://cnet.sphere.ne.jp/News/1998/Item/980829-1.htmlこの記事にある、MSのコメントは卑怯な責任のなすりつけです。笑えるのが「業界標準として受け入れられているリレーショナル・データベース設計を無視するからこういう問題に遭遇するんだ」というコメントです。Access 自体の設計が業界標準を無視した設計なのに、聞いてあきれる話です。確かに他の DB （MSの言う業界標準？）を使ってた人が Access で開発する場合は、こういった問題が発生する設計やコーディングは行わないです。しかし、Access でしか開発したことのない開発者や、dBASE系から入った開発者は、レコードを集合として捕らえずにレコードポインタと捕らえて開発する傾向にあります。Access は幸い？にもそれを容認する手法が多々用意されているではありませんか。FindFirst、MoveFirst,MoveNext,MoveLast,Bookmark と、数えればキリがありません。私は、Access から離れて久しいのですが、RecordsetClone を使った検索を行い、見つかった Bookmark をフォームのブックマークにセットして画面の同期をとる方法は結構使われていませんか？私の記憶（考え）が間違っているのかなあ。実際に Access をやっている方に聞いてみたいところです。
