Комментарии 26
Тэги к посту — прекрасны.
НЛО прилетело и опубликовало эту надпись здесь
Как-то обидно сейчас стало. Разве можно здесь зонды устанавливать, Microsoft?
Возможно назвали бы они это не телеметрией, было бы не так неприятно, но все равно непонятно зачем так утяжелять рантайм.
Возможно назвали бы они это не телеметрией, было бы не так неприятно, но все равно непонятно зачем так утяжелять рантайм.
Ну логи по дефолту не пишутся, поэтому рантайм не утяжеляется.
Т.е. по вашему если в моей программе где-то без моего ведома дергаются WinApi функции это ее _совершенно_ не утяжеляет?
Как минимум это занимает ощутимое место в exe-шнике.
По правде, много места оно не занимает. Я всегда линкую рантайм статически (не люблю лишние зависимости), но после перехода на VS2015 с VS2013 обнаружил, что почти все, что я собираю, стало чуточку меньше в размерах. Т.е. лишний код телеметрии не превышает выгоды от улучшенного оптимизатора новой студии.
Но, соглашусь, сам факт наличия бесполезного кода вносит в мою тонкую душевную организацию немного хаоса.
Для статически линкуемого рантайма способ отключения этой гадости я предложил в комменте ниже.
Но, соглашусь, сам факт наличия бесполезного кода вносит в мою тонкую душевную организацию немного хаоса.
Для статически линкуемого рантайма способ отключения этой гадости я предложил в комменте ниже.
Все же утяжеляется, раз есть код который пишет логи когда они включены. Другой момент который меня беспокоит — когда мы линкуем райнтайм динамически, так на этапе разработки мы не можем знать как поведет себя логирование и телеметрия, Microsoft может обновить рантайм в апдейте Windows 10 и ваше приложение уже после выпуска будет отправлять в MS данные по полной.
Еще один момент смущает, что Microsoft не включили исходники telemetry.cpp в поставку исходников RTL, значит есть что скрывать :-)
Еще один момент смущает, что Microsoft не включили исходники telemetry.cpp в поставку исходников RTL, значит есть что скрывать :-)
Даже если мы линкуем рантайм статически, мы не можем знать, как поведёт себя логирование и телеметрия.
hello.exe из статьи — вполне готовый бинарник, на его месте может быть любая собранная программа. А logman/tracerpt могут быть запущены совершенно независимо от него и от ведома разработчика hello.exe. В том числе апдейтом Windows. В том числе не трогающем vcruntime140.dll или как она там называется.
hello.exe из статьи — вполне готовый бинарник, на его месте может быть любая собранная программа. А logman/tracerpt могут быть запущены совершенно независимо от него и от ведома разработчика hello.exe. В том числе апдейтом Windows. В том числе не трогающем vcruntime140.dll или как она там называется.
В Visual Studio 2013 такого не нашёл… но на работе не последнее обновление. А отключить телеметрию в исходниках пробовал кто-то?
Прологи и эпилоги для процессов, которые Вы внезапно обнаружили, существуют со времен первых мультизадачных ОС. Обычно о том, для чего это нужно, студенты соответсвующих специальностей изучают в курсе осперационных систем и системного программирования. Если посещать лекции по теории этих самых ОС, вопросов такого рода не возникнет. Дело в том, чтобы понять, что там и для чего, нужно изучить код планировщика. Без этого обсуждать crt никакого смысла не имеет. Всю эту «телеметрию» планировщик использует, чтобы принимать решения сугубо по Вашей программе, поэтому нет никакого смысла ее держать в ядре — достаточно юзерспейса.
Относительно MSVC — при разработке на C/C++ для виндовсов это наихудший вариант выбора. Стандарты поддерживаются слабо, куча расширений, ухудшающих переносимость, очень неудобная IDE, скрывающая детали процесса компиляции и сборки, куча особенностей, потакающих программистам в их желаниях не комментировать изменения, плохая поддержка юникода, несогласованность в локалях даже в пределах этой самой MSVC.
При этом в мире виндовсов есть отличные компиляторы, системы сборки проектов и редакторы исходных кодов, обладающие функциональностью, превышающей дешевое IDE MSVC кратно. Предоставляя крайне низкий уровень вхождения, свойственный основной массе школоты, MSVC выполняет главную роль в процессе огораживания и сегрегации программистов на индусов и гуру.
Относительно MSVC — при разработке на C/C++ для виндовсов это наихудший вариант выбора. Стандарты поддерживаются слабо, куча расширений, ухудшающих переносимость, очень неудобная IDE, скрывающая детали процесса компиляции и сборки, куча особенностей, потакающих программистам в их желаниях не комментировать изменения, плохая поддержка юникода, несогласованность в локалях даже в пределах этой самой MSVC.
При этом в мире виндовсов есть отличные компиляторы, системы сборки проектов и редакторы исходных кодов, обладающие функциональностью, превышающей дешевое IDE MSVC кратно. Предоставляя крайне низкий уровень вхождения, свойственный основной массе школоты, MSVC выполняет главную роль в процессе огораживания и сегрегации программистов на индусов и гуру.
Извините, ЧТО?
Я бы предположил, что вы спутали код загрузчика приложений (ntdll.dll/ld-linux.so) и код рантайма конкретной среды программирования, но код загрузчика приложений тоже не имеет никакого отношения к планировщику.
И не соблаговолит ли прилежный слушатель курса операционных систем и системного программирования просветить невежественную шпану типа меня, каким образом прослушивание такого курса избавляет от вопроса «что делает вызов __telemetry_main_invoke_trigger() непосредственно перед вызовом main()»?
Я бы предположил, что вы спутали код загрузчика приложений (ntdll.dll/ld-linux.so) и код рантайма конкретной среды программирования, но код загрузчика приложений тоже не имеет никакого отношения к планировщику.
И не соблаговолит ли прилежный слушатель курса операционных систем и системного программирования просветить невежественную шпану типа меня, каким образом прослушивание такого курса избавляет от вопроса «что делает вызов __telemetry_main_invoke_trigger() непосредственно перед вызовом main()»?
Такое ощущение, что коммент занесло машиной времени, где-то на 10-15 лет в перёд, от момента написания.
Ха. На Windows 10 без отключения телеметрии обновлённая версия детектора показывает, что система таки ведёт все логи. Только не уточняет, куда.
Спасибо. Добавил в свой проект:
// disable VS2015 telemetry
extern "C"
{
void _cdecl __vcrt_initialize_telemetry_provider() {}
void _cdecl __telemetry_main_invoke_trigger() {}
void _cdecl __telemetry_main_return_trigger() {}
void _cdecl __vcrt_uninitialize_telemetry_provider() {}
};
А не будет ли ошибки при линковке, что символы объявлены дважды?
Не скажу за другие версии студии, но в 2015-й, если символы объявлены в стандартной библиотеке и в вашем коде, то студия без лишних разговоров берет ваши. Проверено.
А зачем её отключать, если не секрет? Вижу несколько возможных причин:
1. Накладные расходы на старте/завершении приложения
2. Увеличение размера исходника при статической линковке CRT (а так кто-то ещё делает?)
3. Паранойя
С другой стороны, отключая телеметрию, мы лишаем ОС некоторой (вроде бы вполне невинной) информации о приложении. И усложняем жизнь коллегам разработчикам. Так что именно побудило вас броситься её отключать?
1. Накладные расходы на старте/завершении приложения
2. Увеличение размера исходника при статической линковке CRT (а так кто-то ещё делает?)
3. Паранойя
С другой стороны, отключая телеметрию, мы лишаем ОС некоторой (вроде бы вполне невинной) информации о приложении. И усложняем жизнь коллегам разработчикам. Так что именно побудило вас броситься её отключать?
И усложняем жизнь коллегам разработчикам
Нужно очень постараться, чтобы придумать ситуацию, в которой это ваше утверждение стало бы истиной. Что-то вроде «ищем проблемную программу, ковыряя логи телеметрии». Ну допустим. Только вот 2015-я студия используется для сборки далеко не всех windows программ. Так что телеметрия, которую вшивает студия в мою программу, скорее всего, никогда и никому не пригодится. Т.о., отвечая на ваш вопрос: мой внутренний перфекционист. Меня побудил мой внутренний перфекционист, согласно пунктам 1 и 2, решив, что если код не нужен, то не нужен.
а так кто-то ещё делает?
Если говорить о vccrt, то динамическая линковка не имеет никаких преимуществ, а только недостатки:
1. лишнее время на загрузку и динамическое связывание
2. линкер не смог ничего с'оптимизировать (имеется в виду crt в связке с моим кодом)
3. размер. Казалось бы, размер exe'шника меньше, но расплата в том, что в дистрибутив приходится все эти dll-ки заталкивать, иначе нет гарантии, что ваша программа заработает у среднестатистического пользователя вашей программы.
Так что да, я так делаю и всем рекомендую.
В определённых ситуациях — да, статическая линковка может быть оправдана. Но вот «всем рекомендовать» её — достаточно смело, т.к. она обладает рядом недостатков:
1. Размер бинарника. В противовес вашему пункту 3, проблема среднестатистического пользователя решается запросом Visual Studio Redistributable из инсталлятора. Это возможно не всегда, да, исключения я как раз и отношу к «определённым ситуациям». Однако в большинстве случаев это работает отлично, и я обычно встречаю именно такой подход.
2. Размер исполнимого файла и библиотек в памяти. Если CRT слинкован динамически, то на все процессы будет использоваться только одна загруженная из системной области библиотека.
3. Security updates. Windows может обновить системные библиотеки с сохранением ABI, но не сможет достучаться до ваших копий.
4. Передача объектов между модулями. Если вы создали std::string в одной dll и передали его в другую, то при его освобождении будут проблемы, т.к. выделение и уничтожение выполняется разными CRT. Это по сути значит, что вы не можете свободно использовать С++ интерфейсы. Пожалуй, это главная проблема.
Собственно, сам Microsoft не рекомендует статическую линковку.
1. Размер бинарника. В противовес вашему пункту 3, проблема среднестатистического пользователя решается запросом Visual Studio Redistributable из инсталлятора. Это возможно не всегда, да, исключения я как раз и отношу к «определённым ситуациям». Однако в большинстве случаев это работает отлично, и я обычно встречаю именно такой подход.
2. Размер исполнимого файла и библиотек в памяти. Если CRT слинкован динамически, то на все процессы будет использоваться только одна загруженная из системной области библиотека.
3. Security updates. Windows может обновить системные библиотеки с сохранением ABI, но не сможет достучаться до ваших копий.
4. Передача объектов между модулями. Если вы создали std::string в одной dll и передали его в другую, то при его освобождении будут проблемы, т.к. выделение и уничтожение выполняется разными CRT. Это по сути значит, что вы не можете свободно использовать С++ интерфейсы. Пожалуй, это главная проблема.
Собственно, сам Microsoft не рекомендует статическую линковку.
Если линковщик видит два файла, в которых определена одна и та же функция, то действительно будет ошибка линковки. Фокус в том, чтобы линковщик не пытался смотреть на второй из них.
Выбор файлов для линковки схематично выглядит так:
— берём все obj-файлы, явно заданные в командной строке (при компиляции из IDE это файлы главного проекта, но не файлы в проектах-зависимостях);
— пока есть неразрешённые внешние символы, ищем их в lib-библиотеках и добавляем obj-файлы из lib-библиотек.
При нормальной компиляции линковщик ищет точку входа, находит её в libcmt.lib:exe_main.obj, видит зависимость от __telemetry_main_invoke_trigger и прочих, находит их в libvcruntime.lib:telemetry.obj, подключает telemetry.obj.
Если же явно реализовать функции в своём коде, то, увидев зависимость от __telemetry_main_invoke_trigger и прочих, линковщик обнаружит, что он уже знает реализации этих функций и в telemetry.obj просто не полезет.
Нюанс 1: должны быть реализованы действительно все функции из telemetry.obj, которые может вызвать внешний код. Если, условно, в следующем обновлении функция printf будет вызывать какой-нибудь __telemetry_printf_trigger, получится ошибка линковки из-за двойного определения.
Нюанс 2: если явная реализация находится во вспомогательной библиотеке, то какая именно реализация подхватится, может зависеть от порядка перечисления библиотек в командной строке. Причём навскидку я не в курсе, в каком порядке обрабатываются встроенные библиотеки и считается ли libvcruntime.lib встроенной.
Выбор файлов для линковки схематично выглядит так:
— берём все obj-файлы, явно заданные в командной строке (при компиляции из IDE это файлы главного проекта, но не файлы в проектах-зависимостях);
— пока есть неразрешённые внешние символы, ищем их в lib-библиотеках и добавляем obj-файлы из lib-библиотек.
При нормальной компиляции линковщик ищет точку входа, находит её в libcmt.lib:exe_main.obj, видит зависимость от __telemetry_main_invoke_trigger и прочих, находит их в libvcruntime.lib:telemetry.obj, подключает telemetry.obj.
Если же явно реализовать функции в своём коде, то, увидев зависимость от __telemetry_main_invoke_trigger и прочих, линковщик обнаружит, что он уже знает реализации этих функций и в telemetry.obj просто не полезет.
Нюанс 1: должны быть реализованы действительно все функции из telemetry.obj, которые может вызвать внешний код. Если, условно, в следующем обновлении функция printf будет вызывать какой-нибудь __telemetry_printf_trigger, получится ошибка линковки из-за двойного определения.
Нюанс 2: если явная реализация находится во вспомогательной библиотеке, то какая именно реализация подхватится, может зависеть от порядка перечисления библиотек в командной строке. Причём навскидку я не в курсе, в каком порядке обрабатываются встроенные библиотеки и считается ли libvcruntime.lib встроенной.
Русские умельцы скоро выпустят твикер для отключения телеметрии в вашем коде и слежения за обновлениями, которые её снова включают.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стандартная библиотека Visual Studio 2015 и телеметрия