KB401968 - [MSVC] Visual C++ 1.5 の README.WRI(3/8)

概要

この資料は、Visual C++ 1.5 に添付されている README.WRI の以下の章を抜粋した
ものです。

  第 3 章 App Studio
  第 4 章 SDK, MFC, OLE, CDK サンプル ファイル
  第 5 章 CL コンパイラ

第 3 章 App Studio

App Studio のグラフィックスエディタとディスプレイドライバ

800 × 600 以上の解像度または 16 色以上をサポートするディスプレイハード
ウェア上で App Studio のグラフィックエディタを実行した場合、その動作が
不安定になることがあります。これはたいていの場合ハードウェアメーカーが
提供するディスプレイドライバにその原因があります。
ドライバのバグが存在することを示す兆候には、次のようなものがあります。

奇数の幅の画像の右端のピクセルが黒に設定される
アイコンの編集中に一般保護違反が発生する (この後の "ディスプレイ性能の改善" を参照してください)
Visual Workbench でデバッグ中にドライバファイル内で INT 3 が実行される
モノクロ画像でブラシを使っているときに余分なピクセルまで描画される
1 ピクセル幅の対角線の表示が太すぎる
モノクロ画像をカラー画像に変更すると画像が破壊される
フィルツールで正しく塗りつぶせない。

App Studio のグラフィックエディタを使用中にこれらの問題が生じ、しかも Windows を高解像度か 16 色以上で実行している場合は、問題の原因がディスプ
レイドライバにないかどうか最初に確認する必要があります。原因がディスプレイ
ドライバにある場合は、ハードウェアメーカーから最新版のドライバを入手して
ください。
問題の原因がディスプレイドライバにあるかどうかを調べるには、次に示す手順に
従って Microsoft の標準ディスプレイドライバのいずれかをインストールして
みてください。

Windows のセットアッププログラムを実行します (Visual C++ のセットアッププログラムではありません)。
[ディスプレイ] ドロップダウンボックスから VGA (NEC 版の場合は、640X400、 16 色モード) を設定して OK を選択し、新しいドライバのインストール手順に従って操作します。

新しいドライバを設定して Windows を再起動し、App Studio を実行して同じ問題が再発するかどうか確認してください。これで問題が起きないときは、ディスプレイ
ドライバが問題の原因です。
Windows の標準ディスプレイドライバだけを使いつづけている限りは問題の発生を
防止できますが、ディスプレイハードウェアが提供する高解像度や色数などの性能
を引き出すためにはバグを修正した新しいディスプレイドライバを入手する必要が
あります。最新版のディスプレイドライバを入手する方法としては、直接ハード
ウェアメーカーに問い合わせるのが最もよいでしょう。
App Studio で問題を発生することが明らかになっているドライバの一覧を次に
示します。

App Studio で問題を生じることが確認されているドライバ

ATI Ultra および ATI Ultra Pro。Gateway 2000 をはじめとする各種のコンピュー
タに添付された ATI ドライバにも、Visual C++ 1.0 の出荷時点でディスプレイ
ドライバのバグが何ヶ所か報告されています。ATI ではこれらのバグについて
現在処置を行っており、最新のドライバでは解決されている可能性があります。

ディスプレイ性能の改善

App Studio では、800 × 600 以上の解像度または 16 色以上を表示するディスプ
レイハードウェアに共通して発生する可能性が高いいくつかのバグに対処するため
に、それらの対処機能が組み込まれています。Visual C++ 1.0 が出荷された時点で
は市販のディスプレイハードウェアでは StretchBlt グラフィックス関数が正しく
インプリメントされていないことが多かったため、その障害を回避する機能が追加
されました。App Studio のこの障害回避機能を使うと、使わない場合に比べてグラ
フィックスエディタの再描画速度が遅くなります。このためこの機能を必要と
しないディスプレイドライバを使っている場合は、App Studio グラフィックス
エディタの再描画速度を改善することができます。
グラフィックスエディタの描画速度を改善するには、次の行を APSTUDIO.INI
ファイルの [Graphics Editor] セクションに追加してください。

  [Graphics Editor]
  DriverCanStretch=1

この変更が正しく行われたかどうか確認するには、App Studio を実行して新しい
ビットマップを作成してください。ビットマップの作成と描画が正常に行われる
ときは、ディスプレイドライバには StretchBlt が原因となる問題は生じませ
ん。この場合は、新しい行を .INI ファイルに記述したことによってグラフィッ
クスエディタの性能が改善されています。
新しいビットマップを作成したときに App Studio が正常に動作しないときは、
ドライバには StretchBlt を原因とする問題が生じています。この場合は
DriverCanStretch の行を .INI ファイルから削除して、ハードウェアメーカーの
提供している最新バージョンのディスプレイドライバをインストールして下さい。

