_ [ipmsg] IP Messenger v3.50 正式版

約3年ぶりに IP Messenger v3.50 正式版 をリリース。変更点は以下の通り。

添付ファイルダウンロードの暗号通信(AES-CTR256)対応（＆要求リクエストの電子署名追加）。

IPv6マルチキャストに対応。

画像キャプチャ用マーカ機能で吹き出し矢印モードを追加。

画像の再編集機能（画像右クリックで選択）を追加。

画像ファイルの貼付を追加。

libpng から GDI+ に画像処理ルーチンを移行（セキュリティ対応用）。

遠隔リブート＆シャットダウン機能を追加。

複数行コマンドライン送信(/MSGEX）を増設（文中の\nを改行に置換）。

ショートカットキーを任意のキー組み合わせに設定可能に。

なにか、お気づきの点がありましたら、ご連絡ください。
（次回のメジャーバージョンでは、画像入りログビューアを搭載する予定です）

（17:21 追記）窓の杜で画像入りの分かり易い記事が掲載されました。
窓の杜:　IPv6マルチキャストや遠隔PCの終了・再起動に対応した「IP Messenger」v3.50

それにしても、ノートン先生、相変わらず誤検出 しているなぁ…

余談ながら「なぜipmsgに遠隔リブート機能が追加されたの？」と思う人が居るかもしれません。
これは私自身の用途で恐縮ですが、リモートデスクトップ接続で「TCP接続するのに画面が進まない」という妙な状態に陥ることが時折あり、そういう場合にリブートメッセージを送りつける（or送り付けてもらう）ことで再起動させて回復、という個人的事情による追加機能だったりします（笑）

_ [comp_misc] VirtualAlloc(MEM_RESERVE)を使ったメモリ確保

事前に必要メモリサイズを確定させづらい場合のメモリ確保実装(VBuf)について。

FastCopyではコピー動作を開始すると、ディレクトリに潜るたびにのコピー元とコピー先のカレント直下の全エントリ（とファイル属性）を収集・比較し(**2)、コピーが必要なファイルリストを生成しています。普通であれば、1ディレクトリ直下のファイルは多くとも数千ファイル程度で、FastCopyの場合 1000エントリで160KB程度になります。

とはいえ世間は広く、機械生成な環境で1ディレクトリ直下に100万ファイルといった状況もあり、その場合は160MB（追記: ファイル名が長い場合 600MB以上に）のメモリ消費になったりします。(*1)　つまり、状況によって1000倍程度メモリ必要量が変化します。といってエントリ毎に malloc()等で動的に確保していった場合は確保/解放処理等のコストが大きくなります(**3)。

このため、FastCopyでは VirtualAlloc(MEM_RESERVE) で仮想アドレス空間だけ大きく予約しておき、足りなくなるたびに n KB（ただしページサイズの倍数）づつ VirtualProtect でメモリを割り当てる仕組みを使っています。

この形のいいところは、

１．リストではなく配列/ベクター的に使えること(**4)。

２．フラグメントを気にしなくても良いこと、確保/解放のコストが低いこと

３．増加時に基底アドレスが変化しないので、余分なコピーが無い＆要素内同士でポインタが使えること

といったところです。

ちなみに、UNIX系の場合は mmap(PROT_NONE)で確保した空間を徐々にmprotect()でコミット済メモリを割り付けていく感じにすれば良いかもしれません。(**5)

(*1)だからといって（99%以上の環境では不要な）160MBを毎回確保しておくというのは筋悪ですし、逆に160MBで足りるの？という話に。

（2017/02/22追記）

(**2)このエントリ群に対応するハッシュテーブルも同時に作ることで、高速比較を実現しています。

(**3)1ディレクトリ直下のファイルコピーが終わり、子ディレクトリに潜る等のタイミングで、現ディレクトリ用ファイル情報VBufはクリアされます。

(**4)配列と言っても、stat情報のエントリはファイル名長という可変要素が入るため、個々の要素サイズは変化するため、別途、VBufを使った要素位置を示すポインタ配列も作っています。

(**5)mmap(PROT_NONE)はガードページ的な使い方しかできない模様。（ページ割り当てしない限り、巨大アドレス空間を予約しても、OSからオーバーコミットに見えないような、代わりの方法はないものかしらん？mmap(PROT_NONE)で確保しておいて、必要になるたびにPROTO_NONE領域を縮める方向にmunmap&mmapしつつ、空いた空間に通常mmapする等？）

P.S 現在、64bit版で1GB、32bitで128MBの空間を予約しています。（fastcopy2.iniで変更可）

（追記 2017/08/02) MEM_RESEREVEでアドレス空間だけ確保する場合、PTE/PTDすら不要で、ほぼメモリ消費がない。

