coo MEMO

- Microsoft Windows Server System : ポート番号一覧 -

この Excel のシートは、マイクロソフトの製品・サービスプログラムが利用しているネットワークのポート番号を参照することができます。Windows Server を採用したシステムにおける利用状況などを一覧で確認することができます。

[link...]

φ(．．)メモメモ

何年も前から客先に納入しているプログラムで、先日客先から「WindowsXP(SP2)で動かないよ」とのお叱りを受け、調べてみたら、該当プログラムが対応しているDAOのバージョンが古すぎるためでした。
WindowsXPでは（Windows2000でも）、標準でDAO3.6(+Jet4.0)が入っているのですが、該当プログラムは何年も前に作った物なのでDAO3.5にしか対応していなく、それが動作しない原因らしく、DAO3.6に対応する事になりました。

いまどきDAOですか？という感じだけど、いちおうφ(．．)メモメモ。

■ MFC DAO クラスの場合 ■
CDaoXxxxxxという、MFC DAOクラスを使っている場合の修正は簡単で、「共有DLLでMFCを利用」なプロジェクトなら、
AfxGetModuleState()->m_dwVersion = 0x0601;
とするだけでＯＫらしい。

「MFCのスタティックライブラリを使用」の場合は、ちょっと面倒で、MFCのソースを書き換えないといけないらしい。

これは、VisualC++6.0(SP3以降が必要)の話なので、最近の.NETなら、何もしなくても再コンパイルすれば動くかなぁ、と推測。

"らしい"が多いけど、この辺の情報はググればすぐに見つかるので問題ないでしょう。

■ DAO SDK クラスの場合 ■
上の、MFC DAO クラスの話が"らしい"ばかりなのは、該当プログラムは非MFCアプリで、MFCが嫌い＆書けない私は、DAO SDKクラスを使ってるからです(^_^;)

それ以外にもDAO SDKクラスは、MFC DAOクラスに比べて、

• スレッドセーフティで、マルチスレッド環境で使える。
• GetRows()/GetRowEx()で、一括取り出しが出来るので、かなり高速。
• そして、MFCが不要！(^_^;)

などの特徴があります。

DAO SDKクラスを使って、DAO3.6に対応させるのも（解ってしまえば）簡単です。

1. まず、DAO3.6に対応した、DAO SDKのソースを取得します。
   場所は、VisualC++6.0のSP3以降サービスパックの、Supportディレクトリです。
2. ソースをビルドして、DAO3.6対応なDAO SDKクラスDLLを作成します。
   先ほどのディレクトリに、dbdao.dswがあるので、それを開いてビルドします。
   [ビルド]メニューの[バッチ ビルド]をクリックすると、複数のDLLを同時に構築できます。
3. あとはDAO3.5の時と同じように、DAO3.6対応DAO SDKのライブラリをリンクして終わり。

すごく簡単♪。
なのに、ググってもほとんど情報を見つけられず苦労しました…。
上の情報は、VisualStudio6.0サービスパックのリリースノート中の記述を元にしてます。ちゃんとリリースノートは読みましょうね。

やっとVS.NETを使ってみようかと、WTLをインストール

■ VisualStudio.NET 2002/2003

• WTLの最新版を、SourceForge.netよりダウンロード。
  
• 展開したAppWizディレクトリの、setup71.js(VS.NET2002の場合はsetup70.js)を実行。
  
• VS.NET2003のインクルードの設定に、WTLのincludeパスを追加。
  AppWizardの日本語化が不要なら、ここで終わり。
  
• AppWizardや、自動作成されたリソースが英語のままなので、日本語化しておく。
  まずRoy.'sさんの、「WTL講座 環境編」から、日本語リソースをダウンする。
  
• つぎに%WTL%\AppWiz\Files\HTML\に1033ディレクトリのコピーを作って、名前を1041にする。同様に、%WTL%\AppWiz\Files\Templates\にも1033ディレクトリをコピーした1041ディレクトリを作る。
  
