custom IOCTL in serial.sys

NTDEV
1

Hello,

I’m developping a serial aplication, in which I need to read the UART’s
Line Status Register. I haven’t found any standard IOCTL to use with
DeviceIoControl() which reads this register, so I’ve edited the source
of serial.sys and added my custom IOCTL. Then I tested it by replacing
the original serial.sys by mine, and it works ok.

But now, if I want to distribute my driver, I should replace the
original driver, and I don’t know if it’s really a good idea.
Another possibility could be to build another driver (and name it
serial2.sys, for example), and make my application access this other
one, but I think it would carry to hardware access conflicts.

Can anyone advice me? What is the best and most secure solution?

Thanks.

2

I don’t actually know if this works, but I believe the principle when you
want to add (or remove or change) the functionality of an existing “in the
box” driver is that you write a filter-driver that sits on top of (or
below) the driver you are “changing”.

In this case, you’d implement your IOCTL in the filter driver, and pass all
other IRPs to the serial driver below. Of course, you’re not actually
supposed to touch the hardware in the filter driver, but I think in this
case it’s relatively safe to do so.

It’s a big no-no to replace “in-the-box” drivers, as that tends to break
things when the next service-pack comes out with an updated “in the box”
driver. Since Windows doesn’t actually know that Serial.sys and Serial2.sys
handle the same hardware, it wouldn’t be able to prevent the existing
serial.sys from being loaded, and if you just go modify the PnP settings in
the registry (or whatever), then you’ll confuse all sorts of things.

–
Mats

xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:

Hello,

I’m developping a serial aplication, in which I need to read the UART’s
Line Status Register. I haven’t found any standard IOCTL to use with
DeviceIoControl() which reads this register, so I’ve edited the source
of serial.sys and added my custom IOCTL. Then I tested it by replacing
the original serial.sys by mine, and it works ok.

But now, if I want to distribute my driver, I should replace the
original driver, and I don’t know if it’s really a good idea.
Another possibility could be to build another driver (and name it
serial2.sys, for example), and make my application access this other
one, but I think it would carry to hardware access conflicts.

Can anyone advice me? What is the best and most secure solution?

Thanks.

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT00010A22

3

Eh?

If your device is pnp and its inf installs it and says it uses
serial2.sys…

Why would the system even bother with serial.sys?! That isn’t how things
work!

Use a unique hardware id, associate it with your own driver…
Myserial.sys or whatever and you’re sorted.

You can leave your custom IOCTL code intact.

Only thing may be that you’re likely to have to change symlink names…

BR,

Rob Linegar
Software Engineer
Data Encryption Systems Limited
www.des.co.uk | www.deslock.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 13 April 2005 16:06
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] custom IOCTL in serial.sys

I don’t actually know if this works, but I believe the principle when
you
want to add (or remove or change) the functionality of an existing “in
the
box” driver is that you write a filter-driver that sits on top of (or
below) the driver you are “changing”.

In this case, you’d implement your IOCTL in the filter driver, and pass
all
other IRPs to the serial driver below. Of course, you’re not actually
supposed to touch the hardware in the filter driver, but I think in this
case it’s relatively safe to do so.

It’s a big no-no to replace “in-the-box” drivers, as that tends to break
things when the next service-pack comes out with an updated “in the box”
driver. Since Windows doesn’t actually know that Serial.sys and
Serial2.sys
handle the same hardware, it wouldn’t be able to prevent the existing
serial.sys from being loaded, and if you just go modify the PnP settings
in
the registry (or whatever), then you’ll confuse all sorts of things.

–
Mats

xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:

Hello,

I’m developping a serial aplication, in which I need to read the
UART’s
Line Status Register. I haven’t found any standard IOCTL to use with
DeviceIoControl() which reads this register, so I’ve edited the source
of serial.sys and added my custom IOCTL. Then I tested it by replacing
the original serial.sys by mine, and it works ok.

But now, if I want to distribute my driver, I should replace the
original driver, and I don’t know if it’s really a good idea.
Another possibility could be to build another driver (and name it
serial2.sys, for example), and make my application access this other
one, but I think it would carry to hardware access conflicts.

Can anyone advice me? What is the best and most secure solution?

Thanks.

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT00010A22

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

