Using Event Handle in driver passed fromm application

Most security drivers are stand-alone except through private interfaces. It
does make sense in that case. Yes, that is why the event sample works. It
is a stand-alone example and would not work if some filter switches context
before it passes the IRP downward. I don’t think your device can be opened
if you don’t clear the DO_DEVICE_INITIALIZING flag, so it would not be
possible to change event that way.

wrote in message news:xxxxx@ntdev…
>> If the driver should not be filtered, it can detect a filter from its
>> driver object.
>> Then just reject all requests until they get the filter out of the chain.
>
> Well, if you have attached your device to some stack, you are not really
> in a position to say
> “my driver should not be filtered”, don’t you think??? Certainly, you can
> do it (in fact, not clearing DO_DEVICE_INITIALIZING flag is the easiest
> approach - IIRC, as long as it is set, no one will be able to attach its
> device to yours). However, do you really think it is a good
> programming practice??? The only situation when you may want to do
> something like that is when you want your device to be standalone one…
>
> Anton Bassov
>

> I don’t think your device can be opened if you don’t clear the

DO_DEVICE_INITIALIZING flag, so it would not be possible to change event that way.

This is true - indeed, you will block *any* access to your device if you don’t clear this flag. Therefore, opening your device will be rather problematic. I just did not take it into the account…

Anton Bassov

> resources especially on a 4MB NT 4.0 system. I think 4MB was the minimum or

fairly common memory configuration back in that era.

8MB was the lowest minimum to install NT 3.x
16MB was the more-or-less normal amount of RAM for NT 3.x
64MB was OK for NT4

4MB was not so large even for Win3.11.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com