Opening a DosDevices object with POSIX open() or fopen()

NTDEV
1

Hi (again…),

Even though the official suggestion is to open DosDevices objects with CreateFile(), it will be a significant benefit if it could be done with the POSIX-compliant functions fopen() and open().

I do recall the remarks about Windows not being Linux when I asked a similar question on accessing these objects (symlinks, actually) in a DOS command window. I also know that the common way to expose hardware is with a supporting API. But one of the great benefits of this specific project is to make the hardware available to less professional programmers. It’s a development kit more than a finalized product.

There are no problems at all when using Cygwin. It looks like cygwin1.dll does the translation from fopen() and open() to CreateFile() without making any fuss about what kind of object it’s opening, so both command line utilities and my own test programs work great.

But when compiling the test programs with Visual Studio (or with gcc, with the -mno-cygwin flag), open(…, O_RDONLY), _open(…, O_RDONLY) and fopen(…, “rb”) fail on the DosDevice with an “Invalid argument” error. Needless to say, there is no problem when I try exactly the same programs on a regular disk file.

This is something I’m ready to go a long way to fix.

IrpTracker (as well as other debug dumps) tell me that the device driver itself returned success on the CreateFile IRP. The IRP sequence goes simply CREATE, CLEANUP and CLOSE, all returning with success.

A dump of API calls to kerner32.dll reveals a CreateFileA() call returning successfully, followed by a GetFileType() returning zero (FILE_TYPE_UNKNOWN), after which CloseHandle() is called. When I ran the same thing on a regular file, GetFileType() returned 0x0001 (FILE_TYPE_DISK). It does look like the problem, in particular in light of a question asked some ten years ago:

http://www.osronline.com/showThread.cfm?link=31320

Unfortunately, setting IoCreateDevice()'s DeviceType to FILE_DEVICE_DISK_FILE_SYSTEM didn’t help (neither did FILE_DEVICE_NAMED_PIPE or FILE_DEVICE_STREAMS which make more sense in my context). GetFileType() keeps returning FILE_TYPE_UNKNOWN.

Maybe it’s the difference in Windows version (Windows 7, build 7600 in my case). I couldn’t know.

Any ideas?

Thanks in advance,
Eli

2

How about using _open_osfhandle() after CreateFile() opens the device.

Good Luck,
Dave Cattley

3

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().

Maybe you could step into _open() with a debugger and assess *why* it is
failing.

Good Luck,
Dave Cattley

4

