2010年5月アーカイブ

Microsoft Security Essentialsの定義更新に失敗するようになった。
＃ただし、容量2GBVHDのXPでのこと。

HDD空き容量不足と考えている。

もとより無理矢理な詰め込み状態ではあるのだが、5月中頃から、空き500MBでも定義更新に失敗するようになった。
困ったものである。
しかも、結果として「接続できませんでした」としか表示されない。
＃途中経過で、「ダウンロードしています」とか表示されるのに。

対処法は、あらかじめ定義ファイルを削除してから手動更新をかけること。
Microsoft Security Essentialsは定義ファイル群のバックアップを保持するため、その分を減らすのと、バックアップ処理を行わないことで、処理も減り、ディスク容量は少なくて済むようになる。

ホワイトリストにしても、ブラックリストにしても、定義ファイル容量は増加こそすれ、減少することはないので、いずれこの方法でも対処できなくなると思われる。

3回目も終了。

やってみてなんとなく分かってきたことだが、単なるハンドルリークであれば、より多量に保持することが可能であり、システムへの悪影響も無いはずなのに、1,000,000に到達する前にシステムへ悪影響を及ぼすということは、つまり、「限りある資源をシステム利用分まで奪っている」ということではなかろうか。

では、その限りある資源とは一体なんだろうか。
右クリック時のポップアップメニューの一部が表示できないことから、メニュー処理するイベントトリガが、一番怪しいと睨んでいる。

SEG CLIPは視聴ウィンドウをクリックしたり、ドラッグさせたりといったマウスイベントを発生させると、異常にハンドルカウントを増加させる。
何らかのイベントを作り続けて、回収しない、というのが原因なのではないだろうか？
＃もしそうでも、なぜそういう実装になっているのかは理解できないが・・・

というわけで、次回はイベントを多量に発生させてみようと思う。
＃恐らく、ごく短い時間で問題発生すると思われる。

VS2008(SP1)が落ちる。

「ツールボックス」で「アイテムの選択」をすると100%落ちる。

VS2010との同居に問題があるのか、よくわからない。

しかも、サクッと落ちて、例のデバッグしますか？も表示されないので、気付かないほど。

ツールボックス使わなくても何とかなるからいいんだけど、ついやっちゃった場合、未保存コードがパァになるので、注意せねば・・・

例のあれ。

2回目が終わった時点で再現性ありと踏んだので、とりあえず、問い合わせておいたら反応返ってきた。
来るとは思わなかったよ。＞IOデータ

1週間かかったわけだが、実に立派な反面教師。

Windowsフォームアプリで入力文字を制限するのに、MaskedTextBoxを使うのはいいのだけれど、これ、マスクできる文字種が少なすぎるという欠点がある。
たとえば、16進数で可変長の文字列入力をさせたいなんて、単純なことなのにもう無理。
なんともし難い。

仕方なく、TextBox派生で、文字制限をかけるコンポーネントを実装。
でも、WndProcをオーバーライドしなきゃならんとか、コピペのことまで考えなきゃならんとか、まわりくどいことこの上ない感じ。

もっとスマートな方法があるような気がするのだが・・・
OnTextChangedはあっても、OnTextChangingは無いんだよなぁ。

結果・経過はこちら。

今度は録画だ。

結果は予想できるけど、予想よりも激しくダメな結果を期待したい。

超最低な反面教師として。

この件。
性能まで考えると、やはり、アンマネージC/C++にしたほうがいいのかも知れない・・・

20100524_OverSslClientSetup.zip

TCP通信をSSL暗号化するものである。
マニュアルはまだない。
アルファ版でござる。

マネージャとサービスから成り立っている。
Yahoo!のメール設定をプリセットしてある。

Vector登録するまでには及んでいない(後述のIPv6とかに対応したい)ので、ここに置いておく。
.NET Framework 2.0～3.5xに対応している・・・はず(VS2010でビルドしたので、ちょっと不安)。
Windows 7の64bitでも、動く(32bitターゲットだから、WOW64上ってことになる)のを確認済み。

そうそう、サービスは起動後3分経つと自動停止することに加え、使用期限は2010年6月いっぱいに設定してあるので、もしも気に入って金払ってでも使いたいとかいう奇特な人いらっしゃればコメントを。

システムへの影響あるじゃん。
再現性もあるじゃん。

ダメ過ぎる。

C#で勝手にDisposeしてくれる方のusing。

例外出てもDispose呼んでくれるので便利だけど、気になって確認したのでメモ。

• using(A hoge1 = new A(), hoge2 = new A()) { } と、
  using(A hoge1 = new A()) {using(A hoge2 = new A()) { } } は処理順も同じなので、安心して使ってよい。
• usingで対応できるのは、変数に代入できた場合のみ。
  たとえば、using(A hoge = new A()) で、Aのコンストラクタ処理で例外発生した場合にはhoge.Dispose()は呼ばれない。

まぁ、当たり前っちゃー当たり前だけど、後者は重要な気がする。
どんな場合でもDispose呼んでくれると思って、コンストラクタ等で例外出しまくると、意図しないことになる可能性があるってことだ。

20100521_X509Certificates_Test1.zip (実行ファイルの圧縮)

とりあえず、昨日のコードをごにょごにょして、ここまで解析できることがわかった。

でも、証明書スナップインで表示されるような「目的」を一部を除いた大部分で取得することができていない。
どうやって取ってきてるんだろうか・・・