If you upgrade the devnode to your driver (which does not have the name
serial), serial.sys will be unloaded and our driver will load. This
will survive an SP in place upgrade.

Mats suggestion of a filter driver should be strongly considered. If
you can do that, your life will be easier. Are you sure the native
serial does not support what you want? It has a very rich interface, it
is easily to lose yourself in it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Wednesday, April 13, 2005 8:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] custom IOCTL in serial.sys

I don’t actually know if this works, but I believe the principle when
you
want to add (or remove or change) the functionality of an existing “in
the
box” driver is that you write a filter-driver that sits on top of (or
below) the driver you are “changing”.

In this case, you’d implement your IOCTL in the filter driver, and pass
all
other IRPs to the serial driver below. Of course, you’re not actually
supposed to touch the hardware in the filter driver, but I think in this
case it’s relatively safe to do so.

It’s a big no-no to replace “in-the-box” drivers, as that tends to break
things when the next service-pack comes out with an updated “in the box”
driver. Since Windows doesn’t actually know that Serial.sys and
Serial2.sys
handle the same hardware, it wouldn’t be able to prevent the existing
serial.sys from being loaded, and if you just go modify the PnP settings
in
the registry (or whatever), then you’ll confuse all sorts of things.

–
Mats

xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:

Hello,

I’m developping a serial aplication, in which I need to read the
UART’s
Line Status Register. I haven’t found any standard IOCTL to use with
DeviceIoControl() which reads this register, so I’ve edited the source
of serial.sys and added my custom IOCTL. Then I tested it by replacing
the original serial.sys by mine, and it works ok.

But now, if I want to distribute my driver, I should replace the
original driver, and I don’t know if it’s really a good idea.
Another possibility could be to build another driver (and name it
serial2.sys, for example), and make my application access this other
one, but I think it would carry to hardware access conflicts.

Can anyone advice me? What is the best and most secure solution?

Thanks.

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ForwardSourceID:NT00010A22

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

hi again,

I used serial.sys source coce included in win2000 ddk. I don’t know if
the IOCTL I need is included in the last ddk version, but I don’t think
so, because it’s not mentioned elsewhere.

I also think it’s better to put it in a filter driver, but I’m a
begginer, and I don’t know exactly how to do it. I understand that I
should pass down all IRPs except mine, and I think I’m able to get it
work, but I don’t really know how to put my filter driver between
serenum.sys and serial.sys.
And, again, I’m affraid of a hardware conflict if I try to access the
same register from my filter and serial.sys at the same time. Maybe it’s
only a beginner scare…

Can you give me basic clues which show me the good path?

Thank you very much for your help.

En/na Doron Holan ha escrit:

If you upgrade the devnode to your driver (which does not have the name
serial), serial.sys will be unloaded and our driver will load. This
will survive an SP in place upgrade.

Mats suggestion of a filter driver should be strongly considered. If
you can do that, your life will be easier. Are you sure the native
serial does not support what you want? It has a very rich interface, it
is easily to lose yourself in it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Wednesday, April 13, 2005 8:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] custom IOCTL in serial.sys

I don’t actually know if this works, but I believe the principle when
you
want to add (or remove or change) the functionality of an existing “in
the
box” driver is that you write a filter-driver that sits on top of (or
below) the driver you are “changing”.

In this case, you’d implement your IOCTL in the filter driver, and pass
all
other IRPs to the serial driver below. Of course, you’re not actually
supposed to touch the hardware in the filter driver, but I think in this
case it’s relatively safe to do so.

It’s a big no-no to replace “in-the-box” drivers, as that tends to break
things when the next service-pack comes out with an updated “in the box”
driver. Since Windows doesn’t actually know that Serial.sys and
Serial2.sys
handle the same hardware, it wouldn’t be able to prevent the existing
serial.sys from being loaded, and if you just go modify the PnP settings
in
the registry (or whatever), then you’ll confuse all sorts of things.

–
Mats

xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:

>Hello,
>
>I’m developping a serial aplication, in which I need to read the

UART’s

