Hobbyの最近のブログ記事

最近、2chに捕捉されたので、http://blog.fne.jp/page/msdnxsltxml.htmlへのアクセスが急増したのだけれど、捕捉されたことについては別にいい。

大事なことは、便利という点、ではない。
便利なんだけど、大事なのは、XSLTをXMLとして書けるということだ。
・・・？
いや、良くわからないか。

来月中には出そうと思っているので、一応書いておく。
ってか、書いちゃえ。
予告ってやつですよ。

正しいかどうか分からないが、埋め込みTwitterの取り込み処理と、そこからデータをDOM操作する処理を初回BackgroundWorkerでやってたのだが、BackgroundWorkerだとそのオブジェクトを生成するのに時間が掛かるらしい。
＃確かなことは分からないが、デフォルトドキュメントのカウンタログを見ると、/ と /index.htmlとの間に最大で5秒以上のタイムラグが発生しているらしい。

そこで、BackgroundWorkerをやめて、ThreadPoolを使うようにした。
すると、タイムラグは1秒以内に収まるようになった(今のところ)。

プール数とリクエスト数にも依存するかも知れないけれど、まずまずの結果かな？
これで問題が出なければ、今後、ThreadPoolを使える場所ではThreadPoolを使うことにしよう。

とりあえず、方法だけ書いておくか。

IIS用のマネージモジュールで、HTMLコンテンツに対し、カウンタと一緒に書き換えフィルタ処理を入れてある。
＃フィルタを使ったマネージモジュールの創り方は、ウィジェットのサイトカウンタって文字列をクリックな。

ただ、書き換え時にいちいちrssを取りに行くと、twitterサイトが重いときとか、回線混雑のときに応答待ちが大きくなるので、定期的にメモリ上に取り込むのを別途タイマーかけてやってる。

本当にちゃんと保持できてるかは未確認だけど、一応、シングルトンクラス内でタイマー使ってるから、保持できているはずだ。

保持したrss(XML)をごにょごにょ弄って書き換えるのは、いちいちやってる・・・のは無駄だな。
＃本当なら、保持するのは書き換えに必要な加工状態のものでいいはずだよなぁ・・・ま、いいか。

テキストベースで、Excelとの親和性も高いので、プログラムするには適していると思ったんだが、よくわからないことが多い。

Win32スタティックライブラリのプロジェクトウィザードでATLを選択できないのは、普通に使うとマズイことになるからと推測中。

CoInitialize*を呼ぶことができれば、多分使える。

DLLの場合、スレッドアタッチとかスレッドデタッチのタイミングでCoInitialize*/CoUninitializeすればそのスレッドではCOM利用が可能なはず。
＃でも、DllMainで呼んじゃダメみたいな記述がある・・・

スレッド内にすべてを封じ込めることができれば、スタティックライブラリにしても問題ないんじゃないかという方針で進めてみようと思っている。

並行してドライバの件もなんとかしなきゃなぁ・・・

ATLって、スタティックライブラリには使えないらしい・・・
＃プロジェクトウィザードで選択できましぇんので。

ATL使用部分をスタティックライブラリに内包して、メインのプロジェクトからはATLを隠ぺいしたままにしたいというのは、結果的な希望。

本質の欲求は、msxml利用部分をプロジェクトとして分離したいという、ただそれだけなのにぃ・・・

ATL使うと楽ができるというか、多分コード量も少なくて済むからバグ少なくなると思ったんだけどなぁ。

・・・でもプロジェクトのプロパティではATL利用を選択できるんで、使えそうな気がするんだよね。
どうなってんじゃろぅ。
やっちゃいけないことなんだろうか？

まだちょっと未練があって、いろいろ考えてたら、チェックサム計算を忘れていることに気付いた。
＃アキバ行ったときに、TCP/IP関連の本を読んでて気づいたのが本当のところ。

だから、試しにチェックサム計算を入れたわけだ。
1の補数とか、0xFFFF == 0 とか、そんなの。

でも、やはりパケットは飛んでない様子。

結局、ダメなのかなぁ・・・

サンプルが目的に合ってないのか、やろうとしていることが間違っているのか、やり方が間違ってるのか。
多分、全部だろうな・・・

書き換え方が悪いのか、書き換える場所が悪いのか・・・

イーサフレーム書き換えることはできても、発信できていなく、ダメっぽいので、別な方法を探そうと思ったのだった。

やはり、NICに到達しちゃったあとで、送信先MACアドレスまで入ったイーサフレームも出来上がった後で何かしようと思うのは、そもそもの間違いなんだろうな。

とりあえず、またサンプルを漁るか・・・

イーサフレームを書き換えるところまではできた。

でも、まだTCPコネクションを確立できていない。

意図した書き換えもできてるし、書き換えた結果、影響は与えられているようなので、書き換える値などをもう少し見てみる予定。

超面倒・・・

ドライバはカーネルモードで動くわけで、かなりの特権が与えられる。

そんなものが、無暗にメモリを喰いまくったり、例外吐いたりしたらえらいことになるわけだということは薄々気が付いていた。

サンプルコードを見ても、alloc系関数は特定要素の生成に特化したものだったりするのは当たり前だと思ったのだが、どうも、メモリ確保には細心の注意というか、気軽にメモリ確保しちゃいけないんじゃないかと、思ったのは、今日。

一時的なメモリ領域で、固定長にできず、しかし、内容解析のために連続領域が必要・・・といった場合でも、それを確保せずに済ませる方法を考えた方が、どうやらいいらしい。

メモリ確保しないとか、変数を使わないのは、XSLTで慣れてる？

悪戦苦闘の末、読めたのだが・・・

どうやら取得できたのは、IPパケットじゃなくそれを含んだイーサパケットらしい。

まぁ、そりゃ宛先を決めるのならIPアドレスじゃなくてMACアドレスが必要だよねぇ・・・

じゃなくて、そんなところまでいかないうちに、ループバックさせないとマズイのかも。

と思いつつ、書き換えできるかを先に試してみようかと思う。

当たり障りの無い情報ならいくらでもあるんだけど、ドライバ開発するための資料となると、Webですら殆ど見つからない。

DDK(WDK)のサンプルを選んで、デバッグ表示でIPパケットダンプしようと思っただけなのに、明らかにそこに目的のIPパケットがありそうなのに、もうやり方が分からない。

ヘルプ読むと、関数とかマクロ使えとか書いてあったりするんだけど、具体的な関数名やマクロ名が分からん。

気長にコツコツやるしかないのだろう。

そのうち分かってくるといいなぁ。

まぁ、-2007となっているけれど、2010にも対応ですよ。

BasicとFreeがあります。

Free Editionには目新しい機能はありませんが、少しだけ内部処理(とプロジェクト構造)を変えたのでマイナーバージョンアップしました。

Basic EditionにはMD2とMD4を追加してみました。
どちらも今となっては実用性が薄れていますが・・・

Basic Editionには、まだ追加関数があります。

目玉は円周率。
円周率数百桁～数万桁を計算に利用しちゃってください。
できるのは四則演算程度ですが・・・

他にも追加関数があるので、レジストして使ってくださればと思うのですが・・・

XPのDDKと最新のWDKを落としてきて、英語とにらめっこしたり、サンプルコード見たりしてるんだけど、いまいちよく分かっていない。

やりたいことは分かっている。
IPパケットの書き換えだ。

直接TCP内容を書き換えるか、宛先だけをを書き換えて別プロセス(socketベースのアプリケーション)で書き換えを行わせるか、どちらかの方法でできるはずだとは考えているのだが、やはり、よくわからない。

Vista以降の場合、何とかサンプルになりそうなものを見つけはしたものの、XPでの方法がよくわからない。

やはりいきなりドライバってことに無理があるのだろうか？
最初から順番にやっていかないとダメなんだろうか？

OverSsl Clientのコンセプトは良いはずだ。
暗号化で安全な通信経路を保障しちゃうのは結構ありがたいはずだ。
だが、問題はいくつかある。
＃STARTTLSに対応できないのはコンセプト上、仕方ないのだが。

一番の問題は、アプリケーションの設定を変更しなければならないことだ。
この変更に対応できない場合はとても残念なことだが利用できない。
例えばWWWブラウザなどはその最たるものだ。

