Hi,
I have a software-only KMDF driver, that needs to write data, to multiple clients. The clients can be user-mode apps or kernel-mode drivers, on the same system… I don’t need to communicate with a remote system.
The data that the driver needs to write are individual packets, that can range in size from 10 bytes to 4KBytes… It is not streaming data.
Looking at the different IPC mechanisms in Windows, it looks like pipes serve the purpose.Anonymous pipes seem to be enough since there is no need to communicate with clients outside the local system.
I’m thinking that the client will be the pipe server, and my KMDF driver will be the pipe client. To establish the link, the client “initializes” the communication by providing the Write Handle of the pipe as input in an IOCTL.
Are there any loopholes in this mechanism? One issue I see is that if there is a “hung” client, then my driver gets stuck, since the Write doesn’t return until there is space available in the pipe.
Or if there are better mechanisms to do this, any pointers are highly appreciated!
Regards
Madhavi
Using pipes in a Windows driver is a great way to crash the system but
nothing else. Pipes are undocumented in the kernel, and the samples on
the net are bogus. Again as in your answer to your previous question
use inverted calls, with the IOCTL having a 4K buffer. In this case the
application should post a number of IOCTL requests.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hi,
>
> I have a software-only KMDF driver, that needs to write data, to multiple clients. The clients can be user-mode apps or kernel-mode drivers, on the same system… I don’t need to communicate with a remote system.
>
> The data that the driver needs to write are individual packets, that can range in size from 10 bytes to 4KBytes… It is not streaming data.
>
> Looking at the different IPC mechanisms in Windows, it looks like pipes serve the purpose.Anonymous pipes seem to be enough since there is no need to communicate with clients outside the local system.
>
> I’m thinking that the client will be the pipe server, and my KMDF driver will be the pipe client. To establish the link, the client “initializes” the communication by providing the Write Handle of the pipe as input in an IOCTL.
>
> Are there any loopholes in this mechanism? One issue I see is that if there is a “hung” client, then my driver gets stuck, since the Write doesn’t return until there is space available in the pipe.
>
> Or if there are better mechanisms to do this, any pointers are highly appreciated!
>
> Regards
> Madhavi
> Looking at the different IPC mechanisms in Windows, it looks like pipes serve the >purpose
Why do you need pipes? why not use the simpler layer below - i.e. sockets?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Don Burn wrote:
Using pipes in a Windows driver is a great way to crash the system but
nothing else. Pipes are undocumented in the kernel, and the samples on
the net are bogus.
Allow me to second this. I actually implemented a named-pipe solution
in one driver and got it working, but it was unreliable in ways that
were difficult to nail down. I replace it with the old inverted call,
and my life was much better.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I hope i didn’t misunderstand but can’t we use Section Objects with some
syncronization mechanism (named events) .
- Driver fills the section object’s buffer with a header like “To Process
Id : XX” and data he wants to send
- Sets the event object #1 and waits for #2 to be signalled.
- All listeners wake up, appropriate listener gets the data and sets the
Event #2 which wakes driver thread. And step 1 starts again…
I am not sure if this will be sufficient for many listeners in means of
speed???
Although in order to implement this, you will still need a registering
mechanism for listeners and i think best way would be an IOCTL for
registration with a PID.
Hope it helps…
Best Regards,
*Emre TINAZTEPE***
*Zemana Information Technologies*
On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
> Don Burn wrote:
> > Using pipes in a Windows driver is a great way to crash the system but
> > nothing else. Pipes are undocumented in the kernel, and the samples on
> > the net are bogus.
>
> Allow me to second this. I actually implemented a named-pipe solution
> in one driver and got it working, but it was unreliable in ways that
> were difficult to nail down. I replace it with the old inverted call,
> and my life was much better.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
What do you believe you are saving over the inverted call model?
With inverted call you pick the client you want to send the data to, write the data into their waiting buffers and complete the request to wake them up. You don’t need to have the kernel side block hoping the client sets an event saying that it’s done with the data. You don’t need to expose the data to every process and hope they’ll all be well behaved about its use.
-p
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Emre Tinaztepe
Sent: Monday, November 07, 2011 2:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IPC between kernel and user-mode
I hope i didn’t misunderstand but can’t we use Section Objects with some syncronization mechanism (named events) .
- Driver fills the section object’s buffer with a header like “To Process Id : XX” and data he wants to send
- Sets the event object #1 and waits for #2 to be signalled.
- All listeners wake up, appropriate listener gets the data and sets the Event #2 which wakes driver thread. And step 1 starts again…
I am not sure if this will be sufficient for many listeners in means of speed???
Although in order to implement this, you will still need a registering mechanism for listeners and i think best way would be an IOCTL for registration with a PID.
Hope it helps…
Best Regards,
Emre TINAZTEPE
Zemana Information Technologies
On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts > wrote:
Don Burn wrote:
> Using pipes in a Windows driver is a great way to crash the system but
> nothing else. Pipes are undocumented in the kernel, and the samples on
> the net are bogus.
Allow me to second this. I actually implemented a named-pipe solution
in one driver and got it working, but it was unreliable in ways that
were difficult to nail down. I replace it with the old inverted call,
and my life was much better.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>
Why do you think this is faster than inverted call? I have done simple
inverted call’s on a several year old system at over 1.3 million calls
per second.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Emre Tinaztepe” wrote in message
news:xxxxx@ntdev:
> I hope i didn’t misunderstand but can’t we use Section Objects with some
> syncronization mechanism (named events) .
>
> 1. Driver fills the section object’s buffer with a header like “To Process
> Id : XX” and data he wants to send
> 2. Sets the event object #1 and waits for #2 to be signalled.
> 3. All listeners wake up, appropriate listener gets the data and sets the
> Event #2 which wakes driver thread. And step 1 starts again…
>
> I am not sure if this will be sufficient for many listeners in means of
> speed???
>
> Although in order to implement this, you will still need a registering
> mechanism for listeners and i think best way would be an IOCTL for
> registration with a PID.
>
> Hope it helps…
>
> Best Regards,
>
> Emre TINAZTEPE**
> Zemana Information Technologies
>
>
>
>
>
> On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
>
> > Don Burn wrote:
> > > Using pipes in a Windows driver is a great way to crash the system but
> > > nothing else. Pipes are undocumented in the kernel, and the samples on
> > > the net are bogus.
> >
> > Allow me to second this. I actually implemented a named-pipe solution
> > in one driver and got it working, but it was unreliable in ways that
> > were difficult to nail down. I replace it with the old inverted call,
> > and my life was much better.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
Why do you think this is faster than inverted call?
Was just an idea with the hope that it may help eventough it would be
slower…
On Tue, Nov 8, 2011 at 1:35 AM, Don Burn wrote:
> Why do you think this is faster than inverted call? I have done simple
> inverted call’s on a several year old system at over 1.3 million calls per
> second.
>
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/**WinDrvr http:
>
>
>
>
> “Emre Tinaztepe” wrote in message
> news:xxxxx@ntdev:
>
> I hope i didn’t misunderstand but can’t we use Section Objects with some
>> syncronization mechanism (named events) .
>>
>> 1. Driver fills the section object’s buffer with a header like “To Process
>> Id : XX” and data he wants to send
>> 2. Sets the event object #1 and waits for #2 to be signalled.
>> 3. All listeners wake up, appropriate listener gets the data and sets the
>> Event #2 which wakes driver thread. And step 1 starts again…
>>
>> I am not sure if this will be sufficient for many listeners in means of
>> speed???
>>
>> Although in order to implement this, you will still need a registering
>> mechanism for listeners and i think best way would be an IOCTL for
>> registration with a PID.
>>
>> Hope it helps…
>>
>> Best Regards,
>>
>> Emre TINAZTEPE**
>> Zemana Information Technologies
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
>>
>> > Don Burn wrote:
>> > > Using pipes in a Windows driver is a great way to crash the system but
>> > > nothing else. Pipes are undocumented in the kernel, and the samples
>> on
>> > > the net are bogus.
>> >
>> > Allow me to second this. I actually implemented a named-pipe solution
>> > in one driver and got it working, but it was unreliable in ways that
>> > were difficult to nail down. I replace it with the old inverted call,
>> > and my life was much better.
>> >
>> > –
>> > Tim Roberts, xxxxx@probo.com
>> > Providenza & Boekelheide, Inc.
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page. cfm?name=ListServerhttp:
>> >
>>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page. cfm?name=ListServerhttp:
></http:></http:></http:>
Don,
Some people have used some kind of RTOS which used Event Signaling as its
built-in driver-to-app-equivalent signaling mechanism, and simply cannot
imagine that any other system could possibly work. Furthermore, they
formed their ideas of “efficiency” based on what these systems could do
well or poorly, and are unable to cope with ideas such as inverted call
being the best way in Windows. After a while it is best to let them make
these deep and fundamental design errors, so they eventually catch on that
they are building complex, convoluted, fragile, and often unmaintainable
solutions to what the rest of us know to be trivial problems.
joe.
Why do you think this is faster than inverted call? I have done simple
inverted call’s on a several year old system at over 1.3 million calls
per second.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Emre Tinaztepe” wrote in message
> news:xxxxx@ntdev:
>
>> I hope i didn’t misunderstand but can’t we use Section Objects with some
>> syncronization mechanism (named events) .
>>
>> 1. Driver fills the section object’s buffer with a header like “To
>> Process
>> Id : XX” and data he wants to send
>> 2. Sets the event object #1 and waits for #2 to be signalled.
>> 3. All listeners wake up, appropriate listener gets the data and sets
>> the
>> Event #2 which wakes driver thread. And step 1 starts again…
>>
>> I am not sure if this will be sufficient for many listeners in means of
>> speed???
>>
>> Although in order to implement this, you will still need a registering
>> mechanism for listeners and i think best way would be an IOCTL for
>> registration with a PID.
>>
>> Hope it helps…
>>
>> Best Regards,
>>
>> Emre TINAZTEPE**
>> Zemana Information Technologies
>>
>>
>>
>>
>>
>> On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
>>
>> > Don Burn wrote:
>> > > Using pipes in a Windows driver is a great way to crash the system
>> but
>> > > nothing else. Pipes are undocumented in the kernel, and the samples
>> on
>> > > the net are bogus.
>> >
>> > Allow me to second this. I actually implemented a named-pipe solution
>> > in one driver and got it working, but it was unreliable in ways that
>> > were difficult to nail down. I replace it with the old inverted call,
>> > and my life was much better.
>> >
>> > –
>> > Tim Roberts, xxxxx@probo.com
>> > Providenza & Boekelheide, Inc.
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Joe,
I have to disagree, way too many times I have encountered this type
of mess and the code is so established they can’t change it (or they
were stupid enough to expose the API to the user). Hearing stupid
managers who followed these idiots who designed the crap, complain "You
are a consultant. Worse yet I know of a contract programmer who has
pulled this garbage at more than 10 firms, then never stuck around to
learn.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@flounder.com” wrote in message
news:xxxxx@ntdev:
> Don,
>
> Some people have used some kind of RTOS which used Event Signaling as its
> built-in driver-to-app-equivalent signaling mechanism, and simply cannot
> imagine that any other system could possibly work. Furthermore, they
> formed their ideas of “efficiency” based on what these systems could do
> well or poorly, and are unable to cope with ideas such as inverted call
> being the best way in Windows. After a while it is best to let them make
> these deep and fundamental design errors, so they eventually catch on that
> they are building complex, convoluted, fragile, and often unmaintainable
> solutions to what the rest of us know to be trivial problems.
> joe.
> > Why do you think this is faster than inverted call? I have done simple
> > inverted call’s on a several year old system at over 1.3 million calls
> > per second.
> >
> >
> > Don Burn
> > Windows Filesystem and Driver Consulting
> > Website: http://www.windrvr.com
> > Blog: http://msmvps.com/blogs/WinDrvr
> >
> >
> >
> >
> > “Emre Tinaztepe” wrote in message
> > news:xxxxx@ntdev:
> >
> >> I hope i didn’t misunderstand but can’t we use Section Objects with some
> >> syncronization mechanism (named events) .
> >>
> >> 1. Driver fills the section object’s buffer with a header like “To
> >> Process
> >> Id : XX” and data he wants to send
> >> 2. Sets the event object #1 and waits for #2 to be signalled.
> >> 3. All listeners wake up, appropriate listener gets the data and sets
> >> the
> >> Event #2 which wakes driver thread. And step 1 starts again…
> >>
> >> I am not sure if this will be sufficient for many listeners in means of
> >> speed???
> >>
> >> Although in order to implement this, you will still need a registering
> >> mechanism for listeners and i think best way would be an IOCTL for
> >> registration with a PID.
> >>
> >> Hope it helps…
> >>
> >> Best Regards,
> >>
> >> Emre TINAZTEPE**
> >> Zemana Information Technologies
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
> >>
> >> > Don Burn wrote:
> >> > > Using pipes in a Windows driver is a great way to crash the system
> >> but
> >> > > nothing else. Pipes are undocumented in the kernel, and the samples
> >> on
> >> > > the net are bogus.
> >> >
> >> > Allow me to second this. I actually implemented a named-pipe solution
> >> > in one driver and got it working, but it was unreliable in ways that
> >> > were difficult to nail down. I replace it with the old inverted call,
> >> > and my life was much better.
> >> >
> >> > –
> >> > Tim Roberts, xxxxx@probo.com
> >> > Providenza & Boekelheide, Inc.
> >> >
> >> >
> >> > —
> >> > NTDEV is sponsored by OSR
> >> >
> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
> >> > http://www.osr.com/seminars
> >> >
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >> > http://www.osronline.com/page.cfm?name=ListServer
> >> >
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
Don,
Sadly, people like this leave a trail of detritus behind them that gives
us all a bad name. It is much more satisfying when they are employees and
they can be fired and promised they will not get a good reference.
joe
Joe,
I have to disagree, way too many times I have encountered this type
of mess and the code is so established they can’t change it (or they
were stupid enough to expose the API to the user). Hearing stupid
managers who followed these idiots who designed the crap, complain "You
are a consultant. Worse yet I know of a contract programmer who has
pulled this garbage at more than 10 firms, then never stuck around to
learn.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@flounder.com” wrote in message
> news:xxxxx@ntdev:
>
>> Don,
>>
>> Some people have used some kind of RTOS which used Event Signaling as
>> its
>> built-in driver-to-app-equivalent signaling mechanism, and simply cannot
>> imagine that any other system could possibly work. Furthermore, they
>> formed their ideas of “efficiency” based on what these systems could do
>> well or poorly, and are unable to cope with ideas such as inverted call
>> being the best way in Windows. After a while it is best to let them
>> make
>> these deep and fundamental design errors, so they eventually catch on
>> that
>> they are building complex, convoluted, fragile, and often unmaintainable
>> solutions to what the rest of us know to be trivial problems.
>> joe.
>> > Why do you think this is faster than inverted call? I have done
>> simple
>> > inverted call’s on a several year old system at over 1.3 million calls
>> > per second.
>> >
>> >
>> > Don Burn
>> > Windows Filesystem and Driver Consulting
>> > Website: http://www.windrvr.com
>> > Blog: http://msmvps.com/blogs/WinDrvr
>> >
>> >
>> >
>> >
>> > “Emre Tinaztepe” wrote in message
>> > news:xxxxx@ntdev:
>> >
>> >> I hope i didn’t misunderstand but can’t we use Section Objects with
>> some
>> >> syncronization mechanism (named events) .
>> >>
>> >> 1. Driver fills the section object’s buffer with a header like “To
>> >> Process
>> >> Id : XX” and data he wants to send
>> >> 2. Sets the event object #1 and waits for #2 to be signalled.
>> >> 3. All listeners wake up, appropriate listener gets the data and sets
>> >> the
>> >> Event #2 which wakes driver thread. And step 1 starts again…
>> >>
>> >> I am not sure if this will be sufficient for many listeners in means
>> of
>> >> speed???
>> >>
>> >> Although in order to implement this, you will still need a
>> registering
>> >> mechanism for listeners and i think best way would be an IOCTL for
>> >> registration with a PID.
>> >>
>> >> Hope it helps…
>> >>
>> >> Best Regards,
>> >>
>> >> Emre TINAZTEPE**
>> >> Zemana Information Technologies
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts wrote:
>> >>
>> >> > Don Burn wrote:
>> >> > > Using pipes in a Windows driver is a great way to crash the
>> system
>> >> but
>> >> > > nothing else. Pipes are undocumented in the kernel, and the
>> samples
>> >> on
>> >> > > the net are bogus.
>> >> >
>> >> > Allow me to second this. I actually implemented a named-pipe
>> solution
>> >> > in one driver and got it working, but it was unreliable in ways
>> that
>> >> > were difficult to nail down. I replace it with the old inverted
>> call,
>> >> > and my life was much better.
>> >> >
>> >> > –
>> >> > Tim Roberts, xxxxx@probo.com
>> >> > Providenza & Boekelheide, Inc.
>> >> >
>> >> >
>> >> > —
>> >> > NTDEV is sponsored by OSR
>> >> >
>> >> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> >> > http://www.osr.com/seminars
>> >> >
>> >> > To unsubscribe, visit the List Server section of OSR Online at
>> >> > http://www.osronline.com/page.cfm?name=ListServer
>> >> >
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > For our schedule of WDF, WDM, debugging and other seminars visit:
>> > http://www.osr.com/seminars
>> >
>> > To unsubscribe, visit the List Server section of OSR Online at
>> > http://www.osronline.com/page.cfm?name=ListServer
>> >
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
The problem is that you are defining a simple and obvious solution to
someone who wants to build a solution based on some convoluted and complex
model which bears very little resemblance to the way Windows was designed
to work.
joe
What do you believe you are saving over the inverted call model?
With inverted call you pick the client you want to send the data to, write
the data into their waiting buffers and complete the request to wake them
up. You don’t need to have the kernel side block hoping the client sets
an event saying that it’s done with the data. You don’t need to expose
the data to every process and hope they’ll all be well behaved about its
use.
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Emre Tinaztepe
Sent: Monday, November 07, 2011 2:35 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] IPC between kernel and user-mode
I hope i didn’t misunderstand but can’t we use Section Objects with some
syncronization mechanism (named events) .
- Driver fills the section object’s buffer with a header like “To Process
Id : XX” and data he wants to send
- Sets the event object #1 and waits for #2 to be signalled.
- All listeners wake up, appropriate listener gets the data and sets the
Event #2 which wakes driver thread. And step 1 starts again…
I am not sure if this will be sufficient for many listeners in means of
speed???
Although in order to implement this, you will still need a registering
mechanism for listeners and i think best way would be an IOCTL for
registration with a PID.
Hope it helps…
Best Regards,
Emre TINAZTEPE
Zemana Information Technologies
On Mon, Nov 7, 2011 at 8:55 PM, Tim Roberts
> wrote:
> Don Burn wrote:
>> Using pipes in a Windows driver is a great way to crash the system but
>> nothing else. Pipes are undocumented in the kernel, and the samples on
>> the net are bogus.
> Allow me to second this. I actually implemented a named-pipe solution
> in one driver and got it working, but it was unreliable in ways that
> were difficult to nail down. I replace it with the old inverted call,
> and my life was much better.
>
> –
> Tim Roberts, xxxxx@probo.commailto:xxxxx
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>
>1. Driver fills the section object’s buffer with a header like “To Process Id : XX” and data he wants to
send
2. Sets the event object #1 and waits for #2 to be signalled.
3. All listeners wake up
Inverted calls are much simpler.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> well or poorly, and are unable to cope with ideas such as inverted call
being the best way in Windows.
…and in UNIXen too… Consider the glorious “tun” network adapter.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com