I have 2 applications sharing the same lock file, and I need to know when the
the other application has either locked/unlocked the file. The code below was
originally implemented on a Linux machine, and is being ported to Window 8, VS12.

I have ported all other code in the class successfully and am locking files with
LockFile(handle, 0, 0, sizeof(int), 0) and the equivalent UnlockFile(...). However, 
I am having trouble with the following wait() command.

```
bool devices::comms::CDeviceFileLock::wait(bool locked,
                                           int  timeout)
{
   // Retrieve the current pid of the process.
   pid_t pid = getpid();

   // Determine if we are tracking time.
   bool tracking = (timeout > 0);

   // Retrieve the lock information.
   struct flock lock;
   if (fcntl(m_iLockFile, F_GETLK, &lock) != 0)
      raiseException("Failed to retrieve lock file information");

   // Loop until the state changes.
   time_t timeNow  = time(NULL);
   while ((pid == lock.l_pid) 
          &&
          (lock.l_type != (locked ? F_WRLCK : F_UNLCK)))
   {
      // Retrieve the lock information.
      if (fcntl(m_iLockFile, F_GETLK, &lock) != 0)
         raiseException("Failed to retrieve lock file information");

      // Check for timeout, if we are tracking.
      if (tracking)
      {
         time_t timeCheck = time(NULL);
         if (difftime(timeNow, timeCheck) > timeout)
            return false;
      }
   }

   // Return success.
   return true;
}

```

Note: m\_iLockFile used to be a file descriptor from open(), it is now called
m\_hLockFile and is a HANDLE from CreateFile().

I cannot seem to find the Windows equivalent of the fcntl F\_GETLK command.
Does anyone know if I can either:
a) use an fcntl equivalent to interrogate locking information, to find out
which process has obtained the lock
b) suggest how the above can be re-written for Windows C++.

Note: The server application using the lock file is a standalone C++ executable,
however the client using the lock file is a WinRT Windows Application. So any
suggested solution cannot break the sandboxing of the client.

Thanks.