そして、それは、サーバーを固定指定することに起因する。
OverSsl Serverの場合は、この仕様で問題ないのだが、Clientでは問題となるわけだ。

他にも問題はあるのだけれど、この問題が解消できると、クライアントアプリケーションの設定を不要にできる可能性が出てくる。
つまり、あまりネットワークを知らない一般ユーザでも導入が簡単になる可能性がある。

http://internet.watch.impress.co.jp/docs/column/jirei/20100714_380352.html
↑この事例とそのあとの話の繋がりは少しおかしい。

無線LANの暗号化は、アクセスポイント－無線機器の間で行われるもので、通信経路全体を暗号化しているわけではない。
だから、WEPだろうがWPA/WPA2だろうが、アクセスポイントまで到達できてしまった通信は、それより先では無防備になる。
WEP解読云々は別の話である。
APで受け取ったパケットを解析すれば、無線LANの暗号化なんて、関係ないのだから。
＃だからといって、無線LAN暗号化が不要だとか、知らないAPを使っていいというわけではないので、注意。

記事の事例に限れば最も重要な解は、記事の最後の方にあるメールのSSL暗号化だ。

通信中の情報保護をするのなら、通信経路全体を暗号化する必要がある。
通信経路全体を暗号化するのならば、やはり、クライアントからサーバーまでEnd-to-Endの暗号化が保障されたほうがいい。
SSL暗号化はその一つの解で一般的だと思う。

古いクライアントアプリケーションだと、SSL暗号化通信に対応できてないものもあるので、そういう場合は、OverSsl *を使えばいいのにって話になる。
＃iOSには対応しておりませんが。

ただ、メールの場合、暗号化されたところで、所詮メールサーバーまで。
そこから先の転送(目的のアドレスのメールボックスを保有しているサーバーへの通信)が暗号化されていないと意味は薄れるわけだが。

円周率を追加したアドインの評価を完了。

あとはドキュメントだけ。

鋭意執筆中。

公開されるのは来週・・・かな。

んー、おまけにいくつか関数ぶち込んであるんで、ぜひレジストして全関数を使ってほしいのだけどなぁ。

というのはさておき、現在公開中の0.7.1にもある問題が解決できていない。

なんか、できそうだったので、やってみた。
元ソースは過去のC/C++コード。

非同期パケットダンプがちょっと固まりやすいけれど、一応できた。
＃固まるってのは、Rawパケ採取にBackgroundWorker使ってんだけど、激しいProgressChangedによって、Form描画が詰まっちゃってるっぽい。←応急処置入れたので固まりにくくなったと思う。
あと、停止時に例外出るのは仕様。

一応、実行ファイルだけ置いておく。

OverSsl使った場合、ちゃんと暗号化されていることが、視覚的に分かるぞ。

さすがに、XP以降じゃないとダメかも。
要.NET Framework 3.5だし。
IPv6でも動くかも知れないけど、未確認。
＃IPv6ヘッダ解析はIPアドレス部分だけ入れてあるつもりだけど。
(追記)実行には管理者権限が必要です。

とりあえず、フルマネージコードでRawパケ採取できることが分かったことは収穫。

いつからかは定かではないけれど、キータイプ属性値に変更があったようで。

CUS と Custom Key の両方に対応してはじくようにしたので、変更前でも変更後でもOK。

本当はもっと効率がいいXSLT記述があると思うけど、個人的には、元XMLに手を加えることなくテーブル表示できるだけでいいので、これで十分かつ超便利。

そして、アドインを登録しようとして、重大なエラーとやらが出る。

Heap blockなんとか～ってエラーだとわかり、解放時のエラーらしいというのは分かったのだが、デバッグモードでトラップするのは、非常に困難。

• Excelにあらかじめアドイン(ちゃんと登録できるやつ)を設定しておく
• デバッグビルド物件に置換
• VSデバッグモードでExcelを起動(アドインを引数にしない)
• 操作等を実施
• 例外ダイアログが出たら、デバッグでコードが出るところまで何度かボタンをクリック

これで、何とか原因を突き止めることができる。

今回の問題は、デバッグ実行時の引数にアドインを指定してると呼び出されない関数にあったので、はじめはわけが分からなかった。
＃現在リリースされているものとは違うコードです。

こういう手法に気付くまでが大変だけど、コードや呼び出し履歴を掴めれば、どこの何が原因かを判別するのが容易になる。

ま、PRですし、既出ですが。

まずは、OverSsl Clientをインストールして、↓こんなふうに設定を追加しますよ。

ま、気にする人はいないだろうけど、メモがてら。

• 絶対値・・・実装。
• 円周率・・・実装。
• SQRTPI相当・・・実装延期。
• 桁指定・・・実装延期。
• SUM系・・・実装延期。
• 数値化・・・追加実装。

ま、こんなところか。

円周率は出せているし、絶対値も現状用意済みの内部関数を呼ぶだけ。
あとは数値化だが、これも何とかなったっぽいので、これで、出せる・・・と思うのだが、デバッグモードで実行すると、例外がボロボロ出るところがあるので、原因を調べてからにしたい。

数値化はとても便利かも知れない。
＃現状、Excelには255文字以上の数値文字列を数値化する関数が無い。

64bit版もできるんだけど、これは要望か何かがあるなら考えるけど、メジャーバージョンアップまで非公開の予定。

と、声に出して言いたい。

パイと言っても円周率(π)ですが。

いや～、スタティックライブラリのリソースからロードするのって、結構難しいですね。

あと、ちょっとリソースファイルの編集について、インクルードを処理するのは、リソースビューで開いて、「リソースファイルのインクルード」でやると簡単だったことをメモしておく。

で、πですが、こんな感じ。

しかし、もし、仕様ならば、仕方ないし、そうじゃなくても、現状そうならばそうで対処するしかない。
＃回避策があるのならば、それに頼る。
＃＃回避策が無いのに、不具合を仕様と言っちゃう(再起動したところで、再現を繰り返すだけ)のは愚かなだけだが。

とりあえず、関数の説明は同梱のPDFにお任せしちゃうことで、無しにすることは不可能ではないので、それで対応してみる。

さて、円周率3万桁、ちゃんと出るかはこれから確認。

例のXLLSDKをやっと取り込んだんだけど、やはり引数なしでうまくいかない。

サンプルだと引数なし関数の登録がうまくいくのかと思っていたのだけれど、試しに関数の説明まで出そうとしたところ、引数ありになってしまうことが分かった。

関数の説明を端折ると、引数なしとして登録できる。

これは誰のせいなのか、全く分からないのだけれど、Excelのせい？なのか・・・よくわからん。

とりあえず、Excel2003でも2010でも挙動が同じだったこと、VS2008でもVS2010でも結果は変わらなかったことをメモとして残しておく。

いやはや、さて、困ったぞ。
本読んでもこのあたり書いてないんだよなぁ・・・

あと、文字列(関数の説明以降)の最後1文字が切れるのも俺のせいじゃないらしい。
そういえば、引数なし関数がうまく登録できないとき、関数の引数んとこに空白1文字入ってるっぽいんだよね。
余分な1文字と無くなる1文字で辻褄は合ってるのか・・・？

んー、英語版Excelで試してみるか・・・

早速試してみた。

ただし、バッチファイルではなく、ファイルコピーで。

ビルド前イベントに設定したコマンドは以下(全ての設定で共通)。

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か所に設定せねばならず、面倒なのだ。

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

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

こうすることで、設定は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へ移動させる。

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

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

といっても、サポートの方だけど。
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と同程度のことはできそう。
それ以上の何かを期待できるかも知れないのだが、まずは、そこから。

・・・と、少し満足してたら、こんなものが!!
出てるなら出てるって教えておくれよ!!!＜いや、無理。

仕方ない、中身調べてみるか・・・

Vectorに登録したのが公開されたらしい。

16:45現在、ステータスは公開済ながら、URL不明なためアクセスできないのだけど・・・

IPv6にも対応(とはいえ、OS側でサポートしてもらう必要あるけど)だから、いろいろお得。

22:30 URL通知あり。

