Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Sep 19, 2020 6:22 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 184 posts ]  Go to page Previous 1 2 3 4 5 613 Next
Author Message
PostPosted: Mon Aug 25, 2008 3:16 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
Если использовать для этого отдельный сервис, то может и интерфейс взаимодействия приложений доработать?
Например, можно сделать по образцу D-BUS.

..bw


Top
   
PostPosted: Tue Aug 26, 2008 2:45 pm 
Offline

Joined: Wed Jun 04, 2008 10:16 pm
Posts: 174
E-water wrote:
А может лучше, своего рода, контейнер файлов? Ну типа папка, только её файлы в RAM.

RAM-диск Колибри(/rd/1/) как раз является такой папкой в памяти. А буфер предназначен для обмена данными между приложениями без необходимости вводить имена файлов.

E-water wrote:
Для текста, хорошо бы прогу, которая могла бы эммулируя нажатия клавиш впечатывать текст(тогда не нужно делать поддержку буффера в прогах, для того что бы вставить текст)

Да, согласен. Это может делать и сам сервис.

bw
Что плохо в текущей реализации интерфейса?


Top
   
PostPosted: Tue Aug 26, 2008 4:37 pm 
Offline
User avatar

Joined: Thu Mar 01, 2007 4:16 pm
Posts: 426
При чем здесь плохо, это разные вещи. Посмотри сначала.
Если бы я предложил позаимствовать COM/DCOM, ты бы сказал - чем плох текущий интерфейс? Это просто интерфейсы разного порядка, COM и D-BUS это протоколы высокго уровня, если угодно. Ты ведь не сравниваешь IP и HTTP протоколы? Чем IP хуже HTTP?
Вот например в IPC KOS предусмотрен интерфейс для доступа к сервисам по их именам или другим идентификатором (заранее известным), без дополнительных телодвижений вроде чтения pid из заранее подготовленного, на этот случай, файла?

..bw


Top
   
PostPosted: Tue Sep 09, 2008 11:50 pm 
Offline

Joined: Wed Jun 04, 2008 10:16 pm
Posts: 174
bw
Ясно.

Вот новая версия, здесь есть вставка во все приложения через Ctrl-Alt-V.


Attachments:
clip-0.2.7z [30.62 KiB]
Downloaded 191 times
Top
   
PostPosted: Sun Oct 18, 2009 12:50 am 
Прошло больше года...

Вопрос: Кто-нибудь занимается темой? Не то что есть - вставка текста через эмуляцию, а полноценным буфером?

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

З.Ы. Мне нравится идея процесса-сервера с буфером выделяемым посредством функции 68.22 (без участия функции 60).


Top
   
PostPosted: Sun Oct 18, 2009 3:13 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

Не геморойтесь с расшареной памятью, делайте в ядре. Компактнее, быстрее и намного проще.
Imho буфер обмена это функция оконной системы. Пока она часть ядра буфер тоже должен быть частью ядра.


Top
   
PostPosted: Sun Oct 18, 2009 3:28 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 756
Serge wrote:
Imho буфер обмена это функция оконной системы

а насколько это безопасно?


Top
   
PostPosted: Sun Oct 18, 2009 4:12 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Albom

Даже надёжней чем расшареная память. Для неё нужна синхронизация доступа к данным, а в Колибри таких примитивов нет.

Т.е. если это ресурс статический и расшареный только на чтение: шрифт, битмап и т.п. будет работать замечательно, пока сервер не захочет изменить ресурс. Блокировки доступа нет. Единственный выход сделать счётчик версий для динамичных ресурсов и проверять до и после копирования в локальную память процесса.

P.S. Я вообще не вижу безопасного решения для расшареной памяти. Любой процесс с доступом на запись может забить на синхронизацию и прицип "сейчас другой джигит на красный свет ехать будет" не сработает. Джигит может оказаться дальтоником.


Top
   
PostPosted: Sun Oct 18, 2009 4:33 pm 
Serge
Quote:
Imho буфер обмена это функция оконной системы

Я не согласен. Мы взяли курс на уход от принципа "все в ядро".
Буфер обмена не обязан быть частью оконной подсистемы. Он может передавать разные типы данных.
Quote:
P.S. Я вообще не вижу безопасного решения для расшареной памяти. Любой процесс с доступом на запись может забить на синхронизацию и принцип "сейчас другой джигит на красный свет ехать будет" не сработает. Джигит может оказаться дальтоником.