>Line Status Register. I haven’t found any standard IOCTL to use with
>DeviceIoControl() which reads this register, so I’ve edited the source
>of serial.sys and added my custom IOCTL. Then I tested it by replacing
>the original serial.sys by mine, and it works ok.
>
>But now, if I want to distribute my driver, I should replace the
>original driver, and I don’t know if it’s really a good idea.
>Another possibility could be to build another driver (and name it
>serial2.sys, for example), and make my application access this other
>one, but I think it would carry to hardware access conflicts.
>
>Can anyone advice me? What is the best and most secure solution?
>
>Thanks.
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.
>osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

>ForwardSourceID:NT00010A22

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

As a filter driver you are not allowed ot touch the hw resources, only
serial.sys is allowed. If you need hw access, a filter is not
appropriate and you need to replace serial.sys w/your own driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Wednesday, April 13, 2005 9:14 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

hi again,

I used serial.sys source coce included in win2000 ddk. I don’t know if
the IOCTL I need is included in the last ddk version, but I don’t think
so, because it’s not mentioned elsewhere.

I also think it’s better to put it in a filter driver, but I’m a
begginer, and I don’t know exactly how to do it. I understand that I
should pass down all IRPs except mine, and I think I’m able to get it
work, but I don’t really know how to put my filter driver between
serenum.sys and serial.sys.
And, again, I’m affraid of a hardware conflict if I try to access the
same register from my filter and serial.sys at the same time. Maybe it’s

only a beginner scare…

Can you give me basic clues which show me the good path?

Thank you very much for your help.

En/na Doron Holan ha escrit:

If you upgrade the devnode to your driver (which does not have the
name
serial), serial.sys will be unloaded and our driver will load. This
will survive an SP in place upgrade.

Mats suggestion of a filter driver should be strongly considered. If
you can do that, your life will be easier. Are you sure the native
serial does not support what you want? It has a very rich interface,
it
is easily to lose yourself in it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: Wednesday, April 13, 2005 8:06 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] custom IOCTL in serial.sys

I don’t actually know if this works, but I believe the principle when
you
want to add (or remove or change) the functionality of an existing “in
the
box” driver is that you write a filter-driver that sits on top of (or
below) the driver you are “changing”.

In this case, you’d implement your IOCTL in the filter driver, and
pass
all
other IRPs to the serial driver below. Of course, you’re not actually
supposed to touch the hardware in the filter driver, but I think in
this
case it’s relatively safe to do so.

It’s a big no-no to replace “in-the-box” drivers, as that tends to
break
things when the next service-pack comes out with an updated “in the
box”
driver. Since Windows doesn’t actually know that Serial.sys and
Serial2.sys
handle the same hardware, it wouldn’t be able to prevent the existing
serial.sys from being loaded, and if you just go modify the PnP
settings
in
the registry (or whatever), then you’ll confuse all sorts of things.

–
Mats

xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:

>Hello,
>
>I’m developping a serial aplication, in which I need to read the

UART’s

>Line Status Register. I haven’t found any standard IOCTL to use with
>DeviceIoControl() which reads this register, so I’ve edited the source
>of serial.sys and added my custom IOCTL. Then I tested it by replacing
>the original serial.sys by mine, and it works ok.
>
>But now, if I want to distribute my driver, I should replace the
>original driver, and I don’t know if it’s really a good idea.
>Another possibility could be to build another driver (and name it
>serial2.sys, for example), and make my application access this other
>one, but I think it would carry to hardware access conflicts.
>
>Can anyone advice me? What is the best and most secure solution?
>
>Thanks.
>
>—
>Questions? First check the Kernel Driver FAQ at http://www.
>osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

>ForwardSourceID:NT00010A22

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Doron,

thanks for your explanations. I’ve got another question:

Can both serial.sys and my custom driver (e.g. serial2.sys) coexist? I
mean that my application would access serial2.sys, while the other ones
would access serial.sys. By this way, it wouldn’t be necessary to
replace serial.sys, avoiding the lost of possible innovations introduced
to it in newer SPs, that could be used by applications other than mine.

Regards

En/na Doron Holan ha escrit:

As a filter driver you are not allowed ot touch the hw resources, only
serial.sys is allowed. If you need hw access, a filter is not
appropriate and you need to replace serial.sys w/your own driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Wednesday, April 13, 2005 9:14 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

hi again,

I used serial.sys source coce included in win2000 ddk. I don’t know if
the IOCTL I need is included in the last ddk version, but I don’t think
so, because it’s not mentioned elsewhere.

