DeviceIoControl,METHOD_BUFFERED и данные по поинтеру Win32,
- From
- Eugene Muzychenko (2:5000/14)
- To
- Ihor Osov'yak ()
- Date
- 2003-04-22T16:56:28Z
- Area
- SU.WINDOWS.NT.PROG
Привет!
22 Apr 03 12:19, you wrote to me:
>> Iy> То есть, в драйвер передаются не сами данные, а поинтер на них.
>>
>> Ну а как ты представляешь себе передачу в драйвер "самих данных"
>> неопределенного заранее размера? ;)
Iy> Еще раз повторяю, что я был свято уверен, что что такая техника
Iy> неработоспособна, пока сам не увидел работающее изделие.
Погоди, ты о какой такой технике? Когда в самом буфере передаются другие адреса, а драйвер их достает и лазит по ним?
Iy> То есть я не агитирую за использование этой техники, мало того, я ее
Iy> не собираюсь использовать сам. Нужно только доказать человеку, что
Iy> так плохо (есть такое предчувствие).
Если драйвер рассчитан именно на работу только со своим процессом - это ничем не плохо. Ведь некто посторонний может сесть лишь на стандартный, универсальный драйвер, для которого определен протокол обмена. Если у драйвера свой протокол - как к нему может прицепиться левый процесс или фильтр? То есть, технически, конечно, может, но кому это надо? ;) Для гарантии можно ввести сигнатуры в запросах.
Iy> Относительно "неопределенного заранее размера". Передается поинтер на
Iy> zero terminated str, PChar то бишь.. Я конечно понимаю, что драйвер в
Iy> таком случае станет жертвой ошибки win32 приложения, если оно этот
Iy> zero terminated в передаваемую строку не положит.
Ну, на это есть проверки. Если драйвер проверяет, его ли приложение его вызывает, то вероятность ошибки в приложении сравнима с вероятностью ошибки в самом драйвере. Плюс это можно контролировать.
Iy> Но здесь есть опасность того, что в системе кто-то навешает
Iy> драйвер-фильтр
Который, как уже было сказано, имеет смысл навешивать только на известные драйверы. В протоколах которых таких выкрутасов, как правило, нет :)
Всего доброго!
Евгений Музыченко
--- GoldED+/W32 1.1.4.7
* Origin: Fox Tracks, Novosibirsk, Russia (2:5000/14)