一応コンパイル自体はエラーが出ないようになりました。
言われた通り、無視するライブラリにエラーに出てくるライブラリを指定したらエラーが無くな
りました。

しかし、pngのwrite関連の関数を使うと混合モードになって
「ハンドルされてない例外 は ***.exe(NTDLL.DLL)にあります。0xC0000005:Access
Violation。」
というメッセージが出て停止します。
またpng出力関係でお世話になるかもしれませんが、
助言を下さった皆様ありがとうございました。

「ml が無い」エラーは http://www.masm32.com/ あたりから masm を取得すれば解決です。
が、既に述べたとおり Win32_LIB_Release と Win32_LIB_ASM_Release の違いは速度だけ。

LNK2005 を /NODEFAULTLIB で抑制していいのは、絶対に問題が無いことが保証できる場合だ
けです。
原因を理解せず使うと、必ず問題が生じます。実際問題が生じているようですし。

だからアプリケーションの構成に対して適切なライブラリを選択して使う必要があります。
Makefile.vcawin32 そのままでは１種類しか libpng.lib が作られないので、
適宜コンパイルオプションを修正し、作り直す必要があります。

>適宜コンパイルオプションを修正し、作り直す必要があります。
私もそう思います。
ちょっと気になってはいたのですが、
LIBCD.libはデバッグバージョン、MSVCRT.libはリリースバージョンですね。
zlibがデバッグでlibpngがリリース、又はその逆で作ってしまっているようです。
昨日いじった限りでは、fmake使わなくても
projects\visualc6の中にlibpng.dswってファイルがあります。
ダブルクリックすると当然VC++が起動して、途中にzlib.dspの場所を
聞いてきますから指定してやると、きちんとプロジェクトが開けます。
あとはアクティブな構成を選んでビルドするだけです。
(便利になったなあ)
設定でMFCを使用しない以外にすれば、/NODEFAULTLIB は使わなくて済むはずです。

なるほど。
ということで、zlibのプロジェクトファイルを開いて色々試したところ、
マルチスレッドにしたら、本体の方の例の/NODEFAULTLIB を使わずにビルド出来ました。

ただし、それとは別なのかもですが、pngファイルを扱う上でのエラーはまだ出ます。
出来る限りMFCは使いたく無いのですが、MFCを使わなければならないのでしょうか・・・。
根本的には問題は解決してませんね・・・。すいません。。

すいません、追加です。
MFCを使用しない 以外にすると50近くのエラーを吐きます。本体の方で。
(zlib, libpngそれぞれ MFCを使用してないにしてます)
また、エラーではなく、ライブラリの競合がwarningで確認されました。
それぞれのライブラリは、LIB Releaseで同様にビルドしてるはずなのですが・・・。

>ということで、zlibのプロジェクトファイルを開いて色々試したところ、
zlib側ではなくlibpng側のプロジェクトで試してください。
説明が足りませんでした。すみません。

>MFCを使用しない 以外にすると50近くのエラーを吐きます。本体の方で。
本体はMFC使っていないのですか?MSVCRT.libはMFCが使うライブラリですよ。

_mallocという関数がMSVCRTとLIBCの両方に存在しているんです。
通常MFCを使う場合はMSVCRT、使わない場合はLIBCを用いるのですが、
本体がMFCでライブラリが非MFC、またはその逆の場合、バッティングして
しまうのです。
本体がMFC使っていなければ問題は起きないはずです。

>(zlib, libpngそれぞれ MFCを使用してないにしてます)
どうしてもこうしたいのであれば、/NODEFAULTLIBを使う必要があります。
あとは、MFCバージョンのlibと非MFCバージョンのlibを別々に作るとか。

ちなみに質問しているゆうさんは別人です。

自分も説明不足でした。
libpng.libの方も同様にzlibと同じく非MFC、マルチスレッド等でビルドしたものを使ってま
す。
で、本体の方も非MFCでビルドしてます。
libpng,zlib二つとも作り直したら、ちゃんとwarning以外はエラー無しでビルドされます。
(warning LNK4098: defaultlib LIBCMT は他のライブラリの使用と競合しています)
MSVCRTに関するエラーも全く無くなりました。
肝心のwrite_png関数をコメントアウトすればwarningさえ出ません。
しかし、他の関数の部分でもmallocは使ってます。。
このwrite_png関数を使うと、どうしてもwarningと実行時エラーになります。
実行時エラーは実際にpng書き込み関数を使ったところで止まります。

> 本体はMFC使っていないのですか?MSVCRT.libはMFCが使うライブラリですよ。

MSVCRTはCRTがDLLの場合に使われるライブラリです。
MFCを使っていなくても，使用するCRTとして「マルチスレッド(DLL)」を選択すれば，
MSVCRT.libがリンクされます。

> (warning LNK4098: defaultlib LIBCMT は他のライブラリの使用と競合しています)

LIBCMTは，使用するCRTが「マルチスレッド」の時に使われるものです。

使われるライブラリは，
シングルスレッド：LIBC
マルチスレッド：LIBCMT
マルチスレッド(DLL)：MSVCRT
です。

どこかにCRTがシングルスレッドのものが混じっていませんか？

>MSVCRTはCRTがDLLの場合に使われるライブラリです。
そうなんですか。勉強になります。ありがとうございました。

>どこかにCRTがシングルスレッドのものが混じっていませんか？
私もそう思います。本体がシングルスレッドとか。
エラーに関しては、本体がデバッグ環境でリリース版の
libを使っているとか。

なるほど、そういう仕組みになってるんですね。
分かりやすくまた更に勉強になりました。
確かに、本体がシングルスレッドになっており、
ゆう さんのおっしゃるとおり、本体デバッグ環境でReleaseのlibを使ってました。
なので、マルチスレッドにした後で、試しにRelease環境でビルドしてみました。
すると、ライブラリの競合警告は出なくなりました。
ただし依然としてpngの書き込み関数のところで混合モードで停止するのは変わりませんでし
た。