• そこに、先ほどダウンした日本語化されたリソースをコピーして終了。

■ VisualStudio 6.0

• SourceFogeの最新版WTLは、VisualStudio6.0対応が消えているので、ここは無理せず旧WTL7.1版を使う。WTL7.1は、Microsoftのサイトからダウンロード。
  
• 展開した、AppWiz60ディレクトリの、setup.jsを実行。
  
• VS6.0のインクルードの設定に、WTLのincludeパスを追加。
  AppWizardの日本語化が不要なら、ここで終わり。
  
• WTL7.1のVS6.0対応版のカスタムAppWizardはコンパイル済みの物なので、自己責任でResourceHackerを使って日本語化してみる。AtlApp60.awxを、%VS6.0インストール先%\Common\MSDev98\Template\にコピーして終了。

Microsoft Visual C++ Toolkit 2003が、(無料)配布されています。

これに含まれているコンパイラは、VisualStudio.NET2003と同等の最適化機能が付いている物らしいです。正確には、VS.NET2003付属コンパイラより、リビジョンは小さく（古い？）、生成されるバイナリも異なるようなので、全く同じ物では無いようです。また、VC++ Toolkitには、コンパイラやリンカなどはありますが、MFCやSDKは含まれていませんので、ご注意。

ということで、あとは、PlatformSDKとか、.NET Framework SDKをダウンして、デバッカとしてWinDBGをダウンすれば、C/C++/C#限定だけどMS製な無料Windows開発環境が出来上がるのかな？もしかして、VS.NET 2003いらない？MFCが必要ならVS買うしかないかもだけど、MFC使えないから無くても問題ないし。

さらに、IDEにEclipse使えば完璧？
Eclipse使ったこと無いので、他のツールとの連携が可能かどうかは不明。SDKやVC++ Toolkitは問題無さそうだけど、WinDBGはどうだろう。WinDBGって結構強力なデバッカで、使いこなせるなら悪くないと思う。ドライバ類のデバックには手放せないし。Eclipseと組めるなら、VSマジでいらないかも？…。

VisualStudio.NETを使う上で気になることが一つ。

たぶんそう感じてる人が多いと思うのが、VSエディタのキー操作性。
今使っているVS.NETは、昔のVSエディタに比べると色々と細かいところまでキーカスタマイズ出来るようになったのですが、どうしても範囲指定のキーだけはカスタマイズ出来ないようで（もしかしたら、私が知らないだけかもしれませんが）、困っています。Windows標準（メモ帳互換）な、SHIFTキーとカーソルキーで範囲指定し、Ctrl+CやCtrl+XそしてCtrl+Vを組み合わせる操作方法しか受け付けてくれません。

