Как связать с msvcrt.dll вместо msvcr100.dll в VС++ 10.0?

Ответ 1

Это не время выполнения VC6. Скорее, он был исправлен и обновлен с каждой новой версией Windows. Просто просмотрите размеры файлов в разных версиях Windows.

Вы можете скомпилировать файл MSVCRT.DLL с помощью набора драйверов Windows. Обратите внимание, что эта DLL предназначена для использования "только компонентами системного уровня". Какой компонент системного уровня? Ну, водитель. Или, например, текстовую службу:

http://blogs.msdn.com/b/tsfaware/archive/2008/01/17/visual-studio-2008-issues.aspx

Если вы создаете текстовую службу DLL... Я бы рекомендовал установить Vista (или XP) DDK и вместо этого используйте DDKWizard. DDK приходит с его собственным компилятором C/С++, который использует C Runtime Library, которая отправляет с ОС (и не вызовет проблем с другими приложениями)...

Дополнительная информация:

http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

Возникает вопрос, что делает Microsoft? Они развертывают свои приложений в различных средах Windows. Взгляните на Windbgs зависимостей показали, что он использует MSVCRT.DLL, а не один из новых Кинескопы. В Microsoft Network Network 3.1 также используется MSVCRT.DLL. Windows Desktop Search также использует старый, надежный CRT.

Как все эти новые приложения могут использовать старинный CRT? Theyre не все еще используя антикварный, неподдерживаемый Visual С++ 6.0, не так ли? Ну нет. Ответ более сложный и может быть найден в Набор драйверов для Windows (WDK).

Обновление. В наборе драйверов Windows 8 используется новая система сборки на основе MSBuild, которая больше не связана с системной копией MSVCRT.DLL. До сих пор двоичные файлы, созданные с помощью набора драйверов для Windows 7, отлично работали в Windows 8.

Ответ 2

(вы можете найти резюме, или TL; DR, внизу)

Важно. Этот ответ относится только к официальным инструментам Microsoft, но не к чему-то вроде инструментальной комбинации MinGW (GCC-based), которая также, как известно, связана с msvcrt.dll. Но я сомневаюсь, что Microsoft будет склонна поддерживать эту инструментальную цепочку;)

Короткий ответ: нет!

Не пытайтесь использовать Visual С++ 2010 для этой задачи.

Существует официальный и поддерживаемый метод: используйте автономный WDK, если вам нужно, чтобы ваше приложение связывалось с msvcrt.dll!

Вы никогда не должны пытаться использовать компиляторную цепочку, которая не соответствует заголовкам и библиотекам CRT. Используйте инструментальные средства, как предполагалось Microsoft, а не созданный вами пэчворк. Не смешивайте и не смешивайте. Используйте то, что было передано вам Microsoft. Но используйте это (и не бойтесь FUD).

Самый новый WDK, который вы можете использовать для ссылки на msvcrt.dll (7600.16385.1), использует cl.exe версию 15.00.30729.207. Этот соответствует примерно компилятору, который поставляется с Visual С++ 2008! Позднее WDK свяжутся с CRT версии Visual С++, которую они требуют.

msvcrt.dll вы найдете, скажем, Windows XP или Windows 7, а не оригинальная DLL, которая была включена в Visual С++ 6.0 (даже самая обновленная версия VC6).

Это также было правильно указано в других ответах. Никаких сюрпризов нет.

Тем не менее, msvcrt.dll, который вы найдете в современных системах, в отличие от того, что предлагают другие ответы, позволяет программам, которые связаны с оригинальным VC6 CRT, продолжать работать. Даже сегодня. Это контракт. И продвижение msvcrt.dll в системную DLL подтвердило этот контракт.

Небольшой исторический фон

Инструментальные средства, используемые Microsoft внутри страны, были несколько похожи на то, что WDK до предоставления Windows 8 WDK. Я буду писать исключительно об этом и использовать термин WDK (или автономный WDK) равномерно, даже если до Vista WDK их называли DDK.

Хорошие люди из OSR, у которых, похоже, есть доступ к исходному коду Windows или людям, которые это делают, подтвержденные во время одного семинара я несколько лет назад наблюдал, что WDK раньше была обрезанной версией инструментальной линейки, используемой внутри, для создания Windows примерно в то же время (~ 2005). Подобные подсказки можно найти от MSFT собственного Ларри Остермана и ранние работы Алекса Ионеску на tinykrnl, соавтор последних выпусков "Windows Internals".

