Re: [MD:6879] Re: r3899 - trunk/src

[Shun-ichi GOTO (後藤俊一) <shunichi.goto@xxxxxxxxx>]

# なんか話がかみ合ってないかも？

On 10/13/05, Kyotaro HORIGUCHI <horiguti@xxxxxxxxxxx> wrote:
>  ちなみに windows.h を読み込んでその定義を使ってコンパイルしたバイ
> ナリで使われている DLL 関数はサポートされていない環境で呼び出され
> ると失敗する(エラーで返る) のかなとなんとなく思っていたのですが,
> 実のところどうなんでしょうか.

DLLの関数に関しては、ビルド時にインポートライブラリを使用したリンクを行った
場合、プログラム起動時にWindowsによって動的リンクにより解決されるわけですが、
その際に目的の関数がない場合は「関数xxxがxxx.dllに見つかりません」とかいった
起動エラーとなりプログラムは起動さえできません。
なので、関数がある場合とない場合の両方をサポートするには、LoadLibrary()や
GetProcAddress()で判断するしかありえません。


一方、WM_xxxのようなものが、同一関数で機能番号が増えているような場合は
その限りではありません。戻り値などで対処可能です。

>  そうならば, 新しいSDKを用意するコストを考えなければSDKをアップデー
> トして windows.h を使うのが正しい方法だと思います.

そうでないです。
SDKを更新してもGetProcAddress()は必要です。
なので、SDK更新はMUSTではありません。


>  とはいうもののその一方で 1つの関数を使うのに数万行の include で副
> 作用の心配をするくらいなら10行程度自分で追加するほうが心労も実際の
> トラブルも少ないと思っている自分がいます:-p

なんの副作用ですか？
windows.hをインクルードするかしないかで変わってしまうようなことは
そもそもかなりシビアな、あるいはトリッキーなことをする場合がほとんどかと思います。
定数定義などは増えてはいますが、変わってはいないはずですので、
新しい機能を使用しない限りにおいて、古いシステムでも動くバイナリが
作れるはずです。

> > それから、そのような関数に関連するマクロや型の定義についても、ヘッ
> > ダファイルで必ずしも定義されていることは限らないので、Meadow のヘッ
> > ダ(おそらくmw32term.h)にインポートする必要があります。
>
>  さらに, システム定義の型や定数を自前で定義するというのは感覚的に
> はいやなものがあるのですが, こういう(どういう?)ものの場合は致し方
> なしということなんでしょうかね.

その感覚は正しいと思いますよ。
今回インクルードファイルに頼らずに別途定義をする(ことを正当化する)理由は
古い開発環境(MSVC6)での定義不足な場合でもコンパイルできるようにする、
という理由でしょう。

ちなみに古い環境で動かせるようにするために古いコンパイル環境が必要
というわけではないです。


--
Shun-ichi GOTO (後藤俊一)