I also think it’s better to put it in a filter driver, but I’m a
begginer, and I don’t know exactly how to do it. I understand that I
should pass down all IRPs except mine, and I think I’m able to get it
work, but I don’t really know how to put my filter driver between
serenum.sys and serial.sys.
And, again, I’m affraid of a hardware conflict if I try to access the
same register from my filter and serial.sys at the same time. Maybe it’s

only a beginner scare…

Can you give me basic clues which show me the good path?

Thank you very much for your help.

En/na Doron Holan ha escrit:

>If you upgrade the devnode to your driver (which does not have the

name

>serial), serial.sys will be unloaded and our driver will load. This
>will survive an SP in place upgrade.
>
>Mats suggestion of a filter driver should be strongly considered. If
>you can do that, your life will be easier. Are you sure the native
>serial does not support what you want? It has a very rich interface,

it

>is easily to lose yourself in it.
>
>d
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
>Sent: Wednesday, April 13, 2005 8:06 AM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] custom IOCTL in serial.sys
>
>
>
>
>
>
>I don’t actually know if this works, but I believe the principle when
>you
>want to add (or remove or change) the functionality of an existing “in
>the
>box” driver is that you write a filter-driver that sits on top of (or
>below) the driver you are “changing”.
>
>In this case, you’d implement your IOCTL in the filter driver, and

pass

>all
>other IRPs to the serial driver below. Of course, you’re not actually
>supposed to touch the hardware in the filter driver, but I think in

this

>case it’s relatively safe to do so.
>
>It’s a big no-no to replace “in-the-box” drivers, as that tends to

break

>things when the next service-pack comes out with an updated "in the

box"

>driver. Since Windows doesn’t actually know that Serial.sys and
>Serial2.sys
>handle the same hardware, it wouldn’t be able to prevent the existing
>serial.sys from being loaded, and if you just go modify the PnP

settings

>in
>the registry (or whatever), then you’ll confuse all sorts of things.
>
>–
>Mats
>
>xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:
>
>
>
>>Hello,
>>
>>I’m developping a serial aplication, in which I need to read the
>
>UART’s
>
>
>>Line Status Register. I haven’t found any standard IOCTL to use with
>>DeviceIoControl() which reads this register, so I’ve edited the source
>>of serial.sys and added my custom IOCTL. Then I tested it by replacing
>>the original serial.sys by mine, and it works ok.
>>
>>But now, if I want to distribute my driver, I should replace the
>>original driver, and I don’t know if it’s really a good idea.
>>Another possibility could be to build another driver (and name it
>>serial2.sys, for example), and make my application access this other
>>one, but I think it would carry to hardware access conflicts.
>>
>>Can anyone advice me? What is the best and most secure solution?
>>
>>Thanks.
>>
>>—
>>Questions? First check the Kernel Driver FAQ at http://www.
>>osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>>ForwardSourceID:NT00010A22
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

The short answer is that your driver and serial.sys can coexist on the
machine as long as there are devices for each service to control. Both
driver cannot control the same instance of hw.

Are you are replacing serial.sys for a motherboard serial port? Or a
custom UART that you are shipping? If it is a custom solution, just
write and INF that matches your HW ID to your driver and you are done.

If you are replacing serial.sys for a motherboard serial port, then you
upgrade the installed driver on just that serial port. All applications
which open that particular serial port will use your driver. If there
are other serial ports on the machine, they will not be affected by your
driver b/c they are still running with the original serial.sys

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Thursday, April 14, 2005 1:07 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

Doron,

thanks for your explanations. I’ve got another question:

Can both serial.sys and my custom driver (e.g. serial2.sys) coexist? I
mean that my application would access serial2.sys, while the other ones
would access serial.sys. By this way, it wouldn’t be necessary to
replace serial.sys, avoiding the lost of possible innovations introduced

to it in newer SPs, that could be used by applications other than mine.

Regards

En/na Doron Holan ha escrit:

As a filter driver you are not allowed ot touch the hw resources, only
serial.sys is allowed. If you need hw access, a filter is not
appropriate and you need to replace serial.sys w/your own driver.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Wednesday, April 13, 2005 9:14 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

hi again,

