Решил попробовать 2010-ку. Взял свой проектик из 2008-й студии (небольшая DLL с использованием MFC, статическая линковка), перенёс в 2010-ую. Скомпилял. Полюбовался на скомпилённый файл: 1,7 мегабайта; в 2008-й он занимал 350 килов. Выставил использование девятого рантайма вместо десятого, перекомпилял — получил прежние 350 килов. Результирующий файл при этом зачем-то стал импортировать библиотеки, которые раньше ему были не нужны (msimg32.dll, ole32.dll, gdiplus.dll, imm32.dll…), в тех библиотеках, что использовались и раньше, добавились новые функции… Вопрос: что такого жуткого в десятом рантайме, что файл настолько расколбасило?
PS: Убедительная просьба отвечать по теме, а не предлагать прикупить очередной винт на десяток петабайт, добавить сорок терабайт оперативки и забыть о проблеме. А то есть тут любители…
я пока релиз не компилял десяткой, а в debug размеры моего exe-файла (скомпиленного для 9-го и 10-го рантайма) практически не отличаются
правда, я не использую статическую линковку
Здравствуйте, Андрей, Вы писали:
А>а если линковать MFC динамически?
А>я пока релиз не компилял десяткой, а в debug размеры моего exe-файла (скомпиленного для 9-го и 10-го рантайма) практически не отличаются А>правда, я не использую статическую линковку
Динамически-то нормально, 135 килобайт, как в 2008-й студии. Но я планирую распространять прогу и не хочу заставлять народ качать рантаймы.
Здравствуйте, CaptainFlint, Вы писали:
CF>Решил попробовать 2010-ку. Взял свой проектик из 2008-й студии (небольшая DLL с использованием MFC, статическая линковка), перенёс в 2010-ую. Скомпилял. Полюбовался на скомпилённый файл: 1,7 мегабайта; в 2008-й он занимал 350 килов. Выставил использование девятого рантайма вместо десятого, перекомпилял — получил прежние 350 килов. Результирующий файл при этом зачем-то стал импортировать библиотеки, которые раньше ему были не нужны (msimg32.dll, ole32.dll, gdiplus.dll, imm32.dll…), в тех библиотеках, что использовались и раньше, добавились новые функции… Вопрос: что такого жуткого в десятом рантайме, что файл настолько расколбасило?
Дело возможно в новых картинках засунутых в MFC.
Посмотрите на его содержимое, код от данных там несложно отличить.
Новую 10-ку уже удалил но MFC там тоже тыкал помню было около 3-х метров на приложении натыканном на мастере.
Примерно половину занимали картинки пожатые в PNG, также был всунут какой-то здоровый текстовой скриптец от офисового риббона (я на MFC не пишу хз что это).
Еще около 20% занимали кучи строк с идентификаторами, кстати строки все стали юникодовые даже в самых недрах сишного рантайма (не МФС).
Ну а остальное занимал чистый код.
Кстати МС вернула в компилятор тупорылую развертку циклов, так что распанахивает код он теперь ололо (впрочем она отключается).
А вообще приложение выглядело в стиле 2007 офиса со всеми рюшками, учитывая что все это было залинковано в 1 файл думаю это и есть натуральный размер
В любом случае это лучше чем пол гига фреймворков только ради тех же менюшек.
Даже 3 метра в exe это гроши по сравнению с объемами памяти которые будут съедены после загрузки в память.
Может конечно линкер не отрезал ченить лишнего но это думаю не его вина
msimg32.dll — это вообще микро дллка (содержит кривоватую функцию AlphaBlt написанную на mmx, эдакий костылек который по непонятным причинам небыл засунут в gdi32.dll )
ole32.dll — это по моему всегда была в МФСишных проектах.
gdiplus.dll — вкрутили полюбому для загрузки изображений в разных форматах ну и для новых симпатичных фичек (странно если её раньше там небыло).
Еще добавлю, не забывайте что компилятор ресурсов в отличии от линкера не выбрасывает неиспользуемые данные.
Поэтому если секция ресурсов была распанахана до неимоверных размеров из-за большого кол-ва новых диалогов, картинок и курсоров, и была скомпилена одним rc скриптом, то она со всеми потрохами полетит в исполнимый модуль.
Старая MFC видимо была бедна на графику вот и занимала мало места.
Здравствуйте, CaptainFlint, Вы писали:
А>>а если линковать MFC динамически? А>>я пока релиз не компилял десяткой, а в debug размеры моего exe-файла (скомпиленного для 9-го и 10-го рантайма) практически не отличаются А>>правда, я не использую статическую линковку CF>Динамически-то нормально, 135 килобайт, как в 2008-й студии. Но я планирую распространять прогу и не хочу заставлять народ качать рантаймы.
А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить.
ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить. V>ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным.
А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP.
Здравствуйте, unreg_flex, Вы писали:
_>Дело возможно в новых картинках засунутых в MFC. _>Посмотрите на его содержимое, код от данных там несложно отличить. _>Новую 10-ку уже удалил но MFC там тоже тыкал помню было около 3-х метров на приложении натыканном на мастере. _>Примерно половину занимали картинки пожатые в PNG, также был всунут какой-то здоровый текстовой скриптец от офисового риббона (я на MFC не пишу хз что это). _>Еще около 20% занимали кучи строк с идентификаторами, кстати строки все стали юникодовые даже в самых недрах сишного рантайма (не МФС). _>Ну а остальное занимал чистый код.
Смотрел, но PNG не так-то просто отличить визуально. Хотя сигнатуры PNG в моём файле нет вообще ни одной.
Кроме того, у меня же не используются все эти супер-пупер фичи. У меня простенькая DLL, всё графическое оформление состоит из трёх диалогов. Встроенных MFC-шных битмапов и прочего я не использую вообще (несколько стандартных ресурсов вкомпиливаются, естественно, но они совсем махонькие и в 2008, и в 2010-й версии).
Я попробовал dumpbin. Хоть я с ним знаком весьма поверхностно, но полученная информация насторожила:
Поправьте, если ошибаюсь, но размер секции .text в 1,2 мегабайта во втором файле говорит, что основная часть файла занята как раз кодом (да и объём секции релокаций, по идее, на то же намекает).
_>Кстати МС вернула в компилятор тупорылую развертку циклов, так что распанахивает код он теперь ололо (впрочем она отключается).
Так, а вот это хотелось бы попробовать. Можно чуть поточнее координаты опции? А то я уже, вроде, всё перерыл, но такой либо не заметил, либо её как advanced надо вписывать…
_>А вообще приложение выглядело в стиле 2007 офиса со всеми рюшками, учитывая что все это было залинковано в 1 файл думаю это и есть натуральный размер _>В любом случае это лучше чем пол гига фреймворков только ради тех же менюшек.
Были бы рюшки, я б не жаловался. Я ж понимаю, что за всё надо платить. Проблема как раз в том, что никаких рюшек не используется, а размер всё равно вымахал чуть не на порядок.
_>msimg32.dll — это вообще микро дллка (содержит кривоватую функцию AlphaBlt написанную на mmx, эдакий костылек который по непонятным причинам небыл засунут в gdi32.dll ) _>ole32.dll — это по моему всегда была в МФСишных проектах. _>gdiplus.dll — вкрутили полюбому для загрузки изображений в разных форматах ну и для новых симпатичных фичек (странно если её раньше там небыло).
Дело в том, что они до этого не использовались, даже ole32.dll. Вот полный список используемых библиотек (полужирным выделил отличия):
Количество импортируемых функций при этом возросло примерно вдвое. Тут важна не столько конкретика, что именно добавилось, сколько сам факт наличия новых импортов: лишнее доказательство, что в файле появился какой-то дополнительный код, которого там раньше не было. А появление gdiplus.dll меня просто убило. Ну не используется у меня GDI, не нужен он мне! У меня банальнейшая работа с файлами и реестром. Максимум, что есть из графики — это упомянутые три диалога, причём без наворотов, без кастомной отрисовки, без спец-контролов. Разве что они вообще всю работу с гуями во внутренностях MFC на GDI+ перевели…
Здравствуйте, unreg_flex, Вы писали:
_>Еще добавлю, не забывайте что компилятор ресурсов в отличии от линкера не выбрасывает неиспользуемые данные. _>Поэтому если секция ресурсов была распанахана до неимоверных размеров из-за большого кол-ва новых диалогов, картинок и курсоров, и была скомпилена одним rc скриптом, то она со всеми потрохами полетит в исполнимый модуль. _>Старая MFC видимо была бедна на графику вот и занимала мало места.
Ресурсов мало. Суммарный объём всех ресурсов в скомпилированном файле — 70 килобайт.
Здравствуйте, CaptainFlint, Вы писали:
CF>Здравствуйте, Vain, Вы писали:
V>>А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить. V>>ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным.
CF>А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP.
Мелкомягкие исправили свою ошибку — больше никаких манифестов и прочей идиотии нет. Рантайм это простая DLL — кладете рядом с экзешником и на xp работает молча. Забудем скоро этот редисто-кошмар 2005-2008 как страшный сон.
Здравствуйте, CaptainFlint, Вы писали:
CF>Здравствуйте, Vain, Вы писали:
V>>А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить. V>>ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным.
CF>А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP.
Для того существуют MSMы, которыми можно пользоваться при созданий инсталляций, чтобы не заставлять пользователей устанавливать рантаймы и не плодить рантаймы в папке каждой программы.
Но то, что рантаймы и MSM добавляют мороки прилично, это да.
Здравствуйте, CaptainFlint, Вы писали:
V>>А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить. V>>ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным. CF>А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP.
Оно в моём случае тоже должно запустится на чистой XP
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, SleepyDrago, Вы писали:
V>>>А разве в 2010 не оставили возможность хранить ддл в поддерикториях вроде Microsoft.VC80.DebugCRT и т.д как в предыдущих версиях студии? И рантайм не надо ставить. V>>>ЗыЖ Вроде один недостаток такого подхода — установленный рантайм имеет по дефолту приоритет над локальным. CF>>А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP. SD>Мелкомягкие исправили свою ошибку — больше никаких манифестов и прочей идиотии нет.
Не факт, для того чтобы идиотии не было, надо ещё загрузчик OS обновить, ведь по идее это он лезет либо косвенно, либо через LoadLibrary в WinSxS каталог. А это черевато исчезновением обратной совместимости с предыдущими способами загрузки предыдущих рантаймов.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, SleepyDrago, Вы писали: SD>>Мелкомягкие исправили свою ошибку — больше никаких манифестов и прочей идиотии нет. V>Не факт, для того чтобы идиотии не было, надо ещё загрузчик OS обновить, ведь по идее это он лезет либо косвенно, либо через LoadLibrary в WinSxS каталог. А это черевато исчезновением обратной совместимости с предыдущими способами загрузки предыдущих рантаймов.
Факт! Я между прочим проверил прежде чем писать А то мало ли что они в доке пишут. Эксперимент простой — взял консольное приложение (простейшее) собрал 10й. Посмотрел dumpbin /Imports. упаковал его и msvcp100.dll + msvcr100.dll ( получилось чтото около 350к ) перенес на xpsp2 где десятых никогда не было и запустил
Здравствуйте, CaptainFlint, Вы писали:
CF>Поправьте, если ошибаюсь, но размер секции .text в 1,2 мегабайта во втором файле говорит, что основная часть файла занята как раз кодом (да и объём секции релокаций, по идее, на то же намекает).
Да это код.
Нипанятна правда зачем там релоки болтаются, это же вроде как бы не длл, хотя наверн для того чтобы приложение можно было юзать как объект.
CF>Так, а вот это хотелось бы попробовать. Можно чуть поточнее координаты опции? А то я уже, вроде, всё перерыл, но такой либо не заметил, либо её как advanced надо вписывать…
Если эта опция что и уменьшит то только размер вашего кода (который как вы говорите незначителен), MFC скомпилена в либу и хз с какими опциями именно ее и надо будет пересобирать.
CF>Дело в том, что они до этого не использовались, даже ole32.dll. Вот полный список используемых библиотек (полужирным выделил отличия): CF>
Неверю что comctl32.dll не использовалась ранее, быть такого не может!
Может она ранее динамически грузилась, незнаю, но как бы там и лежат стандартные контролы винды.
CF>Количество импортируемых функций при этом возросло примерно вдвое. Тут важна не столько конкретика, что именно добавилось, сколько сам факт наличия новых импортов: лишнее доказательство, что в файле появился какой-то дополнительный код, которого там раньше не было. А появление gdiplus.dll меня просто убило. Ну не используется у меня GDI, не нужен он мне! У меня банальнейшая работа с файлами и реестром. Максимум, что есть из графики — это упомянутые три диалога, причём без наворотов, без кастомной отрисовки, без спец-контролов. Разве что они вообще всю работу с гуями во внутренностях MFC на GDI+ перевели…
Ощущение что происходит одно из двух:
Либо в библиотеке появился какой то метод который цепляет большую часть MFC (незнаю что это может быть, может фабрика какая нить).
Либо они переписали все контролы, в инете гуляла какая то тема о поддержке win7 в новой MFC.
Что именно незнаю, нужно продизассемблить файл выбрать какую нить апи функци которая у вас точно не должна использоваться и посмотреть в какие процедуры ведет ее вызов, также можно потыкать асмовые листинги которые генерит компилер в минимальном приложении дабы понять что там цепляется.
Оффтоп:
Если говорите что у вас в приложении пара диалогов и работа с реестром, а размер так важен и хотите оставить исполнимый файл маленьким, напишите все на АПИ, при таком количестве гуя переделывается все за пару дней. Экзешник получится порядка 10-20 килобайт и будет работать на любой машине с любыми виндами. Если же в дальнейшем предполагается значительно расширять UI, то смиритесь и ешьте что дают
Здравствуйте, Vain, Вы писали:
CF>>А при чём тут это? По умолчанию в системе есть рантайм-библиотеки только для CRT/MFC 6.0. По крайней мере, в XP. Поэтому чтобы использовать приложение, собранное в студии 2002 и выше, в систему придётся доустановить библиотеки CRT/MFC соответствующей версии. Гарантий, что они уже установлены, у меня нет, а заставлять пользователя, скачавшего мою программу, качать и ставить ещё и рантаймы, я не хочу. Поэтому компиляю статически, чтобы приложение гарантированно запустилось на чистой, свежеустановленной XP. V>Оно в моём случае тоже должно запустится на чистой XP
Да, только потребует тащить с собой несколько дополнительных DLL-файлов, которых в этой самой чистой XP попросту нет в наличии. В итоге размер распространяемого пакета будет ещё больше, чем при статической компиляции — даже в самом упакованном виде занимает чуть меньше 2 мегабайт. Отличное решение проблемы увеличения размера: увеличить его ещё больше.
А то мало ли что они в доке пишут. Эксперимент простой — взял консольное приложение (простейшее) собрал 10й. Посмотрел dumpbin /Imports. упаковал его и msvcp100.dll + msvcr100.dll ( получилось чтото около 350к ) перенес на xpsp2 где десятых никогда не было и запустил 
