Board.KolibriOS.org

andrew_programmer

Ядру проще контролировать указатели и буферы. Досточно проверить таблицы страниц. А как одному приложению проверить другое ? Если я просто читаю память без всяких блокировок и неправильно посчитал размер то будет страничная ошибка и вылет. Сам себе буратино. А если я получил блокировку, даже для галочки, и вылетел ? Галочка останется и все остальные будут ждать. В случае ядра можно тупо поставить cli и скопировать весь буфер. Не айс, но надёжно.

Mario

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

Serge

Если человек целенаправленно, и отдавая себе отчет в своих действиях, совершает зло, да еще просит советов как это лучше сделать (как получилось с автором "оксюморона"), то какой же это дурак и чайник?
Конечно отследить таких умельцев на начальном этапе сложно, но потом надо стучать по башке изо всех сил.

Так зачем плодить, если можно не плодить.
Возможно мои взгляды поменял Таненбаум, но тем не менее.

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

Mario

То есть приложение должно каждый раз получать новое имя области а потом её открывать ?

Serge
Почему каждый раз? Только для вставки в буфер обмена.

Для вставки из буфера обмена будет использоваться область текущего указателя для вставки.

Будет одна область указателей размещенная в именованной памяти, которую при желании долботерроиста (или чайника) можно испортить, а можно и не портить, если использовать для работы с буфером макрос. Плюс процесс-сервер будет хранить резервную копию на этот случай в уже недоступной области.

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

И одновременно будет существовать только одна область на запись, из которой в слоты чтения будет перемещаться информация.
По идее для буфера достаточно 16-32 слотов.

Сколько кстати именованных областей может держать ядро?

В общем шибко подробную модель я еще не продумывал, потому что не знаю - может уже кто-то работал над подобным. Если никто не отзовется то возьмусь.

Mario

Как-то громоздко получается. Если делать по Таненбауму то только через IPC. У него на этот случай есть привилегированный вызов для копирования данных между адресными пространствами. В таком варианте можно сделать надежно и относительно просто. А через расшареную память не получится.

The best sollution I see is as follows:

-Creating a clipboard daemon (an application).
-And then use Unix-like sockets in kernel (wich will be implemented in net branch soon) to manage communication between the daemon and all applications that want to use the clipboard.

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

Serge

Этого не может быть, потому что не может быть никогда?
Я уже сделал похожую работу для OpenDialog, почему нет?

hidnplayr

I'm talking about the same. However, I prefer the terms server and client.

You're already working in this area? Can you tell more detail?

Mario

Дуракоустойчиво.

What more details do you want? Net branch has more or less Posix compatible functions to work with sockets (function 74).
http://wiki.kolibrios.org/New_network_api
There will also be a IPC socket type, like unix sockets:
http://beej.us/guide/bgipc/output/html/ ... xsock.html

_________________
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein

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

Вернемся к теме еще через год.

hidnplayr
Many thanks for the links, but I decided not to pursue the matter.
Best regards.

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

Прошло больше полгода...

Поднямаю тему:
(С) Mario

_________________
ушёл...

Я вот то же интересуюсь - продолжает ли кто разработку полноценной программы-монитора для буфера обмена?

_________________
ушёл...

Nasarus
Я так думаю никто тебе по рукам не даст. Делай, тем более что мы с тобой уже обсуждали тонкости использования расшаренной памяти. Только стоит продумать всю процедур обмена до реализации в коде - лучше начертить блок-схему. Ну, и формат структур данных продумать: TEXT, RAW и т.д. Лучше с возможностью расширения.

Перечитал всю тему, все соглашались на то, что нужно делать в ядре, пока barsuk ВНЕЗАПНО не выложил @clip, реализованный через тормозной IPC. Прикручивать IPC и работу с буфером к приложениям никто не стал, в итоге уже 4 года прошло, как программа есть, но ей никто не пользуется.

Так что я очень хочу попросить: Serge, сделай, пожалуйста, ядерный вариант буфера обмена, как ты предлагал. Тогда ты писал, что это займёт несколько часов с отладкой.

_________________
Звиздеть не мешки ворочать