Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Dec 02, 2020 7:26 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 184 posts ]  Go to page Previous 1 2 3 4 513 Next
Author Message
PostPosted: Tue Feb 19, 2008 8:02 pm 
Offline
Site Founder
User avatar

Joined: Sun Aug 08, 2004 8:55 am
Posts: 691
k@sTIg@r
Согласен, я ни про что другое и не думал как-то. Shared object, а что он там делает для того, чтобы данные другим приложениям передавать и как оно там всё хранится - это уже дело пятое-десятое.

_________________
in code we trust


Top
   
PostPosted: Tue Feb 19, 2008 11:32 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.
IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра. В нынешнем ядре реализовать буфер можно за пару часов с отладкой.

P.S. http://board.kolibrios.org/viewtopic.php?p=9987#p9987


Top
   
PostPosted: Wed Feb 20, 2008 1:02 am 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
согласен с Serge.. к чему тема - я не в состоянии этого реализовать, а сделать эно нужно.. вот и обращаюсь к вам, ядерщикам..

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Wed Feb 20, 2008 8:45 am 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Да, эта тема снова всплывает, но как я уже выразился, имхо, это усложнение ядра. Я не сторонник того, что бы ядро содержало и буфер обмена и gui интерфейс и частично драйвера устройств и т.д. Мне бы не хотелось делать лишнюю работу, и переписывать потом "нормально".


Top
   
PostPosted: Wed Feb 20, 2008 12:54 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Вот именно из-за того, что все мнения по буферу обмена разделялись на сторонников реализации буфера при помощи ядра и на сторонников реализации буфера как приложения, все обсуждения по буферу обмена заканчивались ничем.

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

Мне так кажется, что у разных людей, занимающихся ядром, разное видение каким должно быть ядро KolibriOS. Одни смотрят в сторону микроядра, стараясь всё что можно убрать из него, а другие смотрят в сторону гибридного ядра,оставляя в ядре часть драйверов, и делая другие драйверы динамическими.

В общем нужно одно единое мнение, иначе так и будут всякие разногласия в подходах.

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


Top
   
PostPosted: Wed Feb 20, 2008 1:24 pm 
Offline
Kernel Optimizer
User avatar

Joined: Mon Jan 16, 2006 7:58 pm
Posts: 657
Как однажды высказался diamond:
- Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
От сюда следует правило, если у человека есть реальная потребность и он сделает буфер обмена. Его мнение приоритетнее все тех кто просто болтает. Но ИМХО конечное видение системы должно быть единым! Иначе одни будут писать, другие потом переписывать...


Top
   
PostPosted: Wed Feb 20, 2008 1:37 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5336
>> - Мнение реально пишущего программиста приорететнее мнения тех кто не пишет.
Золотые слова, остальное в теме болтовня.

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


Top
   
PostPosted: Wed Feb 20, 2008 2:16 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
Serge wrote:
Shared object - замечательно. А откуда он возмётся ? Конечно из ядра. Потому что без ядра его никак не реализовать. То есть это будет тот же самый буфер в ядре только в другой упаковке и с другим названием.

Вообще-то без ядра ничего не реализовать, что касается любого вида IPC!

Serge wrote:
IMHO буфер обмена - функция оконной системы. И пока оконная система часть ядра, он тоже будет частью ядра.

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

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

Serge wrote:
В нынешнем ядре реализовать буфер можно за пару часов с отладкой.


Полностью согласен.


Top
   
PostPosted: Wed Feb 20, 2008 2:36 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Кстати для работы черес IPC надо знать PID сервиса.
Гарантировать что у clipboard будет постоянный PID в разных версиях ядра и дистрибутивах сложно. Остаётся после запуска сервиса записывать его PID в файл /rd/1/clipboard_pid_please_dont_delete_me. Но если отказаться от рам-диска то и этот способ перестанет работать.

Тому кто собирается делать clipboard стоит почитать MSDN. Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.


Top
   
PostPosted: Wed Feb 20, 2008 8:59 pm 
Offline
User avatar

Joined: Fri May 18, 2007 11:11 pm
Posts: 125
Serge
Quote:
Кстати для работы черес IPC надо знать PID сервиса.

А что если зарезервировать ряд PIDов (скажем до 100) под системные сервисы, каждый PID будет строго регламенгтирован по назначению, а соответствующая ему прога будет запускаться скажем спецфункцией ядра из таблицы сервисов, или конфигурационного файла. А обращаться к сервису либо через IPC, либо добавить более шуструю функцию сообщений (возможно с автозапуском сервиса, если не запущен). Это может быть полезно не только для буфера обмена, но и для других расширений системы.

