How to Create Inheritable Win32 Handles in Windows 95

Last reviewed: September 25, 1995
Article ID: Q118605

The information in this article applies to:

Microsoft Win32 Application Programming Interface (API) included with:
```
    - Microsoft Windows 95 version 4.0
```

SUMMARY

Sometimes it is convenient for you to create an object such as a semaphore or file and then allow a child process to inherit the object's handle. This provides a means for two or more related processes to easily share an object.

Although Windows 95 does not have a security system such as the one in Microsoft Windows NT, Win32 API functions that create objects still use the SECURITY_ATTRIBUTES structure to determine whether the handle to the newly created object can be inherited. This article shows how to initialize a SECURITY_ATTRIBUTES structure to control whether an object handle can be inherited.

MORE INFORMATION

Win32 API functions that create objects require a SECURITY_ATTRIBUTES parameter to give a newly created object access-control information and to determine whether the handle to the object can be inherited.

The SECURITY_ATTRIBUTES structure contains the following members:

    Type      Name
    ----      ----
    DWORD     nLength;
    LPVOID    lpSecurityDescriptor;
    BOOL      bInheritHandle;

Secure Win32 operating systems such as Microsoft Windows NT use the lpSecurityDescriptor member to enforce how and by which processes an object is accessed. Because Windows 95 does not have a security system, it ignores lpSecurityDescriptor. Like Microsoft Windows NT, Windows 95 uses the bInheritHandle member to determine whether an object's handle can be inherited by child processes.

To initialize a SECURITY_ATTRIBUTES structure so that a handle can be inherited, set bInheritHandle to TRUE. The following code snippet shows how to create a mutex with an inheritable handle:

      // Set the length of the structure, allow the handle to be
      // inherited, and use the default security descriptor (which
      // Windows 95 will ignore, but Windows NT will use.) Then create
      // a named, initially unowned mutex whose handle can be
      // inherited.

   SECURITY_ATTRIBUTES sa;
   HANDLE              hMutex1;

   sa.nLength              = sizeof(sa);
   sa.bInheritHandle       = TRUE;
   sa.lpSecurityDescriptor = NULL;

   hMutex1 = CreateMutex(&sa, FALSE, "MUTEX1");

To prevent the handle from being inherited, set bInheritHandle to FALSE. The following code example demonstrates creating a mutex with a noninheritable handle:

      // Set the length of the structure, do not allow the handle
      // to be inherited, and use the default security descriptor
      // (which Windows 95 will ignore, but Windows NT will use).
      // Create a named, initially unowned mutex whose handle cannot
      // be inherited.

   SECURITY_ATTRIBUTES sa;
   HANDLE              hMutex1;

   sa.nLength              = sizeof(sa);
   sa.bInheritHandle       = FALSE;
   sa.lpSecurityDescriptor = NULL;

   hMutex1 = CreateMutex(&sa, FALSE, "MUTEX1");

You can also prevent a handle to an object from being inherited by specifying NULL in the call to Win32 object creation API function instead of specifying a pointer to a SECURITY_ATTRIBUTES structure. This is equivalent to setting bInheritHandle to FALSE and lpSecurityDescriptor to NULL. For example:

      // Use NULL instead of pointer to SECURITY_ATTRIBUTES
      // structure to create a named, initially unowned
      // mutex whose handle cannot be inherited. A NULL security
      // descriptor will be used by Windows NT, but ignored by
      // Windows 95.

   HANDLE hMutex1;
   hMutex1 = CreateMutex(NULL, FALSE, "MUTEX1");

Cross-Platform Compatibility Information

Keep in mind that while Windows 95 does not have a security system, Windows NT does. Windows 95 ignores the lpSecurityDescriptor member of the SECURITY_ATTRIBUTES, but Windows NT uses it. If access to the object needs to be controlled in a specific way on Windows NT, then the lpSecurityDescriptor should be initialized by calling the Win32 security API functions.

Additional reference words: 4.00
KBCategory: kbprg
KBSubcategory: BseSecurity

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 25, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.