つーさのくーかん

プレイリストは、あまり、Nowでもないが。
なんかこういうブログパーツとか作ってたなぁ……。

リバースプロキシ動作をするスクリプトを置いてて、
FCGIとCache::MemoryCacheを使って1分間はメモリにキャッシュする。

続きを読む

GTmetrix っていうサイトで、PageSpeed ScoreとYSlow Scoreをランク付けしてくれるらしいのでやってみた。

ばーん。

うわっ……私の(サイトの)評価、低すぎ？

説明書きを読んで、簡単にできそうなやつを試した。
具体的には、
jsとcssとはgzip encodingするようにした。
画像とかのリソース類にはExpiresヘッダをつけるようにした。
アイコンにしか使ってない画像は実際の表示サイズx2にリサイズした。

ばーん。

なるほどなー。

Winamp をしっていますか……。

DSPプラグインの作り方は、WinampのPluginのSDKが公開されてるので、
それとおんなじ様に呼んであげれば、できる？　と思ったのと、
Winampのプラグインって関数ポインタを内部の構造体に入れてその構造体へのポインタを返してくるような形してて、
それらのAPIのP/Invoke・マーシャリングの仕方に興味がわいたのでやってみてた。

標準でついてるプラグイン dsp_sps.dll だけは、ロードしたとたんに落ちちゃう。実装を追いかけて調べてみたところ、
Winampには親ウィンドウにWM_USERを投げて関数ポインタの詰まった構造体をもらって、そこからいろんなAPIを呼ぶ機能があることと、
その子には「非対応だぜエラー！」値を返しても、それをそのままポインタとしてメモリアクセスして死んじゃうらしいことがわかった。
このAPI群を実装する気はまったく起こらないので、とりあえずいったんあきらめていつもの SA Stereo Tool を動かしてみた。

インストール済みのプラグインの名前が取得できた。SA Stereo Tool から音が出た。

ソース
https://github.com/ttsuki/ttsuki/blob/e421ad0a3f6e1a51f72aa2d58b231263c7f87d2d/DllPInvoke/WinampDspPlugin.cs
関数ポインタを入れた構造体を返してくるようなAPIはあんまりないけど、マーシャリングしたい場合は、
関数ポインタに戻り値・引数・Calling Conventionもあわせた delegate を宣言して、
それを構造体のメンバとして宣言した状態で、マーシャリングすれば、勝手に関数ポインタからデリゲートを作ってくれる。
が、その方法だと、どうもNULLチェックができないっぽい？　ので、今回は構造体のメンバはIntPtrとして受け取った後に、
関数ポインタをラップするデリゲートを手で作っている。

使い道……？
音ゲーとか作ったときに、Winampのプラグインを(VSTがわりに)エフェクターとして使えるかもしれないなとは思う。
SA Toolsなんかは、ヘボいスピーカでもそれなりに映えるような音に変えてくれるし。
レイテンシの問題はあって、それを回避するには、鳴らした場合の音と鳴らしてない場合の音を両方作っとくみたいな手もあるんだけど、
そもそもWinampのDSPは、(DLLファイルを物理的に複製でもしない限り)設計からして複数インスタンス生成できないし、
フィードバックがあるエフェクタは内部状態を再現するのが無理ゲーなので、1インスタンスでちょっと前に戻ることもできなくて、
リアルタイムにミックスする必要のあるゲームアプリケーション*1では、いまいち使えないかも。

他、自作アプリからDSPがドライブできれば、
自分のミュージックライブラリの中の曲を、外出先の自分の携帯電話から好みのDSP通して聴けるのでは、というのは、ちょっと思う。
上で試してるSA Stereo Toolの場合は、パイプで波形処理してくれるコマンドラインツールがあるのでそれを使った方がいいんだけど。
最近コメントがついてた、HSPで作ってたパイプ使ったプロセス間通信のラッパーみたいなのが要る。

余談だけど、コミットと本記事の公開に時差があるのは
ソースコミットの後に記事書こうと思って先のスクリーンショットをブログにあげたらなぜかサムネイルが作れなくて、
調べたらブログを動かしてるサーバのImageMagickのバージョンをあげたときから PNG 読めなくなってたらしく、
ここ2日ばかりあれこれ苦労して、ようやく再インストールできたからである。。
nice make 中に突然再起動しはじめたりとかして、ちょっとこのサーバもなんとかしたい。

あと、最近このブログがページの表示に2秒とかかかる激重状態になってたのは、
サーバが貧弱だからかなーとか思ってたけどいくらなんでもと思って調べたら、
データディレクトリとキャッシュディレクトリのオーナーとパーミッションがおかしいせいだった。
なおしたのでさくさく動くようになった。わーい。

ぐぅ

ロードされるDLLの一覧がほしいだけなら Dependency Walker 上で、プロファイリングすれば十分なのだけど。

Kernel32.dll は、すべてのプロセスで同じアドレス空間にロードされているため、
あるプログラムで、Kernel32.dll の API に対してGetProcAddress して得た関数アドレスは、実は他のプロセスでも有効。
これを利用して、LoadLibrary に渡される文字列をデバッガから調べてみることにする。

まずは、適当なプログラム(x86)で、LoadLibraryA と LoadLibraryW を GetProcAddress して、アドレスを調べておく。
調べた結果、それぞれ 0x7639A840 と 0x763A4BF0 だった。

