@MSGID: 2:5000/14 64280fb8
@REPLY: 1:104/117 642724b9
@CHRS: CP866 2
@TZUTC: 0200
Привет!

31 Mar 23 12:21, you wrote to me:

 VA> Бардак будет, если каждое приложение будет делать по-своему.

 Кому какое дело, как приложение распределяет свои собственные файлы в
своем собственном каталоге?

 VA> Если следовать стандартам (хоть в линуксе, хоть в винде, хоть в
 VA> макоси), то будет порядок.

 Hе знаю про линукс и макось, но в винде нет никаких стандартов,
регламентирующих размещение файлов приложения, которые не используются ни системой, ни
другими приложениями.

 VA> Shared library - это бинарный файл .so. Пофиг, шарится он реально или
 VA> нет.

Типа, "аппарат имеется, будем судить"? :)

 Hа кой вообще было присваивать обычной динамической библиотеке атрибут
разделяемости?

 VA> Очень сомневаюсь, что разработчики Unix/Linux настолько тупые и
 VA> никогда не задумывались 30+ лет.

Такое везде сплошь и рядом, с чего бы они были исключением? :)

 VA> прежде, чем критиковать, стоит попробовать следовать стандарту.

 Для этого стандарт должен объяснить, зачем ему следовать в тех
случаях, которые не укладываются в идею, положенную в основу стандарта.

 EM>> не припомню, чтоб он для поиска в документе выгружал его в текстовый
 EM>> файл, прогонял по нему стандартный grep, после чего разбирал его
 EM>> вывод.

 VA> Это маловероятно, но такое тоже может быть.

 Ты сам станешь пользоваться текстовым процессором, который, вместо
вызовов библиотечных функций для выполнения простых действий, будет запускать
в фоне различные команды, из-за этого тормозя и съедая ресурсы, лишь
для того, чтобы следовать некой парадигме? Я - точно нет.

 VA> Отладчик. Даже в Visual Studio отладчик - это отдельный процесс.
 VA> Почему его не встроили в саму студию. Пусть даже в виде отдельной dll?
 VA> ;)

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

 VA> Разработчики разных дистрибутивов между собой никак не связаны и
 VA> координировать такие вещи точно не будут. Как ты себе вообще это
 VA> представляешь?

 Если б разработчикам разных дистрибутивов было по барабану, что и
как делается в (и для) других дистрибутивов, они не согласовывали бы
между собой совместимость по POSIX и другим стандартам.

 VA> Если разные зависимости будут использовать разные версии одной
 VA> библиотеки - очень-очень высока вероятность, что оно взорвется.
 VA> Особенно, если это dll/so.

 Про so Юра уже пояснил - там неуправляемая глобальность действительно
ужасна, как вы с нею живете? А с DLL принципиальных проблем нет - линкер
связывает только с тем, что есть в библиотеке экспорта, прилагаемой к DLL.
Можно сделать DLL на одной версии C/C++, хоть втянув туда соответствующую
версию libc статически, хоть прилинковав к соответствующей версии CRT DLL, а
затем связать с этой DLL приложение, написанное под другую версию языка.
Правильная DLL экспортирует только то, что требует ее функциональность, и никому
не должно быть интересно, какие библиотеки она использует сама.

 VA> Под винду вообще каждая либа чаще всего собирается отдельно под каждый
 VA> проект, даже не под систему.

 Это сугубо от лени и убожества. Технически это ничем не обусловлено.
Как и то, что многие драйверы идут в виде отдельных бинарников под XP,
Win 7, 8, 8,1 и 10, хотя нетрудно сделать бинарник, который сам
настраивается на систему, даже в тех случаях, когда системные интерфейсы радикально
меняются.

Всего доброго!
Евгений Музыченко
fi-do@muzy-chen-ko.net (все дефисы убрать)

--- GoldED+/W32-MSVC 1.1.5-b20180707
 * Origin: Fox Tracks, France (2:5000/14)
SEEN-BY: 50/12 400/814 452/28 166 455/19 4500/1
5000/14 5020/400 545 848 1042
SEEN-BY: 5020/1477 1823 4441 12000 5022/128 5025/3
75 5030/1081 1957 2404
SEEN-BY: 5035/85 5053/400 5054/1 5059/26 37 5066/18
5080/68 102 5085/13
SEEN-BY: 5095/20
@PATH: 5000/14 5020/545 4441