Разное

Можно ли компьютер с установленной ХР оснастить двумя мониторами и двумя клавиатурами, и настроить таким образом, что бы на нем ОДНОВРЕМЕННО работали два пользователя?

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

Да есть такое, есть. В интернет-точках на почте такие ставят.

http://www.nowa.cc/showthread.php?t=105133

причем даже софтверно делят:

http://www.ibik-soft.com/

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

PS В основном в ходу обратные решения - объединение нескольких компьютеров под один монитор и клавиатуру.

Я как-то видел обзор материнской платы (кажется, называли её гибридной). К ней подключается две клавиатуры, две мышки и два монитора. И получилось два рабочих компьютера.
За давностью, не могу вспомнить, ни производителя, ни самого обзора, ни даже ключевых слов для гугления. Но точно помню что такое где-то было. Ещё там из плюсов отметили существенную экономию на системный блок и лицензию на ОС, так как используется всего по одному.

Еще и два процессора нужно. И две винды одновременно. Короче говоря, два компа на одной материнке. Прерывание у клавиатуры одно. Сработало прерывание - система передает его параметры активному приложению.

Не нужно два процессора. Распараллеливать вычисления уже давно научились.

> Прерывание у клавиатуры одно.
Всё верно — у каждой клавиатуры по одному прерыванию.

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

Чтобы на каждую клаву было по одному независимому прерыванию - нужно две системы, ведь прерывание зашито на уровне аппаратуры. Каким образом система различит сигналы от двух драйверов? А две системы на одном процессоре не запустишь. В конце концов, ядро системы (ntoskrnl.exe) дважды запустить не удасться, как и hal.dll. Для двух же систем все должно быть независимое - процессор, системная шина, оперативка, HDD, видеоподсистема и т.д. Таким образом получается два компа в одном ящике.

Да очень просто, вы думаете зачем все эти годы последовательный USB всем миром проталкивали - нужно было освободить прерывания - от PS/2 скоро вообще откажутся - это вопрос нескольких лет. COM-порт уже не выводят на заднюю стенку, хотя платы его ещё поддерживают. Несколько USB-клавиатур, как и несколько USB-мышей спокойно подключаются к Windows и неплохо себя чувствуют именно из-за того, что работают последовательно, а не параллельно. Описанные вами проблемы скорее для DOS характерны и для PC многолетней давности (PS/2 как раз из той эпохи). Сейчас уже не так сурово.

Несколько usb мышей, конечно, могут работать параллельно, но управляют они одним курсором. Просто подвешены они на одно прерывание, поэтому и работают параллельно. А как Вы считаете, способна система отличить, от какая мышь дернула этим прерыванием? Черта с два. Просто система знает, что кто-то дернул прерыванием мыши, следовательно, надо переместить курсор. То же касается клавиатуры.

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

Не нужно так категорично, прерывания пускай они одно дергают - это после ввода более 10 лет назад виртуальных драйверов не имеет уже никакого значения... хотя бы о двух операционных системах говорили, а не о двух компьютерах - все-таки сейчас эра виртуализации - произвольное количество компьютеров сначала объединяют в один, потом разбивают опять же на произвольное количество. По крайней мере вот эта часть "Со своими процессором, системной шиной, оперативкой и т.д." точно не соответствует действительности. У вас на ноутбуке тачскрин и мышь - при этом операционная система (по крайней мере программа управления тачскрином) в курсе чем вы работаете - мышью или тачскрином. Я не говорю, что операционная система без дополнительных драйверов сможет определить какая из клавиатур сейчас работает, но такой драйвер создать можно.

> хотя бы о двух операционных системах говорили, а не о двух компьютерах

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

>по крайней мере программа управления тачскрином...

