注：この記事の著者はAlexey Fahrenheit Zakharenkoです。 いい人でスペシャリスト。



メモリとディスクスペースが指数関数的に増加するため、本当に小さなプログラムの作成が必要になることはほとんどありませんが、小さなユーティリティごとに数百キロバイトを余分に失うのが残念な場合には、タスクが発生することがあります。

この記事では、最新の開発ツールであるMicrosoft Visual Studio 2008を使用して、本当にコンパクトなプログラムを取得する方法について説明します。

例として、コンソールアーカイバ7-zipを移植し、この効果を評価します。

問題と明らかな解決策

ランタイムライブラリ（CRT）を動的にリンクするという明確な決定は、最新バージョンがWindows XPにデフォルトでインストールされていないため、適切ではありません。 そしてもちろん、DLLの形でのCRTの供給は、（この記事の基準による）かなりの量があるため、万能薬ではありません。

別の解決策は、標準のmsvcrt.dllライブラリを使用することです。このライブラリの異なるバージョンは、現在のすべてのバージョンのWindowsにあります。 ただし、このDLLを接続できるインポートライブラリは、Microsoft Visual Studio 6.0でのみ使用可能です。後続のエディションでは、新しいバージョンごとにライブラリを使用します（msvcr70.dll / msvcp70.dll、msvcr71.dll / msvcp71.dllなど）。

msvcrt.dllのインポートライブラリを取得し、VS2008でビルドされているプロジェクトに接続しようとする簡単な試みは、Hello Worldタイプの最も単純なケースでのみ成功します-Windows XPのリリース以降、ランタイムライブラリで大きな変更が発生しました-これは「セキュア」カテゴリの機能の出現ですcrt」、例外処理の変更、および追加のランタイムチェック。

問題解決

この問題の解決策は、Koby Kahaneの記事「 Visual C ++ 2005を使用したMSVCRT.DLLとの動的リンク」で提案されています。

彼は、Windows Driver Kit（WDK）の最新バージョンの調査を行い、興味深い機能を発見しました。WDKに付属する多くのアプリケーションと例では、msvcrt.dllが必要なCRTを使用しています。 さらに、WDKのビルド環境は最新です。最新のWDKのコンパイラバージョンは、VS2008SP1のコンパイラバージョンと同じです。

プロジェクトファイルの詳細な調査により、ソリューションはプロジェクトに接続するいくつかのオブジェクトファイル（msvcrt_win2000.obj、msvcrt_winxp.obj、msvcrt_win2003.obj）にあることがわかります。 基本的に、現在のCRTコンテンツと、対応するWindowsのバージョン名に存在するCRTコンテンツとの「差異」が含まれています。 これは、新しいWindowsのオブジェクトファイルのサイズが古いものよりも小さいという事実を説明しています。

したがって、古典的なmsvcrt.dllを接続するには、2つの簡単な手順に従う必要があります。

• コンパイラキー/ NODEFAULTLIBまたはプロジェクト設定を使用して、すべての標準ライブラリの接続を無効にするリンカー->入力->すべてのデフォルトライブラリを無視
• \ lib \ Crt \ i386 \ msvcrt.lib WDKフォルダーにあるmsvcrt.libインポートライブラリを接続し、アプリケーションを実行するWindowsの最小バージョンに対応するオブジェクトファイルを接続する必要があります。 たとえば、これを\ lib \ Crt \ i386 \ msvcrt_winxp.objとします。

すべて、プロジェクトを組み立てることができ、最も単純なケースでは、コンパイルして正しく動作します。

WDKをお持ちでなく、数メガバイトのライブラリのために600 MBをダウンロードしたくない人のために、必要なファイルを個別に含むアーカイブへのリンクを記事の最後に示しました。

練習-落とし穴とニュアンス

それでは、msvcrt.dllを使用するようにプロジェクトを変換して、何が起こるか見てみましょう。

たとえば、かなり優れたオープンソースアーカイバである7-zipを使用します。 そのソースは7-zip.orgで入手できます。 ちょっとした調査によると、プロジェクトは現在Microsoft Visual C ++ 6.0を使用してビルドされているため、移植が簡単です。

このような魔法の一連のアクションを実行します。

• 最初に、Microsoft Visual C ++ 2008を使用してプロジェクトが正しくビルドされていることを確認します。これを行うには、\ CPP \ 7zip \フォルダーからmakefileを実行します（nmakeを使用）。 以降、すべてのフォルダーは、プロジェクトソースが解凍されたフォルダーに関連して示されます。
• すでに初期のアセンブリ段階で、警告が表示されます（プロジェクトの設定に応じて、エラーと見なされます）C4996： 'wcscpy'：この関数または変数は安全ではない可能性があります。 代わりにwcscpy_sの使用を検討してください。
• さて、この小さな修正を行いましょう。 125行目の\ CPP \ Windows \ Security.cppファイルで、
  
  wcscpy（s、MY__SE_LOCK_MEMORY_NAME）;
  
  に
  
  wcscpy_s（s、128、MY__SE_LOCK_MEMORY_NAME）;
  
  128文字は、即時宣言されたバッファーの最大サイズです
