Replace parport.sys?

Hello all,

I am very new to this and consequently profoundly ignorant. I want to control custom hardware through the parallel port; there will never again be a printer connected to it. Moreover, I do not want a user to decide at sometime to setup LPTx as a printer port and try to “print” with this hardware, it could have nasty consequences. Can/should I replace the standard port driver with mine, which will be a lightly modified version of the portio driver, genport.sys? The need is to perform simple port reads and writes, but I am leary of using any of the third party drivers out there that bully their way to the I/O ports.

Getting deeper into it, I have read in the archives here that the genport driver itself is not capable of handling the port hardware without the help of parport.sys. Is this true? (I can’t seem to read/write to the parallel port with the sample code, no matter what I try… no errors, but nothing happens)

I’m building for XP and have the Windows Server 2003 DDK which does not seem to include the parallel port driver code, as I believe the NT DDK did.

Thanks for helping!

I believe that the official answer to this is that you may not (legally)
replace an in box driver with one of your own, unless it happens to be
part of a service pack, the reasoning for this being that there might be
other (software) clients that require the services of the driver that
you wish to replace. In the case of parport, this very well may not be
the case, but that doesn’t matter. You probably want to either check
your license, or perhaps just wait until one of the Microsoft devs on
this list provides further information, but, assuming that it is
correct, replacing this driver is probably not an option.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@lycos.com
Sent: Tuesday, September 04, 2007 16:13
To: Windows System Software Devs Interest List
Subject: [ntdev] Replace parport.sys?

Hello all,

I am very new to this and consequently profoundly ignorant. I want to
control custom hardware through the parallel port; there will never
again be a printer connected to it. Moreover, I do not want a user to
decide at sometime to setup LPTx as a printer port and try to “print”
with this hardware, it could have nasty consequences. Can/should I
replace the standard port driver with mine, which will be a lightly
modified version of the portio driver, genport.sys? The need is to
perform simple port reads and writes, but I am leary of using any of the
third party drivers out there that bully their way to the I/O ports.

Getting deeper into it, I have read in the archives here that the
genport driver itself is not capable of handling the port hardware
without the help of parport.sys. Is this true? (I can’t seem to
read/write to the parallel port with the sample code, no matter what I
try… no errors, but nothing happens)

I’m building for XP and have the Windows Server 2003 DDK which does not
seem to include the parallel port driver code, as I believe the NT DDK
did.

Thanks for helping!


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

xxxxx@lycos.com wrote:

I am very new to this and consequently profoundly ignorant. I want to control custom hardware through the parallel port; there will never again be a printer connected to it. Moreover, I do not want a user to decide at sometime to setup LPTx as a printer port and try to “print” with this hardware, it could have nasty consequences. Can/should I replace the standard port driver with mine, which will be a lightly modified version of the portio driver, genport.sys? The need is to perform simple port reads and writes, but I am leary of using any of the third party drivers out there that bully their way to the I/O ports.

Getting deeper into it, I have read in the archives here that the genport driver itself is not capable of handling the port hardware without the help of parport.sys. Is this true? (I can’t seem to read/write to the parallel port with the sample code, no matter what I try… no errors, but nothing happens)

This depends on whether this is just a hack for laboratory testing, or
if it is a product that might actually be released into the field at
some point. If this is just for laboratory testing, then you can
disable your parallel port in Device Manager (which will unload
parport.sys), load up portio.sys, and pound away on the registers to
your heart’s content.

If this is something that you might want to release at some point, then
you need to think about better solutions. It is possible to make your
driver a client of parport.sys; it offers services to other drivers
through internal ioctls. That lets you change to EPP or ECP mode, and
even hook up the interrupt if you wanted.

I’m building for XP and have the Windows Server 2003 DDK which does not seem to include the parallel port driver code, as I believe the NT DDK did.

The 3790 and 3790.1830 DDKs do include parport.sys, in the
src\kernel\parport directory.


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

Thanks guys, the important thing here is that I need to keep that port under my control, totally. Can it be done?

It’s been a number of years since I’ve messed with this so…

Given the number of products out there that use the parallel port for
non-printer things, there has to be a way for user-mode-only code to do
this. Resorting to kernel modifications seems absurd. I do remember that
there are BIOS settings relating to the way the port works and also that
the print spooler usually grabs exclusive ownership. I don’t know what
example you looked at but if it did not address these two items, I’d
continue looking.

I suspect you will reach your objective faster if you concentrate on
finding out why your read/write attempts didn’t work instead of trying
to replace core O/S components.

xxxxx@lycos.com wrote:

[…] I can’t seem to read/write to the parallel port with the sample code, no matter what I try… no errors, but nothing happens

Mickey Lane wrote:

Given the number of products out there that use the parallel port for
non-printer things, there has to be a way for user-mode-only code to
do this. Resorting to kernel modifications seems absurd.

Well, it may seem that way to you, but it’s a fact. Those folks using
the parallel port for non-printer things are providing their own
drivers. Often, it’s just one of the generic port I/O drivers that
overrides the I/O permission map, but kernel help IS required.

I do remember that there are BIOS settings relating to the way the
port works and also that the print spooler usually grabs exclusive
ownership. I don’t know what example you looked at but if it did not
address these two items, I’d continue looking.

The print spooler doesn’t get involved with the physical parallel port
I/O ports.

I suspect you will reach your objective faster if you concentrate on
finding out why your read/write attempts didn’t work instead of trying
to replace core O/S components.

They don’t work because user mode applications are not allowed to touch
I/O ports – even parallel port I/O ports.


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

> Given the number of products out there that use the parallel port for

non-printer things

IIRC there was an IEEE 1204.x standard for them (don’t sure about the name).


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

Maxim S. Shatskih wrote:

> Given the number of products out there that use the parallel port for
> non-printer things
>

IIRC there was an IEEE 1204.x standard for them (don’t sure about the name).

IEEE 1284.4. That’s why the device class and associated INF file are
called “Dot4”.


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