FNE.JP::とあるIT系脱求職者の日記(仮称)

デバッグモードコンパイルなのか、リリースモードコンパイルなのか、判断して、バージョン情報リソースに任意の文字列として埋め込みたいとか思うと、VC++の場合、リソースコンパイラのプリプロセッサ定義が独立しているので、C/C++コンパイラのそれと2か所に設定せねばならず、面倒なのだ。

で、ちょっと思いついたのでメモ。

• プリプロセッサの定義で構成ごとに変わるものを抜き出しておく。
• バッチファイルなどで、引数指定すれば、特定のファイル(.h)に#define列として書き出せるようにしておく。
• ビルド前イベントに登録し、引数を一意にする。
• リソースやC/C++コードで書き出されたファイルを#includeする。

こうすることで、設定は1か所になるはずだが、果たして・・・
＃後日試してみる。

なぜアナログTVを無くそうとするのか。

今、使えるものを大切に使うことこそが、みんな大好きなエコなんじゃねぇの？と思うのだがね。

要するに、

• 少数意見は無視
• 重大な出荷後バグを仕様と言って直さないのに、仕様は広く公開しないでQ&Aのみ
• 後付けの言い訳だけの問い合わせ対応
• 悪いのはユーザーと片づける
• ユーザーの納得なしに対応打ち切り

というのが、「アイ・オー・データ機器」とかいう糞団体のサポートとか、製品ポリシーらしいというのがよく分かった。

「サポート」なんて単語使わず、「売りっぱなしで放置するけど、形式上」とかに変えろ！
紛らわしい。

IOデータの社長もこれでOKってことか。

SEG CLIP評価実験についてはこちら。
関連記事はこちら。

あとは、その問題の返信(応答に1週間掛かっている)が↓これだ。

手順書は過去記事に載せてあるけど、やはりCA局を組んで、サーバー証明書を取得するのは手間であろうということで、サーバー証明書のサンプルでござる。
オレオレでござる。

OverSsl Serverで使える。
当然、IISでも使えるけどな。

FQDNは、*.sample.localになってるので、mail.sample.localとか、ftp.sample.localとか、適当な名前でどうぞ。

ルートCA証明書ととペアなので、適切にインストールすれば、そこそこ使える。

ルートCA証明書はローカルコンピュータの信頼されたルート証明機関へインポート。
サーバー証明書はローカルコンピュータの個人へインポート(パスワードはSample)。
ルートCA証明書は利用するすべてのサーバーおよびクライアントへインポート。
サーバー証明書は利用するサーバーへインポート。
＃分からなければコメントを。

公的証明機関だと、あらかじめOSに組み込まれていることが多いため、サーバー証明書の設定だけで済むのが利点。
こと暗号化通信に関して言えば、その程度の差しかない。
＃認証となると、また別の側面がある。

超長文字列のリソース埋め込みができそうなので、Excelのアドインで円周率を3万桁ほど返してみようとしたところ、とんでもないところで躓くことになった。
＃悩みまくりのお手上げ。

なんと、引数なし関数の登録ができないのだ。

なぜ、できないのかは、よくわかっていない。
SDKのサンプルではいとも簡単に登録できているし、引数ありなら問題ないのに、引数なしになった途端に破綻する。
＃途端破綻、ドタンバタン。

ま、いい機会だから、気になってたところを直しつつ、VS2010に移行して、メモリ使用効率もあげちゃおうかと考え中。
＃計算部分には手を入れないつもりなので、高速化はできないと思う。
かなり手間だけど。

同時に64bit対応化も。

要は.rc2ファイルへ移動させればよいのだけれど、プロジェクト雛形によってはrcもrc2も無い場合があるので、メモ。

まず、プロジェクトにリソースファイル(.rc)を追加して、バージョン情報リソースを作成する。
これはVC++の統合環境から実行できる。

次に、.rc2の追加だが、これは面倒。
単に.rc2ファイルを追加してもダメなので、.rcファイルの修正が必要になる。

