Board.KolibriOS.org

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

..bw

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

_________________
Всех выше те, кто доброе творят,
И за дела добра не ждут наград,
Всем жертвуют для страждущих людей,
Не думая о выгоде своей.

Прошу заранее прощения, что цепляюсь за "древнюю" фразу и, может быть, за 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 в памяти в принципе (то есть, использование копий либы разными процессами) - это да, проблема.

_________________
in code we trust

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

Хорошо, пусть этот пункт будет более подробно....
Предположим, мы сделаем следующую версию хедера

  db 'MENUET01'
  dd 0x02        ; чтобы ядро могло отличать "старые" хедеры, и не трогать в таком варианте последний dword
  dd __start
  dd __end
  dd __memory
  dd __stack
  dd @IMPORT  ; этого слова нет сегодня!!! но именно оно необходимо для статической загрузки dll-к ядром

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

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

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

Пока выполняемые файлы (программы и библиотеки) не состоят из нескольких секций, на мой взгляд, вряд-ли получится решить эту проблему. Должно быть разделение на 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 , откуда сделал вывод, что с правовой т.з. никаких ограничений на использование нет. С английским у меня не очень, могу ошибаться.

_________________

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

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

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

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

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

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

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

_________________
Через тернии к звездам