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_VERSIONandJETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSIONtoAdmin.h. These are currently set to_WIN32_WINNT_WIN2KandNTDDI_WIN2K. -
Added
JETBYTE_PLATFORM_SDK_VERSIONwhich 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\VC6Compatibilitydirectory 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\VC6Compatibilityto your VC6 include directory. -
Added
TargetWindowsVersion.hand associated target specific files. Either editTargetWindowsVersion.hand change the values ofJETBYTE_MINIMUM_SUPPORTED_WINDOWS_VERSIONandJETBYTE_MINIMUM_SUPPORTED_NTDDI_VERSIONor copyTargetWindowsVersion_Vista.hor whatever over the top ofTargetWindowsVersion.hto 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.hafter extracting the code from source control. -
Adjusted the
SecureCRT.hheader again. -
Some changes to
WinsockWrapper.hfor whenJETBYTE_PLATFORM_SDK_VERSION == 0x0610as version 6.1 of the Platform SDK does not define aSOCKADDR_STORAGEtypedef 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_ptrto 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_ptrfor 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_READaccess. -
Fixed a shutdown race condition in
JetByteTools::Win32::CThreadPoolwhich 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::CCallbackTimerQueuethat 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::CSimpleNamedPipeServerandJetByteTools::Win32::CSimpleNamedPipeClientto useJetByteTools::Win32::CSmartHandleduring construction to remove any chance of resource leaks. -
Added
JetByteTools::Win32::CCriticalSection::SetSpinCount(). -
Added A new constructor to
JetByteTools::Win32::CSharedCriticalSectionto enable you to specify a spin count for the critical sections. -
Changed
JetByteTools::Win32::CSemaphoreso that it derives fromJetByteTools::Win32::IWaitable. -
Fixed a memory leak in
JetByteTools::Win32::CSecurityDescriptorAllowAll(). -
Added optional boolean
inheritHandlestoJetByteTools::Win32::CSecurityAttributes. This defaults tofalsewhich gives the same results as before the change. -
Added
JetByteTools::Win32::CProcessToken::EnablerandJetByteTools::Win32::CProcessToken::OptionalEnablerclasses 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::CProcessso 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::CKernelObjectNameImplto 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::CCommandLinewhere we were using aJetByteTools::Win32::CSmartHeapPointerrather than aJetByteTools::Win32::CSmartLocalPointerfor 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::CAsyncFileWriterto 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::CAsyncFileWriterExwhich 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_SCANwhen opening the file, we can attach to an existing file handle, the file handle is stored in aJetByteTools::Win32::CSmartHandleto avoid any chance of resource leakage, the callback now takes a reference to a buffer rather than a pointer and we recogniseERROR_BROKEN_PIPEas an ’end of file’ indication so that the class can be used to read from pipes as well as files. -
Changed
JetByteTools::IO::CAsyncFileWriterto 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_FOUNDerror. This means that we throw anJetByteTools::Win32::CExceptionin this case rather than theJetByteTools::Win32::CWin32Exceptionthat was thrown in previous versions.
Socket Tools Library - 5.2.2
-
Some changes to
WinsockWrapper.hfor whenJETBYTE_PLATFORM_SDK_VERSION == 0x0610as version 6.1 of the Platform SDK does not define aSOCKADDR_STORAGEtypedef 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_anyto exist, it’s zero and it’s not present when building for some versions of Windows. -
Fixed
JetByteTools::Socket::CAddressRendererso that it actually uses theincludePortOrServiceflag that’s passed in. -
Added
JetByteTools::Socket::IMaintainStreamSocketConnectionsandJetByteTools::Socket::CConnectionMaintainingStreamSocketConnectionFilterwhich enable connections to be automatically reconnected if they are dropped. -
Added
JetByteTools::Socket::CFlowControlStreamSocketConnectionFilterwhich 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::IMonitroStreamSocketFlowControlwhich allows you to monitor how a class likeJetByteTools::Socket::CFlowControlStreamSocketConnectionFilteris working. -
Added
JetByteTools::Socket::IAcceptStreamSocketConnectionFilterswhich makes it easier to add connection filters to servers and connection managers. -
Moved the data sequencing functions from
JetByteTools::Socket::IStreamSocketExtoJetByteTools::Socket::IFilterableStreamSocketto 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::CDatagramSocketServerso that it continues to post read requests when it getsERROR_PORT_UNREACHABLEerrors. A port unreachable error from a send results in a pending recv completing withERROR_PORT_UNREACHABLEand 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::IFullAddressrather than justJetByteTools::Socket::IAddressand 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::ICreateStreamSocketConnectionsfor setting a socket’s send and recv buffer sizes before establishing the connection. -
Added support to
JetByteTools::Win32::CStreamSocketServer,JetByteTools::Win32::CStreamSocketServerExandJetByteTools::Win32::CStreamSocketConnectionManagerfor 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::CReadSequencingStreamSocketConnectionFilterandJetByteTools::Socket::CReadTimeoutStreamSocketConnectionFilterto useJetByteTools::Socket::IAcceptStreamSocketConnectionFiltersto register themselves. -
Fixed a memory leak in
JetByteTools::Socket::CSequencedStreamSocket::SequenceDatawhere we were callingdeletewhen 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 returnstrueif 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.