Hello, I’m new to kernel programming and am learning my way around WDK at the moment.
I wanted to know the difference between a handle and a symbolic link.
We use a handle to a Device Object with a client (usermode processes,calls etc)
The definition of a symbolic link directly taken from _Windows Kernel Programming by Pavel Yosifovich _ is: _“More precisely, CreateFile accepts a symbolic link, a kernel object that knows how to point to another kernel object.” _
He further goes on to say: “All the symbolic links that can be used from user mode CreateFile or CreateFile2 call are located in the Object Manager directory named ??. This can be viewed with the Sysinternals tool WinObj.”
So a handle is a bridge between a client and Device object (I know that a handle is somewhat a pseudo-pointer)and a symbolic link can be used for the same?
What am I missing here?
Any resources linked to help me learn about driver dev would help too.
Appreciate your time.
I wanted to know the difference between a handle and a symbolic link.
To put it simply, symlink is the input parameter to CreateFile() call that can be used instead of the target file’s/device’s name, and a handle is the output one that can be used in the subsequent calls that actually access to the target device/file. Simple,ugh…
Well it looks like the OP is confused because there are several kinds of symbolic links.
Object manager symlinks are described here.
Filesystem symbolic links are something different (and now we have also the Linux symlinks in the WSL filesystem).
And the registry has its own kind of links. So be kind on the noob, gentlemen.
In the driver world, a symbolic link is just a name that points to another name. Your driver name string is in a kernel namespace that cannot be accessed by user code. So, you create a symbolic link in a user-mode-accessible space (like \DosDevices) that also points to your device. The recommended method, using device interfaces, also ends out creating symbolic links, but they’re managed by the kernel.
But it’s still just a string, just like the name of a file. Having the symbolic link doesn’t let you submit requests to the driver. To access a driver, you have to have a handle, exactly like opening a file. To get a handle from a symbolic link, you use CreateFile.
I will be very happy to help the noob, if he/she describes clearly what they want to know… and demonstrates that they’ve done at least some rudimentary searching before asking here.
Well it looks like the OP is confused because there are several kinds of symbolic links. Object manager symlinks are described here.
Filesystem symbolic links are something different (and now we have also the Linux symlinks in the WSL filesystem).
And the registry has its own kind of links.
At the risk of invoking “The Hanging Judge’s” wrath I have to point out that this directly results from the fundamental architectural fallacies, shortcomings and deficiencies of the Windows kernel design (in this particular context, from the lack of VFS, as well as of a clear separation of mechanisms and policies. The only thing that comes to my mind in this context is a saying that “Those who don’t understand UNIX are doomed to reinvent it…poorly”
So be kind on the noob, gentlemen.
Well, as some posters are so fond of saying, we were all inexperienced once, right…
Kuranes,
I suggest you to read more about the Object Manager in Windows.
Windows executive objects can be named in the Object Manager namespace - This namespace is composed of named objects (such as mutex, section, devices). The reason such namespace exists is to allow lookup of objects at runtime by name. The object namespace is global to the whole system. In contrast, a handle is an object manager mechanism to access an object by a value that is unique to a specific process, by looking up this value in the process handle table. One reason handles exist is to allow a user mode caller to perform operations on executive objects in kernel mode.
For example, let’s say you want to open a section object that was created by another process. At that point you don’t have a handle to the section object, but you want to create a handle that can be used later. Let’s say that when the section was created (for example, by calling CreateFileMappingA. FileMapping is the win32 name of section objects) the caller gave this section a name. This means that the section has a name in the object manager namespace. Now your process can create a handle to the same section object by calling OpenFileMappingA. After the handle was created, this handle can be used to perform operations on that section such as MapViewOfFile.
A symbolic link is an object that redirects to another object name - similar to file system symbolic links but in the object manager namespace. As a driver developer you typically create a symbolic link to a device object to allow a user mode caller that uses the Win32 API to access the device. This is explained here:
To make these device objects accessible by Windows applications, the device drivers create a symbolic link (symlink) in the Win32 namespace, “Global??”, to their respective device objects. For example, COM0 and COM1 under the “Global??” subdirectory are simply symlinks to Serial0 and Serial1, “C:” is a symlink to HarddiskVolume1, “Physicaldrive0” is a symlink to DR0, and so on. Without a symlink, a specified device “Xxx” will not be available to any Windows application using Win32 namespace conventions as described previously. However, a handle could be opened to that device using any APIs that support the NT namespace absolute path of the format “\Device\Xxx”.
Windows executive objects can be named in the Object Manager namespace - This namespace is composed of named objects (such as mutex, section, devices). The reason such namespace exists is to allow lookup of objects at runtime by name. The object namespace is global to the whole system. In contrast, a handle is an object manager mechanism to access an object by a value that is unique to a specific process, by looking up this value in the process handle table. One reason handles exist is to allow a user mode caller to perform operations on executive objects in kernel mode.
For example, let’s say you want to open a section object that was created by another process. At that point you don’t have a handle to the section object, but you want to create a handle that can be used later. Let’s say that when the section was created (for example, by calling CreateFileMappingA. FileMapping is the win32 name of section objects) the caller gave this section a name. This means that the section has a name in the object manager namespace. Now your process can create a handle to the same section object by calling OpenFileMappingA. After the handle was created, this handle can be used to perform operations on that section such as MapViewOfFile.
A symbolic link is an object that redirects to another object name - similar to file system symbolic links but in the object manager namespace. As a driver developer you typically create a symbolic link to a device object to allow a user mode caller that uses the Win32 API to access the device. This is explained here:
To make these device objects accessible by Windows applications, the device drivers create a symbolic link (symlink) in the Win32 namespace, “Global??”, to their respective device objects. For example, COM0 and COM1 under the “Global??” subdirectory are simply symlinks to Serial0 and Serial1, “C:” is a symlink to HarddiskVolume1, “Physicaldrive0” is a symlink to DR0, and so on. Without a symlink, a specified device “Xxx” will not be available to any Windows application using Win32 namespace conventions as described previously. However, a handle could be opened to that device using any APIs that support the NT namespace absolute path of the format “\Device\Xxx”.