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.

I’ve been a big fan of Gimpel Lint for years. It’s a great static analysis tool for C++ and it can locate all kinds of issues or potential issues in the code. My problem with it has always been that it’s a bit of a pig to configure and run, more so if you’re used to working inside an IDE all the time. Several years back I had some custom Visual Studio menu items that I’d crufted up that ran Gimpel Lint on a file or a project and some more cruft that converted the output to something clickable in the IDE’s output pane.

I’ve been working on some code for a client recently that needs to run in a multi-threaded environment. Unfortunately it was never really written with that requirement in mind, or, more likely, the people who wrote the code knew that it needed to be accessed from multiple threads but didn’t really understand quite what that meant. As such I’m doing some fairly hairy refactoring for them. It’s high risk as there are no unit tests and the budget doesn’t really extend to completing the work, let alone “spending extra time” writing unit tests… The code is written in quite a ‘C’ style, most things are simple structs and most data is public and as such member functions fall where they are most conveniently written.

This article over on Preshing on Programming looks useful. It gives a step by step guide for building GCC cross-compilers, I expect it will save me lots of time at some point in the future.

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.

I’ve been noticing a strange thing for a while on Windows 8/8.1 and the equivalent server versions. The issue occurs when I’m using a Slim Reader/Writer Lock (SRWL) exclusively in exclusive mode (as a replacement for critical sections). What happens is, when a thread that has just unlocked a SRWL exits cleanly, immediately after unlocking the lock, sometimes threads that are waiting on the lock do not get woken and none of them acquire the lock.

We have a new client profile available here for a new client who is using The Server Framework to power their MMORPG game server.

We’re pleased to be working with Eonic Gaming in the development of the server for their Turf Battles Triumphus 3D MMORPG. Eonic have selected us to replace their existing networking code with The Server Framework to improve the stability and performance of their server.