|Powered by QM on a Rpi server|
KnowledgeBase 00008: Windows Kernel Namespace
QM 2.8-5 changes the way in which QM manages shared memory on Windows systems. One impact of this change is that, except when using the self-contained USB installation of QM, the QMSvc service must be running for QM to work.
A Windows process normally lives in its own address space where its memory is private and cannot be seen by other processes. Windows also supports the concept of shared memory where an application can request that a portion of its memory space is shared with other processes such that values written by one process can be seen by another. QM uses shared memory to store the locking tables, information about open files, and much more.
A shared memory area in Windows is identified by a name in much the same way as a file and it can have access permissions attached to it. One process creates the shared memory area and other processes can then attach to it by referencing the name. The Windows version of QM has always operated such that the first user to login creates the shared memory and subsequent users then attach to it. Unlike Linux, a shared memory area in Windows is automatically deleted when the last process using it terminates. In QM, this will be when the last user logs out. The next user to login will create the shared memory again.
A typical Windows system might have many shared memory areas used by different applications, each with their own name. Regardless of how a QM process starts (QMConsole, telnet, QMClient, etc) it needs to see the shared memory in use by any other QM processes on the system.
What has Changed?
Microsoft introduced a change in a service update to Windows XP and in later versions of Windows such that shared memory names are not necessarily shared across all processes. Instead, there is a concept of a kernel namespace where names have relevence much like applying scope to variables in programs. The impact of this is that two QM sessions running in different namespaces will create separate instances of the shared memory resulting in it not being shared at all.
The way in which processes are assigned to namespaces depends on how they are started and differs between versions of Windows. Although the problem can occur on earlier versions of Windows, it has become far more serious with Windows Vista. In particular, processes started by the QMSvc service tend to be in a different namespace than processes started from the console. Use of Remote Desktop also creates a new namespace.
There has been much complaint about this change on internet user groups. It could have been introduced in a way which was backward compatible to ensure that existing applications continued to run but it was not.
Why is this a Problem?
If two QM processes are using separate namespaces they will both create a shared memory area. These two (or more) areas will hold separate copies of the locking tables, file management tables, etc. The impact of this is that there is the potential for file corruption both at the data and structural level because the processes do not know about each other.
What has to Change in QM?
The changes within Windows include provision of a global namespace such that it is still possible for processes to share memory as they did in earlier releases. Unfortunately, creation of a global shared memory area can only be performed from a highly privileged process such as a Windows service. In QM, this means that QMSvc must create the shared memory before any other QM process starts and must stay running while users are in QM.
What is the Impact on my Application?
Nothing changes in your application software. The only difference visible to QM users is that the QMSvc service must be running before users can log into QM. This is very similar to the way in which QM has to be started on other platforms before it can be used.
Stopping QMSvc will log out all QM users.
What about Windows 98/ME?
Windows 98/ME use QMSrvr instead of QMSvc. These platforms do not have the namespace problem described above. QMSrvr does not need to be running before users can connect.
How is the Self Contained USB Version Affected?
Because the USB version of QM cannot run a service, it is not possible for it to create a global shared memory area. Therefore, the underlying problem introduced by this change in Windows will continue to affect USB users. This is not seen as a problem as it is unlikely that such a system would use QMConsole via Remote Desktop.