Board.KolibriOS.org

> "Tips of the day" всех бесят. Однако, можно чтобы они вылазили после загрузки системы там возле часов, маленькое акуратненькое окошко, которое со временем само бы исчезало.
И пользователи их отключают даже не начав читать. Польза от подсказок будет, если их нельзя будет отключить :-).

..bw

Мне новая версия понравилась.)) Я с первой попытки запустил проигрыватель с файлом mp3, багов не заметил

diamond wrote:Хоть программа и "толстеет" на либу, но "худеет" за счёт выкидывания макросов, так что в целом эффект незначителен. Дополнительные расходы на загрузку либы действительно есть, но они незначительны. Так что это в принципе неактуально, независимо от размера ОЗУ и частоты процессора. В общем, зависимость от box_lib.obj не является минусом, а скорее плюсом - размер кода-то уменьшается.

Прошу заранее прощения, что цепляюсь за "древнюю" фразу и, может быть, за offtop

Просто мне кажется что уже назрела таки необходимость отметить следующие вопросы. Форум еще плохо знаю, а создавать новый топик без увереноости в продолжении - как-то не очень....

1) BOX_LIB.OBJ - это еще далеко не все, что надо для программера. libGUI это тоже только проба пера - не более, к сожалению. Видимо наиболее адекватной была бы библиотека типа VCL (или MCF) + system со своим менеджером памяти, контролами, стримами, листами, и т.д. и т.п.... Масштаб бедствия тоже понятен - 200-400КБайт, если по полной программе.
Ага

2) Какова из этого мораль: далеко не все из этого пользователь отдельной конкретной программы будет использовать, а память либа откушает целиком. И что характерно - столько раз, сколько прог ее будут юзать
((более того - одна и та же dll-ка в одном потоке может сидеть несколько раз, например: SVN\programs\develop\libraries\libs-dev\.test\001\test001.asm))
Это есть неприятность, и как-то сразу видно, что это неправильно
В винде, мне кажется, системные dll-ки вроде все релоцируются в одинаковые адреса, куда-то вверхушку пользовательского адресного пространства
У нас эта потребность тоже назревает вроде. Или я ошибаюсь

3) Код загрузки либы несколько напрягает вроде бы.... Даже пытался "чистить" его (типа - свое меньше пахнет) - улучшения не очень впечатляющие.
Отсюда такая мысль/вопрос: не перенести ли этот код в систему
Сделать следующую версию заголовка на один dword длиннее...
Скажем, с 2-ой во втором dword-е, а в последнем (дополнительном) - адрес "секции" импорта

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

Galkov
Код загрузки DLL и будет в ядре. Всему своё время, собственно. Когда именно и чьими стараниями он там окажется - это уже детали, но то, что никто не собирается и далее использовать такой способ загрузки - это точно. Дублирования DLL в памяти одного процесса можно избежать, ведь в конце-концов программа и все DLL вызывают одну и ту же функцию для загрузки либ, а значит эту функцию можно улучшить соответствующим образом. А вот дублирование DLL в памяти в принципе (то есть, использование копий либы разными процессами) - это да, проблема.

2Gluk
В п.3 имелся в виду простой и короткий вопрос про коды типа из dll.inc
Опираясь на слова Leency: "Учитывая количество программ уже зависящих от box_lib.obj, она уже де факто и является системной"
Простая арифметика: (+) этот код в ядре (+) один dword в хэдере (-) этот же код в том самом "количестве программ"
Смысл примерно такой же, как и перенесение распаковки образа в ядро (то же ведь код распаковки мог содержаться в каждой проге)

Хорошо, пусть этот пункт будет более подробно....
Предположим, мы сделаем следующую версию хедера Далее, на SDK/SVN есть разные версии загрузок: от diamond для одной dll-ки, и от mike.did - для полного пакета из таковых (мне так показалось)
Конечно, если включать это в ядро - логичнее второй вариант... Хотя тоже возможны варианты
Со своей стороны, моя "возня" на предмет изучения чужих кодов привела к такому:

Упс...
Пропустил сообщение...

2mike.dld
просто хотел отметить, что чем серьезней заниматься визуальной(системной ???) либой, тем эта проблема будет все заметнее и заметнее

mike.dld wrote:А вот дублирование DLL в памяти в принципе (то есть, использование копий либы разными процессами) - это да, проблема.

Пока выполняемые файлы (программы и библиотеки) не состоят из нескольких секций, на мой взгляд, вряд-ли получится решить эту проблему. Должно быть разделение на read only часть (общая для всех процессов, код и константы) и на rw данные (свои для каждого процесса), которые могут быть частично инициализированы из файла. А раз так, то эти секции после загрузки и релокации должны быть выровнены на границу 4Кб (в самом файле можно сделать другое выравнивание). Использовать MS COFF формат для DLL, мне кажется не совсем правильно (линкер в ядре - не самое лучшее), а использовать формат win DLL не совсем корректно с правовой т.з. Значит выход только один - придумать свой формат выполняемых файлов, состоящих из нескольких секций, и написать свой редактор связей (link), классически связывающий файлы формата MS COFF.

Кстати, загрузка драйверов ничем не должна отличаться от загрузки других библиотек, разница лишь в том, куда это грузится - выше или ниже границы 2Гб. То есть код загрузки DLL и драйвера (который по сути - та же DLL) можно не дублировать в ядре, а использовать два списка загруженных библиотек (системный и для пользовательских процессов).

Чтобы не быть зависимым от порядка загрузки библиотек, они не должны пересекаться ни в каких адресных пространствах, отсюда и сходство с системными библиотеками (драйверами). Когда библиотека грузится в адресное пространство процесса, одна её часть просто становится видимой для процесса (readonly), а другая часть копируется в дополнительно выделенный блок памяти в этом процессе (если конечно размер инициализированных данных не равен нулю, иначе достаточно просто выделить память). При этом адрес этих данных будет одинаков для всех процессов, в которых используется эта DLL, т.к. код, обращающийся к этим данным - общий.

Что там с правовой т.з.? Процитируешь? Столько раз упоминали, но ничего конкретного никто не сказал. Уже интересно даже.
Немного поискав в нете, нашел http://www.microsoft.com/whdc/system/pl ... ECOFF.mspx , откуда сделал вывод, что с правовой т.з. никаких ограничений на использование нет. С английским у меня не очень, могу ошибаться.

У мелкософта есть куча очкариков, которые, если захотят, по-любому докажут что ты не прав, в любом американском суде.

Microsoft will grant a royalty-free license ... only in the software development tools known as compilers, linkers, and assemblers targeting Microsoft Windows.

Наверное разработчики Reactos получили специальную лицензию за личной подписью BG.

На всех очкариков у них очкариков не хватит.

То есть, предполагается сделать загрузку выполняемых файлов в формате PE?

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

Выкинул кнопку из Run, т.к. назначение её не очень понятно -- зачем тянуться к мышке после набора команды...

Большой шрифт rev #6687