コンボボックスのドロップダウンのサイズ変更

App Studio ダイアログエディタのコンボボックスドロップダウンの初期サイズ
を変更するには、通常はそのコントロールのドロップダウン矢印をクリックしま
す。これによってコンボボックスのドロップダウン部分が表示され、コントロー
ルの一番下にはサイジングハンドルが表示されます。コンボボックスの高さが 0
などの場合には、サイジングハンドルの外観は変更しない場合があります。
その場合でも、垂直方向にはコンボボックスのサイズを変更できます。下方向矢
印をクリックしてマウスカーソルを一番下のサイジングハンドル上に移動して
ください。マウスカーソルの形は上下方向矢印に変わり、通常の方法でコンボ
ボックスを垂直方向にサイズ変更できます。コンボボックスドロップダウンの
サイズ変更について詳しくは Books Online の『 App Studio User's Guide 』を
参照してください。

第 4 章 SDK, MFC, OLE, CDK サンプルファイル

サンプルプログラムの日本語対応

SDK 以外の MFC、OLE、 CDK のサンプルプログラムは 2 バイト文字に対応して
おりません。

2 つのプロジェクトファイルを持つ SDK サンプルファイル

Visual C++ の一部の SDK サンプルファイルにはプロジェクトファイル (.MAK)
を 2 つ持っているものがあります。これらはそれぞれ .EXE ファイル用と .DLL
用です。この場合、必ず先に .DLL プロジェクトをビルドする必要がありますが、
これは .DLL プロジェクトによって生成されるライブラリファイルはすべて .EXE
プロジェクトによってリンクされる可能性があるためです。

RAINBOW サンプルファイル

SDK Samples Reference Help (SAMPLES.HLP) に記述されている SDK のサンプル
ファイル RAINBOW は Visual C++ には含まれていません。

MIDIMON サンプルファイル

MIDIMON サンプルをビルドすると、リソースコンパイラから RW4002 の警告が
発生しますが、ビルドは正常に行われています。この警告メッセージを無視して
下さい。

第 5 章 CL コンパイラ

/Fs コンパイラオプションの利用

(ソースリストを作成する) /Fs オプションを指定してコンパイルすると、TEMP
環境変数で指定したディレクトリに 2 つの一時的なファイルが作成されます。コ
ンパイル中にエラーが発生しなければ、これらのファイルは空のままです。コン
パイル終了後、これらのファイルは削除することができます。

ファイルが多すぎるために生じるコマンドラインオーバーフロー

プロジェクトに含まれるファイル数がほぼ 110 個を超えるとコンパイラは D2031
エラー (コマンドラインオプションが多すぎます) を発生します。コンパイラに
送れるコマンドラインエントリは最大で 128 個までですが、そのうちのいくつか
はコマンドラインオプションに取られるため、その残りがコンパイラの処理する
ソースファイル名ということになります。Visual Workbench はプロジェクト内の
すべてのファイルを 1 個のバッチに送ります。
/Tc または /Tp オプションを使う場合は、ファイルの最大数は約 55 個まで減りま
すが、これは指定したオプションがすべてのファイル名に付加されるためです。
この問題は、プロジェクトをオープンしたときに [Use as an External Makefile]
チェックボックスをチェックしておくことによって回避できます。この場合、
Visual C++ は内部メイクファイルを外部メイクファイルとして取り扱い、
Microsoft NMAKE はコンパイル対象の各ファイルごとにコンパイラをくり返し
呼び出します。

数式の評価と評価順序点

数式は、すべての副作用が解決できる点 (評価順序点) においてのみ評価されます。この ANSI の基準に従っている限り、コンパイラがどのようにプログラムを最適化
してもコンパイラによって最適化されたプログラムともとのプログラムの評価順序
点は一致しているはずです。一方、高速、最適化、p-code の各コンパイルにおいて
はプログラムの最適化レベルが異なるため、評価順序点を含まない数式の評価に
おいては同じ値を返すという保証がありません。例えば、次に示す式は評価順序点
が無いため、"x" と "y" の内容を入れ替えるという保証はありません。 x^=y^=x^=y;

/Z7 オプションの利用

