Latest release of licensed socket server code: 5.2.2
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
andJETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSION
toAdmin.h
. These are currently set to_WIN32_WINNT_WIN2K
andNTDDI_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 fromAdmin\VC6Compatibility
to your VC6 include directory. -
Added
TargetWindowsVersion.h
and associated target specific files. Either editTargetWindowsVersion.h
and change the values ofJETBYTE_MINIMUM_SUPPORTED_WINDOWS_VERSION
andJETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSION
or copyTargetWindowsVersion_Vista.h
or whatever over the top ofTargetWindowsVersion.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 ofTargetWindowsVersion.h
after extracting the code from source control. -
Adjusted the
SecureCRT.h
header again. -
Some changes to
WinsockWrapper.h
for whenJETBYTE_PLATFORM_SDK_VERSION == 0x0610
as version 6.1 of the Platform SDK does not define aSOCKADDR_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 returnedtrue
. -
Fixed memory leak in
JetByteTools::Win32::GetCurrentDirectory()
. We were usingstd::auto_ptr
to attempt to delete an array of memory and we needdelete[]
rather thandelete
. 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 usingstd::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 withFILE_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()
andJetByteTools::Win32::CCallbackTimerQueue::GetMaximumTimeout()
. -
Changed
JetByteTools::Win32::CThreadedCallbackTimerQueue::GetNextTimeout()
andJetByteTools::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
andJetByteTools::Win32::CSimpleNamedPipeClient
to useJetByteTools::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 fromJetByteTools::Win32::IWaitable
. -
Fixed a memory leak in
JetByteTools::Win32::CSecurityDescriptorAllowAll()
. -
Added optional boolean
inheritHandles
toJetByteTools::Win32::CSecurityAttributes
. This defaults tofalse
which gives the same results as before the change. -
Added
JetByteTools::Win32::CProcessToken::Enabler
andJetByteTools::Win32::CProcessToken::OptionalEnabler
classes for enabling privileges in a RAII manner. -
Added
JetByteTools::Win32::CProcessToken::IsUserAnAdmin()
,JetByteTools::Win32::CProcessToken::EnablePrivilegeIfPossible()
,JetByteTools::Win32::CProcessToken::DisablePrivilegeIfPossible()
andJetByteTools::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()
andJetByteTools::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 aJetByteTools::Win32::CSmartHeapPointer
rather than aJetByteTools::Win32::CSmartLocalPointer
for the memory returned from::CommandLineToArgvW()
. -
Added
JetByteTools::Win32::CIOCompletionPort::GetHandle()
andJetByteTools::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()
andJetByteTools::IO::IIOPool::TryAssociateDevice()
and associated changes toJetByteTools::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 inJetByteTools::IO::CAsyncFileWriter
. -
Fied some things in
JetByteTools::IO::CAsyncFileReader
. We now useFILE_FLAG_SEQUENTIAL_SCAN
when opening the file, we can attach to an existing file handle, the file handle is stored in aJetByteTools::Win32::CSmartHandle
to avoid any chance of resource leakage, the callback now takes a reference to a buffer rather than a pointer and we recogniseERROR_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 anERROR_PATH_NOT_FOUND
error. This means that we throw anJetByteTools::Win32::CException
in this case rather than theJetByteTools::Win32::CWin32Exception
that was thrown in previous versions.
Socket Tools Library - 5.2.2
-
Some changes to
WinsockWrapper.h
for whenJETBYTE_PLATFORM_SDK_VERSION == 0x0610
as version 6.1 of the Platform SDK does not define aSOCKADDR_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()
andJetByteTools::Socket::CAddressTypeIPv6()
so that we don’t need the constantin6addr_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 theincludePortOrService
flag that’s passed in. -
Added
JetByteTools::Socket::IMaintainStreamSocketConnections
andJetByteTools::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 likeJetByteTools::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
toJetByteTools::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 getsERROR_PORT_UNREACHABLE
errors. A port unreachable error from a send results in a pending recv completing withERROR_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()
andJetByteTools::Socket::IDatagramServerSocketConnectionManager::OnSocketCreated()
which are called after new sockets are created and which is passed the rawSOCKET
. 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 ofJetByteTools::Socket::IFullAddress
rather than justJetByteTools::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
andJetByteTools::Win32::CStreamSocketConnectionManager
for specifying the send and recv buffer sizes of all sockets created. -
Added
JetByteTools::Socket::ICreateStreamSocketConnections::AsyncConnectNoThrow()
,JetByteTools::Socket::ICreateStreamSocketConnections::ConnectAsyncIfAvailable()
andJetByteTools::Socket::ICreateStreamSocketConnections::ConnectAsyncIfAvailableNoThrow()
. -
Changed
JetByteTools::Socket::CReadSequencingStreamSocketConnectionFilter
andJetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilter
to useJetByteTools::Socket::IAcceptStreamSocketConnectionFilters
to register themselves. -
Fixed a memory leak in
JetByteTools::Socket::CSequencedStreamSocket::SequenceData
where we were callingdelete
when we should have been callingdelete []
.
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 returnstrue
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.