dependency hell
Sep. 10th, 2009 01:32 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
wizzardbinary versions of win-psycopg2 are built against latest DEBUG version of MSVCRT that ships ONLY with VS2005 SP1 ATL Security Update 2
and they don’t have sources readily buildable on Windows, either – only the Linux ones :\
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-09-09 10:35 pm (UTC)no subject
Date: 2009-09-09 10:47 pm (UTC)no subject
Date: 2009-09-10 12:58 am (UTC)+1000. Не первій раз такое наблюдаю(((
спасибо, я уже нашел. как побочній єффект, у меня теперь стоит vs2005, 2008 и вся матрица апдейтов релизов CRT для них (architecture*servicepack*debug/release) >_
no subject
Date: 2009-09-10 01:35 am (UTC)Ну и так далее - о пермишенах и использовании штатного менеджера пакетов для дистрибьюции я вообще молчу.
no subject
Date: 2009-09-10 01:01 am (UTC)no subject
Date: 2009-09-10 01:16 am (UTC)no subject
Date: 2009-09-10 03:59 am (UTC)no subject
Date: 2009-09-10 04:50 am (UTC)no subject
Date: 2009-09-10 04:55 am (UTC)no subject
Date: 2009-09-10 05:34 am (UTC)Использование статической CRT делает использование ДЛЛ крайне ограниченным.
Нормальным явлением я считаю статическую компоновку для небольших утилит. Всё остальное должно таскать c собой в msi merge-модуль для CRT, а бинарные "не устанавливающихся" дистрибутивы должны содержать CRT в виде private assembly.
Решение той же Миранды с компоновкой со старой "стандартной" MSVCRT тоже не самое лучшее.
no subject
Date: 2009-09-10 06:01 am (UTC)no subject
Date: 2009-09-10 05:11 pm (UTC)Проблемы со статической компоновкой именно CRT заключаются в том, что:
- она (CRT) реализует кучу
- она реализует исключения
Как именно она делает - стандарт не оговаривает. Скажем, она может использовать GetProcessHeap(), HeapCreate() или же реализовать кучу самостоятельно.
И вот если CRT реализовывает кучу скажем, через CreateHeap(), то ей нужно этот хендл где-то хранить, и он понятно у каждого инстанса CRT получается разный. И в результате память, выделенная malloc() в одной длл, невозможно _переносимо_ освободить в другой ДЛЛ.
То же самое и с бросанием исключений через границы DLL, и так далее.
Шаблонные библиотеки либо написаны так, чтобы не использовать глобальные данные, либо полагаются на наличие лишь одной копии этих глобальных данных путём всё того же механизма DLL. Та же STL полагается для этого на свою DLL. А то что функции в нескольких копиях (чего не избежать при специализации шаблона, используемого внутри ДЛЛ) - так это не страшно, код не меняется в ходе выполнения и поэтому все инстансы одинаковые и проблем нет.
Вот поменяет завтра майкрософт что-нибудь в undefined behaviour, и софт, на это полагающийся, поломается.
Скажем, сделают в системе новый файловый АПИ, и получится что fopen и fread внутри для ускорения будут использовать некие глобальные таблицы - и всё, нельзя будет и FILE * передавать между ДЛЛ.
И крики начнутся - дескать, какая Майкрософт плохая, ломает на ровном месте такие незыблемые вещи, как CRT.
Прецеденты уже есть - возьмите ту же безопасность. Система с самого начала (NT 3) была формально многопользовательской с разделением доступа, а де факто - однопользовательской с одним суперпользователем. Так понаписали же софта, пишущего куда не попадя, по принципу "работает ну и хуй с ним - зачем нам читать какие-то религиозные бумажки о том где хранить настройки и пользовательские данные".
А потом бац - развился интернет, а в месте с ним и черви, и сразу же необходимость работы под нерутом. А хуй там - проклятые вендоры понаписывали софта, который упорно и в 2009 году продолжает считать, что в системе ровно один пользователь, притом с административными привилегиями - тот, под которым ставился софт. И снова начались крики о том, какой майкрософт плохой - сделал нам UAC, чтобы софт, написанный через зад, меньше вредил грамотно написанному софту.
Причем у этих писателей говнософта, ругающих Майкрософт, двойные стандарты - я уже вижу аргументы, что дескать система была плохой. Так сами же эти критики пишут сознательно на работе пишут из рук вон плохой софт, признают это. А на вопрос "вы делаете плохой софт, почему ты не уйдешь в другое место, чтобы не участвовать в этом?" отвечают "не бывает оптимальных решений сложных задач" и пускают другие подобные отмазки. И при этом требуют чтобы майкрософт играл по другим правилам.
Ужас и оторопь берет, когда видишь, какое безумие, какой поистине кафкианский маразм творится в отрасли. Требования ставятся какими-то левыми деятелями под пиво с заказчиком, проектированием вообще никто не занимается, программисты твердят про какие-то "изменяющиеся требования заказчика", постоянные переделки, то и дело набирают неквалифицированных кадры, о качестве вообще никто не думает, процветает воровство и обман, умы заняты не созданием программ, а выниманием денег из из кармана заказчика, пользуясь удачно подвернувшейся ситуацией.
no subject
Date: 2009-09-10 06:29 pm (UTC)no subject
Date: 2009-09-10 07:26 pm (UTC)Использование многих копий CRT требует особой осторожности при построении межмодульных интерфейсов, накладывает дополнительные ограничения на ровном месте.
Понятно, что для того, чтобы оправдать передачу memory ownership между модулями, нужны веские причины. Но если проект такой, что передавать ownership проще, чем не передавать - то желание экономить 500 кбайт на одной из поддерживаемых ОС не должно вставлять палки в колеса и ухудшать дизайн.
Передача ownership используется довольно часто - в интерфейсе zlib, скажем, есть функции zalloc и zfree, специально для того, чтобы избежать проблем с разными кучами. Кроме того, есть функции gzopen, которые принимают хендлы, возвращаемые CRT. Т.е. библиотека построена с расчетом на то, что c одной стороны, могут использоваться несколько копий CRT с разными кучами, а с другой стороны, что все вызовы open во всех копиях CRT не используют глобальных данных.
Если, скажем, делать библиотеку абсолютно портабельной, то надо либо делать и вызовы zopen, zsocket и т д, либо ограничивать способы использования CRT клиентами. В случае zlib оказалось лучше сделать так, как сделали, а в случае, когда все модули пишутся одним вендором, отказ от статической компоновки упростит дизайн и соответственно, сократит себестоимость разработки.
Грубо говоря, если в нашем приложении 150 вариантов zlib, то не надо будет копипейстить 150 функций zalloc/zfree или придумывать хитрые способы обойти проблему без копипейста.
no subject
Date: 2009-09-10 07:47 pm (UTC)Потому, что стандарт языка ничего не знает о DLL и прочих системных заморочках. Вы с таким же успехом можете создать процесс и передавать ему адреса памяти через пайп - где-то это может и будет работать и, может быть, кто-то будет считать это "официальным поддерживаемым сценарием", но переносимым это никогда не будет.
no subject
Date: 2009-09-10 05:18 pm (UTC)Так правильно - EULA вообще запрещает распространять DEBUG CRT в каком-либо виде, фактически Debug CRT платный, является частью студии, как, скажем, отладчик. Debug CRT может быть раза в три медленнее в определенных сценариях, чем релизный, из-за различных валидаций кучи, которые он выполняет для раннего обнаружения memory corruption, поэтому ни один разработчик в здравом уме и трезвой памяти не будет распространять его с бинарником своего софта.
Впрочем, я не удивлюсь, что окажется, что данный софт просто банально падает в релиз-версии, т.к. дебаг-црт по-другому инициализирует память, и, скажем, использует всякие паддинги вокруг блоков кучи вроде 0xBAADF00D ("bad food"), и глючный код, безобидно повреждающий в дебаг црт паддинг, при компоновке с релизной начал повреждать соседний блок.
no subject
Date: 2009-09-10 05:34 pm (UTC)Я знаю, что он платный :)
Алсо, я иногда даже читаю лицензии и по возможности стараюсь их соблюдать (мало ли что)
no subject
Date: 2009-09-10 06:04 pm (UTC)