I used serial.sys source coce included in win2000 ddk. I don’t know if

the IOCTL I need is included in the last ddk version, but I don’t
think
so, because it’s not mentioned elsewhere.

I also think it’s better to put it in a filter driver, but I’m a
begginer, and I don’t know exactly how to do it. I understand that I
should pass down all IRPs except mine, and I think I’m able to get it
work, but I don’t really know how to put my filter driver between
serenum.sys and serial.sys.
And, again, I’m affraid of a hardware conflict if I try to access the
same register from my filter and serial.sys at the same time. Maybe
it’s

only a beginner scare…

Can you give me basic clues which show me the good path?

Thank you very much for your help.

En/na Doron Holan ha escrit:

>If you upgrade the devnode to your driver (which does not have the

name

>serial), serial.sys will be unloaded and our driver will load. This
>will survive an SP in place upgrade.
>
>Mats suggestion of a filter driver should be strongly considered. If
>you can do that, your life will be easier. Are you sure the native
>serial does not support what you want? It has a very rich interface,

it

>is easily to lose yourself in it.
>
>d
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
>Sent: Wednesday, April 13, 2005 8:06 AM
>To: Windows System Software Devs Interest List
>Subject: Re: [ntdev] custom IOCTL in serial.sys
>
>
>
>
>
>
>I don’t actually know if this works, but I believe the principle when
>you
>want to add (or remove or change) the functionality of an existing “in
>the
>box” driver is that you write a filter-driver that sits on top of (or
>below) the driver you are “changing”.
>
>In this case, you’d implement your IOCTL in the filter driver, and

pass

>all
>other IRPs to the serial driver below. Of course, you’re not actually
>supposed to touch the hardware in the filter driver, but I think in

this

>case it’s relatively safe to do so.
>
>It’s a big no-no to replace “in-the-box” drivers, as that tends to

break

>things when the next service-pack comes out with an updated "in the

box"

>driver. Since Windows doesn’t actually know that Serial.sys and
>Serial2.sys
>handle the same hardware, it wouldn’t be able to prevent the existing
>serial.sys from being loaded, and if you just go modify the PnP

settings

>in
>the registry (or whatever), then you’ll confuse all sorts of things.
>
>–
>Mats
>
>xxxxx@lists.osr.com wrote on 04/13/2005 03:45:35 PM:
>
>
>
>>Hello,
>>
>>I’m developping a serial aplication, in which I need to read the
>
>UART’s
>
>
>>Line Status Register. I haven’t found any standard IOCTL to use with
>>DeviceIoControl() which reads this register, so I’ve edited the
source
>>of serial.sys and added my custom IOCTL. Then I tested it by
replacing
>>the original serial.sys by mine, and it works ok.
>>
>>But now, if I want to distribute my driver, I should replace the
>>original driver, and I don’t know if it’s really a good idea.
>>Another possibility could be to build another driver (and name it
>>serial2.sys, for example), and make my application access this other
>>one, but I think it would carry to hardware access conflicts.
>>
>>Can anyone advice me? What is the best and most secure solution?
>>
>>Thanks.
>>
>>—
>>Questions? First check the Kernel Driver FAQ at http://www.
>>osronline.com/article.cfm?id=256
>>
>>You are currently subscribed to ntdev as: xxxxx@3dlabs.com
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>>ForwardSourceID:NT00010A22
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

9

Doron,

Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.
Elena mentioned not finding anything to do that in the DDK serial sample,
hence the custom IOCTL and custom driver. Do you know of anything in the
in-box driver that would provide the same ability without the this custom
serial driver nonsense?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 04/14/2005 10:49:08 AM:

The short answer is that your driver and serial.sys can coexist on the
machine as long as there are devices for each service to control. Both
driver cannot control the same instance of hw.

Are you are replacing serial.sys for a motherboard serial port? Or a
custom UART that you are shipping? If it is a custom solution, just
write and INF that matches your HW ID to your driver and you are done.

If you are replacing serial.sys for a motherboard serial port, then you
upgrade the installed driver on just that serial port. All applications
which open that particular serial port will use your driver. If there
are other serial ports on the machine, they will not be affected by your
driver b/c they are still running with the original serial.sys

10

I have already asked the owner of serial.sys if such a thing exists. I will let you know.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, April 14, 2005 10:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom IOCTL in serial.sys

