VC++の無償版は、VC++2008 Express が面倒が少なくていいようです、が、
私は、VC++2005 Express に入れなおしてしまったので、このままいきます。

まず、導入はここの手順に従ってやります。
Visual C++ 2005 Express Edition と Microsoft Platform SDK を一緒に使う
http://www.microsoft.com/japan/msdn/vstudio/express/2005/visualc/usingpsdk/

 Microsoft Platform SDK も入れないと使い物になりませんので。


手順 3. [オプション] ダイアログ ボックスの [プロジェクトとソリューション] 
セクションで [Visual C++ フォルダ] を更新します。

これは、toolタブのオプションです。分かりにくいので注意。

このセクションでは、適切なサブセクションにパスを追加します:

Executable ファイル - 「C:\Program Files\Microsoft Platform SDK\Bin」 
Include ファイル - 「C:\Program Files\Microsoft Platform SDK\include」 
Library ファイル - 「C:\Program Files\Microsoft Platform SDK\lib」 

1行挿入ボタンで空行を作り、このパスを貼り付けます。分かりにくいです。


手順 4. corewin_express.vsprops ファイルを更新します。
Visual C++ 2005 Express Edition で Win32 テンプレートを使えるようにするための
作業です。corewin_express.vsprops ファイル 
(「C:\Program Files\Microsoft Visual Studio 8\VC\VCProjectDefaults」にあります) 
を編集し、次の文字列を修正してください。 

