k@sTIg@r
Согласен, я ни про что другое и не думал как-то. Shared object, а что он там делает для того, чтобы данные другим приложениям передавать и как оно там всё хранится - это уже дело пятое-десятое.
Общесистемный буфер обмена
-
in code we trust
Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.
IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра. В нынешнем ядре реализовать буфер можно за пару часов с отладкой.
P.S. viewtopic.php?p=9987#p9987
IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра. В нынешнем ядре реализовать буфер можно за пару часов с отладкой.
P.S. viewtopic.php?p=9987#p9987
согласен с Serge.. к чему тема - я не в состоянии этого реализовать, а сделать эно нужно.. вот и обращаюсь к вам, ядерщикам..
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Да, эта тема снова всплывает, но как я уже выразился, имхо, это усложнение ядра. Я не сторонник того, что бы ядро содержало и буфер обмена и gui интерфейс и частично драйвера устройств и т.д. Мне бы не хотелось делать лишнюю работу, и переписывать потом "нормально".
Вот именно из-за того, что все мнения по буферу обмена разделялись на сторонников реализации буфера при помощи ядра и на сторонников реализации буфера как приложения, все обсуждения по буферу обмена заканчивались ничем.
В конце концов надо аргументировать свои варианты. И подходить ко всему без предубеждений. Но даже в спорных ситуациях нужно находить компромисное решение, иначе будет как в басне Крылова,-"А воз и ныне там.".
Мне так кажется, что у разных людей, занимающихся ядром, разное видение каким должно быть ядро KolibriOS. Одни смотрят в сторону микроядра, стараясь всё что можно убрать из него, а другие смотрят в сторону гибридного ядра,оставляя в ядре часть драйверов, и делая другие драйверы динамическими.
В общем нужно одно единое мнение, иначе так и будут всякие разногласия в подходах.
В конце концов надо аргументировать свои варианты. И подходить ко всему без предубеждений. Но даже в спорных ситуациях нужно находить компромисное решение, иначе будет как в басне Крылова,-"А воз и ныне там.".
Мне так кажется, что у разных людей, занимающихся ядром, разное видение каким должно быть ядро KolibriOS. Одни смотрят в сторону микроядра, стараясь всё что можно убрать из него, а другие смотрят в сторону гибридного ядра,оставляя в ядре часть драйверов, и делая другие драйверы динамическими.
В общем нужно одно единое мнение, иначе так и будут всякие разногласия в подходах.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Как однажды высказался diamond:
- Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
От сюда следует правило, если у человека есть реальная потребность и он сделает буфер обмена. Его мнение приоритетнее все тех кто просто болтает. Но ИМХО конечное видение системы должно быть единым! Иначе одни будут писать, другие потом переписывать...
- Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
От сюда следует правило, если у человека есть реальная потребность и он сделает буфер обмена. Его мнение приоритетнее все тех кто просто болтает. Но ИМХО конечное видение системы должно быть единым! Иначе одни будут писать, другие потом переписывать...
>> - Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
Золотые слова, остальное в теме болтовня.
Золотые слова, остальное в теме болтовня.
Из хаоса в космос
Вообще-то без ядра ничего не реализовать, что касается любого вида IPC!Serge wrote:Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.
Судя по тому что ты написал выше, то оконная система пожизни будет ядерной, т.к. любое взаимодействие процессов (а приложения как то должны общаться с оконной системой) происходит просредством ядра.Serge wrote: IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра.
Тогда в любом слачуе пихаем в ядро, просто в оконной системе "будет тот же самый буфер в ядре только в другой упаковке и с другим названием"
Полностью согласен.Serge wrote: В нынешнем ядре реализовать буфер можно за пару часов с отладкой.
Кстати для работы черес IPC надо знать PID сервиса.
Гарантировать что у clipboard будет постоянный PID в разных версиях ядра и дистрибутивах сложно. Остаётся после запуска сервиса записывать его PID в файл /rd/1/clipboard_pid_please_dont_delete_me. Но если отказаться от рам-диска то и этот способ перестанет работать.
Тому кто собирается делать clipboard стоит почитать MSDN. Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.
Гарантировать что у clipboard будет постоянный PID в разных версиях ядра и дистрибутивах сложно. Остаётся после запуска сервиса записывать его PID в файл /rd/1/clipboard_pid_please_dont_delete_me. Но если отказаться от рам-диска то и этот способ перестанет работать.
Тому кто собирается делать clipboard стоит почитать MSDN. Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.
Serge
А что если зарезервировать ряд PIDов (скажем до 100) под системные сервисы, каждый PID будет строго регламенгтирован по назначению, а соответствующая ему прога будет запускаться скажем спецфункцией ядра из таблицы сервисов, или конфигурационного файла. А обращаться к сервису либо через IPC, либо добавить более шуструю функцию сообщений (возможно с автозапуском сервиса, если не запущен). Это может быть полезно не только для буфера обмена, но и для других расширений системы.Кстати для работы черес IPC надо знать PID сервиса.
Заглянул на огонёк
или резервировать под ядро прерывания, как это сделано в ДОС
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Можно, кстати, пока продумать программный интерфейс для работы с буфером обмена.Serge wrote:Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.
Он то не должен зависеть от реализации.
Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросомSerge wrote:Кстати для работы через IPC надо знать PID сервиса.
"Кто из вас Clipboard?". Ядро должно разослать это сообщение всем процессам.
А процесс Clipboard ответит спросившему приложению.
Вот, IMHO, интересная статья: http://rsdn.ru/article/baseserv/ipc.xml
Есть такая идея тип данных вообще не хранить в буфере, если какой-то компонент принимает из буфера данные он сам должен знать что за тип там лежит, т.е. читать байты из буфера и если их удалось преобразовать в нужный формат то - буфер не пус иначе - пуст. Ну а сам буфер реализовать как демон.
Надо воспользоватся функцией посылки сообщения для передачи данных между процессами. Все это сейчас можно сделать и на С (если только сделать функции get_message для пирема сообщений, set_property для установки перенменной окружения - в которой будет хранится значение PID демона, get_property ну и int get_currend_process_pid)
Для демона буфера обмена предлогаю зарезивировать сообщения с номерами:
CB000000h - послать в буфер обмена данные
000000CBh - принять данные из буфера обмена.
Которые посылать с помощью
void stdcall _ksys_set_wanted_events(int ev);
А код демона приблизительно такой (в самом примитивном варианте):
Надо воспользоватся функцией посылки сообщения для передачи данных между процессами. Все это сейчас можно сделать и на С (если только сделать функции get_message для пирема сообщений, set_property для установки перенменной окружения - в которой будет хранится значение PID демона, get_property ну и int get_currend_process_pid)
Для демона буфера обмена предлогаю зарезивировать сообщения с номерами:
CB000000h - послать в буфер обмена данные
000000CBh - принять данные из буфера обмена.
Которые посылать с помощью
void stdcall _ksys_set_wanted_events(int ev);
А код демона приблизительно такой (в самом примитивном варианте):
Code: Select all
#include <kolibrisys.h>
#include <stdlib.h>
#include <string.h>
#define TO_CLIBOARD CB000000h;
#define OUT_CLIBOARD 000000CBh;
void kos_Main()
{
int datasize = 0;
unsigned char *buf;
// Поставить переменную окруженя CLIPBOARD чтобы все знали на какой PID посылать сообщение
_ksys_set_property( "CLIPBOARD", itoa( get_currend_process_pid() ) );
while(1)
{
start:
switch (_ksys_wait_for_event_infinite())
{
case TO_CLIBOARD:
buf = _ksys_get_message(&datasize); // сообщение в память
goto start;
case OUT_CLIBOARD:
int size, *pid = _ksys_get_message(&size); // принять пид получателя
_ksys_send_message(*pid, buf, datasize);// послать ему данные
goto start;
}
}
}
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.
> Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросом
Хм...а не слишком ли тяжело?
По поводу прерываний. Можно резервировать не прерывание, а системную ф-цию.
Типа ядро предоставляет такой себе сервис буфера обмена. Какое-либо приложение может зарегистрировать себя как менеджер буфера обмена. Теперь ядро знает кому форвардить GET/SET clipboard.
Вот только другой вопрос, соит ли оно того? Чем все выше изложеные методы лучше чем буфер обмена в ядре?
Возможно стоит задуматься о резервировании PID'ов, но что-то мне в этой идее не нравится
> Есть такая идея тип данных вообще не хранить в буфере...
Не разумно. Простой пример - RTF и plain-text. При копировании RTF в буфер заносится 2 копии (вроде бы) RTF и plain-text. Это нужно для того, чтобы приложение могло получить и форматированный текст, если поддерживает его и простой текст, если форматирование не поддерживается. Возможно для экономии памяти лежит одна копия, просто clipboard сам стрипает символы форматирования, в реализацию не вникал. Это раз.
Во вторых, не разумно каждый раз анализировать содержимое буфера.
В-третьих, где гарантия что plain-text в буфере это не картинка? Хидеры? так зачем выдумывать хидеры если можно один раз задать тип и все.
В-четвертых. А как быть с файлами? При копировании файла в буфер заносится лишь путь к файлу.
И т.д.
Хм...а не слишком ли тяжело?
По поводу прерываний. Можно резервировать не прерывание, а системную ф-цию.
Типа ядро предоставляет такой себе сервис буфера обмена. Какое-либо приложение может зарегистрировать себя как менеджер буфера обмена. Теперь ядро знает кому форвардить GET/SET clipboard.
Вот только другой вопрос, соит ли оно того? Чем все выше изложеные методы лучше чем буфер обмена в ядре?
Возможно стоит задуматься о резервировании PID'ов, но что-то мне в этой идее не нравится
> Есть такая идея тип данных вообще не хранить в буфере...
Не разумно. Простой пример - RTF и plain-text. При копировании RTF в буфер заносится 2 копии (вроде бы) RTF и plain-text. Это нужно для того, чтобы приложение могло получить и форматированный текст, если поддерживает его и простой текст, если форматирование не поддерживается. Возможно для экономии памяти лежит одна копия, просто clipboard сам стрипает символы форматирования, в реализацию не вникал. Это раз.
Во вторых, не разумно каждый раз анализировать содержимое буфера.
В-третьих, где гарантия что plain-text в буфере это не картинка? Хидеры? так зачем выдумывать хидеры если можно один раз задать тип и все.
В-четвертых. А как быть с файлами? При копировании файла в буфер заносится лишь путь к файлу.
И т.д.
Сделать системную ф-цию было бы хорошо. Потому что тогда работа с буфером будет стандартной и не потребуется дополнительных программ. Но данной реализацией, по моему мнению, должны заниматься разработчики ядра.
Я вижу это так:
В ebx можно передавать адрес такой структуры:
dd ; номер подфункции (считать, записать)
dd ; тип содержимого (текст, битмап, список файлов)
dd ; объём содержимого в байтах
dd ; адрес, по которому располагаются данные
Список файлов можно сделать как в винде - файлы разделяются нулями, список заканчивается двойным нулём. Работать с таким списком очень удобно. И ещё хочу пояснить, что под словом "битмап" я понимаю файл bmp, а не только данные. Потому что из него можно извлечь размеры и глубину цвета.
Я вижу это так:
В ebx можно передавать адрес такой структуры:
dd ; номер подфункции (считать, записать)
dd ; тип содержимого (текст, битмап, список файлов)
dd ; объём содержимого в байтах
dd ; адрес, по которому располагаются данные
Список файлов можно сделать как в винде - файлы разделяются нулями, список заканчивается двойным нулём. Работать с таким списком очень удобно. И ещё хочу пояснить, что под словом "битмап" я понимаю файл bmp, а не только данные. Потому что из него можно извлечь размеры и глубину цвета.
Who is online
Users browsing this forum: No registered users and 0 guests