А как эта самая программа (кстати, эта программа называется драйвер) сообщит о том, что именно она дернула прерыванием, а не другой драйвер? Возможностей для этого нет. Система (по крайней мере, WinXP) точно не имеет средств для этого. Таков драйверный механизм. Сигналы же от клавы и мыши приложению передает система - это однозначно, разве что если программа умудрится перехватить прерывание от клавы.

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

>А как эта самая программа (кстати, эта программа называется драйвер) сообщит о том, что
>именно она дернула прерыванием, а не другой драйвер?
А зачем? Это Windows и так знает... вы не задумывались почему вы перечатаете в одной программе, скажем в браузере, а рядом открытый Word ваш текст не воспринимает? Не нужно упоминать прерывания - вы не имеете к ним доступа из Windows - Windows владеет ими монопольно и отдает программ лишь те сигналы, которые им предназначены. Прерывания с точки зрения программирования остались в DOS.

>А зачем? Это Windows и так знает... вы не задумывались почему вы перечатаете в одной программе, скажем в браузере, а рядом открытый Word ваш текст не воспринимает?

cheops, Вы путаете понятия. Я прекрасно понимаю, почему сигналы от клавиш принимает браузер, а не ворд - просто у окна браузера есть фокус ввода, а у ворда - нет.

>Прерывания с точки зрения программирования остались в DOS.

В этом Вы правы. Я асм хорошо знаю.

>Очень просто при помощи виртуальной машины.

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

>Виртуальная машина - это прикладная программа.
Прошу прощения, но системная, а не прикладная.

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

>Виртуальная машина одна, а не несколько - операционных систем несколько.

Спор о терминологии. Я привык говорить, что виртуальных машин (компьютеров) несколько.

>Чтобы два устройства одного типа работали независимо, необходимо, чтобы каждое
>устройство дергало своим прерыванием.
Если не организован последовательный доступ, как в случае USB, когда данные от нескольких самых разнообразных устройств последовательно используют одно и то же прерывание. Все устройства на одном прерывании или на пуле нескольких прерываний.

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

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

>да и на ноутбуках зачастую можно подключить внешнюю клавиатуру.

Я как раз за таким ноутбуком сижу. При этом, этот текст я набрал частично на встроенной, а в основном - на подключенной клаве. В этом вся проблема - система не умеет различать встроенную и подключенную клаву. Эту проблему невозможно решить ни в Винде, ни в ДОС, ни в Linux. Теоретически, можно написать систему, которая сможет различать устройства, но Вы будете ее писать?

>чтобы одна клавиатура была закреплена за одним виртуальным столом, а другая - за другим. Вот тут потребуется софтвеерное решение.

А как Вы себе это представляете? Для Этого потребуется переписывать ядро Винды, ведь нужно менять весь механизм взаимодействия драйверов с системой, чтобы система могла различать не только прерывания, но и устройства, которые дернули этим прерыванием. Чтобы сигналы от этой клавы шли одной программе, а сигналы от второй - к другому. Кроме этого, необходимо переписывать диспетчер процессов, чтобы он мог одновременно управлять двумя активными нитями, не забывая про ротацию потоков, с учетом интересов обоих пользователей. Либо же писать сдвоенное ядро системы :), позаботившись о том, чтобы эти два ядра не конфликтовали из-за системных ресурсов.

Все уже давно написано, мелкомягкие не зря жуют свой хлеб. Вы знаете что драйвер - это и есть часть ядра? Создатель драйвера определяет как его устройство ведет себя в системе - его код потом пускают очень глубоко в систему (именно поэтому Windows вас часто спрашивает уверены ли вы в установке неподписанного драйвера). Вы на клавиатуре видите дополнительные клавиши? Их поведение по вашему тоже жестко прописано в ядре Windows? Нет. Создатель любой железки, пишет часть Windows, Linux или DOS - которая называется драйвером. Создать драйвера для клавиатуры таким образом, чтобы одна клавиатура печатала лишь на первом рабочем столе, а вторая лишь на втором - не такая непосильная задача, как вы это рисуете. Я этим заниматься разумеется не буду - провожусь долго, работать будет с синими экранами смерти. Кстати, синие экраны смерти - это зачастую работа писателей драйверов, а вовсе не Microsoft, как это обычно преподносится.

