VC++10.0 で VC6 の MSVCRT.DLL にリンクすることはできますか?
デフォルトでは MSVCR100.DLL とリンクしているようですが、別の DLL を再配布したくありません (MSVCRT.DLL は、サポートしているすべての OS で既に利用可能です)。
==編集==
明確にするために: 私のアプリケーションは、WinAPI 呼び出しを行う純粋な C アプリケーションです。C++ を実行するには C++ ランタイムが必要であることを理解していますが、これは既定では Windows にバンドルされていません (そして、おそらくコンパイラと一致する必要があります)。私の質問は、純粋な C の使用法と、私が対象としている最も初期のバージョンの Windows に存在する CRT 関数のみについてです。
(エグゼクティブ サマリー (TL;DR) は下部にあります)
重要: この回答は、Microsoft の公式ツールチェーンのみを参照しており、リンクすることが知られている MinGW ツールチェーン (GCC ベース) などには言及していませんmsvcrt.dll。しかし、マイクロソフトがとにかくそのツールチェーンをサポートする傾向があるとは思えません;)
タスクに Visual C++ 2010 を使用しようとさえしないでください。
公式でサポートされている方法があります。アプリケーションをリンクする必要がある場合は、スタンドアロンの WDK を使用してくださいmsvcrt.dll。
CRT ヘッダーおよびライブラリと一致しないコンパイラ ツールチェーンを使用しないでください。ツールチェーンは、作成したパッチワークではなく、Microsoft が意図したとおりに使用してください。混同しないでください。Microsoft から渡されたものを使用します。ただし、それを使用してください (FUD を恐れないでください)。
リンクに使用できる最新の WDK msvcrt.dll(7600.16385.1) は、cl.exeバージョン 15.00.30729.207 を使用します。これは、Visual C++ 2008 に付属するコンパイラにほぼ対応しています。以降の WDK は、必要な Visual C++ バージョンの CRT にリンクします。
msvcrt.dllたとえば、Windows XP または Windows 7 は、Visual C++ 6.0 (VC6の最新バージョンであっても) に含まれていた元のDLL ではありません。
これは、他の回答でも正しく述べられています。そこに驚きはありません。
ただし、msvcrt.dll最新のシステムで見つかるものは、他の回答が示唆するものとは反対に、元の VC6 CRT にリンクされたプログラムが引き続き機能することを可能にします。今日も。契約です。そして、msvcrt.dllシステム DLL への昇格により、そのコントラクトがさらに検証されました。
Microsoft が内部的に使用するツールチェーンは、Windows 8 WDK より前の WDK が提供していたものと多少似ていました。これらについてのみ記述し、WDK (またはスタンドアロン WDK) という用語を一様に使用します。Vista WDK より前は DDK と呼ばれていました。
Windows のソース コードにアクセスできると思われるOSRの善良な人々、またはアクセスできる人々は、私が数年前に参加したあるセミナーで、WDK は Windows を中心に Windows を構築するために内部で使用されるツールチェーンの縮小版であったことを確認しました。時間（〜2005）。同様のヒントは、MSFT 自身の Larry Ostermanと、「Windows Internals」の最近の版の共著者であるtinykrnl に関する Alex Ionescu の初期の作品から見つけることができます。BCZbuild -cZは、ここで説明している WDK で一般的に使用される呼び出しを暗示している可能性があります。
このコンテキストで興味深い理由は、すべてのスタンドアロン WDK でmsvcrt.dll、既定でリンクする実行可能ファイルを作成できることです。スタンドアロン WDKの場合msvcrt.dllはCRT であり、 Visual C++ 2010 の場合と同様にmsvcr100.dll.
また、ツールチェーンが Visual Studio ツールチェーンと共に更新されたことにも注意してください。たとえば、3790.1830 の WDKcl.exeレポートでは、Visual C++ 2003 とほぼ同等です。
C:\WINDDK\3790.1830\bin\x86>cl /version
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.4035 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
また、6001.18002 WDK (Windows 2000 をサポートする最新版!) の場合、Visual C++ 2005 とほぼ同等です。
C:\WINDDK\6001.18002\bin\x86\x86>cl/version
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.278 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
7600.16385.1 WDK の場合、Visual C++ 2008 と同等です。
スタンドアロン WDKXP 用のものから始まり、Windows 7 SP1 まで (および Windows 7 SP1 を含む) の WDK バージョンでは、Visual Studio は必要ありませんでした。彼らには独自のツールチェーンが付属していました。
Windows XP より前のバージョンでは、何かをビルドするために Visual C++ が必要でした。私の記憶が正しければ、Windows 2000 DDK の VC6 です。
Windows 8 WDK 以降のバージョンでは、再び Visual C++ が必要になり、これまで以上に緊密に統合されます (ウィザード、さらにはデバッグ用の拡張機能や一部のドライバー固有のタスクも含まれます)。これが、それぞれの WDK を使用するときに、それぞれのツールチェーンの CRT にリンクする理由でもあります。
スタンドアロン WDK の時代には、人々が Visual Studio を使用して WDK ビルド プロセスをラップしようとしたことは前代未聞ではありませんでした。Microsoft が推奨するサポートされていない方法を使用し、Visual Studio ツールチェーンを使用してドライバーを構築した人もいます。これらのサポートされていない方法は、おおむねあなたが試みていることになります。だからしないでください。
とにかく、WDK のbuild.exewithsourcesなどを使用したビルド プロセスmakefileは面倒で制限がありました。たとえば、現在のディレクトリまたはその親ディレクトリ以外のソース ファイルからビルドするには、独自の NMake ルールを作成する必要があります。結局のところbuild.exe、NMake ベースのビルドのラッパーでした。あなたのローカルmakefile.incは、WDK/DDK によって提供されるグローバルなものに含まれます。
msvcrt.dllが公式にサポートされている理由前述のように、リンクmsvcrt.dllはスタンドアロン WDK でサポートされています。
これもまったく問題ありません。実際、ファイルUSE_MSVCRT=1内のステートメントsourcesはまさにその効果があります。ここを参照してください。7600.16385.1 WDK ドキュメントからの引用:
USE_MSVCRTこのマクロを使用して
USE_MSVCRT、Build ユーティリティがビルド用の DLL でマルチスレッド ランタイム ライブラリを使用するように指示します。構文
USE_MSVCRT = 1[...]
注:
Msvcrt.libまたはを に リストしないMsvcrtd.libでTARGETLIBSください。Ntdll.libただし、 にリストすることはできますTARGETLIBS。
サポートされていないのに、なぜ Microsoft はこのパスを提供するのでしょうか? 正しい、彼らはしません!
実際のところ、WDK (XP..7 SP1) はシステム DLL msvcrt.dllを CRT として使用しています。
主に1つの注意事項があります。SEH の実装方法は、Visual C++ の新しいバージョンで時間の経過とともに変化しています。スタンドアロン WDK のツールチェーンは、特定の Visual C++ バージョンに密接に対応しているため、それぞれの SEH 処理を継承しています。
たとえば、Windows 7 SP1 WDK を使用して Windows 7 を対象としUSE_MSVCRT=1、_except_handler4_common. たとえば、その機能は Windows Server 2003 では使用できませんでした。そのため、ターゲットバージョンより前のバージョンの Windows でこのようなアプリケーションを実行しようとすると、失敗する可能性があります。そのような場合、「サポートされていない領域」に足を踏み入れることになり、すべての免責事項が適用されます。ただし、ここで概説されている方法を使用するオプションがあります。つまりmsvcrt_win2000.obj、 、msvcrt_winxp.objおよびmsvcrt_win2003.obj(Vista および 7 WDK で使用可能) にリンクして、希望する (バイナリ) 下位互換性のレベルを達成することができます。
一方、設定することに決めた場合WINVER=0x0601、結果の実行可能ファイルが、たとえば Windows XP では利用できない kernel32.dll (または他のシステム DLL) から関数をインポートすることに驚かないでください。では、なぜ に関して異なるセマンティクスを期待するのmsvcrt.dllでしょうか?
別の補足として、チェックされたビルド (通常、デバッグ ビルドに対応すると見なされます) でさえmsvcrt.dll、デバッグ バージョンの対応物ではなく、 に対してリンクします! 「チェック済み」とは、アサーションが残っているという事実を指すためです。「リリース」や「デバッグ」など、CRT の特定の構成を指すものではありません。msvcrt.dllスタンドアロン WDK でのデバッグ ビルドが利用できないということは、それらの WDKのC ランタイムではないことを意味するという仮定は、チェック ビルドが何を意味するかについての明白で単純な誤解です。
もう 1 つ小さな注意事項があります。たとえば、Windows 7 WDK を使用して へのリンクを実現する場合、 Windows 7以降msvcrt.dllの開発を認識していないツールチェーンを使用しています。これには、インポート ライブラリだけでなく、ヘッダーも含まれます。そのため、リリース時に利用できなかった機能をサポートするとは思わないでください。
msvcrt.dllmsvcrt.dllは、数年前にシステム DLL のステータスに昇格されました。これは、それぞれの再頒布可能パッケージをインストールする必要がある他の Visual C++ CRT とは異なり、システムに含まれていることを意味します (文字通り信頼できます)。これは、別の回答で引用された Raymond Chen によるブログ投稿の要点でもあります。
スタンドアロンの WDK (XP..7 SP1) はデフォルトでmsvcrt.dllCRT としてリンクするため、それに対する客観的な議論はありません。もちろん意見は様々。
残念ながら、私が最初にコメントしてから大きく変わったこの回答は、FUDを永続させ、信頼できるとされる情報源からの引用を文脈から引き出そうとします。また、元の (MSFT) ソースへのリンクも含まれています。これらのソースは、よく調べてみると、リンクされたサポートのステートメントをサポートしていません。
Microsoft の Raymond Chen は、数年前にこれについてブログを書きました。彼のブログからWindows is not a Microsoft Visual C/C++ Run-Time delivery channel :
Visual C++ のすべてのバージョンと互換性のある 1 つの DLL は、メンテナンスの悪夢でした... ある時点で、それをオペレーティング システム DLL として宣言し、オペレーティング システム コンポーネントのみが使用できるようにするという決定が下されました。
鉱山を強調します。もう一度考えてみてください。本当に Windows に付属するものを書いているのでしょうか? Microsoftが 10 年以上前にコンパイラの互換性を断念したシステム コンポーネントに依存する代わりに、サポートされているファイルをセットアップ プログラムに追加したり、CRT の静的バージョンをリンクしたりするのは難しいですか?
さて、2010 年 2 月は 10 年以上も前のことでしょうか (この回答が書かれたのは 2016 年 3 月)? . _ _ msvcrt.dll_
Raymond の発言の残りの部分は、Microsoft が最初に意図したものと一致する可能性がありますが、Microsoft がそれをあきらめて、システム DLL に昇格させたことを認めています。
また、真に古い歴史 (Windows 9x) と、Windows 9x をサポートしていないスタンドアロンの WDK の使用を推奨する推奨事項を混在させるのは、非常に不誠実です。Raymond が説明する歴史的背景は、W2K より前であり、NT ではありません。上記で説明した背景は、Windows の NT 系統に言及しており、実際にはスタンドアロンの DDK/WDK (およびそれ以降) しか知らないため、それ以前はどうだったか、またはそうあるべきだったかはわかりません。
つまり、彼のブログはMicrosoft の公式ドキュメントと混同されるべきではありません。
10 年以上前のことですがmsvcrt.dll、Windows 2000 (SP4) のバージョン情報には次のように記載されています。
Description: Microsoft (R) C Runtime Library
Product: Microsoft (R) Visual C++
Prod version: 6.10.9844.0
File version: 6.10.9844.0
... レイモンドの紹介文に反します。
Windows XP でのみ、次のように変更されました。
Description: Windows NT CRT DLL
Product: Microsoft« Windows« Operating System
この決定を未だに否定している人々の数は驚くべきものです。
いくつかの以前のコメントの後、これが私を真っ向から狙っていると推測するのは公正です.
Windows 8 WDK のリリースに関する決定を否定しているわけではありません。ただし、それはリンクを公式にサポートしたスタンドアロン WDK を「リリース解除」msvcrt.dllしたり、それぞれの公式ドキュメントに記載されている内容を「ドキュメント解除」したりしません。
ねえ、Windows 7 または 8 以降、またはそれに沿ったものだけをサポートする必要があるという贅沢な立場にいるのは、私にとって素晴らしいことです。ただし、以前の Windows バージョンもサポートする必要があるため、これらの Windows バージョン用に Microsoft が提供する公式ツールを最大限に活用します。適切な SDK が統合された Visual C++ 2005 であること、またはスタンドアロンの WDK であること。
それらの人々は、「Visual C++ 製品チームに多くの悲しみをもたらしました」
この声明は、Raymond Chen による前述のブログ投稿を参照していますが、Raymond の声明を文脈、特に時間的な文脈から切り離しています。悲しみは、質問者がやりたいことを人々が試みたことによって引き起こされました-さらに悪いことに、の内臓/内部に手を伸ばしましたmsvcrt.dll. そして、それはW2K以前でした。これは、Microsoft のスタンドアロン WDK のような公式のツールチェーンを使用したことが原因ではありません(また、そうなる可能性もありません)。
最新バージョンの Windows の msvcrt バージョンは、対応するバージョンの Windows SDK では言及されていません。
モダンは修飾する必要がありますが、「Windows SDK」の使用は、「プラットフォーム SDK」から名前が変更された後のすべての Windows SDK を参照することを示唆しています。そして、私はそれをすぐに信じる傾向があります。しかし、ポスターはスタンドアロンの Windows WDK (およびその前の DDK) を無視しています。これらは、それについて言及するだけでなくmsvcrt.dll、CRT としても使用します。これらは、カーネルとユーザー モードの両方の開発を目的とした Microsoft の公式ツールチェーンです。
Microsoft は、公開されているか公開されていない最新のツールチェーンを使用して、CRT DLL を更新します (たとえば、Windows Media Player パッチをリリースする場合)。
そのとおりです。システム DLL にプロモートされているためmsvcrt.dll、更新され続けます。これは、WDK を使用するときに信頼できるコントラクトです。パッチを適用しているという理由だけで、独自のツールチェーンで構築されたアプリケーションを壊すつもりはありません。msvcrt.dll
古い WDK コンパイラとライブラリを使用して Windows で msvcrt DLL をビルドしていないことを期待できます。
確かなことはわかりませんが、2010 年以降の公式のツールチェーンは、私が古代と呼ぶようなものではありません。さらに、Microsoft はその間に XP と 2003 のサポートを中止したため、Vista 以降のみをサポートする必要があります。これは、Windows 8 以降の WDK 用のコンパイラとツールを直接提供する最新の Visual C++ バージョンを使用すると、より簡単になります。
(なぜ古いのですか? WDK チームは、人々がコンパイラを使用して msvcrt にリンクすることを好まないため、バージョン 8.0 の抜け穴を削除して、それらの「賢い」人々を阻止しました)。
ああ、本当に、ドロンはリンクされたフォーラムの投稿で実際にそれを言っていますか? うーん、ダメ：
Windows CRT (msvcrt.dll) に対してリンクしたため、win7 wdk ビルドが正常に展開されました。サードパーティにこれ以上行わせたくない ため、win8 wdk でその機能を削除しました。後方互換性のために引き続き機能します。正常に展開される可能性がありますが、正しい CRT を使用していることを確認する wck ロゴ チェックがある場合があります。
(私のものを強調)
この声明は、マイクロソフトが姿勢を変えるための「政治的決定」 (およびその公式決定) に関するものです。実際、「もう」というのは、これが Windows 8 WDK でのみ変更されたことを意味します。Visual C++ と再び統合された最初の最新の WDK (Windows 2000 DDK 以来)。そのため、WDK はスタンドアロン ツールチェーンから特定の Visual C++ バージョンと統合される拡張機能に降格されているため、新しい要件はまったく驚くべきことではありません。
msvcrt.dllところで、 CRT として使用するスタンドアロン WDK に関する提案がそのポリシー変更の前にあったときに、Windows 8 WDK 以降に基づいて議論するのも不誠実です。msvcrt.dllまた、システム DLL への昇格に至った経緯と、昇格後の時代を混同するのも不誠実です。
この回答に反して、 msvcrt.dll(XP..7 SP1) へのリンクを「ネイティブに」サポートするスタンドアロン WDK など、Microsoft 独自の変更されていないツールチェーンを使用してもまったく問題ありません。これらのツールチェーンに付属のドキュメントにも記載されています (インストールしないか目を閉じない限り:))。
ビルド時に正しい Windows バージョンをターゲットにすることを確認する必要があるのは"だけ" です(基本的に、正しい を定義するのと同じですWINVER)。kernel32.dllしかし、他のシステム DLL (例: user32.dll...)についても同じことが言えます。
ただし、 2002 年以降の Visual C++を使用してリンクすると、必ず問題が発生します。混同しないでください。これらの特定の Visual C++ バージョンに一致する CRT を使用するだけです。msvcrt.dll
VC6 ランタイムではありません。これは、Visual Studio ではなく Windows にバンドルされている MSVCRT.DLL のシステム コピーです。ファイル サイズを確認するとわかるように、Windows の新しいバージョンごとに新しいバージョンの MSVCRT.DLL が取得されます。
Windows Driver Kit を使用して、MSVCRT.DLL のシステム コピーに対してコンパイルできます。この DLL は、「システム レベルのコンポーネントでのみ」使用されることに注意してください。システムレベルのコンポーネントとは? さて、運転手。または、たとえば、テキスト サービス:
http://blogs.msdn.com/b/tsfaware/archive/2008/01/17/visual-studio-2008-issues.aspx
テキスト サービス DLL を構築している場合は、Vista (または XP) DDK をインストールし、代わりに DDKWizard を使用することをお勧めします。DDK には、OS に同梱されている C ランタイム ライブラリを使用する独自の C/C++ コンパイラが付属しています (他のアプリケーションで問題が発生することはありません) ...
詳しくは：
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/
Microsoft は何をしているのかという疑問が生じます。アプリケーションをさまざまな Windows 環境に展開します。Windbg の依存関係を調べたところ、新しい CRT ではなく、MSVCRT.DLL が使用されていることがわかりました。Microsoft の新しい Network Monitor 3.1 も MSVCRT.DLL を使用します。Windows デスクトップ サーチも、古くて信頼できる CRT を使用しています。
これらすべての新しいアプリケーションがビンテージ CRT をどのように使用できるのでしょうか? サポートされていない旧式の Visual C++ 6.0 をまだ使用していませんか? うーん、ダメ。答えはもっと複雑で、Windows Driver Kit (WDK) で見つけることができます。
更新: Windows 8 Driver Kit では、新しい MSBuild ベースのビルド システムが導入されました。これは、MSVCRT.DLL のシステム コピーにリンクしなくなりました。ただし、Windows 7 Driver Kit でビルドされたバイナリは、Windows 8 および Windows 10 でも動作します。
MSVCRT.DLL は、下位互換性のために引き続き Windows 10 に同梱されているため、ファイル バージョンは 7.0.##### です。user32.dll など、現在も開発が活発に行われているコンポーネントのファイル バージョンは 10.0.##### です。
これには、メジャー コンパイラ リリース間での CRT 互換性が必要です。Microsoft はこれに対応しようとしましたが (たとえば、VC6SP2 ランタイムに VC5 ヒープを追加)、最終的にはあきらめて、現在使用されている msvcrxx.dll を導入しました。CRT ソースを見ると、多くの #ifndef _SYSCRT が見つかります。これは、Microsoft の msvcrt.dll と、コードを生成するときにコンパイラが使用するものとの違いです。
Microsoft の Raymond Chen は、数年前にこれについてブログを書きました。彼のブログからWindows is not a Microsoft Visual C/C++ Run-Time delivery channel :
Visual C++ のすべてのバージョンと互換性のある 1 つの DLL は、メンテナンスの悪夢でした... ある時点で、それをオペレーティング システム DLL として宣言し、オペレーティング システム コンポーネントのみが使用できるようにするという決定が下されました。
鉱山を強調します。Microsoftが 10 年以上前にコンパイラの互換性を放棄したシステム コンポーネントに依存する代わりに、サポートされているファイルをセットアップ プログラムに追加したり、静的バージョンの CRT をリンクしたりするのは、それほど難しいことでしょうか?
この決定を未だに否定している人々の数は驚くべきものです。それらの人々は、「Visual C++ 製品チームに多くの悲しみをもたらしました」。あなたが彼らを怒らせ続けるなら、多くの VC6 アプリをクラッシュさせた Windows XP で彼らがしたように、彼らが時々あなたを怒らせても驚かないでしょう。. 多くの人が、Windows 2000 アプリケーション開発者のガイドラインに従わず、設定やゲームの保存ファイルを Program Files フォルダに入れませんでした。Windows Vista がリリースされたときの結末がいかに良いものであったかは、誰もが知っています。
ちなみにdllはVC6のものではありません。システムで古い dll を使用すると、Microsoft のセキュリティ開発ライフサイクルが自動的に失敗します。( https://blogs.msdn.microsoft.com/oldnewthing/20100607-00/?p=13793/#10020962 )。Microsoft が VC6 を使用して最新の製品をコンパイルすることを現実的に期待していませんか?
最新バージョンの Windows の msvcrt バージョンは、対応するバージョンの Windows SDK では言及されていません。使用するコンパイラのバージョンまたは CRT lib のバージョンに関係なく、顧客のコンピューターの DLL バージョンの大部分と一致しない可能性が高くなります。Microsoft は、公開されている場合と公開されていない場合がある最新のツールチェーンを使用して、CRT DLL を更新します (たとえば、Windows Media Player パッチをリリースする場合)。古い WDK コンパイラとライブラリを使用して Windows で msvcrt DLL をビルドしていないことを期待できます (なぜ古いのですか? WDK チームは、人々がコンパイラを使用して msvcrt にリンクすることを好まないため、バージョン8.0 の抜け穴を削除してそれらの「賢い」人々を止めてください）。