choosing IOCTL codes?

I see a lot of samples using 0x801 … etc. Is there some procedure to
follow here or whatever meets your fancy? How is this disambiguated?

// Macro definition for defining IOCTL and FSCTL function control codes. Note
// that function codes 0-2047 are reserved for Microsoft Corporation, and
// 2048-4095 are reserved for customers.

Hayden Livingston wrote:

I see a lot of samples using 0x801 … etc. Is there some procedure to
follow here or whatever meets your fancy? How is this disambiguated?

If you are a custom driver (that is, not one of the standard classes),
then you can use whatever numbers you want, other than the method bits
and the permissions bits, which have special meanings. No one cares
about the other bits. It’s a private convention between your apps and
your driver.

I usually try to specify a real value for the device type (like
FILE_DEVICE_UNKNOWN), but I don’t pay a lot of attention to the
“reserved function code range” thing. I certainly would do that if I
were writing in a standard device class.


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

Tim wrote:

I usually try to specify a real value for the device type (like
FILE_DEVICE_UNKNOWN), but I don’t pay a lot of attention to the
“reserved function code range” thing. I certainly would do that if I
were writing in a standard device class.

Hayden,

Please take a look at:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff543023(v=vs.85%
29.aspx

Regardless of whether you are a custom or standard device class, I would
suggest setting the custom bit for the function code if you are implementing
a non-standard function (bit 13). Otherwise, if someone uses an IOCTL
decoder, they may think that you implementing a standard function (which
would be completely misleading).

If you are doing a custom device type, Tim’s suggestion of
FILE_DEVICE_UNKNOWN is fine. However, you can also set the custom device
type bit (bit 31) and set the device type bits to whatever you want.

I hope this helps.

  • Danilo

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, July 06, 2012 10:47 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] choosing IOCTL codes?

Hayden Livingston wrote:

I see a lot of samples using 0x801 … etc. Is there some procedure to
follow here or whatever meets your fancy? How is this disambiguated?

If you are a custom driver (that is, not one of the standard classes),
then you can use whatever numbers you want, other than the method bits
and the permissions bits, which have special meanings. No one cares
about the other bits. It’s a private convention between your apps and
your driver.

I usually try to specify a real value for the device type (like
FILE_DEVICE_UNKNOWN), but I don’t pay a lot of attention to the
“reserved function code range” thing. I certainly would do that if I
were writing in a standard device class.


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


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

I would implement my own IOCTL codes only on my own separate device stack, not adding ones to the stack I’m filtering.

If the IOCTL code is only valid for your device stacks with your naming scheme, then the IOCTL code can be absolutely any.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

“Hayden Livingston” wrote in message news:xxxxx@ntdev…
>I see a lot of samples using 0x801 … etc. Is there some procedure to
> follow here or whatever meets your fancy? How is this disambiguated?
>
> // Macro definition for defining IOCTL and FSCTL function control codes. Note
> // that function codes 0-2047 are reserved for Microsoft Corporation, and
> // 2048-4095 are reserved for customers.
>

Maxim S. Shatskih wrote:

I would implement my own IOCTL codes only on my own separate device stack, not adding ones to the stack I’m filtering.

If the IOCTL code is only valid for your device stacks with your naming scheme, then the IOCTL code can be absolutely any.

EXCEPT for the method and permission bits. Those are interpreted by the
operating system for ALL device types.


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