ただし、バッチファイルではなく、ファイルコピーで。
ビルド前イベントに設定したコマンドは以下(全ての設定で共通)。
copy "$(ProjectDir)StdDef\$(ConfigurationName)_$(PlatformName).h" "$(ProjectDir)StdDef.h"
StdDefフォルダに「構成名_プラットホーム名.h」でStdDef.hの内容をそれぞれの設定用に記述しておくと、ビルド前にコピーしてくれて、それでOK。
あとは、リソースファイル(.rc2, resource.h)とかstdafx.hとかで#include "stddef.h"してあげればOK。
一つ注意があるとすれば、VC++はデバッグ構成時に_DEBUGを強制定義してくるらしいこと。
よって、デバッグ構成のときは、
#ifndef _DEBUG
#define _DEBUG
#endif
のように定義しておく。
これで、二重定義警告を抑制できる。
＃そして、もし定義されていない場合でも、定義される安心。
デバッグモードコンパイルなのか、リリースモードコンパイルなのか、判断して、バージョン情報リソースに任意の文字列として埋め込みたいとか思うと、VC++の場合、リソースコンパイラのプリプロセッサ定義が独立しているので、C/C++コンパイラのそれと2か所に設定せねばならず、面倒なのだ。
で、ちょっと思いついたのでメモ。
こうすることで、設定は1か所になるはずだが、果たして・・・
＃後日試してみる。
なぜアナログTVを無くそうとするのか。
今、使えるものを大切に使うことこそが、みんな大好きなエコなんじゃねぇの？と思うのだがね。
要するに、
というのが、「アイ・オー・データ機器」とかいう糞団体のサポートとか、製品ポリシーらしいというのがよく分かった。
「サポート」なんて単語使わず、「売りっぱなしで放置するけど、形式上」とかに変えろ！
紛らわしい。
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か月も経ってるのに、ハンドルリークとの関連は「あると考えている」だけだと?
何も根拠を掴めていないんじゃん。
「時代の一歩先行く技術力」とか、「充実したサポート力」なんてゼロ未満。
アイ・オー・データ機器 行動憲章にも大笑いだ。
そして、今、直せなくて、今後の参考になんてできるわけがない。
過去記事にした方法では失敗が多く、最近、比較的うまく出来る方法を獲得したので、そちらを書いておく。
用意するもの：生卵、塩、ラップ、キッチンペーパー、ポリ袋、鍋、水、空ペットボトル、湯、火。
前回の塩を直接振る方法だと、溶けきらないために味の浸透が弱いが、今回は、あらかじめ水溶液になっているので、失敗が少ない。
そして、前回同様、多量の飽和食塩水を用意することもないし、漬けるために容器を用意する必要もない。
＃放置し過ぎても、それほど味が濃くならないのも利点。
といっても、サポートの方だけど。
OverSsl Server / Client のサポートページを用意してみたんだけど、本当は、使用感なんかを知りたかったりする。
あと、SI(お安くしますよ)可能性について、知りたいのだけど・・・
＃証明書って買うと高いけど、小規模なら買わなくても何とかなるんですよ、ホント。
推奨する使用方法は、サーバーマシンとクライアントマシンにそれぞれインストールしてEnd-to-Endの通信暗号化なんだけど、そうじゃなくても、たとえば、サーバーマシンがLinux系だったりする場合には、リバースプロキシっぽくOverSsl Serverを間に挟んで暗号化したりもできる。
＃この挟む方法ってのはクライアントマシンでも同様なんだけどさ。
仮に既にSSL暗号化されていたとしても、そこにTCP通信があるのなら、SSL暗号化することができるので、ぜひ使ってみて欲しいんだけど・・・最近は殆どがHTTPSで済んじゃうんだよなぁ・・・
＃余談だが、認証だけHTTPSで、認証後がHTTPってのは改ざんに対しての対策になってないと思う。
昨日の記事で、発見したXLLSDKのヘルプドキュメントをちらっと見たところ、非同期関数を定義できるとか。
長時間掛処理でExcel無応答になることが、これで防げるのかどうか、どちらにしろ、Excel2010の新機能だと思われる。
長時間処理といえば、HyperLong系の処理なのだが、これ、非同期にしたら、実行時間は変わらなくても、処理的に軽くなるかも知れない。
やってみる価値はありそうだ。
過去記事の誤り。
「署名があるとか無いとか、そんなことはどうだっていいんです」という結論。
やってみることは大事だね。
ただ、まだ、「動いた」というレベルだけれども。
とりあえず、Excel4系関数を排除して、Excel12系関数(SDKだと、_WIN64定義時に呼べないようになってるのを解除)のみにして、x64ターゲットでコンパイル。
すると、登録もできるし、関数も呼べる。
手放しで喜ぶのは構造体のアラインメントを詳しく確認してからなのだが、とりあえず、Excel2007と同程度のことはできそう。
それ以上の何かを期待できるかも知れないのだが、まずは、そこから。
・・・と、少し満足してたら、こんなものが!!
出てるなら出てるって教えておくれよ!!!＜いや、無理。
仕方ない、中身調べてみるか・・・
全文引用してくれと頼んでもこの始末。
最初から抜きまくりだから、「↑↓」の指してるものすら分からん。
日本語を理解するサルの方がまだマシなんじゃなかろうか？
受けてきた。
TS: Windows Server 2008 R2, Server Virtualization
仮想。R2。でも、殆どVMM2008R2だから覚悟せよ。
雨の日受験は避けたい。
本当に避けたい。
でも、予約締切りが早すぎて、天気予報をあてにすることもできない。
まず、遅れた。
雨で風で、もうね、ぐしょぐしょになりながら、遅刻。
最悪。
受付で注意を受ける。
何とかなったけど。
前回から間が空いたのは、近くの試験会場の予約が取れなかったから。
開催日をもっと増やして欲しいと願っても無理か。
Vectorに登録したのが公開されたらしい。
16:45現在、ステータスは公開済ながら、URL不明なためアクセスできないのだけど・・・
IPv6にも対応(とはいえ、OS側でサポートしてもらう必要あるけど)だから、いろいろお得。
22:30 URL通知あり。
OverSsl Server ベータ版
OverSsl Client ベータ版
とりあえず、注意すべきは使用期限と動作時間。
ベータ版だから、それぞれ制限をかけてある。
7月末までには正式版にしたいという、予定も含めて。
とりあえず、日本語のわかる人間を雇えと。
2週間以上待たせてこんなレベル。
俺は、おまえらの製品のバグ検出係じゃないっちゅうの。
オレオレで誰なのかはっきりしないのはダメだけど、オレオレでも誰か分かっているのなら問題ないわけで。
というわけで、エンタープライズオレオレに続いて、スタンドアロンオレオレでもつくってみた。
要求をファイル化したり、バイナリデータを取り込んだりするのがちょっと面倒だけど、要求ファイルは公的な外部認証局へも提出できるわけで、逆に操作する場面は多いかもな～と思いつつ。
エンタープライズ認証局たてるよりは圧倒的に手間要らず。
Windows Serverはお試し版もダウンロードできるので、実際にやってみることよい。
忘れないようにメモ。
IPv6で正しくアドレス指定しても、Connectでエラーになっていた。
「System.Net.Sockets.SocketException: 要求したプロトコルと互換性がないアドレスを使用しました。」だそうな。
IPv4指定にするとConnectを通過するので、IPv6に起因するものだと、思い至る(までに数時間)。
調べると、コンストラクタの中に、IPv6を使うか、IPv4を使うか決めるものがある。
フンガー!!
引数設定したら、例外発生しなくなり、通信できるようになった。
ムッキー!!
どのアドレスファミリで接続するかをConnectで判断しちゃいけないってことを忘れちゃいけない。
サイドウィジェットとして、QRコードを入れてみた。
＃サイトトップ固定だし、このサイト、モバイル対応しているわけじゃないけど。
しかも、画像じゃなくて、テーブルとして。
これを動的に埋め込めるようになれば、おもろいかもなぁ～。
当然といえば当然なんだけど、MouseEventArgs.Buttonの値って、マウスの左右入れ替えすると、ちゃんと入れ替わってくれるのね。
入れ替わってくれなかったらどうしようって思ってたんだけど、これなら安心。
旧ブログに置いてある、WPF本から抜き出して迷路データを自動生成にしたやつをXBAP化してみたんだけど・・・・
なんか、フォーカスをうまく受け取れていない。
そのせいか、キー操作もうまくない。
酔っ払いを操作しているようで、快適とは言えない。
.NET 3.5 と 4.0で試したけど、どちらも同じ。
継承すれば、親クラスのprotectedメンバにもアクセスし放題とばかり思っていた。
この十年余り。
俺もまだまだだな。
こんなC++コードを書くと、「A& GetA(A& org)中のorg.A::GetA()呼び出しって、protectedだからアクセスできないよ～」というコンパイルエラーが出る。
A& GetA(B& org)の方は大丈夫。
なんとなーく、Aのprotectedメンバにサクサクアクセス出来ちゃいそうに思っていたので、自己修正、覚え直し。
C#でも試したけど、同様。
どうしようか考えているんだが、とにかく、ハンドルカウントが大幅にアップするクリティカルパスを無限実行させて、短時間に破たんさせたい。
ま、そういうわけで、ちょっと弄ってるんだけど、その最中のこと。
XPをシャットダウンor再起動したとき、反応がどうも鈍い。
SEG CLIPデバイスを接続して、電波状態が悪い等で「選局中・・・」である場合、割り込みによって、ログオフ処理も阻害されるらしいことが、分かった。
＃デバイスを抜くと、処理が進む。
どんだけ酷過ぎれば気が済むんだよ。
とりあえず、本サイトのサーバー証明書を差し替え。
オレオレエンタープライズ(ワイルドカード)サーバー証明書を、ルートCA局から用意して、差し替えた。
面倒っちゃー面倒だけど、全部毎回作り直しても、手間はあまり変わらないので。
で、サーバー証明書は既出のアレでも使えるので、取得手順書(画面キャプチャ枚数70枚超)も作ったんだけど、結構でかい。
精査前だけど、欲しけりゃ持ってけ。
エンタープライズじゃなくて、スタンドアロンにすれば、AD DS不要で、単純かも知れず、再挑戦予定。
昨日のあれ、なんとか動いた。
いろいろあったけど、利用する証明書は秘密鍵付きじゃないとマズイってことは重要なのでメモ。
公開鍵暗号なんだから、復号化する際に必要なので、当然なんだけど・・・
昨日の画面を見ればわかる人はわかるけど、今回のサーバー版ってのには、Hosts書き換えを不要にする仕掛けを入れてあるので、とても便利。
つまり、受け取った証明書のホスト名が検証されるので、ホスト名が一致している必要があるのだけど、これを接続先アドレスと別に用意できることで、解決しちゃうという、当たり前っちゃー当たり前なことなんだけど、忘れがち。
＃クライアント版にも反映したい。
これで、バックエンドサーバーと同じ証明書を利用して、SSL-SSLの簡易プロキシ(ポートフォワード)としてポートを公開することもできる。
既出クライアントのサーバー版
やっと、ポートListenできた。
＃多分、証明書も読み込めているとは思うのだが、netstatでポートListenの確認まで。
本当に使えるかは、これから確認。
Managerで設定保存するとサービスが自動的に設定再読み込みしてくれるのはクライアント版と同様。
超手間要らず設計。
あとは、オレオレエンタープライズ証明書取得方法文書化ってやつをやっておかなきゃな・・・
＃Windows Only。
四捨五入では、0.4495→0.450(小数点下第3位に丸め)→0.45(小数点下第2位に丸め)→0.5(小数点下第1位に丸め)→1(整数に丸め)のように何度も丸めを行うことはご法度になっている。
0.4495→0.4(小数点下第1位に丸め)であり、0.5ではないし、まして1に丸められることはあってはいけない。
有と無、切り上げられる側と切り捨てられる側は平等でなければならないと考えると、多重丸めは不平等だと言える。
どちらに有利かはさておき、最初に挙げた例のように1になってしまっては、0.5505(=1-0.4495)の存在理由が否定されてしまう。
実は、多数決ってやつが、丸めによく似ていると、最近気づいた。
そして、日本の政治とか選挙が、多重丸めで成り立っていると、気付いた。
System.Net.IPAddressのコンストラクタに渡す文字列をチェックしたかったのだが、IPv4表記ならば楽にバイト列化できるけど、IPv6の場合短縮表記やら、インタフェースIDやら、IPv4埋め込みやらで、やたらと手間がかかる・・・と思っていた。
%や:や.で分割して、0埋めが必要ならどれだけか調べて置換・・・とか、いろいろやったんだけど、結局のところ、
System.Net.IPAddress.Parse
System.Net.IPAddress.TryParse
この2メソッドが異様に強力ということに。
かなり適当な表記でも、正しければIPAddressに変換してくれる。
コンストラクタ要らずで、超便利。
ただし、インタフェースID部分は数値である必要があるらしい。