VZで開こうとしたら、パスが長すぎて、開けないんですね。まいった。(++;
VZのパスバッファは64文字しかないので、いまどきは足りないですね。
そこで、VZ.INCの

PATHSZ		equ	80	;64

を64から128にしたらエラーになるので、80にしてアセンブルできました。
おお、これで長いパスでも開けるようになりました。(^_^)

この改造はファイラーの
34	fl_path		db	PATHSZ dup(?)
のバッファをずらすので、COMファイルの絶対アドレスがこれ以降ずれますが、
いまどきそんな邪悪なマクロを使っている人はいないでしょうから、問題
ないでしょう。(^^;

konnoさん

　（本題はちょっとおいておいて）
　おお、これってすごく画期的ではないですか！

> VZで開こうとしたら、パスが長すぎて、開けないんですね。まいった。(++;
> VZのパスバッファは64文字しかないので、いまどきは足りないですね。
> そこで、VZ.INCの
> PATHSZ		equ	80	;64
> を64から128にしたらエラーになるので、80にしてアセンブルできました。
> おお、これで長いパスでも開けるようになりました。(^_^)

　96ではどうでしょう？(^^;ゞ
　「64から128にしたらエラーになる」って、何の制限なのでしょう？　64KBの壁？
たしか高橋さんが「そろそろサイズ的に限界に来てる」ってどっかで仰ってました
よね。？？？

（以下の絶対アドレス付きdseg.mapはめざらさんのものより。多謝）（A）
0142    pc..25          nbufsz   word   PATHSZ  Hn
038C    pq..127/pn..-48 curdir   word   PATHSZ  current directory (pd)
03A0    pq..137/pn..-38 pathbuf  word   PATHSZ
03A2    pq..138/pn..-37 pathbuf2 word   PATHSZ

（高橋版dseg.mapより）（B）
34	fl_path		db	PATHSZ dup(?)
130	fl_lastpath	db	PATHSZ dup(?)
146	path		db	PATHSZ dup (?)	; path name area

　この７つぶん太ることになりませんか？　(80-64)*7=112 bytes
　完全わからんちんなのですが、（A）で「:0142」以降がずるっとずれるのでは
ないのですかねぇ？
　できあがったcomファイルでも、ファイルサイズが正確にこれだけ増加するので
しょうか？

　で、vz.defに以下のような指定があったら太っちょvz.comではエラーになってま
したね、きっと。（現状では意味がないので、すぐさまコメントアウトしました。）
;Hn64			;pr


> この改造はファイラーの
> 34	fl_path		db	PATHSZ dup(?)
> のバッファをずらすので、COMファイルの絶対アドレスがこれ以降ずれますが、
> いまどきそんな邪悪なマクロを使っている人はいないでしょうから、問題
> ないでしょう。(^^;

　こっちもずれるとは思うのですが、これは上（A）とは連続してませんよね。
異セグなので。

　アセンブル済みファイルを上げていただけませんか？

> 　96ではどうでしょう？(^^;ゞ
> 　「64から128にしたらエラーになる」って、何の制限なのでしょう？　64KBの壁？
> たしか高橋さんが「そろそろサイズ的に限界に来てる」ってどっかで仰ってました
> よね。？？？

試してみたら92まではOKみたいです。エラーはexpr.asmで、ショートジャンプ範囲を
超えているみたいですが、テーブル参照みたいな書き方なので読めません。(++;
「サイズ的に限界」はcomファイル自体のサイズが64kまでですね。

> （以下の絶対アドレス付きdseg.mapはめざらさんのものより。多謝）（A）

おお、これはすごい。参考にさせていただきます。(^^;

> 　この７つぶん太ることになりませんか？　(80-64)*7=112 bytes
> 　完全わからんちんなのですが、（A）で「:0142」以降がずるっとずれるのでは
> ないのですかねぇ？

メモリ上では太るし、ずれますね。ただ、上記のアドレス自体はずれません。そこから
の参照先のバッファがずれるということですね。そのバッファをdz=vz などと、直接
指定したりするのはまずいですが、pc..25のような使い方なら問題ないと思います。

> 　できあがったcomファイルでも、ファイルサイズが正確にこれだけ増加するので
> しょうか？

すみません、私が書き間違えてました。comファイルのファイルサイズは変わりません。
メモリ上に展開されるスタックバッファが増加するんでした。

> 　で、vz.defに以下のような指定があったら太っちょvz.comではエラーになってま
> したね、きっと。（現状では意味がないので、すぐさまコメントアウトしました。）
> ;Hn64			;pr

あれ？ うちのVZ.DEFではHn128にしましたが、問題ないようですよ？　リネーム用の
バッファということですが、以前ロングファイル名のリネームが出来ないときがあった
ので、これが関係しているのかもと思って64を128に変えてみました。
これはSTKHLPでも、変更可能となっていたので、Hnの指定が優先だと思います。
 Hn=pr なんですよね。

> 　こっちもずれるとは思うのですが、これは上（A）とは連続してませんよね。
> 異セグなので。

え〜と、どこのエリアだったか確認してませんが、原理はいっしょだと思います。(^^;
う、よくみたらこっちはコードエリアがずれるようですね。(^^;　

> 　アセンブル済みファイルを上げていただけませんか？

今 92 の版で使ってますが、特に問題ないようなので、明日にでも上げてみますね。
でも文太さんなら、MK6 ですぐでしょう。(^^;

　お宅様のＸＰで一番深いディレクトリはどこでしょうか？　ま、そんなところ
にＶｚで行くかどうかは別にして（konno さんのようにいつ必要に迫られるか分
かりませんよ）、知りたくないですか。以下で調べられます。

----- deepdir.awk -----
#>dirlist /s c:\ >pathd.lst (coffee time -- this takes a while)
#>Jgawk -f deepdir.awk pathd.lst
deepest<length {
	deepest=length;
	longstr=$0;
}
END {print deepest, longstr}
-----------------------

うちの結果：
C:\>Jgawk -f deepdir.awk pathd.lst
117 c:\DOCUME~1\XXXXXX~1\APPLIC~1\MACROM~1\FLASHP~1\#SHARE~1\HR3NCX73\
WWWSON~1.JP\products\Consumer\dslr\xml\SD_RDF~1.SWF

　なんと、９６でもまだ足りないとこがあるらしい…。(>_<)

　追伸：  konno さん、ごめんなさい、今日はお疲れモードのようなので寝ます
ね。レス＆テストランなど明日以降に。m(__)m

konnoさん、

　（色々学ばせていただいたので、こちらにも記念に？レスをつけておきます。
独り言みたいなものですので、パスしてくださってけっこうです。あのね、これは
こうなってるんだよ、って教えてくれたら、ものすごく嬉しくてウルトラ感謝して
しまうでしょうけれど。）

> 「サイズ的に限界」はcomファイル自体のサイズが64kまでですね。
　了解。上がったら、まずメモリーの残り全部を確保する、が常道でしたね。っ
て、まるで違う話になってるみたいですが、たぶん僕は現在位置（無知のポイン
ト）をある程度は把握しているような気がしています。

> > 　この７つぶん太ることになりませんか？　(80-64)*7=112 bytes
> > 　完全わからんちんなのですが、（A）で「:0142」以降がずるっとずれるのでは
> > ないのですかねぇ？
> メモリ上では太るし、ずれますね。ただ、上記のアドレス自体はずれません。

　アドレスはずれませんね（きっと）。

>> 「:0142」以降がずるっと
　これは間抜けだ。タコ＞文太。

>> 　できあがったcomファイルでも、ファイルサイズが正確にこれだけ増加するので
>> しょうか？
>　すみません、私が書き間違えてました。com ファイルのファイルサイズは変わ
>りません。メモリ上に展開されるスタックバッファが増加するんでした。

　あ、最初に。「com ファイルのファイルサイズ」も大きくなりましたよね。


　「スタックバッファ」ですかぁ。また、そういう本にない言葉を使う。ここ、
konnoさんは、スタックセグメントの意味で使われてますよね。

> ■ セグメントの変更
> -----------------------------
> 　コードセグメントとデータセグメントを分離したため、マクロでアクセスする
> ワークエリアは、全てスタックセグメントに移動しました。このため、
> 
> 	dz=gz, p=wa+$92, .. dz=cz,
> 
> のように、セグメントを変更する必要はありません。
> 　また、このように「dz=cz,」でセグメントを復帰しているマクロとの互換性を
> 考慮して、「cz,dz.gz」はすべてスタックセグメントを指しています。真のコー
> ドセグメントの値は、セグメント変数「vz」が示します。

　なんですけどね、ここでc.mosさんがいってる「スタックセグメント」ってアセン
ブラでいうssなんですかねぇ？？？　たぶん、そうなんだろうな、と思っているの
ですが。でも、「コードセグメントとデータセグメントを分離した」ってわけです
よ。1.6以前には、一緒だった。マクロバッファもコードセグメントに、６４ＫＢの
中に、あったと思うのです。
　で、dzは？

高橋　洋光氏,95/9/6, <nifty:FGALPK/MES/13/2537>
------------------------------------------------------------
  　簡単に各セグメントについて説明すると。
  　まず、&i() の cs ds es ss
  cs            現在実行する命令の入っているセグメント。
  ds            bx,si,di のセグメント。
  es            ストリング命令時の di のセグメント。
  ss            スタック、bp のセグメント。
  　次に Vz の主なセグメント。
　vz            vz.com のセグメント。&i() で言うならば、cs ですね。
　dz            データセグメント、システム変数やマクロバッファが入って
                いる。
　cz,gz         基本的には dz と同じですが、微妙にちがう。
  tz(wa..9)     現在編集中のテキストセグメント。
  wa..10        現在編集中のテキストのセグメントの次のセグメント。
  kz            テキストスタックのセグメント。
  pc..178       データセグメントのお尻、一番最初のテキストセグメントの
                １６バイト手前。
  pc..158       最大のセグメント。
  fl..2		ファイラープールのセグメント。
  pq..67	EMS のセグメント
------------------------------------------------------------
　こんなに色々とっかえひっかえしてるわけですよね。うーん。

　それでも、（わけのわからん質問なのかもしれませんが）

　メモリ上の vz.comも、それを書いた c.mos さんも、やっぱり基本的な４つ
のセグメントの分類というか使い分けに従ったわけですよね？　少なくともあ
る瞬間にはその４つがこれとこれとこれとこれ、と分けられるからこう動作す
るという具合に。
　cgroupとか言われると分からないのですよ。

　たとえば、 ps とか pw とかのバッファ自体でなくアドレスが格納されている
領域がデータセグメントに当たるんだろうとか思っているのですが。違いますか？
　しかし、こうなると Hn 増加でＶｚが太った原因が分からなくなるのですが…。

> 　で、vz.defに以下のような指定があったら太っちょvz.comではエラーになってま
> したね、きっと。（現状では意味がないので、すぐさまコメントアウトしました。）
> ;Hn64			;pr

> 　あれ？うちの VZ.DEF  では Hn128 にしましたが、問題ないようですよ？　リ
> ネーム用のバッファということですが、以前ロングファイル名のリネームが出来
> ないときがあったので、 これが関係しているのかもと思って 64 を 128 に変え
> てみました。 これは STKHLP でも、変更可能となっていたので、Hn の指定が優
> 先だと思います。
> 　Hn=pr なんですよね。

　ここはもう問題でもないと思いますが、prに９２が入る可能性があるときに、
Hn=64としていたら、エラーになってしまいますね、という意味でした。
　僕もかつて１２８とか設定していたときがあったのですが、何かの作業領域と
して使う場合があったからで、普通は必要ないですよね。

>> 　こっちもずれるとは思うのですが、これは上（A）とは連続してませんよね。
>> 異セグなので。
>え〜と、どこのエリアだったか確認してませんが、原理はいっしょだと思います。(^^;
>う、よくみたらこっちはコードエリアがずれるようですね。(^^;　

　コードセグメントにもなんかあるのでしょうね。それはデータセグメントなの
かもしれない…。実行ファイルが太ったわけですから。いずれにせよ、Ｄｏｓに
呼ばれてメモリー確保をする前のvz.comの中で。


　とりわけ教えてもらおうという野心も下心もありません。それでも「ここが間
違ってるよ」とか「こうじゃないかな」とかあったら、お教え頂ければ幸いです。