OverSsl Server ベータ版
OverSsl Client ベータ版

とりあえず、注意すべきは使用期限と動作時間。
ベータ版だから、それぞれ制限をかけてある。
7月末までには正式版にしたいという、予定も含めて。

忘れないようにメモ。

IPv6で正しくアドレス指定しても、Connectでエラーになっていた。

「System.Net.Sockets.SocketException: 要求したプロトコルと互換性がないアドレスを使用しました。」だそうな。

IPv4指定にするとConnectを通過するので、IPv6に起因するものだと、思い至る(までに数時間)。

調べると、コンストラクタの中に、IPv6を使うか、IPv4を使うか決めるものがある。

フンガー!!

引数設定したら、例外発生しなくなり、通信できるようになった。

ムッキー!!

どのアドレスファミリで接続するかをConnectで判断しちゃいけないってことを忘れちゃいけない。

当然といえば当然なんだけど、MouseEventArgs.Buttonの値って、マウスの左右入れ替えすると、ちゃんと入れ替わってくれるのね。

入れ替わってくれなかったらどうしようって思ってたんだけど、これなら安心。

旧ブログに置いてある、WPF本から抜き出して迷路データを自動生成にしたやつをXBAP化してみたんだけど・・・・

なんか、フォーカスをうまく受け取れていない。
そのせいか、キー操作もうまくない。

• うまくフォーカスがあるときはALTキー無しで動く。
• フォーカスが無いとき、ALT＋カーソルキーで動く場合がある。
  ＃履歴があるとき、ALT+←で履歴バックしちゃう・・・
• うまく動いても、KeyUpを認識できていないのか、ずるずる動く場合がある。
• 処理が重いときもある。

酔っ払いを操作しているようで、快適とは言えない。

.NET 3.5 と 4.0で試したけど、どちらも同じ。

継承すれば、親クラスのprotectedメンバにもアクセスし放題とばかり思っていた。

この十年余り。

俺もまだまだだな。

こんなC++コードを書くと、「A& GetA(A& org)中のorg.A::GetA()呼び出しって、protectedだからアクセスできないよ～」というコンパイルエラーが出る。

A& GetA(B& org)の方は大丈夫。

なんとなーく、Aのprotectedメンバにサクサクアクセス出来ちゃいそうに思っていたので、自己修正、覚え直し。

C#でも試したけど、同様。

まだマニュアルはない。

例のブツ。

クライアント版の方。
いろいろ変えた。

とりあえず、置いておく。

サーバー版も同程度にはできている。

けど、これだと サーバー版＝クライアント版＋SSL証明書設定 ってだけで、あまり差が無いので、クライアント版にはクライアント版独自機能を盛り込む予定ではある。
＃モバイル用途に超便利な機能を予定。

前回と同様、6月末期限＆サービス起動後3分で停止なので、注意。

(追記)
マネージャーにバグがあります。

昨日のあれ、なんとか動いた。

いろいろあったけど、利用する証明書は秘密鍵付きじゃないとマズイってことは重要なのでメモ。
公開鍵暗号なんだから、復号化する際に必要なので、当然なんだけど・・・

昨日の画面を見ればわかる人はわかるけど、今回のサーバー版ってのには、Hosts書き換えを不要にする仕掛けを入れてあるので、とても便利。
つまり、受け取った証明書のホスト名が検証されるので、ホスト名が一致している必要があるのだけど、これを接続先アドレスと別に用意できることで、解決しちゃうという、当たり前っちゃー当たり前なことなんだけど、忘れがち。
＃クライアント版にも反映したい。

これで、バックエンドサーバーと同じ証明書を利用して、SSL-SSLの簡易プロキシ(ポートフォワード)としてポートを公開することもできる。

既出クライアントのサーバー版

やっと、ポートListenできた。
＃多分、証明書も読み込めているとは思うのだが、netstatでポートListenの確認まで。

本当に使えるかは、これから確認。

Managerで設定保存するとサービスが自動的に設定再読み込みしてくれるのはクライアント版と同様。
超手間要らず設計。

あとは、オレオレエンタープライズ証明書取得方法文書化ってやつをやっておかなきゃな・・・
＃Windows Only。

System.Net.IPAddressのコンストラクタに渡す文字列をチェックしたかったのだが、IPv4表記ならば楽にバイト列化できるけど、IPv6の場合短縮表記やら、インタフェースIDやら、IPv4埋め込みやらで、やたらと手間がかかる・・・と思っていた。

%や:や.で分割して、0埋めが必要ならどれだけか調べて置換・・・とか、いろいろやったんだけど、結局のところ、

System.Net.IPAddress.Parse
System.Net.IPAddress.TryParse

この2メソッドが異様に強力ということに。
かなり適当な表記でも、正しければIPAddressに変換してくれる。
コンストラクタ要らずで、超便利。

ただし、インタフェースID部分は数値である必要があるらしい。

VS2008(SP1)が落ちる。

「ツールボックス」で「アイテムの選択」をすると100%落ちる。

VS2010との同居に問題があるのか、よくわからない。

しかも、サクッと落ちて、例のデバッグしますか？も表示されないので、気付かないほど。

ツールボックス使わなくても何とかなるからいいんだけど、ついやっちゃった場合、未保存コードがパァになるので、注意せねば・・・

Windowsフォームアプリで入力文字を制限するのに、MaskedTextBoxを使うのはいいのだけれど、これ、マスクできる文字種が少なすぎるという欠点がある。
たとえば、16進数で可変長の文字列入力をさせたいなんて、単純なことなのにもう無理。
なんともし難い。

仕方なく、TextBox派生で、文字制限をかけるコンポーネントを実装。
でも、WndProcをオーバーライドしなきゃならんとか、コピペのことまで考えなきゃならんとか、まわりくどいことこの上ない感じ。

もっとスマートな方法があるような気がするのだが・・・
OnTextChangedはあっても、OnTextChangingは無いんだよなぁ。

この件。
性能まで考えると、やはり、アンマネージC/C++にしたほうがいいのかも知れない・・・

20100524_OverSslClientSetup.zip

TCP通信をSSL暗号化するものである。
マニュアルはまだない。
アルファ版でござる。

マネージャとサービスから成り立っている。
Yahoo!のメール設定をプリセットしてある。

Vector登録するまでには及んでいない(後述のIPv6とかに対応したい)ので、ここに置いておく。
.NET Framework 2.0～3.5xに対応している・・・はず(VS2010でビルドしたので、ちょっと不安)。
Windows 7の64bitでも、動く(32bitターゲットだから、WOW64上ってことになる)のを確認済み。

そうそう、サービスは起動後3分経つと自動停止することに加え、使用期限は2010年6月いっぱいに設定してあるので、もしも気に入って金払ってでも使いたいとかいう奇特な人いらっしゃればコメントを。

C#で勝手にDisposeしてくれる方のusing。

例外出てもDispose呼んでくれるので便利だけど、気になって確認したのでメモ。

• using(A hoge1 = new A(), hoge2 = new A()) { } と、
  using(A hoge1 = new A()) {using(A hoge2 = new A()) { } } は処理順も同じなので、安心して使ってよい。
• usingで対応できるのは、変数に代入できた場合のみ。
  たとえば、using(A hoge = new A()) で、Aのコンストラクタ処理で例外発生した場合にはhoge.Dispose()は呼ばれない。

まぁ、当たり前っちゃー当たり前だけど、後者は重要な気がする。
どんな場合でもDispose呼んでくれると思って、コンストラクタ等で例外出しまくると、意図しないことになる可能性があるってことだ。

20100521_X509Certificates_Test1.zip (実行ファイルの圧縮)

とりあえず、昨日のコードをごにょごにょして、ここまで解析できることがわかった。

でも、証明書スナップインで表示されるような「目的」を一部を除いた大部分で取得することができていない。
どうやって取ってきてるんだろうか・・・

証明書ストアにアクセスする必要があるので、コードメモ。

表示用に文字列にしたけど、ひとまずアクセスできることを確認。

使えそう。

サービスに限ったことではないが、msiインストーラプロジェクトで、Permanentプロパティの設定を間違えた。

