parallel port read write - Kernel Mode or User Mode

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.

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 ?

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 ?

xxxxx@justkernel.com wrote:

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.

Yes. That opens a special file called LPT1. That name maps to the
standard parallel port driver, parport.sys, which does the bus-level
I/O. The WriteFile requests simply send I/O requests to parport.sys.
As far as the application knows, it is just writing to a file. It’s not
doing any I/O port operations here.

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 ?

It’s not a contradiction at all. You are not writing to the parallel
port I/O ports here. You are making I/O requests to a kernel driver,
and that driver is writing to the parallel port. This is exactly how
the abstraction is supposed to work.

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 ?

It is POSSIBLE to use internal ioctls to request exclusive access.
That’s not the only way. Parport.sys creates its device object in
“exclusive mode”, which means that only one application at a time can
open the “LPT1” special file.

If writing to LPT1 solves your problem, then that is clearly the right
way to go.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> 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

Thanks Tim for your detailed reply…I was able to get answers to all my questions.

Thanks Joe for sharing your thoughts…