.rcファイルをメモ帳か、VC++のテキストエディタで開いて、
3 TEXTINCLUDE
の箇所と、
// Generated from the TEXTINCLUDE 3 resource.
の箇所に呪文を追加する。
ただ、呪文は結構難しいので、別途作成したMFCプロジェクトの.rcファイルの記述を参考に記述する。
＃もしかするともっと簡単な方法があるかも知れない。

そして、VS_VERSION_INFO VERSIONINFOからの一連のバージョン情報を.rcから.rc2へ移動させる。

移動すると、どんないいことがあるかというと、たとえば、リソースエディタでの変更保存時でも削った不要な情報の再作成が行われないとか、プリプロセッサによる条件分岐を設定しても消されないとか、なんかこんなこともできたりするらしい。

リソースエディタが使えなくなるけど、ある程度プロジェクトが固まったらそんなに編集するものではないので、移動させて勝手に変更されなくするのもアリだと思う。

とりあえず終わり。

時間で発生する現象ではないことだけは確定。
ハンドルカウントとの関連は濃厚。

どういうときにハンドルカウントが増加するのかは、明確化されていないので、大幅に増加する操作をした場合、一発アウトになること請け合い。
そういう操作が無いことを、メーカー側で立証することは、できないだろう。
＃ハンドルリークも見つけられないんですよ。

おまけに、どうやら巨大メモリリークもありそうな・・・

明らかなバグなのに、仕様とかいう単語を平気で使いやがったから、むかついてるんで、4回目。
＃何が仕様なのかはっきりしてないけれど、正常動作を指していないことだけは明らか。

今回は、放置で問題となったシステム不安定が、本当にハンドルリークのせいかどうかを確認するため、積極的にハンドルリークさせることを目的としている。

もし、時間でアウトならば、いくらハンドルリークさせても、5日弱は動くはず。
ハンドルリークと連動するならば、1日持たないくらいの勢いで、リーク発生させ中なので、すぐに結果は出るはず。

もし、ハンドルリークが原因でシステム不安定になるとしたら、それを放置するIOデータはこれ以上ない超極悪結社。
システム不安定の問い合わせから1か月も経ってるのに、ハンドルリークとの関連は「あると考えている」だけだと?
何も根拠を掴めていないんじゃん。
「時代の一歩先行く技術力」とか、「充実したサポート力」なんてゼロ未満。
アイ・オー・データ機器 行動憲章にも大笑いだ。

そして、今、直せなくて、今後の参考になんてできるわけがない。

過去記事にした方法では失敗が多く、最近、比較的うまく出来る方法を獲得したので、そちらを書いておく。

用意するもの：生卵、塩、ラップ、キッチンペーパー、ポリ袋、鍋、水、空ペットボトル、湯、火。

1. ペットボトルに塩を入れる。目分量で、そんなに多くなくていいはず。
2. ペットボトルにお湯を少し入れる。これも目分量。
3. ペットボトルを振り、塩が溶けきってしまったら、塩追加。僅かに溶け残る程度にする。この時点でペットボトルの塩湯の量は卵１つに対し、10～15cc程度(キッチンペーパー1枚が濡れ切る量)でよい。
4. 鍋に水と生卵と塩を入れ、火にかけ、ゆでたまごをつくる。
5. ラップを適量用意し、キッチンペーパー1枚を重ねる。
6. キッチンペーパーに塩湯を垂らす。
7. 殻つきのままのゆでたまごを濡れたキッチンペーパーで包み(可能ならこの時点で塩湯追加)、さらにラップで包む。
8. できた包みをポリ袋に入れて乾燥を防ぐ。
9. これを1~3日放置(冷めたら冷蔵庫で放置)する。

前回の塩を直接振る方法だと、溶けきらないために味の浸透が弱いが、今回は、あらかじめ水溶液になっているので、失敗が少ない。
そして、前回同様、多量の飽和食塩水を用意することもないし、漬けるために容器を用意する必要もない。
＃放置し過ぎても、それほど味が濃くならないのも利点。