これは、「アンインストール時に削除するかどうか」というプロパティではなく、「アンインストール時に残すかどうか」を決めるプロパティ。
＃VS2010では説明が逆なので、迷う。正しくは、残す場合はTrueで、通常はFalse(残さず削除)。

これ、間違えたままインストールすると、インストール用レジストリに、そのキーとなるファイルのインストールカウント履歴らしきものを残すらしく、その後、Permanentプロパティを正しく設定したものをインストール＆アンインストールしても、ファイルが残りまくるという現象が発生する。

これを解消するには、レジストリからキーとなっているファイル名(または単純にファイル名)に関連する部分を全部削除するしか方法はない。

要注意。

ポンコツながらも動くものができた。

今回のものは、Windowsサービス＆GUIなネットワーク系アプリケーション。

まだ、ソケット状態の把握がうまくできていないため、公開するレベルではないけれど、なかなか良い。

こいつをいくらかちゃんとしたレベルに仕上げたら、また、Vectorに登録するとしよう。

VS2010だけなのか、未確認。

ユーザーコントロールを追加して、public EventHandlerを追加した。

しかし、コンパイルして、フォームに張り付けても、プロパティウィンドウにイベントとして表示されない。

[Browsable(true)]と、BrowsableAttributeを設定してもやはり表示されない。

なぜだ？

タスクバーの時計領域って、結構でかい。
もし、これを小さくできたら、スッキリするのになぁ・・・
・・・という理由はさておき、題材としては面白いので、通知領域(タスクトレイ)に超簡易アナログ時計をアイコン表示するアプリケーションを創っちゃうぞ。

覚書きも兼ねて、図解。

C#でござる。
画面キャプチャに全部含まれているので、コードは割愛。

一般に公開されているソフトウェア使えば済む話だけど、自分で実装できたほうがいいものは結構ある。
できれば、クラスライブラリも使わず、完全フルスクラッチのほうが望ましいのだけど、長いものには巻かれてもいい。

POP3の危険性を認識している人は少ないのか、ほとんどがデフォルトでPOP3で、APOPですらない設定だったりする。
ユーザ名とパスワードを平文で送るのは、個人情報ダダ漏れが嫌な現代人にあるまじき放置状態と言っても良いのではないだろうかと。
デフォSSL＆可能ならAPOPにしたらいかがなものか。
あぁ、いかがなものか。
＃サーバ側が対応してないんだから、仕方ない。

で、無料のメールサーバでPOP3 over SSL対応にhotmailが該当するということを知り、ちょいと試してみることに。
＃「ちょい」で済む話じゃなかったりもする。

Office2010の64bit版をインストールしたので、64bit版ExcelでAddin for Excel 95-2007の動作を確認してみたところ、動かない。
動かないというか、アドインの追加で躓く。

原因は、

• 32bitだから
• 署名がないから
• その他

など考えられる。

このサイトはIIS7.5でホストしているので、XBAPのホストもできる。
XBAPってのは、簡単に言うと、WPFなWindowsアプリをブラウザで使っちゃおうってもの。

手っ取り早くつくってみた。
http://lab.fne.jp/hello.net4.0/xbap/
HTMLでブリンクすればいいような気も。
VS2010でつくったので、.NET Frameworkは4.0を必要とする、たぶん。

XBAPなかなかいいんだけど、あまり浸透してないんだよね。
クロスプラットフォームなSilverlightの方が浸透してるみたい。

Addin for Excel 95-2007 Basic EditionのVer0.7.1を公開した。

せっかくコンピュータ使ってんだから、有効桁なんてケチなこと言わず、どーんと数百～数万桁使っちゃえ的に加減乗除＋開根＋比較までできるってことは、100円電卓レベルの操作を多桁で実現できちゃったってことだ。
開根には時間掛るけど、100円電卓では得られない精度。
互換関数使えば互換性と処理速度と精度のいいとこ取り。

是非使ってみて欲しい。

わざわざ、RDPで接続して、SQL Server Management Studioを起動して、テーブル参照して、編集して、とやるのが面倒なのと、そのまま外部からやろうとすると非常にリスキーなので、そういうページを1つつくっちゃいました。

つくっちゃったんですが、URLは晒さない。
晒しても問題ないように認証付けたんですが、晒さない。

HyperLong系の加減乗除、開根、大小比較まで出来るようになっている0.7.1もまだ公開されてませんが、次回(0.7.2)の予告。

絶対値取得関数。
開根関数には必須。
実は、文字列として、たとえ負の数だろうが、- を先頭に付けるだけで、符号反転できたりする仕様なので、条件判定して、- を文字列連結しちゃえばいいんだけど、それだと32767文字超えちゃう可能性があるので、関数として用意しておいたほうがいい。

円周率定数関数。
定数なので、計算処理無しで返したいところ。
これまで、「そんなに長く円周率算出して実際使うのは10ケタも無いじゃん」って言われ続けてきた円周率をこれでもかというくらいに長く利用できるようになったので、なが～く出せるように。
ついでにSQRTPI関数っぽいものも。

あとは提供方法考え中なのが、返却の文字列長指定。
あると、結構便利な予感。

他には、SUM系の関数をと考えてるんだけど、今のところ未定。

ま、こんなところかな。
徐々に追加すれば良い。

Excelの多桁開根関数を追加したやつ、登録しました。

Addin for Excel 95-2007 Basic Edition

多分、来週には公開されるんじゃないかな。

サポートはこちら。

今回のバージョンは、0.7.1になりまする。

是非、ご利用くださいな。

自動化で対応できれば一番楽だろうということで、とりあえず、創った。

これまでの傾向として、リセット後24時間以内に無応答化するのは稀なので、1日に1回午前中にリセットするように、サービスを構成。

内部処理としては、1時間タイマーで指定の時間になったらリセットリクエストを飛ばす、それだけ。
＃つまり、○○時台でリセットすることになる。

サービスだったり、マネージコードだったりしてちゃんと動くかちょっぴり不安だけど、動かなくても、悪影響は無いはず。

リセットできるかどうかは、明日、確認。

これで運用できるなら外部からアクセスできるところに内部の制御を晒すような危険を冒す必要もない。

今度はPLANEXな。

これも問い合わせしたけど、再現性がイマイチ良くわからないので、だましだまし使っているんだけど、ときどき、SSIDが見つからなくなる。

クライアントの問題ではなく、クライアントに無関係に、接続中、切断中関係なく起こる。

戸惑いだけでは先に進まない。

HLCOMP関数は-1,0,1を返すため、整数型を使っていた。
至極当然だろう。

だが、ここに落とし穴があった。

多桁数比較関数として、HLCOMPを用意してみたものの、Excel95のIF関数内で条件に使うと、なぜか#NUM!エラーになる。

HLCOMPを別セルで計算して、その値を条件に使えば問題ないし、IF関数の真偽値としてエラーを返す可能性の無いリテラルを指定すれば、これもエラーにならない。

HLCOMPの仕様は、引数2つをとり、＞なら1、＝なら0、＜なら-1を返すというもの。
確かに、#NUM!エラーを返すパスもあるんだけど・・・
同様に、#NUM!を返す可能性のあるSQRT関数を条件に使う場合、そんな問題発生しないんだよなぁ。

で、Excel2003だと、再現しない。
＃95～2003のどのバージョンまで再現するかは未確認(やらなきゃまずいかなぁ)。
原因はExcel95にあると思うのだけど・・・

ExcelでSQRTに負数を与えると、#NUM!エラーとなるわけだが、多桁の現実装は絶対値に対して平方根を計算している。

互換関数もよさげにできたっぽい評価結果が得られてるんだけど、そろそろ公開をと考えているのだが、さて。

今回比較関数を用意したので、負数を事前に排除することもできるわけだし、#NUM!エラーを返すようにするかな。

追加で絶対値を返す関数を用意する意味も出てくるし。

コメントを暗号化して送りたいときに使うと良いと思う程度だけど、一応、SSL(HTTPS)に切り替えるためのリンクを上部に作成。

これもIISでモジュールフィルタ使って書き換えている。
サイト内リンクをhttpsに書き換える処理も入れてある。
＃トラックバックURLも書き換えちゃってるけど・・・

