あー

折角の SetStdHandle が効いてないー。タイミングが遅かった様だ。C ランタイムの初期化のタイミングよりも遅かった…。C ランタイムは初期化時に StartupInfo や GetStdHandle を使って、そのハンドルをそれ以後ずっと使う様に実装されていた…。そんなの困るよ…。
もっと早目にやらなくては駄目か。それとも自分自身のプロセスでリダイレクトをやるのは無理なのだろうか…。うーん。


DLL のグローバル変数にコンストラクタとデストラクタを持っている変数を置いたのだけど、コンストラクタもデストラクタも動いていない。何でだろう。
静的にリンクされた DLL の DllMain は kernel32!BaseProcessStart よりも早く動くんだなあ。
DLL の C ランタイムの初期化はどんなタイミングで行われるのか。DLL は MSVCRT(D).lib しか使えないんでしたっけ？そんな事無いと思うんだけど、良く調べてない。仮に MSVCRT(D).lib しか使えないとしたら、その初期化はどんなタイミングになるのだろうか。LIBC(D).lib や LIBCMT(D).lib とは違った感じになるのだろうか。
デバッガが最初に止まるタイミングは ntdll.dll のロードより遅いけど、それ以外の DLL のロードよりは早い。
ntdll.dll で最初に DebugBreak で止まった時にやってみるか、無理矢理呼び出すってのを…。SetStdHandle ね。GetStartupInfoA を解析して、無理矢理 StartupInfo 構造体を書き換えるってのも有りかも、難しくなかったらやってみる価値は有るな。