SRWLOCKdata. In such cases we would treat the two locks as the same lock when looking for lock inversions and this could cause us to report spurious inversions in some situations.
DuplicateHandle()API which is tracked as part of our support for tracking lock inversions which include Mutexes.
Back in January 2010 I discovered that if
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS is enabled on a datagram socket and a datagram arrives when a read is NOT currently pending and the datagram is bigger than the buffer supplied to the next read operation then no error is returned and the read will never complete. This was confirmed as a Windows bug and I'm pleased to see that it's been fixed in Windows 8 and Server 2012. It's still present in Windows 7 but that actually makes it easier to reason about the behaviour of the flag on the operating system that you're running on.
IShutdownServiceinterfaces. Many functions now return an
ServiceTools::ExitCode, either directly or by value, which allows you to fine tune the exit code returned from your service under failure conditions. This exit code is reported to the Service Control Manager (SCM) when your service shuts down and also returned from the exe if you run the service as a normal exe. These changes allow finer control of your service but can easily be completely ignored if you want things to stay the way they were.
CRITICAL_SECTIONobjects to using Slim Reader Writer Locks in exclusive (write) mode. You can read about the differences between these two locks in Kenny Kerr's MSDN article here. This change can't be applied to all uses of our
CCriticalSectionclass as SRW locks are not recursive and so we have a whole new locking class hierarchy with new
CLockableObjectlocks which use SRW locks on platforms that support it and drop back to using a
CRITICAL_SECTIONon XP and earlier. Then there's a
CReentrantLockableObjectwhich is, basically, a
CCriticalSectionwith a new name and a slightly new interface. There are also classes for locks which track the thread that owns them (just so that they can tell you if you currently have them locked) as we use that functionality in a couple of places in The Server Framework for optimising code paths.
WSAESHUTDOWNhas changed from "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous <b>shutdown</b> call." to "A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous <b>shut-down</b> call.". Now, apart from the new message being incorrect, it's not a "shut-down" it was a call to
shutdown(), the change has broken some of my (possibly too invasive and therefore fragile) tests!