Board.KolibriOS.org

Rock_maniak_forever хоть и пишет с ошибками, но всё же в чём-то он прав.
Достаточно только прочитать http://ru.wikipedia.org/wiki/DLL:

Фактически, полных преимуществ от внедрения DLL получить не удалось ...... свело на нет преимущества изначального принципа модульности.

а Dependency hell?..
Нужно разрабатывать новые подходы, новые принципы, новые концепции.
Посмотрите на KolibriOS. И чем вообще она отличается от других осей?
"...ОС полностью написана на ассемблере" - где там, не то что прикладные программы, даже драйвера на си написаны. Некоторые.
"А ещё... Нет, больше ничего. Зато она работает, в отличие от Menuet. Ура!"

Mario wrote:Сообщество Колибри давно уже не демократия.

Rock_maniak_forever, ё-моё...

Это совершенно неважно в какой папке лижит DLL либа, потому что, как я уже говорил, расход памяти будет очень высокий, как дисковой так и оперативной памяти. Не надо кошмарить систему.

С какой это стати? А? Расход дисковой памяти будет не больше, чем если бы подобная функциональность была "вшита" в программу без использования библиотек (библиотеками-то никто пользоваться не заставляет, хочешь - пиши свой код). В оперативную память библиотека будет загружена при работе с zSea (до тех пор, пока он не запущен, никуда твоя свободная оперативная память не денется).

Было бы лучше по-твоему, если бы

модули работы с изображениями различных форматов и функции поворота и масштабирования не были бы вынесены в obj-и, а были "намертво" вкомпилены в программу

Нет, ну ты скажи? Если бы не было отдельных файлов-библиотек, а весь код был бы вшит в исполняемый файл zSea, вопросов бы не возникло?

То, что библиотеки различного назначения есть - огромный плюс, но никто же не заставляет ими пользоваться в обязательном порядке.

Вот, хочу я, допустим, конфигурационный файл прочитать. А libini меня по каким-то причинам не устраивает (не будем говорить, по каким именно, это просто условный пример). И? И что? Если я напишу свой код для парсинга конфигурационного файла, это будет трагедией? И программу на этом основании в дистрибутив не включат, сколь бы хороша она ни была?

: Вот под винду Майкрософт разработал библиотеку классов MFC. И? И что? С момента выхода MFC разрабатывать программы на базе чистого WinApi стало запрещено?
Потом .NET Framework появился. Если следовать твоей логике, то с этого момента писать программы на базе MFC и на базе чистого WinApi стало нельзя. Ты что: не дай бог напишешь что-то, что в библиотеке классов .NET уже создано до нас... Вдруг конфигурационный файл сам парсить будешь... Или BMP'шки в JPEG'и конвертировать... Или... Мало ли чего... И вообще, код для .NET Framework - управляемый и безопасный, работает под управлением виртуальной машины - не то, что "настоящий" машинный код, использующий вызовы WinApi "вручную".
А то, что существующая реализация меня по каким-то причинам не устраивает, никого не волнует. По твоей логике, есть библиотека - ОБЯЗАН пользоваться.

Повторяю ещё раз ключевой вопрос:

Если бы модули работы с изображениями различных форматов и функции поворота и масштабирования не были бы вынесены в obj-и, а были "намертво" вкомпилены в программу, проблем с включением программы в дистрибутив не возникло бы???

Я сейчас еще немного нямки подкину.
1) Я собираюсь переписывать KFM -Kolibri File Manager, это думаю знают многие - на форуме читали.
2) В новом KFM будет функция предпросмотра файлов в виде эскизов документов.
3) Угадайте с трех раз - библиотеки какой программы я буду использовать.

KIV???

извините, не удержался

Ага, особенно его библиотеки для масштабирования и преобразования глубины цвета.

Андрей Михайлович, "С какой это стати? А? Расход дисковой памяти будет не больше, чем если бы подобная функциональность была "вшита" в программу без использования библиотек (библиотеками-то никто пользоваться не заставляет, хочешь - пиши свой код)." - будет таки больше, ибо отдельный файл, ибо минимальное дисковое пространство, занимаемое одним файлом довольно велико относительно размеров нашей операционной системы, и редкий файл в ней выровнен под это пространство. А если плагинов еще и несколько вместо одной библиотеки, ситуация усугубляется.

Mario, а как будет реализован шаринг? То есть положение этих библиотек. Или новая версия KFM не будет работать в отсутствие ZSea? или плагины будут продублированы в директорию KFM, т.к. дублирование библиотек - это хорошо? Мне правда интересно.

Gluk

будет таки больше, ибо отдельный файл, ибо минимальное дисковое пространство, занимаемое одним файлом довольно велико относительно размеров нашей операционной системы, и редкий файл в ней выровнен под это пространство. А если плагинов еще и несколько вместо одной библиотеки, ситуация усугубляется.

Вообще то он имел ввиду если один и тот же код 10 и более приложений содержат в своем бинарнике, то вынесение его и в библиотеку, даже если это и дублирующая библиотека - таки даст экономию объема. Другой вопрос, что пока у нас меньше десятка приложений, которые используют вывод RAW графики. Пока.

Mario, а как будет реализован шаринг? То есть положение этих библиотек. Или новая версия KFM не будет работать в отсутствие ZSea? или плагины будут продублированы в директорию KFM, т.к. дублирование библиотек - это хорошо? Мне правда интересно.

Доступные мне методы.
1) Также как и со всеми библиотеками - положив в /sys/lib/
Cnv_png.obj там нормально уже давно лежит - никому не мешает.
2) Прописав в INI положение папки для библиотек.
3) Да, можно и дублировать, хотя это уже самый глупый и вредный вариант, но чего не сделаешь ради умных и талантливых людей составляющих сообщество Колибри.

З.Ы. Вариант 1 и 2 по сути вообще не отличаются, только в варианте 2 еще и дополнительный код на получение из INI нужен.