Object Manager: Difference between revisions

Content deleted Content added
mNo edit summary
m Fixed typo
 
(8 intermediate revisions by 6 users not shown)
Line 1:
{{Short description|Windows NT subsystem}}
{{Refimprove |date=March 2019}}
{{About|the Windows Executive subsystem|the general concept|Object manager}}
{{Refimprove |date=March 2019}}
[[File:Object Manager (Windows) screenshot.png|thumb|Object Manager in Windows, categorized hierarchically using ''namespaces'']]
'''Object Manager''' (internally called '''Ob''') is a subsystem implemented as part of the [[Windows Executive]] which manages Windows ''resources''. Resources, which are surfaced as logical ''objects'', each reside in a namespace for categorization. Resources can be physical devices, files or folders on volumes, [[Windows Registry|Registry]] entrieskeys or even running processes. All objects representing resources have an <code>Object Type</code> property and other metadata about the resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager.
 
==Architecture==
Line 9 ⟶ 11:
Objects can either be ''Kernel objects'' or ''Executive objects''. Kernel objects represent primitive resources such as physical devices, or services such as synchronization, which are required to implement any other type of OS service. Kernel objects are not exposed to [[user mode]] code, but are restricted to kernel code. Applications and services running outside the kernel use ''Executive objects'', which are exposed by the [[Windows Executive]], along with its components such as the memory manager, scheduler and I/O subsystem. Executive objects encapsulate one or more kernel objects and expose not only the kernel and kernel-mediated resources, but also an expanded set of services that the kernel does.{{clarify|date=January 2019}} Applications themselves can wrap one or more Executive objects and surface objects{{Definition needed|date=January 2019}} that offer certain services. Executive objects are also used by the environment subsystems (such as the Win32 subsystem, the OS/2 subsystem, the POSIX subsystem, etc.) to implement the functionality of the respective environments.
 
Whenever an object is created or opened, a reference to the instance, calledknown as a ''handle'', is created. The Object Manager indexes the objects by both by their names as well as theand handles. But, referencing theReferencing objects by the handles is faster becausesince theit bypasses name translation can be skipped. Handles are associated with processes (by making an entry intoin the process's ''Handle table'', thatwhich lists the handles it owns), and can be transferred between processes as well. A process must own a handle to an object beforeto usinguse it., A processand can own aup maximum ofto 16,000,000 handles at one time. During creation, a process gains handles to a default set of objects. WhileThere there existsare different types of handles, -such as ''file handles'', ''event handles'', and ''process handles'', -which they only help in identifyingidentify the type of the target objects; but do not in distinguishingdistinguish the operations that can be performed through them, thus. providingThis consistency toensures uniform howhandling of various object types are handled programmatically. Handle creation and resolution of objects from handles are solelyexclusively mediatedmanaged by the Object Manager, soensuring that no resource usage goes unnoticed by it.
 
The types of Executive objects exposed by Windows NT are:
Line 34 ⟶ 36:
|-
!File
| An open [[fileFile (computing)|file]], [[Directory (computing)|directory]] or an [[I/O]] device.
|NtCreateFile<br />NtOpenFile
|-
Line 42 ⟶ 44:
|-
!Access token
| The identity, properties, privileges and access rights forof a process anor objectthread.
|NtCreateToken<br />NtDuplicateToken<br />NtOpenProcessToken<br />NtOpenThreadToken
|-
Line 54 ⟶ 56:
|-
!Timer
| An objectsobject which notifies processes at fixed intervals.
|NtCreateTimer<br />NtOpenTimer
|-
!Key
| A [[Windows Registry|registry]] key.
|NtCreateKey<br />NtOpenKey
|
|-
!Desktop
Line 83 ⟶ 85:
A <code>Type</code> object contains properties unique to the type of the object as well as static methods that implement the services offered by the object. Objects managed by Object Manager must at least provide a predefined set of services: <code>Close</code> (which closes a handle to an object), <code>Duplicate</code> (create another handle to the object with which another process can gain shared access to the object), <code>Query object</code> (gather information about its attributes and properties), <code>Query security</code> (get the [[security descriptor]] of the object), <code>Set security</code> (change the security access), and <code>Wait</code> (to synchronize with one or more objects via certain events). Type objects also have some common attributes, including the type name, whether they are to be allocated in non-paged memory, access rights, and synchronization information. All instances of the same type share the same type object, and the type object is instantiated only once. A new object type can be created by endowing an object with Properties to expose its state and methods to expose the services it offers.
 
<code>Object name</code> is used to give a descriptive identity to an object, to aid in object lookup. Object Manager maintains the list of names already assigned to objects being managed, and maps the names to the instances. Since most object accesses occur via handles, it is not always necessary to look up the name to resolve into the object reference. Lookup is only performed when an object is created (to make sure the new object has a unique name), or a process accesses an object by its name explicitly. <code>Object directories</code> are used to categorize them according to the types. Predefined directories include <code>\??</code> alias <code>\DosDevices</code> (device names), <code>\BaseNamedObjects</code> (Mutexesmutexes, events, semaphores, waitable timers, and section objects), <code>\Callback</code> (callback functions), <code>\Device</code>, <code>\Driver</code>, <code>\FileSystem</code>, <code>\KnownDlls</code>, <code>\Nls</code> (language tables), <code>\ObjectTypes</code> (type objects), <code>\RPC Control</code> ([[Remote Procedure Call|RPC]] ports), <code>\Security</code> (security subsystem objects), and <code>\Windows</code> (windowing subsystem objects). Objects also belong to a ''Namespace''. Each user session is assigned a different namespace. Objects shared between all sessions are in the ''GLOBAL'' namespace, and (logon) session-specific objects are in the specific (logon) session namespaces
 
OBJECT_ATTRIBUTES structure:
Line 107 ⟶ 109:
 
== Usage ==
Object Manager paths are available to many Windows API file functions, although Win32 names like {{tt|\\?\}} and {{tt|\\.\}} for the local namespaces suffice for most uses.<ref>{{cite web |title=Naming Files, Paths, and Namespaces - Win32 apps |url=https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file |website=docs.microsoft.com |date=28 August 2024 |language=en-us}}</ref> Using the former in Win32 user-mode functions translates directly to {{tt|\??}}, but using {{tt|\??}} is still different as this NT form does not turn off pathname expansion.<ref>{{cite web |title=winapi - Is there a difference between \??\ and \\?\ paths? |url=https://stackoverflow.com/questions/25090101/is-there-a-difference-between-and-paths |website=Stack Overflow}}</ref>
 
Tools that serve as explorers in the Object Manager namespaces are available. These include the 32-bit WinObj from [[Sysinternals]]<ref>{{cite web |title=WinObj - Windows Sysinternals |url=https://docs.microsoft.com/en-us/sysinternals/downloads/winobj |website=docs.microsoft.com |date=26 July 2023 |language=en-us}}</ref> and the 64-bit WinObjEx64.<ref>{{cite web |title=hfiref0x/WinObjEx64: Windows Object Explorer 64-bit |url=https://github.com/hfiref0x/WinObjEx64 |website=GitHub |date=20 February 2020}}</ref>
==See also==
*[[Architecture of Windows NT]]