From: Le Chaud Lapin on 20 Apr 2010 15:06
I have what might be a common problem.
[Note that I never bother to study in any detail the Windows security
model, so my terminology, perception, etc. might be incorrect.]
In my distributed system, I normally have an application, Client.exe,
that must talk to Server.exe, via named
shared memory. There is a one-to-one correlation between "users" on a
Windows machine and Client.exe/Server.exe pairs. For 7 logged-in
users, there would be 7 pairs. My shared memory, and all other named
kernel objects, are created with the omission of "\\global", so as to
take advantage of automatic disambiguation provided by the kernel
It turns out that, in some cases, Client.exe is actually Client.dll,
an ISAPI DLL.
My goal is to find the technically correct method for having
Client.dll talk to Server.exe while taking into account the potential
plurality of logins and web servers running on the same machine.
Obviously, running Server.exe under a normal login while letting ISAPI
load Client.DLL will cause Client.dll to reference objects in the
kernel space different from those referenced by Server.exe.
My guess is that adding some code into Client.dll to launch Server.exe
via CreateProcess from Clien.dll will, at least, allow Client.DLL to
share same namespace as Server.exe.
1. Will the CreateProcess method work?
2. If so, is there a command line launch opportunity from within the
context of Client.DLL? I would rather not put code in Client.DLL just
to launch the companion Server.exe.
3. What login/account/security/etc. model do hosting providers use to
allow, say, 10 customers to share one IIS instance? What happens when
each of 10 web sites uses an ISAPI DLL to invoke
CreateMutex("SomeName")? What elements will I have to allow
-Le Chaud Lapin-