Microsoft C/C++ Version 7.0 のデバッグ情報を生成するオプション (/Z7) を
設定すると、コンパイラはデバッグ情報の一部をプログラムデータベース (.PDB)
ファイル内に生成するかわりに、すべてのデバッグ情報を実行ファイル内に生成し
ます。ただし、このオプションを設定しても、実行可能ファイルは C/C++ version
7.0 で使われている CodeView 4.0 デバッグ情報と互換性のあるファイル形式には
なりません。

/Zr オプションの利用

Windows 用のプログラムのヌルまたは範囲外のポインタをチェックするのに /Zr
オプションを使うことはできません。Windows のメモリ管理手法では、/Zr によ
って検出される状態をチェックしています。このため、Windows 用のプログラム
で /Zr を使うリンカがエラーを返します。[C/C++ Compiler Options] ダイアロ
グボックスでは、すべての Windows プロジェクトタイプにおいて
[Code Generation] カテゴリの [Check Pointers] チェックボックスは無効に
なります。

DLL と /Gy (参照されないコードの無視) および /O1 (スモールコード設定) の各オプションの関係

Windows コールバック関数を含む DLL をビルドする場合は /O1 オプションを設定
できません。/O1 オプションは参照されない関数を実行可能ファイルから取り除く
/Gy オプションを使いますが、/Gy オプションは DLL 内にある Windows コール
バック関数まで取り除いてしまうからです。対策としては、DLL をビルドするとき
にリンカの /NOPACKF オプションを設定してください。

関数をインラインでコンパイルする場合の評価基準

次に示す場合は、インラインで定義された関数でもインライン関数としてコンパイルされません。

関数が大きすぎる場合。コンパイラはインラインの量が増えすぎないようにスレッショルドを決めています。関数の大きさがこのスレッショルドを超えると、インライン展開されません。つまり、インライン展開する関数と、その関数がインライン展開されるためにインライン展開される他の関数を合わせた値がスレショルドの値を超えると、展開は行われません。例えば関数 A が関数 B を呼び出して A がインライン展開されるとき、B をインライン展開することによってスレッショルドを超える場合は B はインライン展開されませんが A はインライン展開されます。スレッショルドの調整は /OV オプションによって行います。
関数が展開可能な最大の深さを超える場合。いったん展開可能な最大深さを超えると、すべてのインライン展開は抑圧されます。これを制御するには inline_depth と inline_recursion の各プラグマを使います。
呼び出し側と呼び出される側が互換性のないオプションを設定している場合。プラグマと最適化スイッチの組み合わせによっては互換性がそこなわれる場合があります。
関数のプロトタイプ宣言と矛盾している場合。プロトタイプ宣言におけるパラメータの個数と実際に指定されたパラメータの個数が異なります。
関数ステートメントの評価順序が決められている場合。評価の順番が決められているステートメントにおいて評価順序を変更しないとインライン展開ができない場合は、関数はインライン展開されません。
十分なメモリ容量がない場合。コンパイラが関数をインライン展開するのに必要なメモリ容量を確保できない場合があります。これは通常、高速コンパイルオプション (/f) を選択するかまたは関数が p-code としてコンパイルされるかしたときに、展開が循環的に行われる場合 (A をインライン展開すると B も展開され、さらに C も展開されるというような場合) のみ発生します。

「 C2371 'HSZ' がすでに宣言されています」のエラーが発生する

AppWizard で生成したソースコードに ddeml.h をインクルードするように記述して
コンパイルすると「 error C2371: 'HSZ' : すでに宣言されています。」というエ
ラーが発生します。これは AppWizard で生成されたコードに標準でインクルード
されている afxext.h と ddeml.h の両方のヘッダファイルの中で、前者は
DECLARE_HANDLE32 マクロで、後者は typedef BPSTR FAR* で HSZ という型が
宣言されているために発生します。この問題は以下の方法で回避することが
できます。

AFXEXT.H と DDEML.H を同一モジュール内でインクルードしないようにコードを記述する。
VBX を使用しないのであれば AFXEXT.H のインクルードの記述の前に NO_VBX_SUPPORT を define する。
どちらかのヘッダを書き換えて HSZ 型の宣言を１つにする。

[MSVC] Visual C++ 1.5 の README.WRI(3/8)

概要

第 3 章 App Studio

App Studio のグラフィックス エディタとディスプレイ ドライバ

App Studio で問題を生じることが確認されているドライバ

ディスプレイ性能の改善

コンボ ボックスのドロップダウンのサイズ変更

第 4 章 SDK, MFC, OLE, CDK サンプル ファイル