История изменений

Задача сервера - объединить окна всех клиентов в единую картинку, как он это будет делать, если у каждого клиента свой «сервер»?

Почему свой? Сервер так и будет один,только объединенный в один «контейнер» в формате библиотеки. Мало кто знает,что в линуксе файлы формата .so могут иметь точку входа и запускаться как обычные исполняемые файлы. При этом они продолжают быть библиотеками,способными динамически линковаться к программам. Вот этим и воспользуемся - при старте запускаем такую «библиотеку», которая создает процесс-«сервер». А программы к этому серверу обращаются посредством динамической линковки и вызова функций API. Как именно там внутри «библиотеки» будет устроено межпроцессное взаимодействие - это вопрос подлежащий обсуждению. Но уж точно не через последовательный канал-сокет. Наверно через разделяемую память и семафоры.

С «запускаемыми библиотеками» я экспериментировал очень давно(два десятка лет назад),причем на ADA и совсем не по «графическим» поводам. Результаты были обнадеживающие. Но вопросы взаимодействия между запущенной «библиотекой» и линкующимися к ней программами требуют дальнейшего изучения на предмет того что там работает,а что нет,и как именно этим пользоваться.

Ну и попутно замечу что мне тогда же удалось скомпилировать с помощью gnat то что можно было загрузить в ядро в качестве модуля. Хотя кроме сообщения об успешной загрузке он ничего и не делал. Это я так,похвастался,просто к слову пришлось :)

Сейчас кроме команднострочного отладчика gdb есть полноэкранный nemiver,так что заниматься подобными хакерскими извращениями будет существенно проще.

Придётся значительную часть кода сервера переносить в ядро.

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

Задача сервера - объединить окна всех клиентов в единую картинку, как он это будет делать, если у каждого клиента свой «сервер»?

Почему свой? Сервер так и будет один,только объединенный в один «контейнер» в формате библиотеки. Мало кто знает,что в линуксе файлы формата .so могут иметь точку входа и запускаться как обычные исполняемые файлы. При этом они продолжают быть библиотеками,способными динамически линковаться к программам. Вот этим и воспользуемся - при старте запускаем такую «библиотеку», которая создает процесс-«сервер». А программы к этому серверу обращаются посредством динамической линковки и вызова функций API. Как именно там внутри «библиотеки» будет устроено межпроцессное взаимодействие - это вопрос подлежащий обсуждению. Но уж точно не через последовательный канал-сокет. Наверно через разделяемую память и семафоры.

С «запускаемыми библиотеками» я экспериментировал очень давно(два десятка лет назад),причем на ADA и совсем не по «графическим» поводам. Результаты были обнадеживающие. Но вопросы взаимодействия между запущенной «библиотекой» и линкующимися к ней программами требуют дальнейшего изучения на предмет того что там работает,а что нет,и как именно этим пользоваться.

Ну и попутно замечу что мне тогда же удалось скомпилировать с помощью gnat то что можно было загрузить в ядро в качестве модуля. Хотя кроме сообщения об успешной загрузке он ничего и не делал. Это я так,похвастался,просто к слову пришлось :)

Сейчас кроме команднострочного отладчика gdb есть полноэкранный nemiver,так что заниматься подобными хакерскими извращениями будет существенно проще.

Придётся значительную часть кода сервера переносить в ядро.

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

Задача сервера - объединить окна всех клиентов в единую картинку, как он это будет делать, если у каждого клиента свой «сервер»?

Почему свой? Сервер так и будет один,только объединенный в один «контейнер» в формате библиотеки. Мало кто знает,что в линуксе файлы формата .so могут иметь точку входа и запускаться как обычные исполняемые файлы. При этом они продолжают быть библиотеками,способными динамически линковаться к программам. Вот этим и воспользуемся - при старте запускаем такую «библиотеку», которая создает процесс-«сервер». А программы к этому серверу обращаются посредством динамической линковки и вызова функций API. Как именно там внутри «библиотеки» будет устроено межпроцессное взаимодействие - это вопрос подлежащий обсуждению. Но уж точно не через последовательный канал-сокет. Наверно через разделяемую память и семафоры.

С «запускаемыми библиотеками» я экспериментировал очень давно(два десятка лет назад),причем на ADA и совсем не по «графическим» поводам. Результаты были обнадеживающие. Но вопросы взаимодействия между запущенной «библиотекой» и линкующимися к ней программами требуют дальнейшего изучения на предмет того что там работает,а что нет,и как именно этим пользоваться.

Ну и попутно замечу что мне тогда же удалось скомпилировать с помощью gnat то что можно было загрузить в ядро в качестве модуля. Хотя кроме сообщения об успешной загрузке он ничего и не делал. Это я так,похвастался,просто к слову пришлось :)

Сейчас кроме команднострочного отладчика gdb есть полноэкранный nemiver,так что заниматься подобными хакерскими извращениями будет существенно проще.

Придётся значительную часть кода сервера переносить в ядро.

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