Latest release of licensed socket server code: 5.2.2

| 0 Comments

The latest release of The Server Framework is now available. This release includes the following changes.

  • This is the first release built using Compuware BoundsChecker and there have been some resource leaks fixed.

The following changes were made to the libraries.

Admin Library - 5.2.2

  • Added JETBYTE_MINIMUM_SUPPORTED_WINDOWS_VERSION and JETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSION to Admin.h. These are currently set to _WIN32_WINNT_WIN2K and NTDDI_WIN2K.
  • Added JETBYTE_PLATFORM_SDK_VERSION which you can use to tell the libraries which version of the Platform SDK you're using. This allows us to work around some of the breaking changes that are introduced by some versions of the Platform SDK.
  • Added a copy of sal.h to the Admin\VC6Compatibility directory as it doesn't ship as part of the Platform SDK but some versions of the Platform SDK require it; this effectively means that VC6 can't be used with the latest versions of the Platform SDK. If you find that you're compiling with VC6 and you get errors about not being able to find sal.h then you can copy the file from Admin\VC6Compatibility to your VC6 include directory.
  • Added TargetWindowsVersion.h and associated target specific files. Either edit TargetWindowsVersion.h and change the values of JETBYTE_MINIMUM_SUPPORTED_WINDOWS_VERSION and JETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSION or copy TargetWindowsVersion_Vista.h or whatever over the top of TargetWindowsVersion.h to build for a specific windows version. We've done it this way so that our continuous integration build server can build for various targets simply by having a file copy job that copies the correct version over the top of TargetWindowsVersion.h after extracting the code from source control.
  • Adjusted the SecureCRT.h header again.
  • Some changes to WinsockWrapper.h for when JETBYTE_PLATFORM_SDK_VERSION == 0x0610 as version 6.1 of the Platform SDK does not define a SOCKADDR_STORAGE typedef for Windows versions of less than 0x0501. We warn about this and include our own typedef if this is the case.
Win32 Tools Library - 5.2.2
  • Fixed a bug in JetByteTools::Win32::IsAllDigits(), it now actually works, before it always returned true.
  • Fixed memory leak in JetByteTools::Win32::GetCurrentDirectory(). We were using std::auto_ptr to attempt to delete an array of memory and we need delete[] rather than delete. Now use a string for the buffer.
  • Only include JetByteTools::Win32::GetSystemWow64Directory() if the underlying OS supports it. Otherwise we throw an exception.
  • Fixed a memory leak in JetByteTools::Win32::GetFileVersion(). Once again we were using std::auto_ptr for an array.
  • Added JetByteTools::Win32::CopyFile().
  • Added JetByteTools::Win32::CreateGUIDAsString().
  • Changed JetByteTools::Win32::FileExists(), JetByteTools::Win32::LoadFileAsUnicodeString(), JetByteTools::Win32::LoadFileAsStringA() to open the file with FILE_SHARE_READ access.
  • Fixed a shutdown race condition in JetByteTools::Win32::CThreadPool which could have caused a thread to callback into the pool after the pool had been destroyed.
  • Added JetByteTools::Win32::CThreadedCallbackTimerQueue::GetMaximumTimeout() and JetByteTools::Win32::CCallbackTimerQueue::GetMaximumTimeout().
  • Changed JetByteTools::Win32::CThreadedCallbackTimerQueue::GetNextTimeout() and JetByteTools::Win32::CCallbackTimerQueue::GetNextTimeout(), they are now const.
  • Fixed the bug in JetByteTools::Win32::CCallbackTimerQueue that is detailed here: http://www.lenholgate.com/archives/000771.html
  • Added several methods to JetByteTools::Win32::CSystemTime. More ways to construct and more ways to access the resulting date/time.
  • Added JetByteTools::Win32::CSmartHandle::GetHandle().
  • Fixed a bug in JetByteTools::Win32::CSmartHandle::~CSmartHandle() which could allow the destructor to leak an exception if the close of the handle failed.
  • Changed JetByteTools::Win32::CSimpleNamedPipeServer and JetByteTools::Win32::CSimpleNamedPipeClient to use JetByteTools::Win32::CSmartHandle during construction to remove any chance of resource leaks.
  • Added JetByteTools::Win32::CCriticalSection::SetSpinCount().
  • Added A new constructor to JetByteTools::Win32::CSharedCriticalSection to enable you to specify a spin count for the critical sections.
  • Changed JetByteTools::Win32::CSemaphore so that it derives from JetByteTools::Win32::IWaitable.
  • Fixed a memory leak in JetByteTools::Win32::CSecurityDescriptorAllowAll().
  • Added optional boolean inheritHandles to JetByteTools::Win32::CSecurityAttributes. This defaults to false which gives the same results as before the change.
  • Added JetByteTools::Win32::CProcessToken::Enabler and JetByteTools::Win32::CProcessToken::OptionalEnabler classes for enabling privileges in a RAII manner.
  • Added JetByteTools::Win32::CProcessToken::IsUserAnAdmin(), JetByteTools::Win32::CProcessToken::EnablePrivilegeIfPossible(), JetByteTools::Win32::CProcessToken::DisablePrivilegeIfPossible() and JetByteTools::Win32::CProcessToken::RemovePrivilegeIfPossible().
  • Added some new constructor arguments to JetByteTools::Win32::CProcess so that you can specify the flags and whether to inhreit handles or not. Also added the following methods: JetByteTools::Win32::CProcess::GetHandle(), JetByteTools::Win32::CProcess::DetatchProcess(), JetByteTools::Win32::CProcess::ResumeProcess() and JetByteTools::Win32::CProcess::GetExitCode().
  • Added validation to the constructors of JetByteTools::Win32::CKernelObjectNameImpl to ensure that we never create a name that is too long.
  • Fixed a bug with JetByteTools::Win32::CEnvironmentBlock. We weren't adding a terminating null to an empty environment block.
  • Added JetByteTools::Win32::CDirectoryChangeMonitor.
  • Fixed a memory allocation/deallocation mismatch in JetByteTools::Win32::CCommandLine where we were using a JetByteTools::Win32::CSmartHeapPointer rather than a JetByteTools::Win32::CSmartLocalPointer for the memory returned from ::CommandLineToArgvW().
  • Added JetByteTools::Win32::CIOCompletionPort::GetHandle() and JetByteTools::Win32::CIOCompletionPort::TryAssociateDevice().
  • Added JetByteTools::Win32::CFileDeleter.
  • Added JetByteTools::Win32::CMD5Digest.
  • Added JetByteTools::Win32::CWOW64FileSystemRedirector.