オレオレ証明書(ワイルドカード)なので、証明書エラーとか出まくるけど、暗号化は可能。
エラーを無くすには、ルート証明書をインストールすればいいんだけどね。
＃ルート証明書、公開してもいいと思うんだけど、躊躇中。
それこそ、気になったらコメント下さい。
＃サポートサイトでもSSL効くんだけど、オレオレだからリンク自粛。

証明書の有効期限もあるので、そのうちオレオレ認証局設置からオレオレワイルドカードSSL証明書取得やIISへのインストールまでの自己流手順書を作成しようかと思っている(予定)。

このサイトのカウンタは、IIS用マネージモジュールを使用している。
IHttpModuleを実装し、text/htmlで200レスポンスの場合だけカウンタログに入れて、クローラーかどうかを判断しつつ、カウンタログを書きだしているのは既出のとおり。

でも、どう考えてもクローラーっぽいアクセスログがあるんだけど、排除する判断が難しい。
判断が難しいのは、情報不足の気がしている。

そこで、リクエストメソッドとその他ヘッダも一緒に書きだせるように、データベーステーブルを拡張。
併せてモジュールも変更。
表示も少し変えて、過去24時間内のアクセスも併記できるようにした。

しばらくまた様子を見ることにする。

Excelで多桁計算。
現在公開されているのは、四則演算まで。

開根実装の目途はついた(と思っている)。
遅いけど。

遅さをカバーする意味も含めて、全Excelで同じ桁数を返す互換関数を用意しようかと思っている。
255文字分で表現可能な値を返すってやつ。

返却を短くできる分、処理が軽くなるので、開根の遅さをある程度カバーできる。

入力(引数)文字数はExcelバージョン依存で出力(解)文字数は互換となる予定。

乗算の打ち切り方について、まだよくわかってないので、入力依存。
除算・開根の打ち切りはできる。
加算・減算の打ち切りはしない。

で、提供予定としておく。

ついでに、比較演算関数も加えたいなぁと考えている。

そして、あともう2つほど関数を考えているのだけど・・・

高速化ってのは、処理を軽量化する方向でやるのと、そうでない場合があると俺は思う。

前者はたとえば、条件分岐を減らしたり、計算回数を減らしたり、より簡易なコードにすることが多いと思う。
＃Simple is Bestってやつ。

今回(今日)の大幅な高速化は後者。

1位にいくつか数を加えた場合の桁上がりを処理するのは、1位値が10を超える場合のみでいいという、いわゆる打ち切り条件を加えた。
＃条件によっては効果が無いけれど、今回はやる前から処理分岐率50%で、その分の処理を打ち切れるという、かなの効果を見込んでいた。

桁上がり処理は、全桁を確実にループするため、条件によってやらなくていいというのは、メリットだろうと思ったわけだ。

おまけに、その処理は何度も通るため、結果、条件判断に掛るコストよりも大幅な処理速度改善につながったわけだ。

にしても、びっくりするのは、これで限界と思ってた60秒から30秒台まで高速化できたことよりも、処理のほぼ半分も無駄なことやってたこと。

さすがに俺もこれには笑うしかない。

＃その後、もう少し手を入れて、30秒切るところまできました。

環境は、Core2Duo L7500(1.6GHz)のまま。

開根時に多用してる減算をどうにかしたら速くなるんじゃないかということで、加算減算を見直し。

今までは、加算では各桁加算ループと桁上がり処理ループに分けていたんだけど、ループを1回で済ませられるように変更。

減算も、桁下ろしループ、各桁減算ループ、桁上がりループの3ループを1ループ化。

これだけで、60秒を切りそうな勢いで高速化できた。
他にもいろいろと手を入れているものの、減算の変更は一番効いたと思う。

もう少し見直して、余裕で1分切りを目指したいと思う。

＃でも、実用とは言い難いので、別の策を考え中。

プロセス情報を操作する時例外出る場合があるようなので抑制。
ダウンロード