Doron,

Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART. ?Elena mentioned not finding anything to do that in the DDK serial sample, hence the custom IOCTL and custom driver. ?Do you know of anything in the in-box driver that would provide the same ability without the this custom serial driver nonsense?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 04/14/2005 10:49:08 AM:

The short answer is that your driver and serial.sys can coexist on the
machine as long as there are devices for each service to control. ?Both
driver cannot control the same instance of hw.

Are you are replacing serial.sys for a motherboard serial port? ?Or a
custom UART that you are shipping? ? If it is a custom solution, just
write and INF that matches your HW ID to your driver and you are done.

If you are replacing serial.sys for a motherboard serial port, then you
upgrade the installed driver on just that serial port. ?All applications
which open that particular serial port will use your driver. ?If there
are other serial ports on the machine, they will not be affected by your
driver b/c they are still running with the original serial.sys
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

11

The line status register is not exposed through any IOCTL, documented or undocumented. A complete replacement of serial.sys for the individual serial port in question is required to read this status.

d

-----Original Message-----
From: Doron Holan
Sent: Thursday, April 14, 2005 11:34 AM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] custom IOCTL in serial.sys

I have already asked the owner of serial.sys if such a thing exists. I will let you know.

d

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, April 14, 2005 10:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom IOCTL in serial.sys

Doron,

Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART. ?Elena mentioned not finding anything to do that in the DDK serial sample, hence the custom IOCTL and custom driver. ?Do you know of anything in the in-box driver that would provide the same ability without the this custom serial driver nonsense?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 04/14/2005 10:49:08 AM:

The short answer is that your driver and serial.sys can coexist on the
machine as long as there are devices for each service to control. ?Both
driver cannot control the same instance of hw.

Are you are replacing serial.sys for a motherboard serial port? ?Or a
custom UART that you are shipping? ? If it is a custom solution, just
write and INF that matches your HW ID to your driver and you are done.

If you are replacing serial.sys for a motherboard serial port, then you
upgrade the installed driver on just that serial port. ?All applications
which open that particular serial port will use your driver. ?If there
are other serial ports on the machine, they will not be affected by your
driver b/c they are still running with the original serial.sys
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com

12

(1) Number one is I agree with most that is posted about this.

(2) Excuse me but could you not just write a small driver that has this
IOCTL and read the register without doing resource allocation at all. With
the x86 I do see anything that wrong with doing a inp “input byte” on the
register. We are running within Ring 0 and there is no protection to
prevent this. Of course this is not good programming with the Windows OS
but it would work for now.

(3) Just take a any sample small Driver Sample and do this input byte
instruction at the line status.

(4) This is not to say you will NOT be able to do this in the furture.

(5) Since you already have the serial.sys built use it.

(6) To get really nasty you could write a bus driver to sit above both your
Serial and the regular Serial driver and that way both could be in memory at
the same time.

(7) Giving all thoughts.

Sincerely;
William Michael Jones

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The line status register is not exposed through any IOCTL, documented or
undocumented. A complete replacement of serial.sys for the individual
serial port in question is required to read this status.

d

-----Original Message-----
From: Doron Holan
Sent: Thursday, April 14, 2005 11:34 AM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] custom IOCTL in serial.sys

I have already asked the owner of serial.sys if such a thing exists. I will
let you know.

d

________________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, April 14, 2005 10:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom IOCTL in serial.sys

Doron,

Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.
Elena mentioned not finding anything to do that in the DDK serial sample,
hence the custom IOCTL and custom driver. Do you know of anything in the
in-box driver that would provide the same ability without the this custom
serial driver nonsense?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 04/14/2005 10:49:08 AM:

> The short answer is that your driver and serial.sys can coexist on the
> machine as long as there are devices for each service to control. Both
> driver cannot control the same instance of hw.
>
> Are you are replacing serial.sys for a motherboard serial port? Or a
> custom UART that you are shipping? If it is a custom solution, just
> write and INF that matches your HW ID to your driver and you are done.
>
> If you are replacing serial.sys for a motherboard serial port, then you
> upgrade the installed driver on just that serial port. All applications
> which open that particular serial port will use your driver. If there
> are other serial ports on the machine, they will not be affected by your
> driver b/c they are still running with the original serial.sys
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: xxxxx@windows.microsoft.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