>Вы знаете что драйвер - это и есть часть ядра?

Да, знаю.

>Создатель драйвера определяет как его устройство ведет себя в системе - его код потом пускают очень глубоко в систему (именно поэтому Windows вас часто спрашивает уверены ли вы в установке неподписанного драйвера).

В этом Вы правы. Но как приложения будут реагировать на действия этого драйвера, определяет система. Ведь она просто передает приложениям информацию о том, что произошло некое событие (onmousedow, onkeypress...) (дельфийская терминология). Драйвер же на прикладную программу воздействовать не может - средств для этого нет. Ведь события - прерогатива оси.

А как вирусы ловят пароли? А как программы в системной трее регируют на горячие клавиши, хотя у них нет фокуса? Пишутся ловушки (hook-и), конечно, в Delphi того компонента нет - нужно Windows API задействовать.

>Драйвер же на прикладную программу воздействовать не может - средств для этого нет.
А зачем? Программа получит информацию, делов-то... Причем странная терминология для событийной системы... что значит не может? Установил виртуальный драйвер компакт-диска (это драйвер - он виден системой) - программа записи может писать в него и читать из него - без драйвера не может - это что не воздействие. Программа для просмотра телепрограмм показывает изображение от тв-тюнера - это что не воздействие? При этом показывает только в свое окне, рядом видео-плеер гонит фильм - он показывает в своем и из другого источника. При этом звук идет от обоих и колонки не горят синим пламенем - нормально перерабатывают звук от двух источников. А теперь разносим обе программы на разные виртуальные столы и перечитываем этот пост свежим взглядом :))) Все можно сделать, если в этом есть потребность.

>Пишутся ловушки (hook-и), конечно, в Delphi того компонента нет - нужно Windows API задействовать.

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

>Причем странная терминология для событийной системы... что значит не может?

Как сообщить системе, что событие от этой клавы неужно передавать этой программе, а событие от той - второй программе?

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

>>Пишутся ловушки (hook-и), конечно, в Delphi того компонента нет - нужно Windows API
>задействовать.
>
>Знаю, ставил хуки. Проблема в том, что должен быть поставлен по правилам. Неправильно
>установишь - получишь кучу неприятностей, вплоть до синего экрана и краха системы.
Это не проблема. Драйвер тоже самое - неправильно напишешь - получаешь синий экран смерти. Не будем же из-за этого от драйверов отказываться?

>Причем странная терминология для событийной системы... что значит не может?
>Как сообщить системе, что событие от этой клавы неужно передавать этой программе, а
>событие от той - второй программе?
>Вообще, весь Ваш пост - от непонимания того, о чем мы дискутируем. Вы хоть понимаете, в
>чем разница между прерыванием и процессом? У меня такое впечатление, что не
>понимаете.
Неправильное впечатление. Скорее у вас не понимание, зачем понадобилось вводить USB-контроллер и что событие нажатия клавиши - это не монополия какого-то одного прерывания - я вам таких событий нагенерирую сколько влезет - без всяких драйверов. Все кончилась эра, когда нажатия клавиш шли с одного устройства - вы это сами признали. У Windows устройства не теряются, особенно, если вы назначаете этому устройству свой драйвер со своим поведением. Я не знаю можно ли добиться ситуации, чтобы было два фокуса - один на одном рабочем столе, другой - на другом. Скорее уж в этом проблема. Но с клавиатурой вы не правы, хотя бы потому, что дополнительные клавиатуры имеются в продаже - игровые или с программируемыми клавишами и их поведение полностью определяется драйверами.

>Не будем же из-за этого от драйверов отказываться?

Конечно. Слава богу, не мне их писать.

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