I/O Tools Library - 5.2.2
  • Added JetByteTools::IO::IIOPool::GetHandle() and JetByteTools::IO::IIOPool::TryAssociateDevice() and associated changes to JetByteTools::IO::CIOPool.
  • Changes to JetByteTools::IO::CAsyncFileWriter to allow much more control as to how the asynchronous file writes are executed. See http://www.lenholgate.com/archives/000765.html for more details.
  • Added JetByteTools::IO::CAsyncFileWriterEx which now contains the simple scatter/gather file write logic that used to live in JetByteTools::IO::CAsyncFileWriter.
  • Fied some things in JetByteTools::IO::CAsyncFileReader. We now use FILE_FLAG_SEQUENTIAL_SCAN when opening the file, we can attach to an existing file handle, the file handle is stored in a JetByteTools::Win32::CSmartHandle to avoid any chance of resource leakage, the callback now takes a reference to a buffer rather than a pointer and we recognise ERROR_BROKEN_PIPE as an 'end of file' indication so that the class can be used to read from pipes as well as files.
  • Changed JetByteTools::IO::CAsyncFileWriter to report (in the exception that's thrown) the name and path of a file if it fails to open a file due to an ERROR_PATH_NOT_FOUND error. This means that we throw an JetByteTools::Win32::CException in this case rather than the JetByteTools::Win32::CWin32Exception that was thrown in previous versions.
Socket Tools Library - 5.2.2
  • Some changes to WinsockWrapper.h for when JETBYTE_PLATFORM_SDK_VERSION == 0x0610 as version 6.1 of the Platform SDK does not define a SOCKADDR_STORAGE typedef for Windows versions of less than 0x0501. We warn about this and include our own typedef if this is the case.
  • Changes to JetByteTools::Socket::CAddressIPv6() and JetByteTools::Socket::CAddressTypeIPv6() so that we don't need the constant in6addr_any to exist, it's zero and it's not present when building for some versions of Windows.
  • Fixed JetByteTools::Socket::CAddressRenderer so that it actually uses the includePortOrService flag that's passed in.
  • Added JetByteTools::Socket::IMaintainStreamSocketConnections and JetByteTools::Socket::CConnectionMaintainingStreamSocketConnectionFilter which enable connections to be automatically reconnected if they are dropped.
  • Added JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter which monitors the amount of data that has been sent and limits the amount of data that can be 'pending a write completion' by buffering data in its own buffers and sending from them as writes complete.
  • Added JetByteTools::Socket::IMonitroStreamSocketFlowControl which allows you to monitor how a class like JetByteTools::Socket::CFlowControlStreamSocketConnectionFilter is working.
  • Added JetByteTools::Socket::IAcceptStreamSocketConnectionFilters which makes it easier to add connection filters to servers and connection managers.
  • Moved the data sequencing functions from JetByteTools::Socket::IStreamSocketEx to JetByteTools::Socket::IFilterableStreamSocket to allow connection filters to control the sequencing of data if they require.
  • Changed how connection shutdown and closure works. See here: http://www.lenholgate.com/archives/000779.html for more details.
  • Fixed JetByteTools::Socket::CDatagramSocketServer so that it continues to post read requests when it gets ERROR_PORT_UNREACHABLE errors. A port unreachable error from a send results in a pending recv completing with ERROR_PORT_UNREACHABLE and we only issued a new recv if the completion is without error which would lead to read starvation and eventually to a server that wouldn't receive any more datagrams.
  • Added JetByteTools::Socket::IStreamSocketConnectionManager::OnSocketCreated(), JetByteTools::Socket::IDatagramSocketConnectionManagerCallback::OnSocketCreated() and JetByteTools::Socket::IDatagramServerSocketConnectionManager::OnSocketCreated() which are called after new sockets are created and which is passed the raw SOCKET. You can use these to set the socket up in any way you want to, such as set various socket options that the framework doesn't have any explicit support for, or whatever.
  • Changed JetByteTools::Socket::IFilterStreamSocketConnections::FilterConnect() so that it takes an instance of JetByteTools::Socket::IFullAddress rather than just JetByteTools::Socket::IAddress and so that it also gets to filter the user data.
  • Added JetByteTools::Socket::IFilterStreamSocketConnections::FilterConnectionFailed() which allows filters to be notified of failures to establish connections.
  • Added support to JetByteTools::Socket::ICreateStreamSocketConnections for setting a socket's send and recv buffer sizes before establishing the connection.
  • Added support to JetByteTools::Win32::CStreamSocketServer, JetByteTools::Win32::CStreamSocketServerEx and JetByteTools::Win32::CStreamSocketConnectionManager for specifying the send and recv buffer sizes of all sockets created.
  • Added JetByteTools::Socket::ICreateStreamSocketConnections::AsyncConnectNoThrow(), JetByteTools::Socket::ICreateStreamSocketConnections::ConnectAsyncIfAvailable() and JetByteTools::Socket::ICreateStreamSocketConnections::ConnectAsyncIfAvailableNoThrow().
  • Changed JetByteTools::Socket::CReadSequencingStreamSocketConnectionFilter and JetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilter to use JetByteTools::Socket::IAcceptStreamSocketConnectionFilters to register themselves.
  • Fixed a memory leak in JetByteTools::Socket::CSequencedStreamSocket::SequenceData where we were calling delete when we should have been calling delete [].
PerfMon Tools Library - 5.2.2
  • Added a checksum system to the schema and the installer. You can now extract a checksum from a schema and pass it to the installer, this is then written to the registry as part of the installation process. When you come to create your counters you can compare the checksum of your schema with the checksum that the installer retrieves from the registry and spot if the installed counters don't match the schema that you're expecting.
  • Added JetByteTools::PerfMon::IInstallPerformanceMonitorCounters::CanInstall() which returns true if the installer can install the counters; you can use this to check to see if the account that the process is running as has the required permissions to install the counters.
  • Added code to the installer to validate the counter dll. This checks that the dll is built for the expected processor architecture (x86 or x64) and that it exposes the expected entry point functions.
  • Fixed a bug in the installer. An x86 process can now correctly install an x64 counter dll.

Full details of the licensed version of the code are available here.

Full details of the free version of the code are available here.

No new documentation for this release.

Doxygen documentation for the latest release is available here.

If you're an existing client and you'd like these changes let me know.

Leave a comment