В этом контексте интересно, что все автономные WDK позволяют создавать исполняемые файлы, которые по умолчанию связаны с msvcrt.dll. Для автономных WDK msvcrt.dll используется CRT, как и для Visual С++ 2010, msvcr100.dll.

Следует также отметить, что инструментальные цепочки были обновлены рядом с инструментальными целями Visual Studio. Например, в отчетах WDK cl.exe 3790.1830 как примерно соответствует параметру Visual С++ 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 С++ 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 С++ 2008.

Версии WDK, начиная с версии для XP и вплоть до (и включая) Windows 7 SP1, не требуют Visual Studio. Они пришли со своей собственной инструментальной цепочкой.

Для версий до Windows XP требуется Visual С++. Если я правильно помню VC6 для DDK Windows 2000.

Версии, начиная с Windows 8 WDK, требуют Visual С++ снова и интегрируются с ним более жестко, чем когда-либо. Именно поэтому, когда вы используете соответствующие WDK, они будут ссылаться на CRT соответствующей инструментальной цепочки.

Во время автономных WDK это не было неслыханным - и что сама причина для DDKWizard и более поздняя VisualDDK - что люди попробовал использовать Visual Studio для завершения процесса сборки WDK. Некоторые даже использовали неподдерживаемый метод, рекомендованный Microsoft против, и построил свои драйверы с инструментальными средствами Visual Studio. Эти неподдерживаемые методы примерно соответствуют тому, что вы пытаетесь сделать. Так что не делайте этого.

В любом случае процесс сборки с использованием WDK build.exe с sources и makefile и т.д. был громоздким и ограничивающим. Например, чтобы построить из любого исходного файла за пределами текущего каталога или его родительского каталога, вам придется писать свои собственные правила NMake. В конце концов, build.exe был оберткой вокруг сборки на основе NMake.

Почему привязка к 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.

Предостережения

Там в основном одна оговорка. Способ реализации SEH со временем изменился с новыми версиями Visual С++. Поскольку привязки из автономного WDK тесно связаны с конкретной версией Visual С++, они наследуют соответствующую обработку SEH.

Например, если вы используете WDK для Windows 7 с пакетом обновления 1 для целевой Windows 7 и USE_MSVCRT=1, он статически импортирует _except_handler4_common. Например, эта функция недоступна в Windows Server 2003. Поэтому попытка запустить такое приложение в версиях Windows до целевой версии может завершиться неудачей. Поэтому в таком случае вы отправляетесь на "неподдерживаемую территорию", и все заявления об отказе от ответственности применяются.

Ну, с другой стороны, если вы решите установить WINVER=0x0601, вам также не следует удивляться, обнаружив, что получаемые исполняемые функции импорта из kernel32.dll(или других системных DLL), которые недоступны, скажем, Windows XP.

В качестве еще одной заметки: даже проверенные сборки (обычно считающиеся совместимыми с отладочными сборками) также связаны с msvcrt.dll, а не с его отладочной версией! Поскольку "проверено" относится к тому факту, что утверждения остаются; он не относится к конкретным конфигурациям ЭЛТ. Предположение о том, что отсутствие отладочной сборки для msvcrt.dll в автономных WDK означает, что это не так, C-среда выполнения этих WDK проста и проста в недоразумении того, что проверила сборка.

Есть еще одно небольшое предостережение. Если вы используете, скажем, Windows 7 WDK, для достижения привязки к msvcrt.dll, вы используете инструментальную цепочку, которая не знает о событиях с Windows 7. Это включает библиотеки импорта, но также заголовки. Поэтому не ожидайте поддержки функций, которые были недоступны в момент его выпуска.

Системная DLL: msvcrt.dll

msvcrt.dll несколько лет назад был присвоен статус системной DLL, что означает, что он входит в систему (и на нее можно положиться, в буквальном смысле), в отличие от других ЭЛТ Visual С++, для чего вам необходимо установить соответствующие распространяемые пакеты. Что также является сущностью блога Раймонда Чена, приведенного в другом ответе.

Поскольку автономные WDK (XP..7 SP1) по умолчанию ссылаются на msvcrt.dll как на их CRT, нет объективного аргумента против него. Конечно, мнения меняются.

"Ответ"

К сожалению этот ответ, который изменил много, поскольку я впервые прокомментировал это, увековечивает FUD и пытается вытаскивать цитаты из якобы авторитетных источников из контекста. Он также ссылается на исходные (MSFT) источники, которые - при закрытой проверке - не поддерживают заявления, для поддержки которых они были связаны.