＃そうそう、しきい値10000ってのは結構妥当っぽい(http://technet.microsoft.com/ja-jp/windows/ee787049.aspx)のでそのまま。
＃＃曰く、「特定の時点で 1 万個を超えるハンドルを開いているプロセスは設計がよくないか、ハンドル リークが発生しているかのいずれかである～」だそうな。

当然、まだ回答は無い。

「いましばらく」という言葉は使用者や受け手、場面により、その示すであろう期間が異なる曖昧な言葉であるため、回答で使用すべきじゃないよな。

「○日までに再度ご連絡致します」って書けば、その日までは待とうと思うじゃん。

だめだよ、あの会社。

開根筆算では2桁ずつ下ろしてくる処理がある。
これを省略してみたところ、少し速くなって2や3の開根で80秒を切れるようになった。

これが限界だと思っても、諦めなければ、その先がある。
でも、多分、今のままで1分切るのは難しい。

※A3には =HLMLT(A2,A2) で検算。

多桁開根確認中、数バイトのnewでヒープ破壊の例外発生。

何が原因かは目下不明。

Free Heap block xxxxxxxx modified at yyyyyyyy after it was freed
と言われるので、yyyyyyyyアドレスを見ると、確かに周りと違う値。

参照変数は、別スコープに移動したし・・・飛び地を不用意に書き換える処理は入っていないはず。

OS再起動して再現するようなら調査続行か。

メモリ使用量を減らしたり、演算回数を減らしたりして、処理速度アップを狙ってはいるのだけれど、どうも、方法にも限界はあるし、そもそものクラスのメモリ使用方法自体にもボトルネックがあって、どうにも速くならん。

2の開根で32767桁(文字(整数部や小数点等を含む))、二乗誤差は最小位+1なのはいままで同様。
二乗検算まで含めると結果表示まで、約2分。

そう、何とか2分を切るくらいまでは高速化(とは言えないが)できた。
開根のみであれば、なんとか90秒を切れるようにはなった。
＃非常にうれしいのだが、全く実用的ではない。

しかし、これ以上高速化しても、恐らく1分の壁すら到達できないだろう。

なんにしても、クラスの基本部分を弄るしかないだろうと思っている。
開根くらいでもたついていては、開立や三角関数なんてどんなに時間が掛ることか知れたもんじゃない。

激しく表示制御をすると落ちるのは、タスクバー表示制御で何らかの問題が発生するからのようだということで、少し修正。

で、ドライバ側にも問題があるのか知らんけど、SEG CLIPの終了に失敗する場合がある。
そのときは、処理を中断する。
＃本当にどうにかしろっつうの＞IO。

で、そうなっちまった時にはデバイスを抜いて再挿入すれば、復活するっぽい。
手作業ウザし。

合法ダウンロードはこちらから。
書き忘れてたけど動作確認はXPのみ。
要.NET Framework 3.5。

記事へのIOデータからのアクセスを確認！
その後の、リファラ無しの石川県(*.infoweb.ne.jp)からのアクセスも、無関係ではないだろうと思いつつ。

既出の対策ツール、ウィンドウをそのまま出してるのもどうかと思ったので、タスクトレイに入れてみた。
単なる監視だけでタスクバーを圧迫するのもどうかと思ったし。

ダウンロードしたけりゃすればいいじゃない！

タスクトレイのアイコンをクリックするとウィンドウ表示・非表示されるはず。
＃初期値の設定が難しいので、最初のクリックがノーカウントになるようですが。
＃あと、あまり激しくクリックすると、落ちるようなので、注意。

終了はウィンドウを[Ｘ]で終了するか、タスクトレイアイコンを右クリックして「終了」。

最小化で隠す処理は未実装。

そんなことより、しきい値を変更できるようにしたほうがいいかもね。
＃予約録画時抑制もできればいいんだけど。

公開されたようです。

Addin for Excel 95-2007 Basic Edition ダウンロードページ

Addin for Excel 95-2007 Free Edition ダウンロードページ

不具合修正されてますので、是非。

ハンドルリークを仕様とか言っちゃうダメなサポートのある会社の続き。
＃もう、伏せない。

サポートがダメだから、個人的に何とかしないとならん。
「ハンドルリークは仕様だから適宜再起動してください」では、何のサポートにもなっていないことを、IOデータは自覚すべき。
＃ま、自覚できてりゃもう少しマシな回答するんだろうけどな。

と、言ってもはじまらん。

とりあえず、再起動しないわけにはいかない。
しかし、いちいち、ハンドルカウントを確認して、再起動するのは面倒この上ない。

↑2の平方根です。

多桁開根を実装しました。

しかし、喜べないのです。

ずっと考えていたけど、無いんですよね、必要な場面って。

とりあえず修正終わりました。

今回のメインは多桁計算だったのに・・・

ま、いいか。
不具合潰せたんだし。

とりあえず、何かあったらサポートページにてコメントください(と、ここにも書いておこう)。

昨日からの続き。
そして、構造体にコンストラクタを用意したところ、構造体を取り込んだ共用体でコンパイルエラーが発生する罠。

曰く、「共用体メンバに既定のコンストラクタを持たせることはできません」だそうな。

じゃぁ、既存構造体から新たに継承したクラスを作って・・・とかやると大手術になってしまうので、仕方ないからそれは次期バージョンにて考慮。

今回は、newでサーチしてnewや変数宣言など、構造体メモリを確保している箇所で片っ端から初期化してやろうと思う次第。
＃必要な個所だけ。

他に、実はnewしているのは決まってExcelに返すデータをエクスポートする箇所なので、それらを一か所に集約してやろうかと。

これで今回の原因は撲滅できるはず。

実にえらいミスです。

概要は、こちら。

それにしてもtry～catchが効かないってのは痛い。

catchできてれば、狭めていくことで分かるのに。
＃いや、catchでスタックトレースすれば一発か？

今回は、トレースを入れて、どこまで出続けるかを追っていくという超アナログな方法を採用したため、非常に時間が掛った。

いや、言い訳に過ぎない。

100%確実ではないけれども、再現させる方法だけは見つけたので。

Windows 7を起動して、評価に使用したExcel95ブックをExcel2007で開くだけ。

すると、再計算50%を過ぎたところあたりでExcelがエラー(動作を停止)を起こす。

ここら辺が微妙なんだけど、50%のときもあれば、そうでない場合もあり。

2回目には起こらないので、都度OS再起動が必要。

ところが、通常、プロセスの異常時には、「デバッグしますか？」のダイアログが出るのだけれど、このExcel2007は自動修復するのか、デバッガでアタッチするとプロセスが終了してしまう。

困ったことナリ。

デバッグモードでは再現したことがないので、あたりをつけようにも・・・

とりあえず全エクスポート関数の大部分をtry～catchで囲んでみたのだけれども、状況は好転せず。

なんだか変。

Windows7やVistaで動作確認しようと、アドインを設定して、気を良くしてHLDIV(10,3)とかやるとExcel停止・・・
なんでやねん！

デバッグしようとしても痕跡なし。

じゃぁとVS2008からデバッグ実行すると、全く落ちず。
そうこうしてるうちにExcel停止が再現しなくなる。

なんだこりゃ？

重要。

でも、検算するのがとても大変なのは多桁演算の宿命。
だから、大体正しければいい、というものでもない。

除算の評価結果を見ていて、変なことに気付いた。

検算をするとどうもおかしい。

筆算してみても、自分が間違えてる可能性もある。

Windows付属の電卓はかなりの桁数計算できるが、それと比較すると、やはりどうも多桁計算側がおかしいようだ。

使用メモリ量と演算回数を削減したんだけど、Excel95落ちるようになっちゃいました・・・
多分、どこかで例外発生しているってことなんだろうけど。
おっかしいなぁ・・・って、よく見たら凡ミス。

直したら動くようにはなったけど、やはり重い。
＃加算・減算だけでなく、内部で加算処理をしている乗算も重い場合がある。

リソース絡みだと思いたい。
Excel95のリソース制約は一番厳しいので、Excel95で動けばExcel2003でも動く。
＃Excel2007からは別物だけど。

なんか、すごく重い。

今のところ原因不明。

Excel95で桁数多い場合に発生中。

Excel2003では発生しないようだした。

Excel95では同じ計算でも発生するときと、しないときがあるようだ。

数としてはあってもいいんだけど、-0が返るパターンがあったので、符号補正を入れて修正。

別に、1文字2文字で困る文字数じゃないから放置してもいいんだけど、0と-0が違うかっていうと十進数演算の中では同じなので、だったら符号不要ということで。

多桁計算にも一応、四捨五入丸め処理を入れている。
というのは既出だが、Excelに文字数制限があるため。
つまり、表現上、数に制限が生まれるわけで、普通の有効桁と同じ扱いと思ってくれればいい。
除算した場合、循環小数なんかはその限界まで延びるのだけれど、そこで四捨五入が必要になる。
掛け算でも桁が多ければ丸める必要がある。

多分、浮動小数点絡みだと思うんだけど、微妙に異なるらしい。

それも、Excelのバージョンによって、微妙さも違うときた。

これにより、計算結果を評価するのがとても面倒なんですが・・・

どうやって評価しようかと、そんなところで躓く。

因みに、やってびっくりしたのが、=1.5*1.3-1.95って計算、Excel95でやると、2.22E-16になるんだぜ・・・。

どうしてやろうか。
多桁乗算を使って、=VALUE(HLMLT(1.5,1.3))-1.95を計算すると、Excel95でも、0が返るんだけどな。

C/C++(非.NET)でHTTPSクライアントをつくるとき、OpenSSL使わなきゃできないと思い込んでいたんだけど、ことWindowsに関して言えば、OpenSSLをインストールしなくても、IEとかで普通にHTTPSアクセス出来てるので、単なる思い込みだった。

マルチプラットホーム対応するならば別だけど、Windows専用ならば、MSXMLを使えばできるっぽい。

Windows2000以降になるようだが、IServerXMLHTTPRequestなオブジェクトを使うと、HTTPSコンテンツを取得できたので、これは素敵過ぎる。

MSXMLを使う利点は、MSXMLに不具合があっても、WindowsUpdate(MicrosoftUpdate)で対応できる点。
＃つまり、MSXMLを利用するアプリケーション開発側の対応は不要ということ。

一応、オレオレエンタープライズなオレオレワイルド証明書を使ってるこのブログサイト(https://blog.fne.jp)のコンテンツも取得できたので、こいつは使える。
＃エンタープライズルート証明書のインストールは必要です(多分)。

乗算と除算、ずっと考えていた方法でできそうだったので、気合い入れて実装しちゃいました。

まだ評価していないけれど。
加算・減算・乗算・除算の4関数を軽く動作確認。
処理速度にはちょっと満足できないけれど、処理結果にはほぼ満足。

小数点以下数万桁の数に意味はあるのかと問われれば、あると答える根拠を持ち合わせているわけでは無い。
けれど、逆に本当に無視していい数なんてあってよいものかと考えたら、小数点以下数万桁でも無視するのは忍びない。
だから、できるだけ多くの桁を利用したい、そのための多桁計算関数。
そして、リソースを喰い尽くす罠。

さて、どのEditionに組み込んで、バージョンをいくつにするか、決めなきゃな。
とりあえず、今回はBasicEdition(有料版)かなぁ。

因みに、まだまだ追加予定の関数はありますよ。

E(10のn乗)も処理できるようになったので、なかなか使えそうなものになった。

A2セルには「=-1.23456789012345E-21+123」と、普通に計算してみた。
当たり前だが、有効桁(Excelの場合15桁らしい)丸めで無視される大きさなので、A2セルの結果は123。

A1セルのHLADD(自作関数)ではちゃんと計算できている。
HLADDなら、小数点や符号を含みながらも、3万桁超(Excel2003以前は255桁)まで対応している。
因みに、E±9999まで入力可能にしたので、本来は文字列で指定した方がよいのだが。

残念なのは、まだ加算と減算しかできないってところか。

Excel関数にすると気になっちゃうのがEの処理。

文字列引数を受け取る関数にしたんだけど、ある程度の桁数の数値を引数に指定すると、E付きの文字列になっちゃう。

できればEを有効に読み取ってあげたいところ。

もうちょっと時間を掛けよう。

ので、少しうれしい。

何でもそうだけど、実際にやろうとすると、意外に手間取るよね～。

一応、走査回数は標準2回(最悪n^2オーダーになる条件が含まれるけど)でパースできるようにした。
＃本当は1回でやるべき。

符号は数値前のものだけ。
でも複数連続符号も認識できるように。

数値中のカンマや空白の読み飛ばし機能とか、数値前後の文字列を無視する機能とか、そういうのも実装。

ってことくらいは知ってる。
MCDBAも持ってるし。

ただ、どの情報の格納にデータベースを使えばよいかの判断について、皆目不明瞭だった。

情報を格納するのなら、ファイルでいい。
＃広義ではファイルシステムもデータベースだけど。

テキストファイルで良いのなら、その方が分かりやすい。
typeコマンドやメモ帳など、中身を見る手段はいくらでもある。
多量の情報を処理することも、一度プログラムを組んでしまえばどうということはない。

いくらISV試験を受けても、こういう実に基本的な事柄ってやつは、出てこないし、解決されない。

データベースというものがあって、どういうものかも分かる。
確かに情報を格納したり参照するといった処理をするのには便利な機能がいっぱいだ。

でも、今ここにある情報をデータベースに格納する意味はあるのかと。

何が起きてるか分からんけど、どうやら、IISワーカープロセスが無応答になるらしい。

ワーカープロセス数を増やせば、ある程度抑制できるが、・・・

やはり、: Stream, IHttpModuleってのがマズイのかも。
と、思って、分離したんだけど、やはりダメ。

いや、発覚したからといってすぐに改修するわけではないが。

「/」へアクセスすると、何らかの既定ドキュメントを返すのはWWWサーバなら大抵持っている機能だけれど、IIS7.5ではどうやらモジュールがこの役割をしている・・・らしい。
＃そんな名前のモジュールが見えるよね。

で、これ、リダイレクトをさせるのではなく、また、ハンドラのように、自分で何か取ってくるわけでもなく、モジュール内でリクエストを繰り返しているっぽいんですよ。

詳しく調査したわけじゃないから、違うかも知れないけど。

ってか、もう少し早く気付けよってことで。

モジュールで受け取れるリクエスト情報にはクライアントのIPアドレスとそのホスト名があるんだけど、これ通常どちらも同じ情報が含まれている、というか、名前解決のコスト削減ってことなんだけどね。

だから、IPアドレスからホスト名を引っ張ってくる処理を入れてたわけ。

これが遅かった原因。

ログ書きをスレッド化したんだけど、そのスレッドに渡す変数(クラス)オブジェクトを構築する際にDNS引いてたから遅かった。

ログ書きスレッド内でDNS参照を行うよう変更したら、嘘のように軽くなった。
マジで、嘘みたいに軽い。

実際、カウント数集計と、レコード書き込みはどっちが先に行われているかは分からないけれど、あまり気にすることはない。

これなら、twitterの内容埋め込みもできそうな感じ・・・
＃twitter内容を定期的にローカルへ蓄えておく必要がありそうですが。

レスポンスのContent-Typeとステータスから条件判断してから、DBへのLog書きをThreadPoolに委託、フィルタチェイン構成となるよう、モジュールイベントを構成したんだけど、やはり遅い。
＃少しは改善したような気がしなくもないけれど。

さらにDB処理を削っても遅いため、恐らくDB処理は無関係だと思われる。

ならば、残りのフィルタStream自体が問題と思われる。

思われ・・・る・・・

このブログにカウンタを付けてみようかと思っていた。

普通はカウンタって、たとえば、imgタグで動的に画像を返すとか、JavaScript使ったりすると思うんだけど、それは、再リクエストを期待しないと無効なわけだし、レスポンスを返す時点でカウンタ値は決まっているわけで、いろいろと無駄があると常々思っていた。

たとえ、レスポンス一発であっても、CGI使うとか、サーバサイドインクルードとか、静的コンテンツには不向きだったりする。

前記事のとおり、IISならフィルタでレスポンス書き換えできるので、これでやってみようと思ったわけ。

.NET Frameworkでは、IHttpModuleを実装すると、IISを通過するリクエストやレスポンスを操作できるモジュールを作成できます。

たとえば、リクエストに合わせてレスポンス内容を変化させるなんてことも・・・
そう、いつも通り簡単にできるだろうと思っていました。

HttpResponse.OutputStreamの中にはレスポンスコンテンツが蓄えられるはずです。
これを読み取って、書き換えてしまえばよい、そう思っていました・・・

Session Memo

クッキーレスセッションを使ってみた。
WEBサーバのセッション内に一時的に記憶するメモ。
クッキーレスで、モバイル対応にした(つもり)なので、ブラウザを跨いで、各種ケータイでも使えるはず。

たとえば、

• ちょっと思いついたことをケータイでメモ→PCに移動してメモをコピペして清書
• PCでお買い得情報をさくっとメモして、ケータイでメモを見ながらお買いもの
• 2台のケータイでミニチャット代わりに使ってみる

なんてことができたりする(には少し機能が足りてないかも)。

一応QRコードを出してはいる(が、内容の有効性については未確認)。
＃PNG固定(Powered by Google API)なので、PNG非対応機の場合は見えないかも。

暗号化や認証は無いので、URLバレしたらヤバい。
けれど、セッション潰す機能を付けたので、ケータイで画面メモとかしたら消しちゃえば安心。

最後のアクセスから60分、または、サーバメンテナンス等で消えます。

よくある話。

VC++のWin32(非MFC)のウィンドウアプリケーションプロジェクトのひな型では、クラス化されてないコードでだらだら書かれているので、クラス化したいなぁと思うわけだ。

思うことは自由なんだけど、WndProcコールバックがクラスメンバだからということで、いろいろ困難が付きまとう。

Azureは限りなく透明に近いブルーって感じの色らしいです。
クラウド(雲)を浮かべる空の色ってことかも。

Vector様のご厚意でAzureの無料セミナー(ハンズオン)をうけるため、はるばる静岡から日帰り(はるばるじゃねぇ)。

当初、Windows Azureって、機能特化したOSを販売するのかと思ってた。
使った分だけお支払いの仕組みを持つサービスってことらしい。

じゃ、他のウェブアプリホスティングサービスとどこが違うのか、という点については、まだよくわからないけれど、いろんな部分で、Hyper-Vっぽい仮想化技術が使われているから、ほぼノンストップだったりとか、柔軟なスケーラビリティとかの恩恵を受けることができるらしい。
あと、アプリホスティングの場合、標準のままだと、手元で作ったアプリを動かすことができなかったりする場合があるのだけれど、Azureの場合は、VisualStudioでAzure専用にアプリ開発ができるわけで、開発から実稼働までの一貫性が確保できる点は大きいような気がした。

高速化は後回し。
一応、Sleep(0)とかSystem.Windows.Forms.Application.DoEvents()とか入れてるんですけど。

マウスポインタを取得しようと思ったんです。

System.Windows.Forms.Cursor.Currentを使えばいいってことらしいんですが、これ、バックラウンドで取得すると砂時計になっちゃうし、じゃぁUIスレッドだったらいいかというと、自分の領域外では正しく取得できないという罠。

でも、何とか、VGAダミーアダプタを利用した仮想セカンダリ画面で、各種操作が可能なことを確認。
＃細かい文字を読み取るのは厳しいものがありますが・・・
2048×1536,32bitでも、XGA画面上でなんとか操作できます。

あとは、セカンダリ画面上で全て操作できるように、タスクバーもどきでも用意すれば・・・と思ったりするんだけど、もっと高速軽量化しないと無理か。

ローカルでRDPとかを使う方法って無いかしら・・・

単純な仮想スクリーンでいいじゃんってのは無し。

P.S. *.rdpで画面圧縮する呪文で満足しちゃったので、これ終了。ソース欲しい？

Formでつくって、とても遅い気がしたので、WPFにしたいと思ったところからはじまる。

いろんなところを検索して、キャプチャしたビットマップデータを表示するところまではできた。
しかし、リアルタイムで更新するにはタイマーか・・・ツールボックスに無い。

Thread.Timerを使うと、Imageへビットマップを設定するところで、違うスレッドが所有してるから変更できないとかの例外が発生する。

で、探して、見つけた↓。
WPF のスレッド: Dispatcher を使用して応答性の高いアプリケーションを構築する

そうそう、BackgroundWorker使えるんだよ。

できましたのでアップしておきましょう。

相変わらずWindows7でリサイズやXPモードの問題はありますが。

20091217_TwitbarSetup.msi

入力方向のみですが、テキストのDrag&Dropに対応ですよ。

とりあえず、できたっぽい。
favicon.icoのマネージハンドラ。

できたっぽいんだけどね。

時間(JST)を埋め込むようにしてみたんだ。
アクセスする都度変わるとおもろいと思ってたんだけど・・・

Expires指定してもfavicon.icoはキャッシュ更新されないのですよ。
なんででござろうか。

キャッシュから削除してアクセスすれば取得してくれるので、キャッシュチェックしていないわけじゃなさそうなんですが。

IE8だけかな？

ま、動くハンドラができたことと、favicon.icoが無くてログに404を記録されることが無くなったことは良いかな。

所詮、機能を実現すればいいってことになるんだけど。

コードを書く際、どこからはじめるか、どういう順番で記述していくか、とか、ちょっとしたことでずいぶんと楽ができるのではないかという、希望的観測とか、実際に知ってるよとか、そういうのはあると思う。

でも、そういうのって、文章に出来る部分と、勘でやってる部分とがあって、どうにも。

コードを複数人で書くとかいうことはペアプログラミングとかやらない限り、滅多にないはず。
出来たコードを複数人でレビューしたとしても、途中経過は分からない。

Hobbyカテゴリに入れちゃってるのはいかがなものか。

なんか、メールでこんなの来てた。

ボリュームライセンスでもOKなのか、無料なのか、また、契約更新時の料金体系も不安ではありますが。

体系的には分かりやすくなったのではないかと。
＃分業化はいいけれど、それでツール選択をしないといけないのはいかがなものかと思っておりましたよ。
＃境界的作業もあるわけですが、現体系でTeam System2本買うとSuiteと同額ってのも・・・。

でも、これで、UMLツールは確保できるかなぁ、と。

☆ボタン(右から3つ目)を付けてみました。

ポチッとサイズ変更できます。

FormBorderStyleをNone設定しておかないと、フォームサイズ最小値が正しく反映されにくい模様、というのは覚書。

で、肝心のWindows 7での動作では、やはりリサイズが有効に働かないので、☆ボタン(右から3つ目)を押すようにとのこと。

20091204_TwitbarSetup.msi

因みに、XPモードのRemoteAppだと、全画面サイズの取得ができないらしく・・・

Postボタンがキレ気味なので修正を。

20091203_TwitbarSetup.msi

レイアウト系パネルを重ねてるんだけど、どこかで自動リサイズが無効になってるとデザインモードのサイズが適用される部分が出てくるらしい・・・よくわからんけど。

そうでした。

いくら加算・減算ができるといっても、返却可能な桁数には制限があるのです。

桁数が足りないからエラーにしちゃうのは、まずいわけで、少なくとも、整数部が制限に収まっているのであれば、値を返すべきでしょう。

であれば、特定の桁位置の値で四捨五入しなければならないのですが・・・これがちょっと難しい。

四捨五入処理自体はそれほどのことはないのだけれども、返却文字列長を考えるとね。

既出のアプバーをアップしてみる。

20091201_TwitbarSetup.msi

動作には、.NET Framework 2.0が必要。
64bitOS未確認。

正常にPOSTできると、IDとパスワードを保存する。
＃保存するけど、暗号化はしない。

正式なAPIを使用しているかは不明。

サポートサイトでのサポートはなし。

何かあればコメントで。

C++でフォームアプリつくってたら、デザイナの挙動がおかしくなって、しまいにはデザイナエラー。

仕方ないので、C#。

でも、結果としてC#の方が楽だった。

TechNet Plus Directからもキーを落としてきたので、まとめて見れたらうれしいかと思い、試行錯誤を再び。

なんとなく、前と挙動が違う感があるのだけど、MSXML更新されてたような気がするので、そのせいかも知れないとか思いつつ。

件のXMLコードはMSDNプロダクトキー変換表示用XSLT/XMLコードに更新。

見るだけなら問題なし、かな？

html化が必要なら、msxslを使えばよい(はず)。

http://fne.cocolog-nifty.com/blog/2009/10/post-7c67.html

で書いたコード、確かにコマンドラインコンパイルでは問題なく動いたのに、プロジェクトに組み込んだら、#defineの中身を解釈してくれないばかりか、コンパイルエラー出まくる。

仕方ないので、ベタ書きした。

Office2010βの32bit版を動かしてみた。

なんか変なこと起こるかなと期待半分だったけど、アドインは問題無く動作。

Excel2007からの文字列長(32767文字)制限もそのままらしいので、内部仕様も全く問題なし。

さて、64bitは、どうなのか。
32bit混在で動くわけがないから、Excel自体が32bitであると64bitの恩恵を受けられないってことは64bitネイティブって可能性が。
アドイン呼び出し部だけ32bit化されてる可能性はあるけど、それだとオーバーヘッドでかいだろうし。
件の構造体のアラインメントは64bitだと変わりそうな感じがしてて・・・

あぁ、恐ろしい。＜すぐにやってみれよ、俺。

パース方式考えなきゃな。
カンマくらいは大目に見てあげようとか考えつつ、本当に数万桁の計算ができるかやってみようかと。

やりすぎたか。

ロジック的には整数部小数部それぞれで2^32-1桁の計算に対応したはずなので3万桁なんて屁でもないんだけど、それを見るのは厄介。

とりあえず内部処理だけだが、加算・減算ができるようになった。

処理速度はイマイチだけど、負数も小数も含めて、600桁計算しても大丈夫になった。

結果の一例を載せておこう

忘れないように。

constメンバ関数のconst意味は、そのconstメンバ関数を実行する際に所有するオブジェクトの内容を変更しないという意味だが、それ故、constオブジェクトが実行できるのはconstメンバ関数に限られるということ。

つまり、

void Hoge::Func(const Hoge &obj)
{
    if( obj.IsOK() )  // call Hoge::IsOK()
    {
         Hoge.m = obj.m;
    }
}

のときの、Hoge::IsOK()はconstで定義されていなければならないということ。
この場合、bool Hoge::IsOK() const;のような定義が必要。
＃たとえ、Hoge::IsOK()の中で変更をして無いとしても、constの省略はコンパイラエラーを招く。

うっかり忘れて多量のエラーを吐かれると、イヤなのでメモ。

シェアウェア登録したのだけれど、使ってもらえてないのか、まだ売り上げが無いので、やはり追加関数で対応していきたい。

Excelで計算できる数値は10の309乗程度までの浮動小数点範囲なので、ここはひとつ、3万桁目指して計算できたら、何かうれしいことが起こることを期待しつつ実装中。
＃3万桁使えるのはExcel2007以降だけど。

なにやら超胡散臭い方法を多々取り入れつつできたのだけれど、なぜ例外が発生していたのか、さっぱりわからない。

try catchでも捉えきれないってのは、tryブロック外か、catchブロック内で例外になっているのかも知れないんだけど、それでも超想定外で、さっぱり。

でも、とりあえず、動くようになったから、一応信じておくとするか。

今のところ、高機能なものはいらない。
投稿さえできれば、面倒は極端に減る。

ならばというわけで、シンプルなものをつくってみた。

リンクは上部にあるサポートサイトで。

これで、公開ソフトウェアのサポートも可能になる。

不具合情報の公開とかもできる・・・けど、まだコンテンツを用意できてない・・・

このサイトも実はDDNSを利用している。

MyDNSというDDNSを利用させてもらっているのだが、他のDDNSサイト同様、定期的にアドレス通知を送る必要がある。
＃というか、それでDNS情報を更新できるからDynamicDNSなわけだが。

MSDNサブスクライバーダウンロードとかの・・・: 気晴日記、重複を削ればもっとわかりやすい: 気晴日記に書いたXSLTを改版したので、載せておこうと思う。

改良点としては、仮番号が付くようになったことと、色を付けて少し見易さを意識してみたことが挙げられる。

コードはウェブページ化(こちら)。

直したら都度アップ。