2006年2月アーカイブ

　思いつくままにプログラミングをしています。NanDoKuβ3でなんとか一通り対応できるようになったと思いますが。ソース解析の精度に不安が残っているので、肝となる難読化部分を大幅に改良しています。今のところ安定性は後退していますが、速度面ではβ3の半分程度の時間で処理でき、最終的には解析制度も今までより良くなる予定です。ジェネリック周辺で難読化できない部分も今回の改造で視野に入れているので、需要は知りませんが最終的には対応できそうです。あとは、前々から考えていたコードの枝切り（不要メソッドの削除）がなんとなく出来そうな様子です。実際のコードは１行も書いていないので、プログラムした後で現実的な速度で処理できるといいのですが。

　早々にNanDoKu3のβ2を公開しました。今回ＧＵＩまわりをFramework 2.0のコントロールに変更して、見栄えを良くしてみました。変換アルゴリズムも少々手を加えたので、今までの2/3程度の時間で作業で処理が行なえると思います。
　ジェネリックの動作についてはいろいろ検証していますが、βのページに書いたように複雑なことをすると失敗します。一応対策をしたβ3が控えているので、その他の修正とあわせて近々に公開を予定しています。

　NanDoKuの改良が思ったより調子よく行ったので、とりあえずβ１を公開しました。プログラムの特性からＧＵＩやパフォーマンスより実行結果の正確性が問題になると思うので、早めのβ公開でフィードバックを集めようと思います。ＧＵＩはC# 2005へコードを移植してコンパイルしただけでVersion2からほとんど触っていません。.NET Framework 1.1の難読化も行なえますが、内部にエンジンを２種類入れただけなので、こちらが目的の方はVersion2.0.0を使用したほうが確実だと思います。
　現在検証中の部分は、ジェネリックを使用したときの難読化と、自動で生成されるコードにクラス名が文字列として出現する個所の対策です。どちらも問題なく動作することは確認していますが、検証例自体が少ないので、難読化に失敗するようならこの部分を疑ってください。

　VB,C#の2005が無料ダウンロードできるためか、「NanDoKuを2005対応にして欲しい」という要望を良く頂くようになりました。いつまでもほっとくわけにも行かないので、そろそろテストを始めましたが、流石にすんなり動くわけも無く．．．。

今日の成果
・NanDoKuをFramework2.0アプリにするためにC# 2005へコンバート
・逆アセンブル->再アセンブルテスト成功
・Framework1.1相当の記述での難読化成功
・イテレータ、ジェネリックの難読化テスト成功
・NanDoKuをFramework1.1とFramework2.0両用に修正

あとは、残りの新機能を使用したときの難読化テストと、設定画面の追加ぐらいです。
意外と早い段階で対応できそうですが、テストするアプリが少ないので、βバージョンの期間が長くなりそうです。

　MagicMirrorのVersion1.4.0がやっと公開できました。今日はそれだけ。

　週末に風邪を引いたり、なんだか忙しかったりして、更新がしばらく止まっていました。
　プログラムの方は、TKFP.DLL、TKMP.DLLと不具合修正を完了して、MagicMirrorのリリース準備をしています。転送時の機能をいろいろ追加したので、そいつらをＧＵＩでどう表現するか試行錯誤しています。β２のままだと、ファイルがどういう条件で転送されるのか分かりづらいので、リスト項目へ転送時の設定がアイコンで表示しようとしています。最終的にはビジュアルを取るかパフォーマンスを取るかの選択になると思います。

　TKMP.DLLで添付ファイルのRFC2231形式のファイル名に対応させていたら、結局ヘッダのエンコード処理全面的に書き直すことになってしまいました。一応過去のメールでエンコード、デコードの一致確認をしたので、問題ないとは思います。この辺の仕様を調べれば調べるほど、仕様と現実のギャップに苦しんでいます。

　TKMP.DLLでRFC2231形式のファイル名の「受信」を追加しました。Outlook系が受信処理がうまく出来ないので、送信機能は必要ないかと思いますが、こちらはそのうち追加しようと思います。
　そういえば、Outlookで「AT000.txt」なんて添付ファイルを見たことあるような．．．RFC2231形式でファイル名の解析に失敗した結果、このような名前を勝手に付けていたみたいですね。で、Outlookは何時頃対応するのだろう。APOPの対応はしたのか？そろそろなんちゃってメーラーじゃなくて真面目にメーラーを作成して欲しいものです。

　TKMP.DLLの添付ファイル名の扱い方について調べていました。ファイル名の前後に付けた「"」はエンコードの対象にしていいのか資料を調べていると、そもそも日本語ファイル名を扱う方法のルールが違うことが判明。正確にはRFC2231で取り扱い方法が決まっているのに、すべてのメーラーが処理できない可能性があるため、世の中のほとんどのメーラーがルールと違った方法で送信している状況です。つまり、メールに添付した日本語名のファイルは偶然処理できている状況。で、TKMP.DLLは一応メール解析が出来るライブラリなので、この辺を対応しようかと思います。RFC2231での処理が行えるようになれば、TKMP.DLLを使用しているプログラムは勝手にRFC2231対応る予定です。外部ライブラリはこの辺が利点ですかね。

　いろいろと速度が出ない原因を調べていて、描画パフォーマンスもかなり改善したのですが、一向にダウンロードの速度が上がらない。でも、アップロードの速度は予測値程度出るのになぜかと不思議に思っていたら、思わぬところに不具合が潜んでいました。実はTKFP.DLLがファイルのダウンロード時の転送量を正確に返していないためで、見かけ上の問題だということが判明。つまり、FTPのライブラリから修正することになり、今日公開するつもりでいたベータ２はしばらく後になりそうです。

　いつまでもベータバージョンにしておくわけにも行かないので、気になっている点を修正しています。前からスッキリしなかった、アスキー転送と非同期のファイルの設定方法を統一して、属性変更や文字コードの変更のようにワイルドカードが使用可能になる予定です。
　他には、なんだか転送中のパフォーマンスが予定より出ないので、原因を確認していました。で、確認できたのがやっぱり画面の表示が足を引っ張っていました。いろいろ調整して、通信ログのカラー表示をなくしたら、ちょっと改善したのですが．．．なんだか寂しい。きっとコマンドラインでの実行ではいい感じで速度が出ているとおもんだけど。