On 05-Mar-2012 13:32, xxxxx@billauer.co.il wrote:
HKR,DeviceType,0x10001,0x11
That set the device type of the PCIe device to 0x11 (FILE_DEVICE_NAMED_PIPE, reflecting the device’s behavior). Resulting in GetFileType() returning 0x0003 (FILE_TYPE_PIPE) and _open() opening the device file with no complaints.
Named pipes in Windows are actually kind of file system (NPFS)…
sooooo…
– pa
David R. Cattley wrote:
I just looked at the SRC for _open() and you can too. The CRT sources are
shipped with VS. I cannot see where it does anything other than pass the
path parameter directly to CreateFile().
Yes, but after CreateFile, it calls GetFileType and fails if the return
is FILE_TYPE_UNKNOWN. That’s what is biting him.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 05-Mar-2012 15:00, Pavel A wrote:
On 05-Mar-2012 13:32, xxxxx@billauer.co.il wrote:
> HKR,DeviceType,0x10001,0x11
>
> That set the device type of the PCIe device to 0x11
> (FILE_DEVICE_NAMED_PIPE, reflecting the device’s behavior). Resulting
> in GetFileType() returning 0x0003 (FILE_TYPE_PIPE) and _open() opening
> the device file with no complaints.Named pipes in Windows are actually kind of file system (NPFS)…
sooooo…
Soo… if no one sees anything wrong with FILE_DEVICE_NAMED_PIPE,
then congratulations, you did it.
– pa
Pavel – the truth is I haven’t given much thought yet about the implications of declaring the device as a pipe. I think reading through the CRT sources will give me a better view of what Microsoft really had in mind.
A simple Google check reveals that the term “Named pipe” is by far, far, more frequent than the “Named Pipe File System” or NPFS. I couldn’t find anything about directories in this so-called file system, nor is there any persistence of files and their content. So it looks like the named pipe has much in common with the abstraction my driver offers.
The only problem I foresee with this declaration is that I’m going to allow seeking on some of my device files, which is not necessarily a sane thing on a named pipe. Still to see if this is a problem.
xxxxx@billauer.co.il wrote:
Pavel – the truth is I haven’t given much thought yet about the implications of declaring the device as a pipe. I think reading through the CRT sources will give me a better view of what Microsoft really had in mind.
I’ll give you my opinion on the topic. In practical terms, there are no
implications. No component in the operating system cares what you
specify as a file type. It is decorative – a piece of documentation.
The check in open.c in the C run-time library is almost certainly the
only place you will ever encounter that checks this, and if you’ve
satisfied that, you should be happy.
Once you get past the open, everything is just IRPs, and the IRP
processing doesn’t care about the device type.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
[Making device ‘named pipe’ to satisfy POSIX-compliant open() in VSCRT]
On 3/6/2012 7:09 PM, Tim Roberts wrote:
I’ll give you my opinion on the topic. In practical terms, there are
no implications. No component in the operating system cares what you
specify as a file type. It is decorative – a piece of documentation.
The check in open.c in the C run-time library is almost certainly the
only place you will ever encounter that checks this, and if you’ve
satisfied that, you should be happy. Once you get past the open,
everything is just IRPs, and the IRP processing doesn’t care about the
device type.
Statements valid today. [Sorry for the nit-picking, Tim. Reading this, I
just remembered the OP who complained bitterly that his “perfectly
working fine on XP” USB device - with a broken descriptor - was not
recognized by Vista (and probably not by Win7 and Win8 either).]
OP needs to be aware that a future version of Windows™ might change
todays “checking” behavior, i.e. MS could prevent you from using
anything that is not really “pipe-like”. And the change can come
unannounced, overnight with Windows Update. Unlikely as this might be,
better “know your risks.” 
My concern was not possibility of changes by MS, but some
threads in NTFSD - smart people wanting to filter npfs, and so on.
They dig there righ now… while we do not watch them.
Regards,
– pa
“Hagen Patzke” wrote in message news:xxxxx@ntdev…
> [Making device ‘named pipe’ to satisfy POSIX-compliant open() in VSCRT]
>
> On 3/6/2012 7:09 PM, Tim Roberts wrote:
>> I’ll give you my opinion on the topic. In practical terms, there are
>> no implications. No component in the operating system cares what you
>> specify as a file type. It is decorative – a piece of documentation.
>> The check in open.c in the C run-time library is almost certainly the
>> only place you will ever encounter that checks this, and if you’ve
>> satisfied that, you should be happy. Once you get past the open,
>> everything is just IRPs, and the IRP processing doesn’t care about the
>> device type.
>
> Statements valid today. [Sorry for the nit-picking, Tim. Reading this, I
> just remembered the OP who complained bitterly that his “perfectly
> working fine on XP” USB device - with a broken descriptor - was not
> recognized by Vista (and probably not by Win7 and Win8 either).]
>
> OP needs to be aware that a future version of Windows™ might change
> todays “checking” behavior, i.e. MS could prevent you from using
> anything that is not really “pipe-like”. And the change can come
> unannounced, overnight with Windows Update. Unlikely as this might be,
> better “know your risks.”
>
>
I completely agree with Hagen about trying to play things so that future changes in Windows won’t break things all of the sudden.
I’ve just read through the CRT sources to get an idea of what should be expected from different file types. Even though they only display how the POSIX functions are ported to Windows, I believe that’s as official as things will ever get. Besides, since those functions are already used in binaries, and Microsoft tends to respect backward compatibility, I suppose they won’t change anything that will break a UNIX-style program compiled natively under Windows.
So these are my conclusions so far:
Declaring my device file as a regular file: Bad idea, since open may take the liberty to seek a regular file to its last character, in order to see if it’s a CTRL-Z. Will not work nice with a data stream.
Declaring the device file as a FILE_TYPE_CHAR is not a good idea either, because that will make _isatty return true, meaning that the device is a terminal. I also saw some other places where a FILE_TYPE_CHAR is treated as a terminal, in particular with CTRL-Z’s.
As it turns out ,a FILE_TYPE_PIPE is treated with most respect. It’s not assumed to be seekable, but the _lseek() implementation doesn’t care if it’s a pipe. A pipe may return a broken pipe error condition, but of course it doesn’t have to. And there are no assumptions about the data format, since any application could be feeding the other end in a normal pipe application.
So FILE_TYPE_PIPE it is. It looks like picking the most intuitive type turned out to be the correct one. I may run into problems with seeking in the future, but right now that doesn’t seem to be the case.
Just thought I should share this with you.
Eli
And since I’m at it: Regarding what happens when trying to seek a pipe, taken from the documentation for SetFilePointer:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365541(v=vs.85).aspx
“The hFile parameter must refer to a file stored on a seeking device; for example, a disk volume. Calling the SetFilePointer function with a handle to a non-seeking device such as a pipe or a communications device is not supported, even though the SetFilePointer function may not return an error. The behavior of the SetFilePointer function in this case is undefined.”
So I can just hope that those implementing Perl, Python, Java, C# or whatever just let the seek commands through for pipes, since they might succeed despite the suspicious file type.
Assuming we’re talking about the DEVICE_TYPE field supplied to IoCreateDevice, I’m afraid this is not really correct.
There are SEVERAL things that the OS itself, and user-mode pieces parts, do differently based on DEVICE_TYPE. The obvious one is whether the DEVICE_TYPE is FILE_DEVICE_DISK (or a few others) which determines whether the VPB is created to link the FDO to a mounted File System device instance. Other things include the default protection applied to a Device Object when it’s created.
Another really strange example is how accessing the device from a command prompt windows seems to depend on DEVICE_TYPE… set the DEVICE_TYPE to something unexpected and you won’t be able to CD to the device… or successfully issue a mkdir. We just discovered this last week ourselves. Very annoying.
So, the chosen DEVICE_TYPE is more than a decoration. It actually matters for a lot of little bitty annoying stuff that can rise-up and bite you.
Use FILE_DEVICE_NAMED_PIPE if you like it… just be sure to run through all the scenarios that you want to support for your users accessing your device.
Peter
OSR