> Thanks for replying… I am a lot clear about the parallel port concepts
now… Thanks a lot
I have this one confusion regarding a basic concept. Everywhere on the net
I have read that we need to implement kernel mode driver to read and write
to parallel port. The samples that are available like inpout32, dlportio
also implement kernel mode driver and then use READ_PORT_UCHAR and
WRITE_PORT_UCHAR to read and write to parallel port.
But yesterday (as mentioned in my previous mail) I was able to read and
write to parallel port using cmd.exe (copy abc.txt LPT1). Now I am sure
that cmd.exe uses Createfile and WriteFile functions which are just user
mode functions.
****
You command just writes to the parallel port; I see no evidence that it is
reading.
What I find odd is the number of people here who have no idea about how
application mode works; I find it amazing that anyone could write a device
driver without understanding the application level.
You seem confused; you think that writing to LPT1 requires access to the
parallel port. It does not. It requires access to the port that maps to
LPT1. This could be a parallel port, a serial port, a network port, a USB
port, etc. LPT1 is an abstraction which represents the “main printer” and
as far as I know has no commitment to being implemented by a parallel
port.
Note that parport only has to support those operations that it is defined
to support. At one time, before bidirectional ports existed, the printer
driver could *only* write. But since that time, the bidirectional ports
have become common, as many printers needed to return status of some kind.
There are components of the printer subsystem called “Port monitors” that
write to printer ports of any description, and “Language monitors” (I have
no idea what the name means) that handle messages coming back. I have
implemented sophisiticated port monitors, but never a language monitor.
The port monitor was mapped to a virtual printer, although I did not need
to know that. The mapping is another level of abstraction.
I ported a sophisticated DOS printer application from MS-DOS to Windows in
the mid-1990s. THe major effort was building a nice GUI interface for it,
instead of the horrific MS-DOS command-line interface. But the basic
logic of fopen/fwrite did not change.
****
So here we have contradiction - On one hand website says that we need to
implement driver for parallel port access , even MS says that starting
Win2k user mode access to port is blocked, and on other hand I am able to
successfully write to parallel port from cmd.exe… Please suggest ?
*****
Your key problem here is that you are confusing “ability to write to a
printer” with “ability to access the data and control registers of a
hardware printer port”.
*****
Another doubt is that as per MS documentation I need to use INTERNAL
IOCTLs to get exclusive access to parallel port… But even when I opened 2
cmd.exe and both try to write one is able to get exclusive access to
parallel port . (And also as per replies, by nature of parallel port if
any app tries to write to parallel port its granted exclusive access). The
why need to kernel mode driver to implement INTERNAL IOCTLS. Please
suggest ?
*****
If you are buidling something in the kernel, then you need to use internal
IOCTLs for your device driver to talk to the parallel port driver. This
has absolutely nothing to do with how an *application* accesses a printer.
joe
*****
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