BBTaskSwitch 0.1.0 をリリースしました。マルチモニター環境での表示位置をアクティブなウィンドウが存在するモニターの中央に変更しました。以前のものはプライマリモニターの中央に表示されてたはずです (というのもモニターは 1 つしか持っていないので確認できません)。
I've released BBTaskSwitch 0.1.0. Modified for multi monitor environments to pop up BBTaskSwitch on the monitor where the active window is. Previous versions are popped up on the primary monitor.
Littlewitch がオフィシャルファンクラブの会員募集を開始したのですが……どうしましょう。入るべきか入らざるべきか。
実のところ 3 作目に (2004 年末辺りにちまちまと主要人物のシルエットを公開していましたが、もう 5 枚目辺りから) 幻滅しているので入らない方向に傾いています。4 作目以降に期待か。
BBInterface 0.9.62 にツールチップを表示させるパッチを書いてみたけど今一。
ところで Cygwin の g++ 使ってコンパイルするとできるバイナリがやたらとでかいのは何でですか。軽く 100k 超えるし。
一応 Visual Studio だかなんだかでもコンパイルしてみたけれど、大してサイズに違いがないのは何でだろう。
取り敢えず BBInterface 0.9.62 に上記のパッチを適用したバイナリを置いておきます。
BBInterface 0.9.62 に上記のパッチを適用 + .rc のロード時に現在の設定を消去するオプションを追加したバイナリを置いておきます。
RSA 暗号の安全性の根拠について。素因数分解以外にも、離散対数問題が簡単に解けたら解けたで崩壊しますよね。ざっと探してみたけれど、素因数分解についてしか触れていないものが多い気がしますし、具体的な方法を述べているものも見つかりませんでした。
で、思いついた方法は以下の通り: 公開鍵を (e, N)、秘密鍵を (d, N) とすると、暗号化が c ≡ n^e (mod N)、復号が n ≡ c^d (mod N)。e と N が既知なので、自分で適当な平文 n を決めて暗号文 c を作り、log n / log c を計算すれば d が出ます。
実際に求めようとしても mod N でマスクされてて色々と厄介か。
BBBalloon 0.0.1 をリリースしました。日本語等の扱いが適当だったことを修正。他細かいところ色々。
I've released BBBalloon 0.0.1. Fixed incorrect non-ascii characters handlnig, and modified some minor things.
BBBalloon 0.0.0 をリリースしました。
途中から傍受しても中途半端になる
けど、別にそれでも構わないものもあるということで。
ところで `balloon' を `baloon' と打ち間違いそうになりませんか? コードを書く際に何度も何度も `baloon' と打ってしまって困りました。果てはファイル名まで BBBaloon.c となっていたし。
I've released BBBalloon 0.0.0.
BB4W のソースコード見てて思ったのだけど、こんなのでいいのかね。
Shell_TrayWnd でウィンドウを作る。PostMessage(HWND_BROADCAST, RegisterWindowMessage(TEXT("TaskbarCreated"), 0, 0) を投げる。Shell_NotifyIcon で送られたデータは WM_COPYDATA で送られてくるので、後は適当に。戻り値は (多分) Shell_NotifyIcon の戻り値として使われる。COPYDATASTRUCT の内容は以下の通り:
dwData1((BYTE*)lpData) + 4Shell_NotifyIcon の dwMessage (NIM_ADD 等)((BYTE*)lpData) + 8Shell_NotifyIcon の NOTIFYICONDATA(確認してないので推測ですが) Shell_TrayWnd は Explorer のシステムトレイのウィンドウクラス名と被ってるので、これでどうにかできるようです。これは取りも直さず BB4W を Explorer の上で実行した際に BBTray 等が利用できない理由に他なりません。この辺りの事情は他の代替シェルでも同じことでしょう。
逆にそれっぽいウィンドウにフックかけて云々、と思ったけどそれは無理か。TaskbarCreated の受信側に期待される挙動を考えると途中から傍受しても中途半端になる。
まず WS_EX_ACCEPTFILES なり DragAcceptFiles なりでウィンドウにドロップ可能にしておく。
ドロップされると WM_DROPFILES が送られる。WPARAM にはドロップされたファイルについての情報 (へのハンドル) が渡される。これを DragQueryFile に渡せばドロップされたファイルへのパスが解る。
最後に DragFinish で後始末をしておく。
BBMenu 0.0.0 をリリースしました。使う意味があるかどうかはお察しください。BBTrayIcon と組み合わせると馬鹿っぽさがさらに増します。
I've released BBMenu 0.0.0. No worth to use.
確かにキャストを利用すればそういうことはできなくはありませんね。問題点や手法自体は .NET 以前からある話。C++ だと一口にキャストといっても色々あるけれど、使い方の問題であって悪用は防げませんから。
ただ、managed code と unmanaged code が混在する現段階では仕方がない話というだけであって、将来はどうかは解りません。Microsoft がわざわざ .NET なんてものを作ったということは、将来的に全て managed code で通すという目論見があるからでしょう。逆にそういう目的がなければあんなもの作りません。
.NET において最初から全て managed code で通さなかったのは移行に色々と手間取るからです。過去の資産も色々あるし、第一 Microsoft だけが移行しても仕方ないですからね。.NET は将来と現在との間の単なるクッションでしかありません。
そういう訳なので、上記の経緯を無視して問題の指摘をしているこの記事は Java の宣伝でしかありません。
(個人的な好みの問題ですけど) 昔から Java にはいい印象がないのですが、こんな記事を見るとますます嫌になりますね。
ついでにいうと、New languages such as C# and Visual Basic.NET only produce managed code.
というのも言い回しもアレ。この書き方だと C# や VB.NET のような新しい言語でないと、言い換えれば従来の言語では駄目だという意味に取れます。C++ でもコンパイルオプションや #pragma でどこを managed にするか unmanaged にするか指定できます。何だかますます宣伝臭さが増してきたな……
モディファイヤでもそうでなくてもキーを直接書けばいい。
key U-*LeftWindows = ...
逆に押したときの場合は、押したキー自身のモディファイヤがかかるので以下のように書く。
mod shift += !!RightShift key S-*RightShift = *BackSlash
で、本題は前者について。BBAltTray の作成時に「Windows の Alt-Tab のアレっぽいキーバインドを割り当てたらどうか」と思っていて、ようやく今になって実際に窓使いの憂鬱を使って試してみました。
key L9-U-~W-*LeftWindows \
= &Toggle(Lock9,off) \
&PlugIn("BBMayuKon.dll", "Kontroll", "broam('@BBAltTray.Cancel')", true)
key *L9-W-Tab \
= &Toggle(Lock9, on) \
&PlugIn("BBMayuKon.dll", "Kontroll", "broam('@BBAltTray.Next')", true)
key *L9-S-W-Tab \
= &Toggle(Lock9, on) \
&PlugIn("BBMayuKon.dll", "Kontroll", "broam('@BBAltTray.Prev')", true)
key *L9-W-H \
= &Toggle(Lock9, on) \
&PlugIn("BBMayuKon.dll", "Kontroll", "broam('...')", true)
...
単に U-~W-*LeftWindows とすると必要のないときにも bro@m を投げてしまうので、ロックキーを使って対策をしています。
また、&ShellExecute で BBKontroller を使うとオーバーヘッドが目に付く (特にマウスカーソルが一瞬だけビジー状態のものに変わって鬱陶しい) ので繭のプラグイン (これは BBKontroller のアーカイブに同梱) から実行させています。なお、&PlugIn の runAsThread を true にしておかないと bro@m を送るたびに 30 秒ほど何も入力ができなくなるので注意。
さて、実際に使ってみて気付いたのですが、Alt-Tab のアレは「選択」、「切り替え」、「キャンセル」の 3 択しかないからいいのであって、似たようなキーバインドを BBAltTray に割り当ててもよくはありません。特に Win-Tab の辺りが駄目。選択はともかく、その後の操作を考えると片手では動きが不自然になります。
素直に別のキーバインドを割り当てた方がいいか。それでもモディファイヤキーを離すことで選択をキャンセルするのはそこそこ便利ですけどね。