13

Since I have invested so much so far :slight_smile: …

(2) if you implement this, how are you going to coordinate the reading
of this register with the rest of the serial state machine? Or is this
register non destructive on read and not used at all w/in serial? My
guess is that neither are true and that accessing the register while
serial.sys is touching it is bad mojo.

(6) a bus driver doesn’t help b/c you need to assign the hw resources to
both and you don’t want to do that b/c they both think they own the
port. You also then have an exclusion problem (assuming you overcome
the shared resources issue). Since both device drivers think they own
the hw and they are both there at the same time for the HW, you have to
somehow prevent the other child from being opened while the first is
open. This means you would have to filter on top of serial to redirect
creates, not such a great idea and that means another driver. …

Like I said, the only way you can do this (safely, sanely, and within
the prescribed boundaries of the OS) is to replace serial.sys for the
piece of hw in question (and only this instance of the hw, not all
instances).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jones
Sent: Thursday, April 14, 2005 2:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

(1) Number one is I agree with most that is posted about this.

(2) Excuse me but could you not just write a small driver that has this
IOCTL and read the register without doing resource allocation at all.
With
the x86 I do see anything that wrong with doing a inp “input byte” on
the
register. We are running within Ring 0 and there is no protection to
prevent this. Of course this is not good programming with the Windows
OS
but it would work for now.

(3) Just take a any sample small Driver Sample and do this input byte
instruction at the line status.

(4) This is not to say you will NOT be able to do this in the furture.

(5) Since you already have the serial.sys built use it.

(6) To get really nasty you could write a bus driver to sit above both
your
Serial and the regular Serial driver and that way both could be in
memory at
the same time.

(7) Giving all thoughts.

Sincerely;
William Michael Jones

“Doron Holan” wrote in message
news:xxxxx@ntdev…
The line status register is not exposed through any IOCTL, documented or
undocumented. A complete replacement of serial.sys for the individual
serial port in question is required to read this status.

d

-----Original Message-----
From: Doron Holan
Sent: Thursday, April 14, 2005 11:34 AM
To: ‘Windows System Software Devs Interest List’
Subject: RE: [ntdev] custom IOCTL in serial.sys

I have already asked the owner of serial.sys if such a thing exists. I
will
let you know.

d

________________________________________
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Philip D Barila
Sent: Thursday, April 14, 2005 10:22 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] custom IOCTL in serial.sys

Doron,

Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.
Elena mentioned not finding anything to do that in the DDK serial
sample,
hence the custom IOCTL and custom driver. Do you know of anything in the
in-box driver that would provide the same ability without the this
custom
serial driver nonsense?

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

xxxxx@lists.osr.com wrote on 04/14/2005 10:49:08 AM:

> The short answer is that your driver and serial.sys can coexist on the
> machine as long as there are devices for each service to control. Both
> driver cannot control the same instance of hw.
>
> Are you are replacing serial.sys for a motherboard serial port? Or a
> custom UART that you are shipping? If it is a custom solution, just
> write and INF that matches your HW ID to your driver and you are done.
>
> If you are replacing serial.sys for a motherboard serial port, then
you
> upgrade the installed driver on just that serial port. All
applications
> which open that particular serial port will use your driver. If there
> are other serial ports on the machine, they will not be affected by
your
> driver b/c they are still running with the original serial.sys
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to
ntdev as: xxxxx@windows.microsoft.com To unsubscribe send a blank email
to
xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

14

> Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.

Since I’m pretty sure that you can get these values with one of the user
level CommStatus type functions, it seems clear that there must be a way to
pull that information out of the driver. Whether you can read the LSR by
itself, or if it comes with other data, I don’t know.

Loren

15

> The line status register is not exposed through any IOCTL, documented or
undocumented. A complete replacement of serial.sys for the individual
serial port in question is required to read this status.

Hum. GetCommModemStatus returns CTS, DSR, RI, and RLSD. As best I recall
that is about half of the LSR values. I wonder what GetCommModemStatus
translated to as it goes downward?

Loren

16

> > Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.

Since I’m pretty sure that you can get these values with one of the user

Duh, never mind! I was thinking of the MSR not the LSR.
There is indeed no function to read the LSR.

