Global Semaphore ignores local Semaphore - windows

Question

I have an application that accesses some files and system ressources, so there may only be one instance of the application active. That is accomplished by creating a named Semaphore and stopping the applicationrun when the Semaphore is already assigned.
In the past (read: when Windows XP was the most common Operating System) that worked well, but now we noticed that the old code did not work with multiple user sessions.
Here the old code:
hInstanceSem := CreateSemaphore(nil, 0, 1, PChar(GetProductName(Application.ExeName)));
if (hInstanceSem <> 0) and (GetLastError = ERROR_ALREADY_EXISTS) then
// do not run the Application
So I did some research, learned about global Semaphores and changed the code to this:
function CreateGlobalSemaphor(SemaphorName: String): Cardinal;
var
desc: SECURITY_DESCRIPTOR;
att : TSecurityAttributes;
sem : Cardinal;
begin
att.nLength := SizeOf(TSecurityAttributes);
att.bInheritHandle := true;
att.lpSecurityDescriptor := #desc;
InitializeSecurityDescriptor(att.lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(att.lpSecurityDescriptor, True, nil, False);
sem := CreateSemaphore(#att, 0, 1, PChar('Global\' + SemaphorName));
if (sem <> 0) and (GetLastError() <> ERROR_ALREADY_EXISTS) then begin
Result := sem;
end else begin
Result := 0;
CloseHandle(sem);
end;
end;
if CreateGlobalSemaphor(GetProductName(Application.ExeName)) = 0 then
// do not run the Application
Now, when I start the application on User1, change to User2 and try starting the Application, it will not run (as intended).
BUT when I run an older version of my program and start the current version with the new code in the same user session, the new code ignores the Semaphore created by the older code and a second instance of my application is started. (Needless to say that it crashes...)
It seems to me that the local Semaphore is out of the scope of the global Semaphore, else a second object with the same name could not be created.
My question is: How can the global Semaphore (new code) detect, that a local Semaphore (old code) with the same name is already assigned?
Please keep in mind that this is a problem of backward compatibility. I cannot simply recompile and redistribute the older versions of my application.

Answer 1

The documentation for kernel object namespaces explains that:
For processes started under a client session, the system uses the session namespace by default.
Since the old program does not explicitly include a namespace, the session namespace, Local\ is used. This means that the old program creates a semaphore named Local\xxx. Now, the new program uses a semaphore named Global\xxx. So you have two distinct semaphores and the programs are completely unaware of themselves.
If you want the new program to interact with the old program, you must use an object named Local\xxx.
If you wish the new program to block other new programs in different sessions, you must use an object named Global\xxx.
The obvious conclusion to draw here is that you need to create two objects. One named Local\xxx and one named Global\xxx.
Note that it is not possible to backfit cross-session exclusion to the existing programs. They already use Local\xxx and there's no way to you to change that now.
You must also fix the error handling in your new code. You call CreateSemaphore and then go on to call GetLastError without first checking the value returned by the call to CreateSemaphore.