Невозможно. В этом-то вся загвоздка.

>и их поведение полностью определяется драйверами.

Все, что они передают, получает система, а уж кому передать полученную информацию - она сама определит. А передаст она приложению, которое имеет фокус ввода.

Короче, две клавы Вы между двумя приложениями не разделите, разве что если напишете все то, что я упомянул в одном из постов ниже (ядро, хал и т.д.)

Фокус да, можно конечно потрепыхаться... но для этого нужно сейчас долбать MSDN в плане управления учетными записями и виртуальными рабочими столами (но на это время нет, не стоит это свечь).

>управления учетными записями

Какие ученые записи Вы имеете в виду?

>>управления учетными записями
>
>Какие ученые записи Вы имеете в виду?
Хм... вроде правильно написал "учетные", а не "ученые"...

Опечатался. Хотел спросить, какие учетные записи Вы имеете в виду.

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

>роме этого, необходимо переписывать диспетчер процессов, чтобы он мог одновременно
>управлять двумя активными нитями, не забывая про ротацию потоков, с учетом интересов
>обоих пользователей. Либо же писать сдвоенное ядро системы :), позаботившись о том,
>чтобы эти два ядра не конфликтовали из-за системных ресурсов.
Вы хорошо себе программирование под Windows представляете? Просто утверждение несколько парадоксальное... Зачем вперлось диспетчер процессов переписывать, который одновременно управляет сотнями процессов, десятками тысяч потоков (нитей), обращающихся к ограниченным ресурсам, да ещё и распределяя это все между парочкой другой ядер операционной системы... Знаете на залазя глубоко в Windows я могу заставить все свои программы работать лишь на четных ядрах, игнорируя нечетные и это можно делать было ещё в прошлом веке - Windows API это позволяет... Другое дело, что это нафиг не вперлось, 5 человек одновременно работая на современном компьютере не передеруться из-за ресурсов - так их много.

Вы понимаете, как диспетчер процессов определяет, какому процессу в настоящий момент передать управление компьютером. Я имею в виду управление потоками в WinNT? Прежде всего процессорный квант получает тот процесс (поток), с которым работает пользователь (поток активного окна). А если их будет два? Во сколько раз упадет производительность?

Софтверное решение, о котором Вы упомянули, предполагает набор драйверов, которые будут ловить сигналы от двух клавиатур, двух мышей, две видеоподсистемы, которые будут выводить изображение на два монитора, диспетчер процессов, который должен учитывать интересы двух пользователей одновременно, чтобы каждый драйвер, каждое активное окно получало управление в нужное время... Диспетчер процессов находится в ntoskrnl.exe - Вы и его собрались переписывать? Еще надо будет затронуть библиотеку аппаратных абстракций (hal.dll) и т.д.

>Вы понимаете, как диспетчер процессов определяет, какому процессу в настоящий момент
>передать управление компьютером. Я имею в виду управление потоками в WinNT? Прежде
>всего процессорный квант получает тот процесс (поток), с которым работает пользователь
>(поток активного окна).
Прекрасно понимаю, как и то, что у меня сейчас работает [url]одновременно[/url] сотня процессов и до тысячи потоков - это система и системные процессы других программ. Когда я работаю cron запускает самые разнообразные мои скрипты.

> А если их будет два? Во сколько раз упадет производительность?
Зависит от того, что делают пользователи, скорее всего процентов на 10-20% - на большее количество редко кто использует компьютер.

>Софтверное решение, о котором Вы упомянули, предполагает набор драйверов, которые
>будут ловить сигналы от двух клавиатур, двух мышей
Да.

> две видеоподсистемы, которые будут выводить изображение на два монитора,
Это не надо - это уже реализовано как стандартная функция Windows - я сейчас сижу за двумя мониторами - на которых два независимых рабочих стола.

>диспетчер процессов, который должен учитывать интересы двух пользователей >одновременно, чтобы каждый драйвер, каждое активное окно получало управление в
>нужное время... Диспетчер процессов находится в ntoskrnl.exe - Вы и его собрались
>переписывать? Еще надо будет затронуть библиотеку аппаратных абстракций (hal.dll) и т.д.
Это не надо - он и так все нормально учитывает - у него сотни процессов и все нормально работают, работают одновременно и без задержек. В любом случае так далеко лазать не нужно - у вас два ядра в системе? Если да, пожалуйста зайдите в диспетчер задач - выберите любой процесс, нажмите правую кнопку мыши и выберите "Задать соответствие" - там 30 неактивных процессора и два активных - вот это я уже без всяких драйверов при помощи маленькой программки могу менять. Это просто приоритет задания, но даже если его не трогать, ровным счетом ничего страшного не произойдет - не настолько у нас компьютеры слабые чтобы не выдюжить пару-тройку одновременно работающих людей, иначем бы эта тема не возникла. В Windows чего только нет - ничего переписывать в нём не нужно - все уже имеется и даже с избытком.

Вы поработать-то сегодня оба успели, или на аргументацию весь день убили?

Возьмите, скачайте 10-дневную версию "Астера", подключите всего по два и пробуйте (потратите времени столько же, зато с бОльшей пользой).

Это не реклама, просто, первое, что я нашел.

Да вы им всё удовольствие портите=))

Да, сначала написал, а потом уж подумал. Учитывая, что таких "велосипедов" пока что мало, может, изобретут новый.

>Это не надо - он и так все нормально учитывает - у него сотни процессов и все нормально работают, работают одновременно и без задержек.

Он учитывает все это при условии, что имеется только одно активное окно - ему процессорное время и передается чаще всего. А если будет два активных окна?

>там 30 неактивных процессора и два активных - вот это я уже без всяких драйверов при помощи маленькой программки могу менять.

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

Так в чем проблема - ищем активное окно, смотрим какому процессу оно принадлежит и переключаем одного пользователя на четное ядро, другого - на нечетое. Вот пишется на раз два (все Windows API функции могу хоть сейчас подсказать).

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

PS Скорее проблема будет в другом - в фокусах - два одновременно активных окна по умолчанию не создать - вот это не знаю можно обойти или нет.

>PS Скорее проблема будет в другом - в фокусах - два одновременно активных окна по умолчанию не создать - вот это не знаю можно обойти или нет.

В этом-то вся проблема.

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

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

Но основная проблема в том, как определить, какая клава (мышь) дергает прерыванием (то есть посылает событие нaшей прикладной программе). Если Вы, cheops, знаете - можно написать такую программу. По-моему, это невозможно. Система не дает нам данных об устройстве, которое вызвало событие - она просто сообщает, что событие произошло. Чтобы понять, какое устройство вызвало событие, нужно спускаться на системный уровень, то есть заменить собой библиотеку аппаратных абстракций (в ней перехватывается прерывание от клавы) и часть ядра системы (в котором генерируются события). Впрочем, часть ядра заменить невозможно - ядро представляет собой один exe-файл.

Как то поздно заглянул в эту ветку. Все это решаемо и даже есть в вариациях. Писать драйвер не такая уж большая проблема, тем более что для клавиатур можно обойтись HID драйвером. Запускать несколько ОС на одном компе современные виртуализаторы могут прекрасно. В чем вы сложности видите. Две видеокарты тоже можно поодерживать без проблем. Не делайте проблемы.

Посмотрите мое сообщение, на которое Вы ответили. Драйвер написать не проблема - вопрос в том, как связать одну клавиатуру с одной программой, а вторую - с другой. И как при этом одновременно сделать обе программы активными, да еще с фокусом ввода. Я почему и говорю, что требуется две оси - и эмулятор здесь не поможет, он, как и любая другая программа получает события от системы, а она не станет сообщать, какая именно клава вызвала событие onkeypress.

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