Microsoft Raymond Chen написал об этом несколько лет назад. От его blog Windows не является службой Microsoft Visual C/С++ Run-Time канал:

одна DLL, совместимая со всеми версиями Visual С++, была кошмаром для обслуживания... В какой-то момент было принято решение просто отказаться от   объявите его операционной системой DLL, , используемой только при работе   системные компоненты.

Акцент мой. Подумайте еще раз, вы действительно пишете что-то, что корабли с Windows? Трудно ли добавить поддерживаемый файл в вашей программы установки или ссылку на статическую версию CRT вместо в зависимости от системного компонента, который Microsoft отказался от компилятора совместимость более десятилетия назад?

Хорошо, так февраль 2010 года более десяти лет назад (время, когда этот ответ был написан: март 2016 года)? Потому что дата выпуска 7600.16385.1 WDK, которая официально поддерживает привязку к msvcrt.dll.

И остальные инструкции Raymond могут соответствовать тому, что первоначально предполагалось Microsoft, но он даже признает, что они отказались от этого и продвинули его в системную DLL.

Кроме того, совершенно нечестно смешивать по-настоящему древнюю историю (Windows 9x) с рекомендациями в пользу использования автономных WDK, которые даже не поддерживают Windows 9x. Исторический фон Raymond описывает pre-W2K и non-NT. Описанный выше фон относится к линии NT для Windows, и я знаю только автономные DDK/WDK (и более новые) из практики, поэтому я не могу сказать, как это было или должно было быть до этого.

Все, что сказал: его блог не следует путать с официальной документацией от Microsoft, хотя в его блоге можно найти много драгоценных камней, и я долгое время был жадным читателем.

И хотя это более десятилетия назад, информация о версии 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, поэтому я полностью использую официальные инструменты, предоставленные Microsoft для этих версий Windows. Будь то Visual С++ 2005 с соответствующим SDK интегрированным или быть автономным WDK.

Эти люди вызвали "много горя для команды разработчиков Visual С++"

Это утверждение относится к вышеупомянутому сообщению msvcrt.dll как их CRT. Это официальные инструментальные средства от Microsoft.

Microsoft обновляет DLL CRT (например, при выпуске патча для проигрывателя Windows Media) с использованием текущей инструментальной цепочки, которая может быть обнародована или не опубликована.

Это правильно. msvcrt.dll постоянно обновляется, поскольку его продвигают в системную DLL. И это контракт, на который можно положиться при использовании WDK. Они не собираются прерывать приложения, созданные своими собственными инструментальными цепочками, только потому, что они исправляют msvcrt.dll.

Вы можете рассчитывать на то, что они не используют древний компилятор WDK и библиотеки libs для создания DLL файлов msvcrt в Windows

Я даже не был бы в этом уверен, но формальная официальная с 2010 года - это не то, что я бы назвал древним. Кроме того, поскольку Microsoft тем временем отказалась от поддержки XP и 2003, им нужно только поддерживать Vista и далее. Это будет проще с последней версией Visual С++, которая напрямую предоставляет компилятор и инструменты для WDK, начиная с Windows 8.

(почему древний? Потому что команда WDK не любит, чтобы люди использовали свой компилятор для связи с msvcrt, и удалили лазейку в версии 8.0, чтобы остановить этих "умных" людей).

На самом деле, действительно ли Дорон говорит, что на связанном форуме? Ну, нет:

win7 wdk build развернут успешно, потому что вы связаны с окна CRT (msvcrt.dll). мы не хотим, чтобы третьи стороны делали это больше, поэтому мы удалили эту возможность в win8 wdk. он все еще работает для обратной совместимости. в то время как он может успешно развернуться, могут быть проверены логотипы whck, чтобы убедиться, что вы используете правильный CRT

(акцент мой)

В заявлении говорится о "политическом решении" (и официальном в этом) Microsoft, чтобы изменить свою позицию. "Больше" на самом деле означает, что это изменилось только с Windows WDK. Первый современный WDK, который снова интегрируется с Visual С++ (с Windows 2000 DDK). Так как WDK был понижен с помощью отдельной инструментальной цепочки на расширение, которое интегрируется с данной версией Visual С++, новые требования не удивительно.

Это, кстати, также нечестно спорить на основе Windows WDK и новее, когда предложения относительно автономных WDK, которые используют msvcrt.dll в качестве своего CRT, были до этого изменения политики. Также нечестно смешивать историю, которая привела к продвижению msvcrt.dll в системную DLL с эрой после того, как она была повышена.

Глоссарий