_________________
Заглянул на огонёк


Top
   
PostPosted: Wed Feb 20, 2008 9:23 pm 
Offline
User avatar

Joined: Mon Apr 16, 2007 6:38 pm
Posts: 1222
или резервировать под ядро прерывания, как это сделано в ДОС

_________________
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!


Top
   
PostPosted: Wed Feb 20, 2008 11:40 pm 
Offline
User avatar

Joined: Mon Nov 05, 2007 12:09 am
Posts: 32
Serge wrote:
Хорошо работающий clipboard требует больше функций чем просто чтение/запись в буфер.

Можно, кстати, пока продумать программный интерфейс для работы с буфером обмена.
Он то не должен зависеть от реализации.

Serge wrote:
Кстати для работы через IPC надо знать PID сервиса.

Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросом
"Кто из вас Clipboard?". Ядро должно разослать это сообщение всем процессам.
А процесс Clipboard ответит спросившему приложению.

Вот, IMHO, интересная статья: http://rsdn.ru/article/baseserv/ipc.xml


Top
   
PostPosted: Thu Feb 21, 2008 12:28 am 
Offline

Joined: Thu Dec 21, 2006 10:51 am
Posts: 88
Есть такая идея тип данных вообще не хранить в буфере, если какой-то компонент принимает из буфера данные он сам должен знать что за тип там лежит, т.е. читать байты из буфера и если их удалось преобразовать в нужный формат то - буфер не пус иначе - пуст. Ну а сам буфер реализовать как демон.
Надо воспользоватся функцией посылки сообщения для передачи данных между процессами. Все это сейчас можно сделать и на С (если только сделать функции get_message для пирема сообщений, set_property для установки перенменной окружения - в которой будет хранится значение PID демона, get_property ну и int get_currend_process_pid)

Для демона буфера обмена предлогаю зарезивировать сообщения с номерами:
CB000000h - послать в буфер обмена данные
000000CBh - принять данные из буфера обмена.

Которые посылать с помощью
void stdcall _ksys_set_wanted_events(int ev);

А код демона приблизительно такой (в самом примитивном варианте):

Code:
#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;
      }
   }
}

_________________
Если бы строители строили здания, так же как программисты пишут программы первый же залетевший дятел разрушил бы цивилизацию.


Top
   
PostPosted: Thu Feb 21, 2008 2:31 pm 
Offline

Joined: Wed Feb 21, 2007 3:03 pm
Posts: 188
> Может сделать броадкастом? Отправить сообщение процессу с PID=0FF...FFH с запросом

Хм...а не слишком ли тяжело?
По поводу прерываний. Можно резервировать не прерывание, а системную ф-цию.
Типа ядро предоставляет такой себе сервис буфера обмена. Какое-либо приложение может зарегистрировать себя как менеджер буфера обмена. Теперь ядро знает кому форвардить GET/SET clipboard.
Вот только другой вопрос, соит ли оно того? Чем все выше изложеные методы лучше чем буфер обмена в ядре?
Возможно стоит задуматься о резервировании PID'ов, но что-то мне в этой идее не нравится :)

> Есть такая идея тип данных вообще не хранить в буфере...
Не разумно. Простой пример - RTF и plain-text. При копировании RTF в буфер заносится 2 копии (вроде бы) RTF и plain-text. Это нужно для того, чтобы приложение могло получить и форматированный текст, если поддерживает его и простой текст, если форматирование не поддерживается. Возможно для экономии памяти лежит одна копия, просто clipboard сам стрипает символы форматирования, в реализацию не вникал. Это раз.
Во вторых, не разумно каждый раз анализировать содержимое буфера.
В-третьих, где гарантия что plain-text в буфере это не картинка? Хидеры? так зачем выдумывать хидеры если можно один раз задать тип и все.
В-четвертых. А как быть с файлами? При копировании файла в буфер заносится лишь путь к файлу.
И т.д.


Top
   
PostPosted: Thu Feb 21, 2008 4:29 pm 
Offline
Mentor
User avatar

Joined: Tue Jan 15, 2008 11:27 am
Posts: 756
Сделать системную ф-цию было бы хорошо. Потому что тогда работа с буфером будет стандартной и не потребуется дополнительных программ. Но данной реализацией, по моему мнению, должны заниматься разработчики ядра.

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

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

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


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

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 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