Unfortunately, solving the problem with programming tricks won’t do. The purpose is to supply users with something that can be opened like a file with whatever tools or language they’re used to. For example, Perl compiled under Windows directly might use fopen(). Or open(). And it might not. In theory, I can check up each and every language (Python? MATLAB? C#? Java? Visual Basic? Graphical programming languages?), but the whole point is to be able to say “use anything you want”.

But thanks for trying. :slight_smile:

5

> it will be a significant benefit if it could be done with the POSIX-compliant functions fopen() and open().

I do recall the remarks about Windows not being Linux

Actually, high-level fopen() C library function cannot be used with device files on Linux either - in order to open them you need to make a low-level open() system call. I guess you should do a bit of research…

Anton Bassov

6

As an application programmer, I frequently use fopen, particularly when I
need potentially portable code. Note that there is no other way to open a
file except CreateFile (or the underlying NtCreateFile) so it is not clear
why you are asking for something that os “Posix-compliant” since this is a
library concept, and all libraries just map to CreateFile. You have not
said *what* you are trying to open (as in giving the exact string you are
passing in) and you have not reported what GetLastError or errno contain.

So all you have said is “my program doesn’t work, what did I do wrong?”
and the answer, of course, is “something. Fix it.”

Note that the proper way to specify a device is “\\.\whatever” (in C
string syntax, using \ to mean a single ). As far as I know, no other
syntax is supported. But since you gave practically no information in
your question, it is hard to guess what you meant. You have said that you
see different values coming back for the file type, but failed to do the
obvious examination of the CRT source, or indicate whether the call to
query the device type came from the CRT or the application itself.
Perhaps the application author decided not to support non-file types. I
am not anywhere near a machine that can examine the CRT sources, but I
would have done that before trying to tell the kernel that my device is a
file system.

Note that for file systems, a ReadFile that returns without an error but
which returns 0 bytes is the official definition of EOF, but there are
many hardware devices which return 0 bytes successfully (including serial
ports) which simply means “I have no data, but the device is fine”. So
perhaps some CRT or some application have decided that to make sure eof()
is well-defined that non-file-system devices will not be supported in that
library. At this point, you have a fair argument that the given CRT is
not Posix-compliant, but note that it only needs to be compliant with the
ISO C library spec, and any correspondence between THAT spec and the Posix
spec is, at this late date, purely coincidental (remember that the Posix
spec was a snapshot, now decades old, of what one vendor’s CRT did at that
point in time, and both Posix and C standards have evolved separately
since that time)

joe

Hi (again…),

Even though the official suggestion is to open DosDevices objects with
CreateFile(), it will be a significant benefit if it could be done with
the POSIX-compliant functions fopen() and open().

I do recall the remarks about Windows not being Linux when I asked a
similar question on accessing these objects (symlinks, actually) in a DOS
command window. I also know that the common way to expose hardware is with
a supporting API. But one of the great benefits of this specific project
is to make the hardware available to less professional programmers. It’s a
development kit more than a finalized product.

There are no problems at all when using Cygwin. It looks like cygwin1.dll
does the translation from fopen() and open() to CreateFile() without
making any fuss about what kind of object it’s opening, so both command
line utilities and my own test programs work great.

But when compiling the test programs with Visual Studio (or with gcc, with
the -mno-cygwin flag), open(…, O_RDONLY), _open(…, O_RDONLY) and
fopen(…, “rb”) fail on the DosDevice with an “Invalid argument” error.
Needless to say, there is no problem when I try exactly the same programs
on a regular disk file.

This is something I’m ready to go a long way to fix.

IrpTracker (as well as other debug dumps) tell me that the device driver
itself returned success on the CreateFile IRP. The IRP sequence goes
simply CREATE, CLEANUP and CLOSE, all returning with success.

A dump of API calls to kerner32.dll reveals a CreateFileA() call returning
successfully, followed by a GetFileType() returning zeroy
(FILE_TYPE_UNKNOWN), after which CloseHandle() is called. When I ran the
same thing on a regular file, GetFileType() returned 0x0001
(FILE_TYPE_DISK). It does look like the problem, in particular in light of
a question asked some ten years ago:

http://www.osronline.com/showThread.cfm?link=31320

Unfortunately, setting IoCreateDevice()'s DeviceType to
FILE_DEVICE_DISK_FILE_SYSTEM didn’t help (neither did
FILE_DEVICE_NAMED_PIPE or FILE_DEVICE_STREAMS which make more sense in my
context). GetFileType() keeps returning FILE_TYPE_UNKNOWN.

Maybe it’s the difference in Windows version (Windows 7, build 7600 in my
case). I couldn’t know.

Any ideas?

Thanks in advance,
Eli

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

7

> But since you gave practically no information in your question, it is hard to guess what you meant.

Actually, the OP gave enough information to understand what his error is about - he tries to use fopen()
(i.e. a function that opens a stream) with a device file. It does not work, either under Windows or Linux…

Anton Bassov

8

My bad; I should have remembered that. But it’s been over 25 years since
I last wrote a Unix program. And I have never used streams for device
I/O, because nearly all my device I/O has been asynchronous and therefore
I had to use CreateFile.
joe

> But since you gave practically no information in your question, it is
> hard to guess what you meant.

Actually, the OP gave enough information to understand what his error is
about - he tries to use fopen()
(i.e. a function that opens a stream) with a device file. It does not
work, either under Windows or Linux…

Anton Bassov

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

9

Eli,

Windows generally supports passing a “tail” in CreateFile targeted to a
device, and the device driver may be made responsible to parse this
“tail” - or disable using the “tail” at all.
So, since it is your own driver (the long-awaited Xillybus release for
Windows? :slight_smile: maybe it should not take too much to implement.
Could you tell again, what is the complete “file path” you’re trying to
open, what is the name (symlink) of underlying device(s), and what
protection you want for the leaf “files”.

But in any case, unlikely that users will accept solutions based on
something undermining system stability - and filesystem stuff is a very
painful place in Windows (One of many reasons why Windows is not Linux).
Just mention that your driver goes anywhere near filesystems, and this
will immediately turn red light for many customers.
Like using ethernet for reliable data streaming :slight_smile:

Good luck,
– pa

On 03-Mar-2012 23:37, xxxxx@billauer.co.il wrote:

Hi (again…),

Even though the official suggestion is to open DosDevices objects with CreateFile(), it will be a significant benefit if it could be done with the POSIX-compliant functions fopen() and open().

I do recall the remarks about Windows not being Linux when I asked a similar question on accessing these objects (symlinks, actually) in a DOS command window. I also know that the common way to expose hardware is with a supporting API. But one of the great benefits of this specific project is to make the hardware available to less professional programmers. It’s a development kit more than a finalized product.

There are no problems at all when using Cygwin. It looks like cygwin1.dll does the translation from fopen() and open() to CreateFile() without making any fuss about what kind of object it’s opening, so both command line utilities and my own test programs work great.

But when compiling the test programs with Visual Studio (or with gcc, with the -mno-cygwin flag), open(…, O_RDONLY), _open(…, O_RDONLY) and fopen(…, “rb”) fail on the DosDevice with an “Invalid argument” error. Needless to say, there is no problem when I try exactly the same programs on a regular disk file.

This is something I’m ready to go a long way to fix.

IrpTracker (as well as other debug dumps) tell me that the device driver itself returned success on the CreateFile IRP. The IRP sequence goes simply CREATE, CLEANUP and CLOSE, all returning with success.

A dump of API calls to kerner32.dll reveals a CreateFileA() call returning successfully, followed by a GetFileType() returning zero (FILE_TYPE_UNKNOWN), after which CloseHandle() is called. When I ran the same thing on a regular file, GetFileType() returned 0x0001 (FILE_TYPE_DISK). It does look like the problem, in particular in light of a question asked some ten years ago:

http://www.osronline.com/showThread.cfm?link=31320

Unfortunately, setting IoCreateDevice()'s DeviceType to FILE_DEVICE_DISK_FILE_SYSTEM didn’t help (neither did FILE_DEVICE_NAMED_PIPE or FILE_DEVICE_STREAMS which make more sense in my context). GetFileType() keeps returning FILE_TYPE_UNKNOWN.

Maybe it’s the difference in Windows version (Windows 7, build 7600 in my case). I couldn’t know.

Any ideas?

Thanks in advance,
Eli

10

On 04-Mar-2012 02:25, xxxxx@hotmail.com wrote:

> it will be a significant benefit if it could be done with the POSIX-compliant functions fopen() and open().
> I do recall the remarks about Windows not being Linux

Actually, high-level fopen() C library function cannot be used with device files on Linux either - in order to open them you need to make a low-level open() system call. I guess you should do a bit of research…

Anton Bassov

Generally yes - but the OP talks about “device files” specially designed
for simple scripting, like certain parts of sysfs, debugfs, configfs and
so on. /*Pathetically low-tech and under-designed, if compared to WMI :~[ */

  • pa
11

Hello,

Sorry, I forgot to mention what the path was. I’m not sure it’s relevant, but anyhow. I described this in a previous question here:

http://www.osronline.com/showthread.cfm?link=220533

I’ll repeat the highlight: Following the classic convention, the driver sets up an UNNAMED device (with IoCreateDevice()'s DeviceName parameter set to NULL). The interface’s name is later acquired from IoRegisterDeviceInterface()'s SymbolicLinkName. The driver’s namespace is then created by virtue of several symbolic links under \DosDevices, each pointing at the interface name given by IoRegisterDeviceInterface() appended with some “\myname” string. So when the application creates a file with the symbolic link (say, \.\hello), the symbolic link redirects the object manager to something link {…Long blob…}\hello, which in turn redirects to the actual device (\Device\NTPNP_PCI0015).

As for protection (security?) I don’t find that necessary. At the current moment the policy is any user can do anything.

As far as I know, fopen() is a wrapper for open() in Linux, and judging by call traces to kernel32.dll, open(), fopen() and _open() are wrappers for CreateFile(). I have no problem with that. The problem is that after Windows’ open() calls CreateFile() and successfully gets a file handle, it decides to close that file handle and report an error. Before closing the handle, it calls GetFileType() (with the file handle it just got), gets a FILE_TYPE_UNKNOWN, which I suspect is the reason it becomes unhappy.

I think it’s reasonable to assume, that after getting the file handle, Windows’ open() doesn’t care about the suspicious path anymore, but only what the file handle has to offer.

As for Joe’s remark: Is the source’s for the CRT available? As a matter of fact, I’m more curious about what kernel32.dll does, because my best guess is that it translated the device’s DeviceType to the return value of GetFileType(), and I believe that if I solve this problem, all will be well again.

Pavel – I guess Google revealed all my little secrets. :slight_smile: But these device files are used to carry actual data, not meta information. And yes,the whole point is to make the entire machinery stable and running with everything. In fact, that’s already the situation once the CreateFile() part is getting through. It works great with the native Window’s call, in synchronous and asynchronous (“overlapping”) mode, and also with all kind of nasty things I’ve tried from Cygwin. And indeed, I don’t want to make a filesystem, because I have a guess of what kind of new problems I’ll encounter.

I just want any possible Windows program, which gets this \.\hello (backslashes doubled as necessary) to behave just like normal. No matter what language or wrappers it may use for CreateFile().

Thank you all for trying to help so far.

Eli

12

On 04-Mar-2012 18:37, xxxxx@billauer.co.il wrote:
…

I’ll repeat the highlight: Following the classic convention, the driver sets up an UNNAMED device
> (with IoCreateDevice()'s DeviceName parameter set to NULL).
> The interface’s name is later acquired from
IoRegisterDeviceInterface()'s SymbolicLinkName.
The driver’s namespace is then created by virtue of several symbolic links under
\DosDevices,each pointing at the interface name given by IoRegisterDeviceInterface()
appended
with some “\myname” string. So when the application creates a file with the symbolic
link (say, \.\hello), the symbolic link redirects the object manager to something link
{…Long blob…}\hello, which in turn redirects to the actual device (\Device\NTPNP_PCI0015).

The problem seems to be in the last point:
What if you create only one link under DosDevices that points to the
actual device, and let the driver parse the following path components
(the “hello” part)?

Look in the WDK help file for topic “Controlling Device Namespace Access”.

[quote] A WDM driver receives open requests for all names in the device’s
namespace. The driver treats an open request for “\Device\DeviceName” as
an open of the device object itself. If the driver implements support
for open requests into the device’s namespace, then it treats an open
request for “\Device\DeviceName\FileName” as an open of a “file” within
the device object’s namespace (where the notion of “file” for the device
is driver-determined).
[/quote]

– pa

13

> /*Pathetically low-tech and under-designed, if compared to WMI :~[ */

Anton Bassov

14

Pavel – the driver does indeed parse the “FileName” part within a namespace, as your quote suggests. As a matter of fact, the same device is opened under several different “file names” using this method, and there has been no problem with opening these different symbolic links, each having a slightly different functionality, in parallel. Heavily tested and works with no problem at all.

The thing I could look at, is to avoid the double hop from the symbolic link generated by the driver, to the one created by the NT kernel, which in turn points at the object in the \Device “subdirectory”. But I will eat my hat if that makes a difference, as I suspect GetFileType(), which runs on the file handle, not the file’s path. I mean, once the handle is there, I doubt if it matters if it was reached through one symbolic link hop or two. Lacking any better idea, I’ll check this eventually. :slight_smile:

15

Dony worry about the two symbolic links, it happens only in create which would not be your hot path.

d

debt from my phone

From: xxxxx@billauer.co.il
Sent: 3/4/2012 11:17 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Opening a DosDevices object with POSIX open() or fopen()

Pavel – the driver does indeed parse the “FileName” part within a namespace, as your quote suggests. As a matter of fact, the same device is opened under several different “file names” using this method, and there has been no problem with opening these different symbolic links, each having a slightly different functionality, in parallel. Heavily tested and works with no problem at all.

The thing I could look at, is to avoid the double hop from the symbolic link generated by the driver, to the one created by the NT kernel, which in turn points at the object in the \Device “subdirectory”. But I will eat my hat if that makes a difference, as I suspect GetFileType(), which runs on the file handle, not the file’s path. I mean, once the handle is there, I doubt if it matters if it was reached through one symbolic link hop or two. Lacking any better idea, I’ll check this eventually. :slight_smile:

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

16

On 04-Mar-2012 21:15, xxxxx@billauer.co.il wrote:

Pavel – the driver does indeed parse the “FileName” part within a namespace, as your quote suggests.

And this is another thing how Windows is not Linux: Windows usually has
better documentation, where it isn’t undocumented:) Kudos go to the
great WDK docum team.

– pa

17

Hi again,

I tried a few other things. One was to try opening \.\NUL with _open(). And yes, that worked, and attempting to read data gives the EOF right away (which makes sense somehow). The I wrote a simple program that calls CreateFile() and then GetFileType(), which returned FILE_TYPE_CHAR. Which is very good news, because that means _open() knowingly opens something that isn’t a plain file.

The \.\NUL device is a symbolic link pointing at \Device\Null. I have good reasons to believe that its DeviceType is FILE_DEVICE_NULL. Not just because it makes sense, but because single-stepping into the assembler part implementing GetFileType, I saw that magic number (0x15) being compared with a lot of constants, and then returning the value 2 (which is FILE_TYPE_CHAR).

So I said: NUL is a symbolic link, and I provide one. I’ll set my DeviceType to FILE_DEVICE_NULL and see what happens.

The outcome was: My device is still a FILE_TYPE_UNKNOWN. It just didn’t work.

My next step is probably to reverse engineer the GetFileType() function until I understand how it could tell the difference between NUL’s symbolic link to \Device\NUL and my own link to \Device\NTPNP_PCI0017.

Unless someone spares me that agony with a brilliant suggestion. Someone? :slight_smile:

18

I thibk you are to the root cause. The sym link points to the pdo which had a device type which you don’t control, it doesn’t matter what you set your device type to because the symlink points below you in the stack. Fortunately you can override the device type in your inf

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546320(v=vs.85).aspx

DeviceType
A DeviceType HKR AddReg entry specifies a device type for the device. The device-type is the numeric value of a FILE_DEVICE_XXX constant defined in Wdm.h or Ntddk.h. The flag value of 0x10001 specifies that the device-type value is a REG_DWORD. For more information, see Specifying Device Types.

A class-installer INF should specify the device type that applies to all, or almost all, of the devices in the class. For example, if the devices in the class are of type FILE_DEVICE_CD_ROM, specify a device-type of 0x02. If a device INF specifies a value for DeviceType, it overrides the value set by the class installer, if any. If the class or device INF specifies a DeviceType value, the PnP manager applies that type to the physical device object (PDO) created by the device’s bus driver.

d

debt from my phone

From: xxxxx@billauer.co.il
Sent: 3/4/2012 3:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Opening a DosDevices object with POSIX open() or fopen()

Hi again,

I tried a few other things. One was to try opening \.\NUL with _open(). And yes, that worked, and attempting to read data gives the EOF right away (which makes sense somehow). The I wrote a simple program that calls CreateFile() and then GetFileType(), which returned FILE_TYPE_CHAR. Which is very good news, because that means _open() knowingly opens something that isn’t a plain file.

The \.\NUL device is a symbolic link pointing at \Device\Null. I have good reasons to believe that its DeviceType is FILE_DEVICE_NULL. Not just because it makes sense, but because single-stepping into the assembler part implementing GetFileType, I saw that magic number (0x15) being compared with a lot of constants, and then returning the value 2 (which is FILE_TYPE_CHAR).

So I said: NUL is a symbolic link, and I provide one. I’ll set my DeviceType to FILE_DEVICE_NULL and see what happens.

The outcome was: My device is still a FILE_TYPE_UNKNOWN. It just didn’t work.

My next step is probably to reverse engineer the GetFileType() function until I understand how it could tell the difference between NUL’s symbolic link to \Device\NUL and my own link to \Device\NTPNP_PCI0017.

Unless someone spares me that agony with a brilliant suggestion. Someone? :slight_smile:

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

19

Every time I install a version of Visual Studio, it installs the complete
CRT source tree, including assembly-code versions of several functions
which have C source, but the hand-tuned assembler is faster in these
restrictive cases.

The source tree starts at c:\Program Files (x86)\Microsoft Visual Studio
10.0\vc\crt\src

kernel32.dll sources are not available to ordinary people, and they
shouldn’t matter.

However, as pointed out, fopen expects to open a steam device, and
hardware devices are not supported by fopen. Today, I am at home and have
access to the sources, and here’s the exact lines from c:\Program Files
(x86)\Microsoft Visual Studio 10.0\vc\crt\src\open.c

static errno_t __cdecl _tsopen_nolock(…stuff…)
{
…more stuff…

/* find out what type of file (file/device/pipe) */
if ( (isdev = GetFileType(osfh)) == FILE_TYPE_UNKNOWN) {
DWORD dwLastError = 0;
_osfile(*pfh) &= ~FOPEN;
dwLastError = GetLastError();
_dosmaperr(dwLastError);
CloseHandle(osfh);
if (dwLastError == ERROR_SUCCESS)
{
/*
* If GetFileType returns FILE_TYPE_UNKNOWN but doesn’t fail,
* GetLastError returns ERROR_SUCCESS.
* This function is not designed to deal with unknown types
of files
* and must return an error.
*/
errno = EACCES;
}

Note the comment, which says explicitly that this is not going to support
anything that is FILE_TYPE_UNKNOWN.

Perhaps you are better off calling your device a “pipe” rather than a
“file system”. Note that you are expected to properly support EOF
semantics.

joe

Hello,

Sorry, I forgot to mention what the path was. I’m not sure it’s relevant,
but anyhow. I described this in a previous question here:

http://www.osronline.com/showthread.cfm?link=220533

I’ll repeat the highlight: Following the classic convention, the driver
sets up an UNNAMED device (with IoCreateDevice()'s DeviceName parameter
set to NULL). The interface’s name is later acquired from
IoRegisterDeviceInterface()'s SymbolicLinkName. The driver’s namespace is
then created by virtue of several symbolic links under \DosDevices, each
pointing at the interface name given by IoRegisterDeviceInterface()
appended with some “\myname” string. So when the application creates a
file with the symbolic link (say, \.\hello), the symbolic link redirects
the object manager to something link {…Long blob…}\hello, which in
turn redirects to the actual device (\Device\NTPNP_PCI0015).

As for protection (security?) I don’t find that necessary. At the current
moment the policy is any user can do anything.

As far as I know, fopen() is a wrapper for open() in Linux, and judging by
call traces to kernel32.dll, open(), fopen() and _open() are wrappers for
CreateFile(). I have no problem with that. The problem is that after
Windows’ open() calls CreateFile() and successfully gets a file handle, it
decides to close that file handle and report an error. Before closing the
handle, it calls GetFileType() (with the file handle it just got), gets a
FILE_TYPE_UNKNOWN, which I suspect is the reason it becomes unhappy.

I think it’s reasonable to assume, that after getting the file handle,
Windows’ open() doesn’t care about the suspicious path anymore, but only
what the file handle has to offer.

As for Joe’s remark: Is the source’s for the CRT available? As a matter of
fact, I’m more curious about what kernel32.dll does, because my best guess
is that it translated the device’s DeviceType to the return value of
GetFileType(), and I believe that if I solve this problem, all will be
well again.

Pavel – I guess Google revealed all my little secrets. :slight_smile: But these
device files are used to carry actual data, not meta information. And
yes,the whole point is to make the entire machinery stable and running
with everything. In fact, that’s already the situation once the
CreateFile() part is getting through. It works great with the native
Window’s call, in synchronous and asynchronous (“overlapping”) mode, and
also with all kind of nasty things I’ve tried from Cygwin. And indeed, I
don’t want to make a filesystem, because I have a guess of what kind of
new problems I’ll encounter.

I just want any possible Windows program, which gets this \.\hello
(backslashes doubled as necessary) to behave just like normal. No matter
what language or wrappers it may use for CreateFile().

Thank you all for trying to help so far.

Eli

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

20

*** SOLVED ***

Thank you so very much for that one, Doron.

Indeed, the following little line did the trick in the INF file:

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.

Joe – I wasn’t aware of these sources, and I will surely read through the relevant files carefully. Thanks for that.

As for the EOF issue, my driver returns STATUS_END_OF_FILE + zero in the information field when applicable, and non-zero data count otherwise.

Thanks to all who tried to get me back on track. Eventually, you did! :slight_smile: