On these platforms, there is one global \DosDevices directory, and multiple local \DosDevices directories. The global \DosDevices directory holds the MS-DOS device names that are visible system-wide. A local \DosDevices directory holds MS-DOS device names that are visible only in a particular local DosDevices context.
The local DosDevices contexts are as follows.
- On Windows XP and later, each logon session has its own local DosDevices context. The system process, and any process running as the LocalSystem user, does not run in a local DosDevices context.
- On Windows 2000, each terminal server session has its own local DosDevices context. Any process running as part of the console session does not run in a local DosDevices context.
If a process is currently running in a local DosDevices context, then any MS-DOS device names that it creates are created only in the local DosDevices directory. Thus, processes running in a local DosDevices context cannot affect the MS-DOS device names that are visible to processes running in another local DosDevices context or in the global DosDevices context. For example, if a user on Windows XP or later mounts a network drive as X:, this does not affect the meaning of X: for any other user, or for the system as a whole.
On Windows XP and later, when the Object Manager looks up a name in \DosDevices, it first searches the local \DosDevices directory, and then the global \DosDevices directory. If the name exists in both places, the local name shadows the global name.
On Windows 2000, whenever a new terminal server session is initiated, the system builds local \DosDevices directory by copying the global \DosDevices directory. Any subsequent changes to the global directory are not propagated to the local directory.
A driver that must create its MS-DOS device names in the global \DosDevices directory can do so by creating its symbolic links in a standard driver routine that is guaranteed to run in the system process context, such as DriverEntry. Alternatively, the global \DosDevices directory is available as \DosDevices\Global; drivers can use a name of the \DosDevices\Global\DosDeviceName to specify a name in the global directory.
Note that \DosDevices\Global does not exist on platforms that do not support local and global versions of \DosDevices, such as Windows 98/Me. Here is sample code for creating a global symbolic link that works on Windows 98/Me as well as Windows 2000 and later operating systems.:
UNICODE_STRING deviceName; // already initialized. UNICODE_STRING symbolicLinkName; // initializing below. if (IoIsWdmVersionAvailable(1, 0x10)) { // We're on Windows 2000 or later, so we use \DosDevices\Global. RtlInitUnicodeString(&symbolicLinkName, L"\\DosDevices\\Global\\SymbolicLinkName"); } else { // Windows 98/Me. We just use DosDevices. RtlInitUnicodeString(&symbolicLinkName, L"\\DosDevices\\SymbolicLinkName"); } IoCreateSymbolicLink(&symbolicLinkName, &deviceName);A driver can create MS-DOS device names in a local \DosDevices directories by creating the symbolic link in response to an IOCTL. When a process in a particular local DosDevices context sends the IOCTL, the driver's DispatchDeviceControl is called from within the current process context.
For more information about the context in which a standard driver routine executes, see Dispatch Routines and IRQLs.
The system distinguishes local \DosDevices directories as follows:
- On Windows XP and later, local \DosDevices directories are identified by the AuthenticationID for the logon session's access token. For more information about the AuthenticationID, see the TOKEN_STATISTICS structure in the Platform SDK documentation.
- On Windows 2000, local \DosDevices directories are identified by the SessionId for the terminal server session. For more information about the SessionId, see the WTS_SESSION_INFO structure in the Platform SDK documentation.
No comments:
Post a Comment