私の好みは、ファクションキーで選択開始を指定出来る操作方法。これは、DOSの頃に使用したエディタ(RED。たぶんMIFES互換）の操作方法で、この操作方法以外ではコーディングできない体になってしまっています（慣れの問題だという話もありますが…）。どうしてもアメリカンなWindows標準のキー操作に馴染めず、いままでVS上でコーディングすることは極力避け、自分好みにキーカスタマイズした秀丸エディタを使ってのみ、コーディングしていました。そういえば、DOS->Win3.1の頃って、そこまでキーカスタマイズ出来るエディタって秀丸くらいしかなかったよなぁ。重宝してます。

今までは、これでも良かったのですが、VS.NETでC#なる物を使う事を考えた場合、VS.NET上でコーディングしたほうが、入力支援や各種ヘルプ等を使用できてラクチンになりそうです。しかし、どうしてもWindows標準な範囲指定のキー操作に馴染めず、途中でイライラしちゃいます。このままでは、開発効率も落ちますし、ストレスがたまります（毎回「ＭＳのアホ〜」とかツブやいてます(--;）。

たぶん、私以外にも同じような不満を持っている人がいて、既にVS上の範囲指定キーをカスタマイズ出来るツールを作っている人がいるだろうと、ネットを探してみたのですが、（VS関係なく）単純なキーマップの変更とかはあるのですが（それってレジストリ操作するだけで実現出来るヤツじゃん…）、求める機能を実現してくれるツールは見つけられません。MIFES互換なキー操作だから、需要あると思ったんだけどなぁ…。

しかたないので、無ければ自分でなんとかするしかないか、と、作り始め。フックすればいいだけだから簡単だろうと思ってたら、これがめちゃくちゃ面倒。メモ帳君レベルなら騙すの簡単なのですが、どうもVSはそう単純では無い模様…。何度もPeekMessage(PM_NOREMOVE)してくるなよ>VS(--; おかげで、出来上がったプログラムは、フラグだらけ…。恐い恐い。SetWindowsHookEx()なんて中途半端な事は止めて、フィルタードライバ作っちゃったほうが早かったと後悔。それはヒマな時でいいか…。

さて、出来上がったのはいいのだけど、やはり秀丸エディタの操作性には遠く及びません。範囲指定その物のキーはカスタマイズ出来たけど、範囲指定と他のキー操作の組合せ（例えば、範囲指定したまま検索とか）が出来ないと、ダメだよねぇ。MS社内の人はこれで満足してるんだろうか？それとも何か他の方法があるのかなぁ？？？？？

システムモニタや、タスクマネージャの「プロセス」タブ等で、表示される「CPU使用率」とか「メモリ使用量」とかを所得する方法のメモ。
PDH系APIを使用します。ただし、これはNT系のみでの動作。たしか95系はレジストリに値が記録されていたと記憶…。たしか、昔MSDNLibraryかなにかでPDHの記事があったような記憶あるけど、忘れてしまったのでサンプル作って動作確認。で、何に使うかは不明(^_^;

#include    <windows.h>
#include    <stdio.h>
#include    <pdh.h>

void    main()
{
        HQUERY    hQuery;
        HCOUNTER hCounter;
        PDH_COUNTER_PATH_ELEMENTS cpe;
        char path[256];
        DWORD size = 256;
        PDH_FMT_COUNTERVALUE FmtValue;


    //クエリー作成
    PdhOpenQuery(NULL, 0, &hQuery);

    //所得したい情報(カウンタ)のパスを作成
    //例として、メモ帳のCPU使用率
    //ObjectNameやCounterNameで指定する名称は、
    //PdhEnumObjects()でオブジェクトの列挙
    //PdhEnumObjectItems()でカウンタの列挙が出来る
    //決めうちなら、システムモニタの「カウンタの追加」を参照
    cpe.szMachineName    = NULL;
    cpe.szObjectName     = "Process";
    cpe.szInstanceName   = "notepad";
    cpe.szParentInstance = NULL;
    cpe.dwInstanceIndex  = 0;
    cpe.szCounterName    = "% Processor Time";
    PdhMakeCounterPath(&cpe, path, &size, 0);

    //カウンタをクエリーに追加
    PdhAddCounter(hQuery, path, 0, &hCounter);

#if    1
    //値取得
    PdhCollectQueryData(hQuery);
    //10秒間待つ
    Sleep(10000);
    //値取得
    PdhCollectQueryData(hQuery);
#else
    //こちらでもよいが、NT4では動かない
    PdhCollectQueryDataEx(hQuery, 10, NULL);
#endif

    //10秒間のメモ帳のCPUの使用率を取得
    PdhGetFormattedCounterValue(hCounter, PDH_FMT_DOUBLE, NULL, &FmtValue);
    printf("メモ帳のCPU使用率: %f%%\n", FmtValue.doubleValue);

    //終了
    PdhCloseQuery(hQuery);
}

追記：.NETでのパフォーマンスカウンタ fromMSDN
こちらはちゃんと日本訳されてます。Longhornを見据えて、そろそろクライアントアプリも.NETで開発してよいのかも。ただ現状では、.NET Frameworkが別配布&重いのが難点だけど…。