• CRT == Время выполнения C/С++
• 3790.1830 == Windows Server 2003 с пакетом обновления 1 (SP1) Комплект разработки драйверов (DDK)
• 6001.18002 == Комплект драйверов Windows SP1 для Windows Server 2008/Vista​​li >
• 7600.16385.1 == Windows Driver Kit версии 7.1.0 (поддержка Windows 7, Windows Vista, Windows XP, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003)

TL; DR

В отличие от этого ответа, отлично использовать Microsoft собственные и неизменные инструментальные цепочки, такие как автономные WDK, которые поддерживают привязку к msvcrt.dll (XP.. 7 SP1) "изначально". Он даже задокументирован в документации, которая поставляется с этими инструментальными цепочками (если вы не решите не устанавливать ее или закрыть глаза:)).

Вам нужно "только", чтобы убедиться, что вы настроили правильную версию Windows при построении (по сути, это то же самое, что и определение правильного WINVER). Но то же самое можно сказать и для других системных DLL (например, kernel32.dll, user32.dll...).

Однако, используя любой Visual С++ с 2002 года, чтобы связать с msvcrt.dll привязан, чтобы создать Проблема. Не смешивайте и не смешивайте. Просто используйте CRT, соответствующий тем конкретным версиям Visual С++.

Ответ 3

Средней программе Win32 в стиле "Петцольд" требуется только несколько функций из файла msvcrt.dll. В моем случае мне часто нужны подпрограммы форматирования с плавающей запятой, такие как _sntprintf(). И маловероятно, что функциональность таких функций когда-либо изменится. По этой причине я создал библиотеку импорта "msvcrt-light.lib" в качестве замены стандартной библиотеки, которую я включил в проект MSVC. (http://www.tu-chemnitz.de/~heha/hs/msvcrt-light.zip/)

Для полноценных программ на С++ msvcrt-light.lib может вообще не подходить. Используйте DDK, как указано выше.

Ответ 4

Для этого требуется совместимость с CRT в основных выпусках компиляторов, которые Microsoft попыталась разместить (например, добавила кучу VC5 в среду выполнения VC6SP2), но в итоге отказалась и ввела msvcrxx.dll, которые используются сегодня. Если вы посмотрите на источник CRT, вы найдете много #ifndef _SYSCRT, что разница между Microsoft msvcrt.dll и тем, что используется вашим компилятором при генерации кода.

Microsoft Raymond Chen написал об этом несколько лет назад. Из своего блога Windows не является каналом доставки Microsoft Visual C/С++:

одна DLL, совместимая со всеми версиями Visual С++, была кошмаром обслуживания... В какой-то момент было принято решение просто сдаться и объявить операционная система DLL, используется только компонентами операционной системы.

Акцент мой. Подумайте еще, не так ли сложно добавить поддерживаемый файл в вашу программу установки или связать статическую версию CRT, а не в зависимости от системного компонента, который Microsoft отказался от совместимости компилятора более десяти лет назад?

Удивительно, сколько людей все еще отрицает это решение. Эти люди вызвали "много горя для команды разработчиков Visual С++" , и если вы продолжаете обманывать их, я не удивлюсь если они иногда мочат вас, как что они сделали в Windows XP, которые разбили много приложений VC6. Многие люди не следовали рекомендациям разработчиков приложений Windows 2000 и помещали настройки/игры в папку Program Files. Мы все знаем, какое прекрасное завершение, когда была выпущена Windows Vista.

Кстати, dll не является VC6. Использование старой dll в системе автоматически завершит жизненный цикл разработки Microsoft Security. (https://blogs.msdn.microsoft.com/oldnewthing/20100607-00/?p=13793/#10020962). Вы реально не ожидаете, что Microsoft использует VC6 для компиляции своего современного продукта, не так ли?

Версия msvcrt в современных версиях Windows никогда не упоминалась в соответствующих версиях Windows SDK. Независимо от используемой версии компилятора или версии CRT lib она скорее всего не будет соответствовать большинству версий DLL на вашей клиентской машине. Microsoft обновляет DLL CRT (например, когда освобождает патч для проигрывателя Windows Media) с использованием текущей инструментальной цепочки, которая может быть или не быть обнародована. Вы можете рассчитывать на то, что они не, используя древний компилятор WDK и библиотеки libs для создания DLL-библиотеки msvcrt в Windows (почему древний? Потому что Команда WDK не любит, чтобы люди использовали свой компилятор для связи с msvcrt, и удалили лазейку в версии 8.0, чтобы остановить этих "умных" людей).