andrew_programmer
Ядру проще контролировать указатели и буферы. Досточно проверить таблицы страниц. А как одному приложению проверить другое ? Если я просто читаю память без всяких блокировок и неправильно посчитал размер то будет страничная ошибка и вылет. Сам себе буратино. А если я получил блокировку, даже для галочки, и вылетел ? Галочка останется и все остальные будут ждать. В случае ядра можно тупо поставить cli и скопировать весь буфер. Не айс, но надёжно.
Mario
1)Всёх не забанишь, а дураков и чайников обижать грех.
2)К старым дырам добавится ещё одна, что не радует.
3)Ядро может свободно менять размер буфера, благо прямого доступа к нему приложение не имеет. Хочешь - страница текста, хочешь - снимок экрана. Для расшареной области это невозможно сделать. Надо создавать новую. Очень легко получить законные утечки памяти.
Общесистемный буфер обмена
Serge
Конечно отследить таких умельцев на начальном этапе сложно, но потом надо стучать по башке изо всех сил.
Возможно мои взгляды поменял Таненбаум, но тем не менее.
Если человек целенаправленно, и отдавая себе отчет в своих действиях, совершает зло, да еще просит советов как это лучше сделать (как получилось с автором "оксюморона"), то какой же это дурак и чайник?а дураков и чайников обижать грех.
Конечно отследить таких умельцев на начальном этапе сложно, но потом надо стучать по башке изо всех сил.
Так зачем плодить, если можно не плодить.К старым дырам добавится ещё одна, что не радует.
Возможно мои взгляды поменял Таненбаум, но тем не менее.
Согласен. Но можно выйти из положения организовав кольцевую очередь буферов, рано или поздно потерянный участок будет ликвидирован. Тем более что все именованные области будут выделяться процессом-сервером. Плюс к процессу-серверу можно будет оформить графическую часть, которая позволит вручную чистить буфер при необходимости.Для расшареной области это невозможно сделать. Надо создавать новую. Очень легко получить законные утечки памяти.
Mario
То есть приложение должно каждый раз получать новое имя области а потом её открывать ?
То есть приложение должно каждый раз получать новое имя области а потом её открывать ?
Serge
Почему каждый раз? Только для вставки в буфер обмена.
Для вставки из буфера обмена будет использоваться область текущего указателя для вставки.
Будет одна область указателей размещенная в именованной памяти, которую при желании долботерроиста (или чайника) можно испортить, а можно и не портить, если использовать для работы с буфером макрос. Плюс процесс-сервер будет хранить резервную копию на этот случай в уже недоступной области.
В области указателей будут хранится ссылки на существующие слоты буфера обмена. В каждом слоте (который является независимой именованной областью, открытой только на чтение) может хранится произвольное содержимое в соответствии с указателями контейнера.
И одновременно будет существовать только одна область на запись, из которой в слоты чтения будет перемещаться информация.
По идее для буфера достаточно 16-32 слотов.
Сколько кстати именованных областей может держать ядро?
В общем шибко подробную модель я еще не продумывал, потому что не знаю - может уже кто-то работал над подобным. Если никто не отзовется то возьмусь.
Почему каждый раз? Только для вставки в буфер обмена.
Для вставки из буфера обмена будет использоваться область текущего указателя для вставки.
Будет одна область указателей размещенная в именованной памяти, которую при желании долботерроиста (или чайника) можно испортить, а можно и не портить, если использовать для работы с буфером макрос. Плюс процесс-сервер будет хранить резервную копию на этот случай в уже недоступной области.
В области указателей будут хранится ссылки на существующие слоты буфера обмена. В каждом слоте (который является независимой именованной областью, открытой только на чтение) может хранится произвольное содержимое в соответствии с указателями контейнера.
И одновременно будет существовать только одна область на запись, из которой в слоты чтения будет перемещаться информация.
По идее для буфера достаточно 16-32 слотов.
Сколько кстати именованных областей может держать ядро?
В общем шибко подробную модель я еще не продумывал, потому что не знаю - может уже кто-то работал над подобным. Если никто не отзовется то возьмусь.
Mario
Как-то громоздко получается. Если делать по Таненбауму то только через IPC. У него на этот случай есть привилегированный вызов для копирования данных между адресными пространствами. В таком варианте можно сделать надежно и относительно просто. А через расшареную память не получится.
Как-то громоздко получается. Если делать по Таненбауму то только через 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.
-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
Этого не может быть, потому что не может быть никогда?А через расшареную память не получится.
Я уже сделал похожую работу для OpenDialog, почему нет?
hidnplayr
I'm talking about the same. However, I prefer the terms server and client.-Creating a clipboard daemon (an application).
You're already working in this area? Can you tell more detail?And then use Unix-like sockets in kernel (wich will be implemented in net branch soon)
Mario
Дуракоустойчиво.
Дуракоустойчиво.
What more details do you want? Net branch has more or less Posix compatible functions to work with sockets (function 74).Mario wrote:Serge
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?
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.
Ну, хорошо - ты меня убедил. Я не специалист и заниматься этим вопросом не буду, потому что моя концепция ущербная и ее реализация будет вызывать нездоровые чувства у всей прогрессивной части сообщества. А пока специалисты решают какую ногу резать, больной будет терпеливо лежать и слушать.
Вернемся к теме еще через год.
hidnplayr
Many thanks for the links, but I decided not to pursue the matter.
Best regards.
Блин ! Это получается как честный человек я теперь должен сделать буфер сам ??? Надо было помалкивать в тряпочку.
Ладно. Если разработаете API я сделаю реализацию. Если других желающий не появится.
Ладно. Если разработаете API я сделаю реализацию. Если других желающий не появится.
Прошло больше полгода...
Поднямаю тему:
Поднямаю тему:
(С) MarioВопрос: Кто-нибудь занимается темой? Не то что есть - вставка текста через эмуляцию, а полноценным буфером?
Если у кого то на полпути и он вот-вот доделает, то я буду заниматься другими вопросами, благо их хватает.
Если желающих нет, то возьмусь за реализацию. Надо же к выходу следующей официальной версии сделать наконец буфер обмена по человечески.
З.Ы. Мне нравится идея процесса-сервера с буфером выделяемым посредством функции 68.22 (без участия функции 60).
ушёл...
Я вот то же интересуюсь - продолжает ли кто разработку полноценной программы-монитора для буфера обмена?
ушёл...
Nasarus
Я так думаю никто тебе по рукам не даст. Делай, тем более что мы с тобой уже обсуждали тонкости использования расшаренной памяти. Только стоит продумать всю процедур обмена до реализации в коде - лучше начертить блок-схему. Ну, и формат структур данных продумать: TEXT, RAW и т.д. Лучше с возможностью расширения.
Я так думаю никто тебе по рукам не даст. Делай, тем более что мы с тобой уже обсуждали тонкости использования расшаренной памяти. Только стоит продумать всю процедур обмена до реализации в коде - лучше начертить блок-схему. Ну, и формат структур данных продумать: TEXT, RAW и т.д. Лучше с возможностью расширения.
Перечитал всю тему, все соглашались на то, что нужно делать в ядре, пока barsuk ВНЕЗАПНО не выложил @clip, реализованный через тормозной IPC. Прикручивать IPC и работу с буфером к приложениям никто не стал, в итоге уже 4 года прошло, как программа есть, но ей никто не пользуется.
Так что я очень хочу попросить: Serge, сделай, пожалуйста, ядерный вариант буфера обмена, как ты предлагал. Тогда ты писал, что это займёт несколько часов с отладкой.
Так что я очень хочу попросить: Serge, сделай, пожалуйста, ядерный вариант буфера обмена, как ты предлагал. Тогда ты писал, что это займёт несколько часов с отладкой.
Из хаоса в космос
Who is online
Users browsing this forum: No registered users and 1 guest