As you’ll see, we released 3 new versions of The Server Framework today. Of these, only the 7.3 release includes code changes. The 7.2 release updates almost every header file in the framework to remove ‘old style’ include guards and touches lots of source files to remove lint directives that we no longer use. This kind of change creates a lot of noise in an update and so it has been done separately to the functional changes to make it easier for users of the framework to see what has actually been changed in 7.
Visual Studio Update 3 adds some new warnings for precompiled header generation. One of these, C4598, will prevent precompiled header builds of framework code due to our warnings as errors policy.
A fix for this issue is to add the new warning to the list of disabled warnings in the project file. The easiest way to do this is to do a search and replace across your source tree for *.
I hinted at the end of the last post that the 6.7 release might increase performance a little. Well, whilst the bulk of the changes in 6.7 are purely code cleaning and the removal of legacy support there is a fairly major functional change as well.
In most situations references or pointers to I/O buffers have been replaced with smart pointers. This change may cause some issues during an upgrade as you need to change some function signatures from IBuffer refs to CSmartBuffers.
We’ve only just shipped Release 6.6.5 of The Server Framework but we already have another release that’s just about to ship. This isn’t because some horrible bug has slipped through our testing, it’s because we’ve been planning to produce a ‘clean up’ release for some time. 6.7 is that release.
Lets be straight here, 6.7 is a release for us more than for you. The aim is to simplify our build/test and release process, remove dead code whilst introducing no new bugs and removing no functionality that you rely on.
Last week I learnt something new, which is always good. Unfortunately it was that for over 15 years I’d been working under a misconception about how an API worked.
TL;DR When using WSARecv() and WSASend() from multiple threads on a single socket you must ensure that only one thread calls into the API at a given time. Failure to do so can cause buffer corruption.
It all began with this question on StackOverflow and I dived in and gave my usual response.
The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Visual Studio 2005 or Visual Studio 2008.
The 6.6.x releases will be the last to support these compilers.
Please get in touch immediately if this will be a problem for you.
The 7.0 release of The Server Framework, which is likely to be released early next year, will no longer support Windows XP or Windows Server 2003.
The 6.6.x releases will be the last to support these operating systems. Release 6.6.3, is due shortly and is a minor bug fixing release. We may release subsequent 6.6.x bug fix releases but no new development will occur on the 6.6 branch.
Removal of support for these operating systems allows us to clean up the code considerably and to remove lots of code that’s required purely to work around ‘interesting’ twists in various Windows APIs pre-Vista.
We have a new Option Pack, The Streaming Media Option Pack. This allows you to easily add streaming of H.264 and MPEG audio and video to your clients and servers using RTSP, RTP and RTCP.
With more and more Internet Of Things devices supporting rich media streaming for remote monitoring it’s becoming essential to have the ability to manage these media streams within your device management servers and clients. Whether it’s recording device streams for later analysis or arbitrating between multiple clients and devices, manipulating streaming media is becoming more and more important.
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.
