Proc_Lib.obj - процедурная библиотека

Discussing libraries simplifying applications development
  • ИМХО идея отличная. Можно будет ее сделать как аналог kernel32l/ntdll/user32.dll
    ушёл...
  • А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.
  • Asper wrote:А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.
    Я думаю, что Mario хотел сказать, что пора делать библиотеку, в которой будут процедуры для программ, избавляющие их от создания лисипедов. Например, надо перекодировать текст cp886 в cp1251, программе надо будет просто вызвать oem2ansi(str1, str2) и все. Это моё IMHO, конечно.
    ушёл...
  • Asper
    Box_Lib это все-таки библиотека графических компонентов. Не во всех программах они используются, а тут будут именно общие процедуры. В общем логическое разделение. Ну, и Nasarus правильно сформулировал.
    В противном случае опять будем иметь одну большую библиотеку вместо ядра - от этого ведь и уходим постепенно.
  • SVN r. 1509 - загрузил код библиотеки. Пока в нем только процедуры для вызова OpenDialog. Работоспособность проверил на zSea. Позже прикручу к другим приложениям.
  • SVN r. 1581 - доработана библиотека для поддержки сохранения размеров OpenDialog и центрирование его относительно текущего окна.
  • Mario wrote:Мне требуется сделать библиотеку для вызова OpenDialog. Однако создавать отдельную библиотеку для одной только программы не эффективно. Я думаю вполне логично создать процедурную библиотеку, куда и будут помещаться всевозможные процедуры для обработки промежуточных данных. Формат вызова будет подобен Box_Lib, который уже доказал свою состоятельность. Со временем в этой библиотеке можно разместить процедуры работы с сервером буфера обмена и много еще чего разного и нужного.
    В настоящее время КолибриОС может работать с множеством форматов файлов. Пусть это не всегда полноценная реализация потенциальных возможностей. Тем не менее, уже сейчас существует выбор: какой программой просматривать изображения, каким редактором открывать текстовые файлы. Думаю, в будущем этот список расширится. У каждого человека свои предпочтения, это касается и используемых программ.

    Сегодня в КолибриОС есть больше одного файлового менеджера. Каждый из них использует собственный конфигурационный файл, из которого узнаёт какое приложение соответствует определённому типу файлов. Пользователь, желающий работать с *.??? файлами в программе B, вынужден редактировать конфиги всех ФМ и заменять стандартное приложение A на B. К тому же, в случае появления новой версии ФМ с, например, несовместимым конфигом, придётся в новом конфиге проделать все замены повторно. То же и в случае появления другого ФМ. В целом, этот вопрос актуален для многих программ, работающих с файлами, а файловые менеджеры просто наглядный пример.

    Суть.
    Предлагаю создать единую базу(файл) ассоциаций, к которой следовало бы "прислушиваться" выше очерченному кругу приложений. Один файл, задающий ассоциации, для всех приложений (в т.ч. для тех, которые ещё даже не появились в системе). Таким образом, будет достаточно один раз высказать свои предпочтения - и все программы сами "прислушаются". В дальнейшем, в базе можно будет хранить и пути к иконкам для определённых типов файлов. Для удобной работы с такой базой я берусь написать функции к Proc_Lib (кое-что уже есть).

    Дальше идёт моё представление и вопросы о структуре файла и функциях.

    Структура.
    1. *.ini файл
    Считаю, что это наилучший вариант, т.к. в библиотеке libini уже есть много нужных функций и она хорошо себя зарекомендовала
    2. Секции вида [расширение.параметр]
    Под "расширение" понимается, как обычно, 'txt', 'png' и так далее без кавычек. "Параметр" определяет цель открытия файла. Поясню: изображение можно просмотреть (view), а можно отредактировать (edit). Например, GIMP прекрасно работает с изображениями, но было бы странно пользоваться им для просмотра. Логично хранить такие ассоциации в разных секциях.
    2.1. Мне на ум пришли две цели открытия: view и edit. Хотя извлечение архива, вроде, ни к одной из них не относится... В общем, здесь особо жду предложений :)
    3. Ключи в секциях имеют вид 00, 01, 02, .., 99. Таким образом, количество ассоциаций на один тип файла на одну цель открытия ограничено числом 100. Этого, думаю, достаточно. Да и с такими строками/числами удобно работать прямо в 4-байтных регистрах.

    Функции.
    1. .get_keys_number - возвращает количество ключей(ассоциаций) в секции
    2. .get_sections_number - возвращает количество секций во всём файле
    3. .get_associations __section, __from, __number_to_read, __buffer - собственно, основная функция (уже написана). Возвращает в eax кол-во реально прочитанных ассоциаций. Записывает [__number_to_read] ассоциаций для секции [__section], начиная с номера [__from], в буфер [__buffer] в следующем виде:
    3.1. Первые 4*[__number_to_read] байт отведены под указатели на прочитанные ассоциации. Далее идут ASCIIZ-строки ассоциаций
    4. .set_associations - сохраняет ассоциации. пока в планах
    5. .get_first __where_to_search - возвращает первую найденную ассоциацию при заданном порядке поиска. Обозначает "открыть хоть как-нибудь". Может быть полезна при работе с текстовыми файлами, т.к. уже есть редакторы, а просмотрщиков (типа юниксового less) пока нет :wink:

    Обсуждаем, предлагаем)
  • dunkaist
    Было бы замечательно если вместе с реализацией ты приложил еще и примеры использования.
    2.1. Мне на ум пришли две цели открытия: view и edit. Хотя извлечение архива, вроде, ни к одной из них не относится... В общем, здесь особо жду предложений
    Вот тут я несколько не понял - какая разница для каких целей ассоциация? По идее нужен просто список ассоциаций показать пользователю, а он уж сам выберет и решит для чего ему это нужно.
    1. .get_keys_number - возвращает количество ключей(ассоциаций) в секции
    2. .get_sections_number - возвращает количество секций во всём файле
    3. .get_associations __section, __from, __number_to_read, __buffer - собственно, основная функция (уже написана). Возвращает в eax кол-во реально прочитанных ассоциаций. Записывает [__number_to_read] ассоциаций для секции [__section], начиная с номера [__from], в буфер [__buffer] в следующем виде:
    3.1. Первые 4*[__number_to_read] байт отведены под указатели на прочитанные ассоциации. Далее идут ASCIIZ-строки ассоциаций
    Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?
  • Mario wrote:Было бы замечательно если вместе с реализацией ты приложил еще и примеры использования.
    Когда всё станет более-менее определённо и можно будет начинать прикручивать, залью на svn вместе с примерами.
    Mario wrote:Вот тут я несколько не понял - какая разница для каких целей ассоциация? По идее нужен просто список ассоциаций показать пользователю, а он уж сам выберет и решит для чего ему это нужно.
    Можно, конечно, показать весь список, а можно только два пункта: посмотреть, изменить. А на двойной клик (действие по умолчанию) искать сначала в view, а потом только в edit. Хотя, без целей даже проще. Посмотрим, что ещё скажут.
    Mario wrote:Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?
    Я делал по аналогии с функцией 70.1, а там "+16 = +0x10: dword: указатель на буфер, куда будут записаны данные, размер буфера должен быть не меньше 32 + [+12]*560 байт ". Если выделять, то надо не забыть освободить. А так написал "assotiations_buffer rb ****" и всё в порядке. Опять-таки, посмотрим...

    Кстати, я подключаю libini из функции UFO.init, так так остальной части библиотеки libini не нужна. Может, перенести это в главную init-функцию? Тогда не придётся вызывать UFO.init.

    p.s. UFO - Unified File Open functions
  • dunkaist wrote: Кстати, я подключаю libini из функции UFO.init, так так остальной части библиотеки libini не нужна. Может, перенести это в главную init-функцию? Тогда не придётся вызывать UFO.init.

    p.s. UFO - Unified File Open functions
    Это смотри сам - кода не вижу ничего не могу сказать конкретно.
  • Какая максимальная длина имени файла с полным путём?

    Как лучше поступить: сразу выделить память под [__number_to_read] строк наибольшей длины, а потом сделать realloc или добавлять realloc'ом памяти до строки наибольшей длины перед чтением каждой следующей строки? В первом случае будет выделено MAX_NAME_LENGTH*[__number_to_read] байт на строки и ещё [__number_to_read]*4 на указатели. Во втором куча реаллоков.
  • Если это путь к программе то 1024 символа включая ноль.
  • dunkaist wrote:Какая максимальная длина имени файла с полным путём?
    Serge wrote:Если это путь к программе то 1024 символа включая ноль.
    Для 1024 байт имеется ввиду собственный путь к бинарнику. Размер же пути в 70-й функции теоретически не ограничен.

    Serge ты так и не ответил, когда было введено ограничение и почему. Если это сделал не ты, то можно так и сказать.
    dunkaist wrote:Как лучше поступить: сразу выделить память под [__number_to_read] строк наибольшей длины, а потом сделать realloc или добавлять realloc'ом памяти до строки наибольшей длины перед чтением каждой следующей строки? В первом случае будет выделено MAX_NAME_LENGTH*[__number_to_read] байт на строки и ещё [__number_to_read]*4 на указатели. Во втором куча реаллоков.
    Я так думаю лучше первый - в свое время для 70-й функции мы обсуждали структуру, сошлись на том что со статичной структурой работать намного проще. Экономия места в этом случае не так существенна.
  • Mario

    Ограничение появилось когда стали записывать путь к исполняемому файлу. svn #91 fs_execute. Это то, что нашел я. Может было что-то раньше.
  • Who is online

    Users browsing this forum: No registered users and 7 guests