デバッグ対象のEXEをVisual Studioでソリューションとして開き、「デバッグ→ステップイン」でプロセスを開始する。
EXEのエントリポイントで止まるので、この状態で「デバッグ→ウィンドウ→逆アセンブル」を開き、
アドレスに先ほど得た 0x7639A840 を、アドレスとして入力しLoadLibrary の先頭にブレークポイントを仕掛ける。
同様に 0x764A5BF0 にもブレークポイントを仕掛ける。

F5で実行を再開。
ブレークしたときLoadLibraryの先頭にいる。
x86の関数呼び出し規約によれば LoadLibrary の第1引数は、ESPレジスタの指しているアドレス+4の位置に格納されている。
LoadLibraryの第1引数はロードしたいDLLへのパスを格納している文字列へのポインタなので、
これを得るための式をウォッチウィンドウに追加することで、何を引数に関数が呼ばれたかがわかる。

  (char**)(@esp+4) ← LoadLibraryAが呼ばれたとき
  (wchar_t**)(@esp+4) ← LoadLibraryWが呼ばれたとき

結果。*1

というようなことをやっていた。
↑のDSPプラグインを他のアプリから使いたかったんだけど、うまく動かないやつがあってどうしてだろうと思って。

ちなみに、ESPレジスタで思い出したけど、
上記のように関数が呼び出されたとき、ESPレジスタの指す先にはリターンアドレスが入っているので、
これを使うことで、関数の呼び出し元のアドレスを得て メモリリークの追跡もできたりした。
過去形なのは最近x64が台頭しつつあるから。*2

void *my_alloc(void *pCaller, size_t size) { ... }

#define NAKED __declspec(naked)
#define WITH_CALLER(...) { void *CALLER; { __asm mov eax, [esp] __asm push ebp __asm mov ebp, esp __asm mov CALLER, eax } __VA_ARGS__;  { __asm pop ebp __asm ret } }

NAKED void * operator new(size_t size) WITH_CALLER(my_alloc(CALLER, size));

// WITH_CALLER の 展開後イメージ
__declspec(naked) void* operator new(size_t size)
{
	void* pCALLER; 
	__asm mov eax, [esp];    // 関数が呼び出された瞬間、ESPの指す先にあるリターンアドレスをEAXにメモ。
	__asm push ebp;            // VC++ がローカル変数へのアクセスをEBPを元に行うコードを生成するので、
	__asm mov ebp, esp;        // それと互換するようにEBPを準備する。
	__asm mov pCALLER, eax;      // メモったリターンアドレスをローカル変数へ移して
	my_alloc(pCALLER, size);     // それを使って本命の関数呼び出し。
	__asm mov esp, ebp;        // 使ったものは
	__asm pop ebp;             // 戻しておこう
	__asm ret;               // my_alloc の戻り値がEAXに入ってるはずなので、それがそのまま戻る。
}

my_alloc は呼び出し元のアドレスをつけて呼び出されるので、線形リストなどに時刻・サイズ等とともにメモっておけばよい。
ビルド時 .map ファイルや、逆アセンブルを出力しておけば、__FILE__などなくとも関数を特定できるのでこれで十分。

XGTGCTL2　開発やめた の続きになる。

あれから10年近く経っても、自分のDTM環境が、MU2000 EXから脱却できていないので、
ドラムやEQを自由にいじりやすくするために結局作っていた。
前のバージョンはHSPで作ってて、ソースコードがスパゲティ状態で、拡張なんてとても無理だったのでC#で書き直している。
gitの使い方の勉強もかねて、GitHub上で公開してみる。

リリース: https://github.com/ttsuki/XGMidiControllerForMU2000EX/releases

これを使って作った曲: Another Wing -Deep White- と、そのソースコード
スクリーンショット:

MIDIファイルからの読み込み機能はあんまり使わないので省いて、
音源とSysExでSEND/DUMPするほか、サクラMMLスクリプトではき出すようにしたりした。

もはやXGという規格がレトロ化してきている昨今。
MOXFを買おうかとか、でもソフトで何でもできる時代だしーと思うと躊躇してしまう今日この頃。

RAMDISKドライバを作る

ほんとは、これがやりたくてオレオレ認証局とか作ってたんだけど、
調べたところによると、Windowsで使えるドライバ用のコード証明書のCAは決まってて、
そればかりか、Windows 10のカーネルモードのドライバのコード署名はEV証明書でないといけないみたいで、
結局、この記事でやってるようにドライバ署名の検証をスルーしないと動かせなかった。
趣味レベルでカーネルモードドライバをちゃんと作ってリリースする道はもはや絶望的だなー……。

この記事では、

Visual Studioでのドライバの開発に必要なものをインストールして、
サンプルドライバをビルド・インストールしてみてから、
RAMDISKの容量が1GBになるよう、ソースコードを改造してみます。

制限

この記事の範疇ではFAT16なので、2GB(一説では4GB？)よりも大きいドライブは作れないはず。
FAT32への対応はすぐできるんだと思うけど、あんまり調べてない。

上記の通りドライバにコード署名できないので、ドライブを使うには、
毎回ドライバ署名の検証をスルーできる状態でWindowsを起動する必要がある。

続きを読む

自分用ミラー
GNU GENERAL PUBLIC LICENSE
wget.exe md5:(file not found)
wget64.exe md5:(file not found)