Loren

17

Hi,

Don’t worry, Loren, I had the same confusion when I first looked for the
way to read LSR.

Doron, it’s for motherboard UART, so I will replace the driver for just
one serial port, as you suggested me.

Thanks again for your help, I’ll tell you when I get it work.

En/na Loren Wilton ha escrit:

>>Elena, the OP, just wanted to read the LINE STATUS REGISTER on the UART.
>
>Since I’m pretty sure that you can get these values with one of the user

Duh, never mind! I was thinking of the MSR not the LSR.
There is indeed no function to read the LSR.

Loren

18

Of course, the next set of questions comes up. What if I plug the
device into the other com port on the machine? What if I plug the
device into a usb -> serial adapter which you cannot rewrite the driver
for? What if I plug it into a multi port serial card?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Thursday, April 14, 2005 11:48 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

Hi,

Don’t worry, Loren, I had the same confusion when I first looked for the

way to read LSR.

Doron, it’s for motherboard UART, so I will replace the driver for just
one serial port, as you suggested me.

Thanks again for your help, I’ll tell you when I get it work.

En/na Loren Wilton ha escrit:

>>Elena, the OP, just wanted to read the LINE STATUS REGISTER on the
UART.
>
>Since I’m pretty sure that you can get these values with one of the
user

Duh, never mind! I was thinking of the MSR not the LSR.
There is indeed no function to read the LSR.

Loren

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

19

Oh, and by the way OP, why do you think you need to read the LSR? That’s
usually an extremely accurate sign of a poorly designed serial device.

Doron Holan wrote:

Of course, the next set of questions comes up. What if I plug the
device into the other com port on the machine? What if I plug the
device into a usb -> serial adapter which you cannot rewrite the driver
for? What if I plug it into a multi port serial card?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
Sent: Thursday, April 14, 2005 11:48 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] custom IOCTL in serial.sys

Hi,

Don’t worry, Loren, I had the same confusion when I first looked for the

way to read LSR.

Doron, it’s for motherboard UART, so I will replace the driver for just
one serial port, as you suggested me.

Thanks again for your help, I’ll tell you when I get it work.

En/na Loren Wilton ha escrit:

>>>Elena, the OP, just wanted to read the LINE STATUS REGISTER on the

UART.

>>Since I’m pretty sure that you can get these values with one of the

user

>
>Duh, never mind! I was thinking of the MSR not the LSR.
>There is indeed no function to read the LSR.
>
> Loren
>
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

20

Thank you Doron for the good explaination. After posting the bus driver
idea I remembered part of what you said. So thanks.
Sincerely
William Michael Jones

“Ray Trent” wrote in message
news:xxxxx@ntdev…
> Oh, and by the way OP, why do you think you need to read the LSR? That’s
> usually an extremely accurate sign of a poorly designed serial device.
>
> Doron Holan wrote:
>> Of course, the next set of questions comes up. What if I plug the
>> device into the other com port on the machine? What if I plug the
>> device into a usb -> serial adapter which you cannot rewrite the driver
>> for? What if I plug it into a multi port serial card?
>>
>> d
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of elena nito
>> Sent: Thursday, April 14, 2005 11:48 PM
>> To: Windows System Software Devs Interest List
>> Subject: Re:[ntdev] custom IOCTL in serial.sys
>>
>> Hi,
>>
>> Don’t worry, Loren, I had the same confusion when I first looked for the
>>
>> way to read LSR.
>>
>> Doron, it’s for motherboard UART, so I will replace the driver for just
>> one serial port, as you suggested me.
>>
>> Thanks again for your help, I’ll tell you when I get it work.
>>
>>
>> En/na Loren Wilton ha escrit:
>>
>>
>>>>>Elena, the OP, just wanted to read the LINE STATUS REGISTER on the
>>
>> UART.
>>
>>>>Since I’m pretty sure that you can get these values with one of the
>>
>> user
>>
>>>
>>>Duh, never mind! I was thinking of the MSR not the LSR.
>>>There is indeed no function to read the LSR.
>>>
>>> Loren
>>>
>>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
>> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
> –
> …/ray..
>
> Please remove “.spamblock” from my email address if you need to contact me
> outside the newsgroup.
>