Виртуальные порты, inP=>outV; outP=>inV

Возможно ли создать некий виртуальный порт, что бы направить out некого реального порта на in виртуального, и out виртуального порта на in реального?

 

Драйвер. Больше ничего сказать не могу, т.к. не знаю, но в форуме нечто подобное недавно проскакивало.

 

Отладочные регистры из под R-0.(читай мануал интела)

Против прог типа старфорса не поможет

 

Поставлю вопрос несколько иначе:



Есть некое устройство оно генерит int я его перехватил, моя прога эти данные обработала, считав данные из порта этого устройства посредсдвом in, после этого если данные должны обрабатыватся ОС(что определяет моя прога), тогда она должна передать эти данные драйверу винды, но я то их уже считал из порта, как мне их передать?, ведь когда я дальше передам управление, драйвер винды начнет считывать данные из порта, а там то уже ничего нету!! Как мне реализовать передачу данных, что бы для драйвера виндовс мой драйвер был обсалютно прозрачен?

 

Так ты устройству не сообщай, что прочел данные, они на шине и останутся.

 

Передаёщь управление по строму вектору и всё.

 

Все врубился, спс))



Но все равно, я уже чисто из интереса хочу знать, если ли такая железка "контроллер портов"?.

 

Рано я обрадовался, а сколько байт можна оставить на шине? Ведь под понятием данные я имел ввиду от 1к до 600к байтов. То есть прога считает данные с устройства к примеру 1к байт, проверит, можна ли передать дальше или нет. Возможно появится необходимость поменять некоторые байты. И все это потом отдать драйверу этого устройства, тобиш стaрому обработчику прерывания, который будет in нашептывать)))



Т.е. я имею ввиду, что мне сначало надо сделать много раз сделать <font color="255]in</font><!--color-->, а потом только передать данные дальше.

Я думаю этот метод здесь не поможет:

(Так ты устройству не сообщай, что прочел данные, они на шине и останутся) + (Передаёщь управление по стaрoму вектору и всё)

 

Почему вобще я про виртуальные порты начал говорить, потому что есть программы которые могут эмулировать любое железо, и даже весь комп целиком, я ставил на такой комп 2003 винду, и она пахала там абсолютно не зная, что ее включили из под ХР, я просто уверен что там используются виртуальные порты (in\out), т.к. контролировать io необходимо, чтобы хотябы знать какая винда, что запрашивала.

 

Nimnul, так это уже эмулятора кода,с ними история совсем другая.(главные слова "комп целиком").

Эмулировать отдельно порты не получится.

 

Что еще за эмулятор кода? Прикалываешся?))(как в фильме: @тридцать три несчастья@ - пойди подои змею...) Если нет линки, линки, линки..

 

Cудя по твоим словам, ты знаешь место где программа(драйвер) читает данные с порта(ов). Почему бы тогда не пропатчить в том месте инструкцию rep insb (или что там) на jmp/call/int/int3/icebp/etc. на свой код который будет выполнять, к примеру

...

rep movsb

...

 

В том то и дело, что я не знаю... да и не хотел с этим заморачиваться, ведь на разных версиях ОС да и на разных версиях дров адрес этих 'мест' будет разным(, вот поэтому я хочу заморочится с виртуальными портами...

 

Если это дос-код, то его обращения к устройству (in/out) легко перехватываются самой виндой - смотри, к примеру, работу со звуковыми картами. На уровне ядра (в 98-ой точно) есть семейство функций для перехвата такого перехвата - см. к примеру VMMCall Enable_Local_Trapping.



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

Код (Text):

1. ; Set protected mode ports handler
2.   mov  ax,4A15h
3.   ...
4.   int  2Fh

Если твой код на уровне ядра винды, то тут могут быть два способа (минимум). Первый - это перехват через регистры отладки DRx. Если прога не написана с целью зашиты, то скорее всего ты легко перехватишь команды in/out. Второй - на самом деле в современных виндах появилось развлечение типа "вирутализации порта" - работа идет не через in/out, а через интерфейс HAL.DLL типа ReadPortUshort, которые на самом деле есть обрамления для In/out команд.



Не забывай про DMA при эмуляции своей железки

 

ха, а как насчет SMM для port trapping?

 

могут быть два способа (минимум).



Ты хочешь переключать всю винду в SMM для этого ? Для (например) ~5*10^4 команд in/out для HASP3 lpt ?

 

deleted

 

deleted

 

Я вообще не очень понимаю, как ты из System Mode будешь выходить "при выполнении где-то в коде" команды in/out.

Вот что написано в книге Е.Бердышева "Технология MMX. Возможности процессоров P5 и P6":



"...Единственный выход из S-режима - это выполнить команду RSM. Она может быть выполнена только в S-режиме". Также далее написано, что S-код может создать таблицу прерываний и размаскировать прерывания, но что это даст ?

 

deleted