We've released new versions of both our Lock Inversion Detector, LID and our Lock Inversion Analyser, LIA today.

This release fixes a problem when running LIA against an executable which has been compiled with Frame Pointer Omission enabled. This causes some call stacks to be reported as zero length and we were failing to treat these correctly which led to a vast number of duplicate lock sequences being created. Also a bug has been fixed in LIA which caused it to fail to use symbol paths supplied on the command line when looking up symbols.

We've also added several new command line switches to LIA to enable you to ignore inversions that occur in specific dlls, limit the number of lock inversions reported, ignore stack frames which are shorter than a configurable length and force slower but more reliable call stack collection to be used.

All customers are being contacted via email with details of how to obtain the latest release of LIA and you can download the latest version of LID from here (if you've already registered for the updates mailing list then simply reply to the email notification and we'll send you the latest version).

Do continue to get in touch with comments and suggestions and any problems that you have.

We have a new client profile available here for a client who uses The Server Framework in their Printer presence and print job transfer system.

They use both the OpenSSL Option Pack and the SSPI Option Pack in their product. The ease of adding security and authentication which can communicate with a disparate selection of clients is one of the strong points of developing with The Server Framework.

Version 6.6 of The Server Framework was released today.

This release is a major release and contains many changes, see the release notes, here, for full details of all changes.

All clients are advised to upgrade to this release.

• Increased performance due to major design changes in the dispatch and processing of completion and per socket buffer pooling.
• New lock classes which offer more efficient locking.
• Lots of breaking changes in the Service Tools library.
• The removal of deprecated compilers and operating systems and the addition of support for Visual Studio 2013 and Windows 8.1
• Added support for Out of Band data, TCP "Urgent mode".

The latest release of The Server Framework, which is due later this month, adds support for Visual Studio 2013 and Windows 8.1 as well as a host of other major changes.

As we first mentioned here, release 6.6 of The Server Framework removes support for Visual Studio .Net (2002) and Visual Studio .Net (2003). The 2002 compiler is no longer supported by Microsoft and the 2003 compiler becomes unsupported in October this year. To be honest, I'm very pleased to see the back of them. Hopefully most users of the framework are using at least Visual Studio 2005, if you're not, get in touch now.

We're also dropping support for Windows 2000, which Microsoft stopped supporting in 2010 this means the Windows XP is the earliest supported operating system for version 6.6.

Finally we're deprecating quite a bit of code. This will still be present in 6.6 but will, generally, be unavailable by default. You can add various defines to your Config.h to re-enable the deprecated code but be warned, it will be going in a future release.

The following code is deprecated in 6.6

• CInOrderBufferList - use a CSortedBufferChain and a CBufferProcessor instead.
• CSequentialBufferList - use a CSortedBufferChain and a CBufferProcessor instead.
• The entire concept of "shared" locks, so CSharedCriticalSection, CSharedCriticalSectionFactory, CUniqueCriticalSectionFactory, ICriticalSectionFactory, ISharedCriticalSection, IManageSharedCriticalSections and CSmartSharedCriticalSection - the concept is no longer especially useful as the resource limitations and problems that existed with NT4 are now a thing of the distant past. However, since the code is still present in the framework people use it and end up with slower and more complex servers with contention between otherwise unrelated connections. Use the socket allocators that do NOT require lock factories as a replacement.
• Likewise the entire concept of "shared lock sockets" which require the above shared locks to work, so socket allocators no longer take lock factories as constructor arguments and CSharedLockDatagramServerSocket, CSharedLockDatagramSocket, CSharedLockStreamSocket and CSharedLockSequencedStreamSocket are also no longer available - but that's an implementation issue.
• CCriticalSection and CCriticalSection2 - use one of the new locks, CLockableObject or CReentrantLockableObject instead.
• CLowContentionBufferAllocator and CTLSBufferAllocator - use CBufferAllocator or CLockFreeBufferAllocator instead.
• CDeflatingStreamSocketConnectionFilter and the "deflate-stream" WebSockets extension - note that "deflate-stream" was dropped from the final WebSocket standard and is not generally used.

It seems that isprint() is broken.

The following program demonstrates the problem.

In VS20013 it prints "test failed" in all previous versions of visual studio it prints "test passed".

From this reference: http://en.cppreference.com/w/cpp/string/byte/isprint it seems that VS2013 is broken.

I've opened a Microsoft Connect issue for this.

#include <ctype.h>

#include <iostream>

int main()
{
   int c = 9;

   if (isprint(c))
   {
     std::cout << "test failed" << std::endl;
   }
   else
   {
     std::cout << "test passed" << std::endl;
   }

   return 1;
}