NTDeviceName and DosDeviceName

NTDEV
1

Hi,

All the documentation I have read says that with IoCreateDevice you could pass in a unicode string that defines the NTDevicename for the device. This name is what you could use to access the device from the kernel space (say using IoGetDeviceObjectPointer). In case you want to access the driver from user space we need to define a Symbolic link which is defined as the DosDeviceName.

My question is, why is it not possible to access the NTDeviceName from user space? Why do I have to access the device only using the DosDeviceName from user space?

Thanks,
Giri

2

> why is it not possible to access the NTDeviceName from user space?

Actually, it seems to be just a general belief, directly related to the fact that Win32 wrapper prepends ‘??’ to a string that you have supplied, so that the system looks only in ‘Global’ directory upon those calls that have been submitted via Win32 wrapper. Therefore, opening a device by its “real” NT name by CreateFile() is not going to work. However, if you call ZwCreateFile() from the user mode directly, I believe you should not have a problem with opening a device in its native NT format, i.e. like\Device\xxx…

Anton Bassov

3

xxxxx@yahoo.com wrote:

Hi,

All the documentation I have read says that with IoCreateDevice you could pass in a unicode string that defines the NTDevicename for the device. This name is what you could use to access the device from the kernel space (say using IoGetDeviceObjectPointer). In case you want to access the driver from user space we need to define a Symbolic link which is defined as the DosDeviceName.

My question is, why is it not possible to access the NTDeviceName from user space? Why do I have to access the device only using the DosDeviceName from user space?

Part of this goes back to the original design philosophy of Windows NT.

Today, we think of the NT-based systems as one single operating system
that happens to be split between kernel and user – Win32 to the core.
However, that’s really not the way the system was designed. Instead,
exaggerating only slightly, the NT kernel was intended to be a
standalone operating system, which supported a number of different
system views in user mode, using the now-obsolete term “subsystem”. To
begin with, you had the Win32 subsystem, the OS/2 subsystem, and the
Posix subsystem. Win32 user-mode programs would call user-mode DLLs in
the Win32 subsystem that bridged to the native kernel-mode interfaces.
OS/2 user-mode programs would call user-mode DLLs in the OS/2 subsystem
that, again, bridged to native KM interfaces. The kernel interfaces
were supposed to be subsystem-independent, with essentially no knowledge
of the client’s current subsystem.

That’s why display drivers originally ran in user-mode. The display
drivers model is very much Win32 – very GDI-specific. The user-mode
Win32 display drivers would call into their kernel miniports, which were
(theoretically) independent of the client subsystem. This division
still lives on to a certain extent today, in that win32k.sys is
essentially the kernel half of the Win32 subsystem.

So, from the very beginning, the kernel had its own private namespaces,
and names that needed to be referenced from user-mode subsystems would
be created via symbolic links into subsystem-specific namespaces.

It’s actually a pretty slick concept, and it’s somewhat unfortunate that
necessity has forced the distinction to be blurred over time.

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