Драйвер виртуального COM порта

[Natur_Keks]

 Здравствуйте. На работе поставили задачу: написать драйвер, создающий виртуальный COM порт, к которому сторонняя прога подключается как к реальному, но все отправляемые данные должны перенаправляться моему приложению. Также и наоборот: все данные от моей проги должны через драйвер уходить в этот виртуальный COM порт(и соответственно стороннему приложению).
 И вот вопрос: можно ли создать виртуальный COM порт, одновременный доступ к которому разрешён нескольким (двум) приложениям? Причём так, чтобы данные, приходящие от одного, перенаправлялись другому?
 Или нужно два драйвера: 1) драйвер виртуального COM порта 2)просто драйвер ядра. К первому подсоединяется стороннее приложение, ко второму моё приложение, между драйверами наладить обмен данными.
 Если что, сильно не пинать , написанием драйверов никогда не занимался . Буду благодарен за любые советы, ссылки, исходники.
 

[RXL]

http://sourceforge.net/projects/com0com/
Посмотри вот это.
Идея проста: два виртуальных COM-порта, также виртуально соединенных нуль-модемным кабелем.

[Natur_Keks]

http://sourceforge.net/projects/com0com/
Посмотри вот это.
Идея проста: два виртуальных COM-порта, также виртуально соединенных нуль-модемным кабелем.

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

[RXL]

А как второе приложение будет общаться с драйвером - об этом они подумали? И вообще, нафига изобретать велосипед, если все уже давно придумано.

[Ochkarik]

эээ... я не совсем понимаю что требуется.
во первых, если это должен быть как бы совсем стандартный по функциям COM порт... разве можно одновременно подключится к ОДНОМУ COM порту из двух приложений?))  ответ - нельзя принципиально! не реальные, ни виртуальные.
то есть в любом случае, COM порт в системе захватывается одним приложением - монопольно. таким образом в любом случае, если вам действительно нужна эмуляция COM в обоих приложениях - порта должно быть два.
в качестве довода привести этот факт - начальству, после чего с чистой совестью  использовать вышеуказанную ссылку)

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

Добавлено через 13 минут и 22 секунды:
ежели припрет, постараюсь подсказать с чего начать)

[Natur_Keks]

 Насчёт невозможности открытия одного виртуального COM порта - программа VSPE http://www.radioscanner.ru/files/miscsoftware/file9815) каким-то образом это позволяет,т.е. возможно создать виртуальный COM порт, который можно открыть несколькими приложениями (типа Hyper Terminala) одновременно (проверял - работает). Причём данные из одного приложения передаюся в другое.
 Получается, в принципе это возможно, только, интересно, насколько сложно .
 Во второй программе,да действительно, интерфейс COM эмулировать не нужно - она (по задумке) производит обмен данными напрямую с драйвером.
  постараюсь подсказать с чего начать) - очень бы хотелось

[darkelf]

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

Ну ведь она не телепатически с драйвером общается - с ним тоже должен быть определённый интерфейс, а если так - почему-бы ему не быть com-портовым.

[Natur_Keks]

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

[Ochkarik]

VSPE свой драйвер подставляет.
ну тогда видимо выбора нет, надо писать драйвер.... можно для очистки совести на API посмотреть - что там позволено... может быть можно поставить hook на функции обращения к порту и перехватывать http://www.rsdn.ru/article/baseserv/IntercetionAPI.xml
и была еще какая то библиотека для перехвата ядра... но убей бог пока не вспомню названия...
... вспомнил! Detours. http://research.microsoft.com/en-us/projects/detours/

если драйвер... то, ща поищу с чего начать.

Добавлено через 1 час, 53 минуты и 51 секунду:
раздел msdn архитектуры последовательных COM портов
для драйвера, вам потребуется DDK. наверное лучше сразу новый с майкрософта, но подойдет и старый с сайта.
из литературы - Вальтер Они, Руссинович и msdn - ваши друзья)
компиляция драйвера - утилитой build.exe, либо настройками VS (темы были на форуме)

там есть примеры драйвера COM порта, но он вам не факт что подойдет, потому как использует железо. хотя теоретически его тоже можно обрезать до виртуального устройства.
обязательно стоит посмотреть исходники com0com. это почти ваш случай, хотя тоже много избыточный вариант.
файлы операций чтения/записи там выделены, можно попробовать внедрить туда свой API, если его там еще нет)

еще есть пример в DDK/WDF DDK\6001.18001\src\input\vserial\
это какой то простенький виртуальный порт, для эмуляции планшетов... не знаю насколько он подойдет. но имеет смысл обязательно глянуть! особенно после того как напугает объем кода предыдущих источников)

да. сразу - в винде существует два подхода написания драйвера. при помощи "чистого" DDK (начиная с win98) и с использованием WDF (начиная с XP+SP, книга Пенни Орвик).
последнее более новое, и быть может незначительно проще, но скорее всего в интернете инфа об этом пока менее распространена.

[Natur_Keks]

 Спасибо за помощь  .
 На данный момент есть такой замысел:
 1) непосредственно драйвер виртуального порта (как самое сложное) создаётся в Compuware DriverStudio 3.2 - там на автомате создаётся проект WDM драйвера виртуального порта (компилируется, получаем драйвер - вроде работает: через Панель Управления->Добавление Оборудования добавлял последовательный порт в систему, подсовывал этот драйвер - состояние порта в итоге "Устройство работает нормально", приложения тоже новопоявившийся порт видят).
 2) написать фильтр-драйвер (это проще, типа legacy драйвер), который будет помещаться в стек над драйвером виртуального порта, перехватывать запросы READ/WRITE и работать с моим приложением. Фильтр-драйвер должен загружаться в систему динамически - при запуске моей проги (SCM менеджер).
 Понимаю, что это костыли конечно, но вроде как реально в относительно короткие сроки. 
 

[Ochkarik]

если DS создает такую "рыбу"(не знал;) - то лучше конечно использовать ее, иначе чей то сторонний драйвер виртуального порта все таки придется ставить? нумега оч хорошие "рыбы" варит) до сих пор пользуюсь)

но наверное оба способа имеют право на жизнь... DS - фильтры кстати тоже генерила.
посмотрите оба проекта мельком - что больше понравится то и используйте)
но ИМХО правильнее допилить сразу виртуальный драйвер)

PS или вы имели в виду, что хотите два драйвера собрать?
можно обойтись одним виртуальным портом) фильтр лишний.

[Natur_Keks]

Спасибо за помощь, работа над драйвером движется, но вот возникла одна проблема:
нужно задержать обработку запроса IOCTL_READ - и если я пишу в ReadDispatch(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp):

Код:

...
ReadIRP = Irp;                 // сохраняем IRP (ReadIRP - глобальная переменная)
IoMarkIrpPending(Irp);         // помечаем Irp как отложенный
status = STATUS_PENDING;       // выставляем статус "Отложенный"
Irp->IoStatus.Status = status;
IoCompleteRequest(Irp, IO_NO_INCREMENT);
...

То как мне в дальнейшем его обработать?
Вариант просто написать (в обработчике другого IOCTLa) что-то типа:

Код:

...
user_buf = ReadIRP->AssociatedIrp.SystemBuffer;            // указатель на сист. буфер чтения/записи отложенного запроса
Out_Len = IoGetCurrentIrpStackLocation(ReadIRP)->Parameters.Read.Length;
RtlMoveMemory(user_buf, sys_buf, Out_Len);            // sys_buf[] - буфер, где хранятся необходимые для передачи данные      
ReadIRP->IoStatus.Information = In_Len;                    // In_Len - количество передаваемых байт
ReadIRP->IoStatus.Status = STATUS_SUCCESS;                 // завершаем отложенный IRP
...

приводит к синему экрану
***STOP: 0x0000008E(0xC0000005, 0xF8128406, 0xB1F4A904, 0x00000000)
***Driver_COM.sys - Address F8128406 base at F8120000, DateStemp 4e1e7308
Читал про очереди (queue), не совсем понятно как этот механизм реализуется.

[Ochkarik]

первое не совсем верно. точнее совсем не верно.
вы должны пометить пакет как отложенный (при помощи IoMarkIrpPending) и вернуть STATUS_PENDING из диспечерской функции (буквально return STATUS_PENDING )
и только когда вы решите, что уже все сделали, то должны вызвать IoCompleteRequest для этого IRP (предварительно заполнив Irp->IoStatus.Status/ReadIRP->IoStatus.Information)

кстати там достаточно  много нюансов связанных с различными случаями....
настоятельно рекомендую к очень-очень неспешному и внимательному прочтению несколько раз Уолтера Они, 5тую главу.
там и про очереди все написано, и про обработку IRP.

[Serge Roussak]

Natur_Keks, скажите, получилось ли у Вас что-нибудь по этой теме?

[Natur_Keks]

получилось процентов на 70 )  то есть взял по сути готовый драйвер виртуального com порта от NuMegaStudio, добавил свой обработчик IOSTL, ещё там кое-чего, получилось из-за отсутствия опыта достаточно  криво - возможны были "подвисания драйвера"(запрос приходит, ему статус "ожидания" выставляется и не освобождается), но для той локальной задачи для которой это всё делалось - типа устроило. И так и в некоторых местах нашей родины и работает этот мой кривоватый драйвер ))