前回の日記で、おまじないを唱えてMSVCRT.DLLに依存しないexeファイルを作る方法を見つけました。
しかし、これを実用化するには、標準ライブラリの実装やコマンドラインへの対応といった課題が残っていました。
そこで、私は考えました。

待てよ…前回の実験は主にC言語のライブラリを使うCUIアプリケーションの話だった。
一方、GUIのアプリケーションなら主にWindows APIを使い、C言語のライブラリの出番はほとんどなくなるはずだ。
さらに、CUIアプリケーションは主に競技プログラミングや実験、個人的な計算向けが多いが、
GUIアプリケーションは主にVectorなどで本格的に公開するものが多い。(個人の感想・状況です)
ということは、GUIアプリケーションから優先して脱MSVCRT.DLLしたほうがいいんじゃないか？

というわけで、早速実験。
実験用のコードには、C言語を始めよう！ v.1.1.2.3に付属している「サンプル（Windows）」を使用しました。(著作権保護のためコード略)

まずは普通にコンパイルしてみる。 予想通り、思いっきりMSVCRT.DLLに依存しています。

次に、おまじないを唱える。
今回、なんとソースコードを一切変更することなく、コンパイルオプションだけでMSVCRT.DLLに依存させないことに成功しました！ やったか！？

…でも、よく見ると あっ！MSVCRT.DLLだ！
さらに、WS2_32.DLLなど、多くのDLLからMSVCRT.DLLへの依存が見つかりました。
しかし、アイコンをよく見てください。
ヘルプを参照すると、このアイコンは「そのDLLの関数が呼ばれた時にDLLがロードされる」ということらしいです。
といっても、USER32.DLLから関数が呼ばれる可能性が大いにあり、実質MSVCRT.DLL依存ということになります。
さらに、WS2_32.DLLが依存しているということは、winsockを使ったら即アウト、ということになりそうです。

でも、よく考えると、このUSER32.DLLはWindowsの基本的なDLLの一つのはずです。
これがMSVCRT.DLLに依存しているということは、MSVCRT.DLLもWindowsに標準搭載されているはず、と考えられるのでしょうか？
コメントお待ちしています。

MSVCRT.DLLはシステムDLLです。
当然，Windows Resource Protectionの対象ファイルになります。
このため，VC++では，例えばMSVCR100.DLLなどがCRTのDLLとして提供されています。

MSVCRT.DLLに依存することの何が問題か，まったく理解できません。
Linuxでlibcに依存することに問題がある，と言っているのと同じことなので。