Intercepting drivers
From: Frank Pelzer (Pelzer_at_discussions.microsoft.com)
Date: 09/13/04
- Next message: poltrone: "Re: Intercepting drivers"
- Previous message: poltrone: "Re: Multithreading problem printf"
- Next in thread: poltrone: "Re: Intercepting drivers"
- Reply: poltrone: "Re: Intercepting drivers"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 13 Sep 2004 11:27:02 -0700
Do I have to become a device driver developer to intercept a device driver or
is there a higher level available?
My problem is the following. I have a legacy program which eventually uses
the physical serial port by means of serial.sys. I have to filter/intercept
the byte-stream over the serial line.
With my restricted possibilities I see 3 (extreme) ways to do this job:
(a) Write your own serial driver (I am not and will not be able do this,
since it is too far from my originial goals)
(b) Spy sytem etc. calls of the legacy win32 application (pfui!)
(c) Take an additional IBM-PC, read from COM1, filter, write to COM2, and
the other way around (Hhmm, sounds simple, fast, and clean)
Is there something smarter which I can do in the user mode level of the host
which runs the application which uses the serial port? Ideally as easy as
option (c), however without the need of additional hardware?
-- Frank
- Next message: poltrone: "Re: Intercepting drivers"
- Previous message: poltrone: "Re: Multithreading problem printf"
- Next in thread: poltrone: "Re: Intercepting drivers"
- Reply: poltrone: "Re: Intercepting drivers"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|