• これで、ビルドプロセスが成功しました。 出力は、7zアーカイバーのすべてのコンポーネント（コンソールバージョン、ファイルマネージャーなど）の実行可能ファイルを受け取りました。 アセンブリの操作性を確認するには、ファイル\ CPP \ 7zip \ UI \ Console \ O \ 7z.exeおよび\ CPP \ 7zip \ Bundles \ Format7zF \ O \ 7z.dllを1つのフォルダーにコピーし、コンソールアーカイバーが動作していることを確認します。 また、正常に起動するには、その横にマニフェストファイルを配置する必要があります。 このプロジェクトでは、記事の添付ファイルに記載されています。

ここで最も興味深い部分は、アプリケーションで従来のランタイムを使用する方法です。 これを行うには、いくつかの魔法のパスを作成します。これは、前のセクションを読んだすべての人にとって明らかです。

• リンカーフラグの\ CPP \ Build.makファイルで、既に無関係なオプション-OPT：NOWIN98を/ NODEFAULTLIBで置き換えます（45行目）
• ここで、最小限の労力でKernel32.lib uuid.libライブラリのリンクを各プロジェクトに追加する必要があります。 各プロジェクトのメイクファイルを個別に編集したくないので、同じ\ CPP \ Build.makで、各プロジェクトに必要なライブラリとモジュールをリンカー設定行に追加します。 したがって、次の設定文字列を取得します。
• LFLAGS = $（LFLAGS）.. \ .. \ msvcrt \ msvcrt_winxp.obj .. \ .. \ msvcrt \ msvcrt.lib Kernel32.lib uuid.lib -nologo -NODEFAULTLIB -OPT：REF -OPT：ICF
• 結果を収集して確認します。 Win7と仮想XPではすべて問題なく動作し、アセンブリによって作成されたアーカイブは元の7zipで正常に開きます。

次に、そのような移植がパフォーマンスにどのように影響したかを確認しましょう。 比較のために、元のアセンブリと2つのアセンブリを使用します。1つはMSVCR90.dllを使用し、もう1つはMSVCRT.dllを使用します。

次の表は、結果のファイルサイズを比較しています。 新しいコンパイラへの移植により、実行可能ファイルのサイズの約10％が自動的に節約されました。

	MS VC 6.0	MS VC 9.0	MS VC 9.0（msvcrt.dll）
7z.exe	150 016バイト	136,704バイト	138,240バイト
7z.dll	726016バイト	655,872バイト	657,920バイト

速度を測定するために、プロジェクトアセンブリの結果として受け取ったすべてのバイナリファイル（約187Mb）をパックします。 各アセンブリは、10回のパッキングサイクルを実行して、ディスクアクセスとキャッシュ速度の影響を軽減し、取得したデータを平均化します。

	MS VC 6.0	MS VC 9.0	MS VC 9.0（msvcrt.dll）
梱包時間	122.86秒	112.02秒	113.73秒

ご覧のとおり、更新されたコンパイラへの切り替えにより、実際のパフォーマンスが向上しました（10％近く、この種のアプリケーションにとってそれほど悪くはありません）。 また、生成されたバイナリファイルは同じ約10％減少しました。

VC90のクラシックランタイムとmsvcrt.dllの使用に大きな違いはありませんでした。

メソッドの制限

ただし、この方法のいくつかの潜在的な欠点と制限に注意する必要があります。

デバッグランタイムmsvcrtd.dllに接続する方法はありません

そのインポートライブラリがWDKに含まれているという事実にもかかわらず、.dll自体は見つかりませんでした。KobyKahane氏によると、MicrosoftはそれをWDKの将来のバージョンに含める予定はありません。

これにより、アプリケーションのデバッグが大幅に複雑になり、リリース前にのみ記事で説明されているメソッドの使用が引き起こされます。これにより、製品の最終的な直接リリースでわかりにくいバグが発生する可能性があります。結局、ランタイムの完全な互換性は保証されません。

MFC、ATL

MFCまたはATLをドラッグアンドドロップして新しい古いランタイムを動的に使用するのはかなり難しいタスクであり、この記事の範囲外です。 ただし、これらのライブラリを使用するアプリケーションの場合、通常、ディスク容量に厳しい要件はありません。

ファイル

記事に添付されているアーカイブ（1.8 Mb）には以下が含まれます。

1. 7z diffフォルダーには、7zipプロジェクトに対するすべての変更が含まれています。 ダウンロードした7z465.tar.bz2をサイトから解凍し、プロジェクトのルートフォルダーの上にパッチをロールします。
2. msvcrtフォルダーには、msvcrt.dllを使用するようにプロジェクトを移植するためのWDKのバイナリが含まれています
3. 出力フォルダーには、テスト結果を信頼せずに再確認したい人のために、コンソールバージョンの7-zipの3つのビルドがすべて含まれています。

ファイルは次の場所からダウンロードできます。http ： //download.zillya.com/attach/MsVCArticlesAttach.zip



更新しました 。 Cryptochildが招待を手伝ってくれました、ありがとう！