参考: https://twitter.com/shirouzu/status/840539380099903491

_ [comp_misc] 小町トピ主フィルタ

少しだけ改良してみたり。

１．CTRL+SHIFTを押しながらトピ主レス数クリックで既読情報クリア

２．「びっくり率」が高いトピ主レス数を赤色強調するオプション追加

    （ただし新規トピ及び更新レスから順次適用）

https://ipmsg.org/tools/komachi_filter.html

_ [fastcopy] FastCopy次期バージョン

次期バージョン用に

１．相対パスフィルタ

２．セッション0対応（完全GUI問い合わせなし）

３．バッファサイズ4GB以上対応

４．ANSI/WCHAR両対応を止め、W系に一本化（XP以降必須）

などが概ね完成してきた。

ソースコードのかなりの部分に手を入れたこともあり、これを機に次期バージョンのライセンスについて現行のBSDから、GPL＆商用系のdualライセンスに変更するかどうかを真面目に検討したほうが良いかもとか思ったり。

さらに、機能に関してはいずれ、UI改良と非同期I/Oはどこかで入れておきたいところ。

_ [fastcopy] 次期バージョンのフィルタ拡張仕様

次のバージョンの FastCopy では Include/Exclude フィルタが大幅に拡張され、パスの最終要素へのフィルタだけでなく、途中のディレクトリ要素を含めて、UNIXワイルドカード形式でのフィルタ指定が可能になる予定。

Source指定が下記のいずれの場合も、

C:\src\

C:\src\file.txt

C:\src\dir*

フィルタ検査の起点は C:\src\ になります。

さらに、上記の C:\src\ が起点として「絶対指定」と「相対指定」の説明。

絶対指定（＝先頭が \ or / で開始）の場合、

\abc\dir\ → C:\src\abc\dir がマッチし、C:\src\bbc\abc\dir はマッチしません

（絶対指定：フィルタ検査の起点から一致検査）

相対指定（先頭が \ or / で開始しないの場合、

src\dir\ → C:\src\src\dir や C:\src\aaa\src\dir などにマッチしますが、C:\src\dir にはマッチしません

（相対指定：末尾要素から（最長で）起点までの一致検査）

フィルタ指定には従来通り、ワイルドカードが利用可能。

dir?\sub\dir*\ などの柔軟な指定が可能

（この場合、dir1\sub\dir123\ などのディレクトリがマッチします）

ただし、パス区切りに \ を利用可能としたため、キャラクタクラス内（[a-z] の類）以外では \ をエスケープに使えなくなるのでご注意

例えば、"file[" という妙な名前のファイルを指定する場合、従来可能であった２通りの表現のうち、"file\[" は使えなくなり、"file[\[]" のみが正しい書式に

ただ、DestDirの結果だけを見るとフィルタの起点が判りづらい点が気になるところ。

例示するボタンを付与するか、DestDir直下を常に起点とするかも検討したほうが良いかもしれない。

（後者の場合、Sourceフォルダ自体もフィルタ対象になってしまうのが互換性的にイマイチなところ…）

ところで、GPL にする場合は、v2 にするか v3 にするかも悩みどころにななりそう。

_ [ipmsg] IP Messenger v3.51 正式版

IP Messenger v3.51 正式版 をリリース。変更点は以下の通り。

コマンドラインでポート番号指定が効かない問題を修正。

XPでバルーン通知が出ない問題を修正。

なにか、お気づきの点がありましたら、ご連絡ください。