Все решаемо, структура получится немного сложней, но все будет работать. Джигиты будут соблюдать правила, как и все!

Ну, если уж на то пошло, что кто-то их не соблюдает, так ведь и система вообще не защищена от злого умысла. Пока что уродских действий больных на голову старателей не наблюдается. Я надеюсь и в дальнейшем таковых не будет.

З.Ы. Ну, так никто и не ответил - занимается кто-нибудь вопросом?


Top
   
PostPosted: Sun Oct 18, 2009 4:51 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

Так опиши алгоритм. Я действительно не вижу относительно простого и безопасного решения. На строгое соблюдение ПДД не надеюсь. И самый законопослушный водитель может заглохнуть на перекрёстке.


Top
   
PostPosted: Sun Oct 18, 2009 4:59 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 756
Mario wrote:
Мы взяли курс на уход от принципа "все в ядро".

Да, правильно. Но есть такие вещи, которые неплохо всё же было иметь в ядре... Вот моё сообщение в этой теме от 21 февраля 2008 года:

Сделать системную ф-цию было бы хорошо. Потому что тогда работа с буфером будет стандартной и не потребуется дополнительных программ. Но данной реализацией, по моему мнению, должны заниматься разработчики ядра.

Quote:
Я вижу это так:
В ebx можно передавать адрес такой структуры:

dd ; номер подфункции (считать, записать)
dd ; тип содержимого (текст, битмап, список файлов)
dd ; объём содержимого в байтах
dd ; адрес, по которому располагаются данные

Список файлов можно сделать как в винде - файлы разделяются нулями, список заканчивается двойным нулём. Работать с таким списком очень удобно. И ещё хочу пояснить, что под словом "битмап" я понимаю файл bmp, а не только данные. Потому что из него можно извлечь размеры и глубину цвета.


Хотя ранее (18 февраля 2008 года) я писал:
Quote:
по моему мнению, оптимальный вариант - приложение-монитор, выделяющее нужный объём памяти и указывающий какой тип информации хранится в буфере (текст, битмап, список файлов)


Я и сейчас тоже за такую реализацию... Хотя сис. функцию использовать проще :)


Top
   
PostPosted: Sun Oct 18, 2009 5:14 pm 
Albom
Quote:
Хотя сис. функцию использовать проще

Не согласен.
1)Трудозатраты на организацию взаимодействия через системные функции или через такой же код реализованный посредством макроса, приблизительно одинаковы. Только в последнем случае не придется трогать ядро.
2)Плодить баги дешевле на уровне приложения, поскольку вероятность грохнуть всю систему ниже. К тому же при появлении джигита не соблюдающего правила грохнуть и перезапустить поток-сервер отвечающий за механизм буфера обмена проще и быстрее, чем перезагружать всю систему, в которой на этот момент могут работать приложения, работу которых прерывать не желательно.


Top
   
PostPosted: Sun Oct 18, 2009 5:31 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario

В данном случе это будет баг уровня системы. Падающий сервис не намного приятней упавшего ядра.
В худшем случае (не джигит а малолетний долбо... террорист) перезапускать сервер придётся постоянно. Вероятно вместе с задействованными приложениями. Защитить ядро намного проще.


Top
   
PostPosted: Sun Oct 18, 2009 6:08 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Quote:
Защитить ядро намного проще.


На аппаратном уровне через страницы или как-то по другому?

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Top
   
PostPosted: Sun Oct 18, 2009 6:11 pm 
Serge
Quote:
Падающий сервис не намного приятней упавшего ядра

Не приятно согласен, но не фатально как в случае с ядром.
Quote:
В худшем случае (не джигит а малолетний долбо... террорист) перезапускать сервер придётся постоянно. Вероятно вместе с задействованными приложениями.

Таких вещей в системе предостаточно и без этого и даже текущее ядро можно уронить, в большинстве случаев это получается случайно. Дырки то все не исследованы, а даже не все известные заштопаны. А от малолетних и не совсем малолетних долботерористов не застрахованы даже более развитые системы. Единственно реальный выход - жесткий, я бы даже сказал жесточайший, контроль со стороны всего сообщества: раздача бананов и прекращение консультации.
От лобовой атаки значительными силами - брутфорса, ничто не спасает.
Quote:
Защитить ядро намного проще.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 184 posts ]  Go to page Previous 1 2 3 4 5 613 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited