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

Discussing libraries simplifying applications development
Mario

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

Post by Mario »

Мне требуется сделать библиотеку для вызова OpenDialog. Однако создавать отдельную библиотеку для одной только программы не эффективно. Я думаю вполне логично создать процедурную библиотеку, куда и будут помещаться всевозможные процедуры для обработки промежуточных данных. Формат вызова будет подобен Box_Lib, который уже доказал свою состоятельность. Со временем в этой библиотеке можно разместить процедуры работы с сервером буфера обмена и много еще чего разного и нужного.
User avatar
Nasarus
Posts: 269
Joined: Wed Jan 27, 2010 10:59 am

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

Post by Nasarus »

ИМХО идея отличная. Можно будет ее сделать как аналог kernel32l/ntdll/user32.dll
ушёл...
User avatar
Asper
Posts: 988
Joined: Fri Jun 27, 2008 3:22 pm

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

Post by Asper »

А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.
User avatar
Nasarus
Posts: 269
Joined: Wed Jan 27, 2010 10:59 am

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

Post by Nasarus »

Asper wrote:А нельзя функции в *.mac файлах просто реализовать в самой box_lib.obj, добавив их в таблицу экспорта? В библиотеке при этом будут присутствовать и низкоуровневые и высокоуровневые функции.
Я думаю, что Mario хотел сказать, что пора делать библиотеку, в которой будут процедуры для программ, избавляющие их от создания лисипедов. Например, надо перекодировать текст cp886 в cp1251, программе надо будет просто вызвать oem2ansi(str1, str2) и все. Это моё IMHO, конечно.
ушёл...
Mario

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

Post by Mario »

Asper
Box_Lib это все-таки библиотека графических компонентов. Не во всех программах они используются, а тут будут именно общие процедуры. В общем логическое разделение. Ну, и Nasarus правильно сформулировал.
В противном случае опять будем иметь одну большую библиотеку вместо ядра - от этого ведь и уходим постепенно.
Mario

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

Post by Mario »

SVN r. 1509 - загрузил код библиотеки. Пока в нем только процедуры для вызова OpenDialog. Работоспособность проверил на zSea. Позже прикручу к другим приложениям.
Mario

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

Post by Mario »

SVN r. 1581 - доработана библиотека для поддержки сохранения размеров OpenDialog и центрирование его относительно текущего окна.
User avatar
dunkaist
Mentor
Posts: 730
Joined: Mon Oct 19, 2009 10:58 am
Has thanked: 4 times
Been thanked: 2 times

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

Post by dunkaist »

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:

Обсуждаем, предлагаем)
Mario

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

Post by Mario »

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-строки ассоциаций
Т.е. размер буфера должно выделить и передать указатель само приложение? Не лучше ли будет библиотеке самой выделять память?
User avatar
dunkaist
Mentor
Posts: 730
Joined: Mon Oct 19, 2009 10:58 am
Has thanked: 4 times
Been thanked: 2 times

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

Post by dunkaist »

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
Mario

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

Post by Mario »

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

p.s. UFO - Unified File Open functions
Это смотри сам - кода не вижу ничего не могу сказать конкретно.
User avatar
dunkaist
Mentor
Posts: 730
Joined: Mon Oct 19, 2009 10:58 am
Has thanked: 4 times
Been thanked: 2 times

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

Post by dunkaist »

Какая максимальная длина имени файла с полным путём?

Как лучше поступить: сразу выделить память под [__number_to_read] строк наибольшей длины, а потом сделать realloc или добавлять realloc'ом памяти до строки наибольшей длины перед чтением каждой следующей строки? В первом случае будет выделено MAX_NAME_LENGTH*[__number_to_read] байт на строки и ещё [__number_to_read]*4 на указатели. Во втором куча реаллоков.
Serge
Kernel Developer
Posts: 3952
Joined: Wed Mar 08, 2006 6:25 pm

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

Post by Serge »

Если это путь к программе то 1024 символа включая ноль.
Mario

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

Post by Mario »

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-й функции мы обсуждали структуру, сошлись на том что со статичной структурой работать намного проще. Экономия места в этом случае не так существенна.
Serge
Kernel Developer
Posts: 3952
Joined: Wed Mar 08, 2006 6:25 pm

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

Post by Serge »

Mario

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

Who is online

Users browsing this forum: No registered users and 0 guests