RUN - запуск программ

...
  • Мне новая версия понравилась.)) Я с первой попытки запустил проигрыватель с файлом 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 в памяти в принципе (то есть, использование копий либы разными процессами) - это да, проблема.
    in code we trust
  • 2Gluk
    В п.3 имелся в виду простой и короткий вопрос про коды типа из dll.inc
    Опираясь на слова Leency: "Учитывая количество программ уже зависящих от box_lib.obj, она уже де факто и является системной"
    Простая арифметика: (+) этот код в ядре (+) один dword в хэдере (-) этот же код в том самом "количестве программ"
    Смысл примерно такой же, как и перенесение распаковки образа в ядро (то же ведь код распаковки мог содержаться в каждой проге)

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

    Code: Select all

      db 'MENUET01'
      dd 0x02        ; чтобы ядро могло отличать "старые" хедеры, и не трогать в таком варианте последний dword
      dd __start
      dd __end
      dd __memory
      dd __stack
      dd @IMPORT  ; этого слова нет сегодня!!! но именно оно необходимо для статической загрузки dll-к ядром
    Далее, на SDK/SVN есть разные версии загрузок: от diamond для одной dll-ки, и от mike.did - для полного пакета из таковых (мне так показалось)
    Конечно, если включать это в ядро - логичнее второй вариант... Хотя тоже возможны варианты
    Со своей стороны, моя "возня" на предмет изучения чужих кодов привела к такому:
    Attachments
    DLLg.7z (1.35 KiB)
    пока нет полной ясности с инициализацией dll-ки
    Downloaded 381 times
  • Упс... :)
    Пропустил сообщение...

    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?
  • Программка, похожая на мелкий скрипт. Запуск приложений с параметрами посредством нажатия на глобальные клавиши.
    Attachments
    runkey.7z (1.01 KiB)
    Downloaded 356 times
    Last edited by staper on Thu Dec 17, 2009 10:33 am, edited 1 time in total.
  • Выкинул кнопку из Run, т.к. назначение её не очень понятно -- зачем тянуться к мышке после набора команды...
    Attachments
    run.7z (5.07 KiB)
    Downloaded 349 times
  • Image
    Большой шрифт rev #6687
    Из хаоса в космос
  • Who is online

    Users browsing this forum: No registered users and 9 guests