Global name of createevent and openevent event

Today, I read other people's code and noticed the following when operating the event object:
Sprintf (ctemp, "Global \ Event _ % s", lpfilename );
M_hmapevent = openevent (event_all_access, false, ctemp );

Note: No. A global is added before the event object name, so that the global is added randomly. You can change it to other characters. Later, you can refer to msdn and Google, only then can we find that this global has a lot to come!

Global \ xxxevent ensures that the specified name is global when the nametime object is created.
The benefits of doing so are as follows:
The kernel object created in this way can be opened and used by the application layer no matter whether it is out of service or in the kernel.
Createevent (null, false, false, "Global \ csapp"); this is a kernel object.
============
The classification of event objects between service programs and common desktop applications is discussed as follows:
1. Create an event in a common desktop application and open the event in the Service Program
XP
Create in a common desktop application:
M_hevent =: createevent (null, false, false, text ("{67bde5d7-c2fc-49f5-9096-c255ab791b75 }"));
Enable and enable it as a signal in the service program:
Handle hevent =: openevent (event_all_access, false, text ("{67bde5d7-c2fc-49f5-9096-c255ab791b75 }"));
DWORD dwerr =: getlasterror ();
: Setevent (m_hevent );
Vista
A problem in Vista is that, if it is written as above, when the service program opens the event object, the error "the system cannot find the specified file .", The reason is that the namespace of the kernel objects created by the service programs and Applications in XP is global by default, but not in Vista. The kernel objects created by the service are under session0 by default, the kernel objects created by the user are under their respective sessions by default (session1, session2 ......), The solution to this problem is simple, that is, when creating a nametime object, the specified name is global, that is, set the last parameter of createevent and openevent to text ("Global \ {67bde5d7-c2fc-49f5-9096-c255ab791b75 }").
2. Create events in the service program, and open events in common desktop applications
The following is not a systematic explanation, but a fundamental issue.
Create in the service program:
M_hevent =: createevent (null, false, false, text ("{67bde5d7-c2fc-49f5-9096-c255ab791b75 }"));
Open in a common desktop application:
Handle hevent =: openevent (event_modify_state, false, text ("{67bde5d7-c2fc-49f5-9096-c255ab791b75 }"));
: Setevent (hevent );
The above Code does not work normally. When an event object is opened in a common desktop application, an error "Access Denied" is returned .", The obtained event handle is null because the kernel object created in the service program cannot be opened by the desktop program by default, each kernel object has access control, and the kernel object created in the service has a high permission. When the lpsecurity_attributes parameter is null, the default access control is used. A common desktop application naturally has no access permission. The solution is as follows: when a service program creates an event object, specify a security descriptor.
// Set security_descriptor
Security_descriptor secutitydese;
: Initializesecuritydescriptor (& secutitydese, security_descriptor_revision );
: Setsecuritydescriptordacl (& secutitydese, true, null, false );
Security_attributes securityattr;
// Set security_attributes
Securityattr. nlength = sizeof security_attributes;
Securityattr. binherithandle = false;
Securityattr. lpsecuritydescriptor = & secutitydese;
M_hevent =: createevent (& securityattr, false, false, text ("{67bde5d7-c2fc-49f5-9096-c255ab791b75 }"));
In this way, it is no problem for a common desktop application to open the event object again. (Note: The name of the event object in Vista must still specify the global space)
In addition, we will talk about the session in Windows programming, which has encountered some very depressing problems recently. I have been tossing the problem of starting the process of the service program under Vista. I have a little bit of experience. I want to help my friends who have encountered the same problem. In Windows XP and Vista, the service programs run in session0, While 1st, 2 ,... and n users run in session1, session2 ,... and sessionn. Different sessions have different namespaces, but we do not feel these differences because Windows XP, a mainstream user, supports Fast User Switching.
In XP, the processes started with sevice are similar to those started with the current user in programming. But in Vista, the situation is different. Vista's new security mechanism strengthens the restrictions between different sessions. Some named kernel objects, such as the use of event, in process 1 (in session1) for Process Communication, I created a named event object, then, the event is detected in process 2 (started by my service, so it runs in session0) and the error message is "the system cannot find the specified file." In addition, a small program is specially written for detection (directly running, also running in session1), but it can be detected.
Later, I carefully read the "Kernel Object Name spaces" Information in msdn to understand some kernel objects named, such as: events, semaphores, mutexes, waitable timers, file-mapping objects and job objects all exist only in their own namespaces. Different sessions are caused by different namespaces. For more information, see the description of the lpname parameter in the createevent document in msdn.
You can refer to the "Kernel Object Name spaces" in msdn (it's okay to post something in msdn, and msdn is King ):

Kernel Object Name Spaces
A remote desktop services server has multiple namespaces for the following named kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects. there is a global namespace used primarily by services in client/server applications.
In addition, each client session has a separate namespace for these objects, such as in Windows Vista.

The separate client session namespaces enable multiple clients to run the same applications without interfering with each other. for processes started under a Client Session, the system uses the session namespace by default. however, these processes can use
The global namespace By prepending the "Global \" prefix to the object name. For example, the following code CILS createevent and creates an event object named csapp in the global namespace:

Createevent (null, false, false, "Global \ csapp ");

Service applications in a remote desktop services environment use the global namespace by default.

Session zero is only used for hosting services, and there is no console session, unlike previous versions of Windows.

The global namespace enables processes on multiple client sessions to communicate with a service application. for example, a client/server application might use a mutex object for synchronization. the server component can create the mutex object in the global
Namespace. Then a client session can use the "Global \" prefix to open the mutex object.

Another use of the global namespace is for applications that use named objects to detect that there is already an instance of the application running in the system running SS all sessions. this named object must be created or opened in the global namespace instead
Of the per-session namespace. The more common case of running the application once per session is supported by default because the named object is created in a per session namespace.

In addition to the "Global \" prefix, client processes can use the "local \" prefix to explicitly create an object in their session namespace. These keywords are case sensitive.

The "session \" prefix is reserved for system use and you shoshould not use it in names of kernel objects.

Fast User Switching is implemented by using Remote Desktop Services sessions. the first user to log on uses session one, the next user to log on uses session two, and so on. kernel Object names must follow the guidelines outlined for Remote Desktop Services
So that applications can support multiple users.

The creation of a file-mapping object in the global namespace, by using createfilemapping, from a session Other than session zero is a privileged operation. because of this, an application running in an arbitrary remote desktop Session host (rd Session host)
Server session must have secreateglobalprivilege enabled in order to create a file-mapping object in the global namespace successfully. the Privilege Check is limited to the creation of file-mapping objects, and does not apply to opening existing ones. for
Example, if a service or the system creates a file-mapping object, any process running in any session can access that file-mapping object provided that the user has the necessary access.

[Reprint] http://hi.baidu.com/mikenoodle/item/06b069869bec6ccdee083d71