SocketTools 12 Release Notes

SocketTools 12 is a major update focused on modern platform support, expanded protocol capabilities, improved security defaults, and new developer-facing APIs. The core interfaces for the components are compatible with the previous release, while adding new components, features and functionality.

Major Features

Native ARM64 Support

SocketTools 12 adds native ARM64 support across all editions, including the Windows DLLs, .NET assemblies, and ActiveX components. Applications can now be built specifically for ARM64 versions of Windows, including devices powered by processors such as the Snapdragon X Elite and other modern ARM-based platforms.

Native ARM64 applications can take full advantage of the performance and power-efficiency benefits offered by ARM-based hardware. While Windows provides x64 emulation for compatibility with existing applications, native ARM64 binaries eliminate the overhead associated with emulation, resulting in faster startup times, improved performance, reduced memory usage, and better battery life on mobile and always-connected devices.

For developers, native ARM64 support simplifies deployment to modern Windows platforms without requiring additional compatibility layers or third-party solutions. Applications built using SocketTools can target x86, x64, or ARM64 architectures using the same programming interfaces, making it easier to support a broader range of Windows devices while maintaining a single code base.

As ARM-based Windows systems continue to gain adoption in both consumer and enterprise environments, native ARM64 support helps ensure applications are prepared for future hardware platforms while delivering the best possible user experience on current-generation devices.

Large Language Model Client

SocketTools 12 introduces Large Language Model (LLM) client components that provide a unified interface for integrating artificial intelligence capabilities into Windows applications. Developers can use the same programming model to connect to popular cloud-based AI services as well as locally hosted models, without having to implement provider-specific APIs or manage the complexities of individual service integrations.

The LLM client components simplify common tasks such as establishing connections, authenticating with providers, managing conversation history, tracking token usage, and sending prompts to AI models. By providing a consistent API across multiple services, applications can be designed to work with different providers and models while minimizing code changes. This flexibility allows developers to evaluate new AI technologies, support customer preferences, or switch providers as requirements evolve.

Large language models can be used to enhance a wide range of applications. Developers can create intelligent assistants, provide natural language search and question-answering features, summarize documents, generate content, analyze text, automate repetitive tasks, and build conversational interfaces. Because the components support both cloud-based services and locally hosted models, applications can be deployed in environments ranging from public Internet services to private networks where data privacy and regulatory requirements are important considerations.

By integrating AI capabilities through a straightforward and familiar programming interface, developers can focus on adding value to their applications rather than implementing and maintaining the underlying service integrations required to communicate with multiple AI providers.

For C and C++ developers, the LLM client library provides direct access to modern AI services using a native Windows API. Many AI libraries and SDKs are designed primarily for Python, JavaScript, or managed .NET environments, often requiring developers to integrate additional runtimes, third-party libraries, or complex REST interfaces into existing applications. The SocketTools LLM API provides a straightforward native interface that allows developers to add AI capabilities to desktop, server, and systems-level applications while continuing to use a familiar Win32 API style of interface.

The ActiveX control offers a practical way to integrate AI features into existing applications built with technologies such as Visual Basic 6, PowerBuilder, Visual FoxPro, and other environments that support COM automation. Organizations often maintain business-critical applications that have been in service for many years, but adding support for modern AI services can be challenging when current SDKs target newer development platforms. By providing AI functionality through a familiar ActiveX interface, developers can enhance established applications without requiring a complete rewrite or migration to a new technology stack.

WebView API and ActiveX Control

SocketTools 12 introduces WebView components that simplify the integration of modern web content into native Windows applications. Built on Microsoft's WebView2 technology, these components provide access to the latest web standards, HTML5, CSS, and JavaScript capabilities using the Microsoft Edge rendering engine. Applications can display local or remote web content without relying on Internet Explorer or legacy browser technologies.

For C and C++ developers, the WebView API provides a straightforward Win32-style interface that can be used in both graphical and console applications. Rather than working directly with the underlying COM interfaces and C++ class libraries provided by WebView2, developers can create and manage embedded browser windows using a familiar procedural API consistent with the rest of the SocketTools library. This simplifies development and reduces the amount of code required to host modern web content within native Windows applications.

The ActiveX control offers the same capabilities through a COM automation interface, making it easy to incorporate modern web-based user interfaces into applications developed with Visual Basic, Delphi, PowerBuilder, and other environments that support ActiveX controls. Existing applications can be enhanced with standards-compliant web content without requiring Internet Explorer or compatibility modes that may no longer be supported on current versions of Windows.

The WebView components are fully integrated into SocketTools and do not require developers to install or manage separate WebView2 SDK packages through NuGet or other distribution mechanisms. All required interfaces and support code are included with the library and control, simplifying deployment and reducing external dependencies during development. Applications are designed to use the Microsoft Edge WebView2 Runtime, ensuring they automatically benefit from security updates, performance improvements, and standards compliance provided through Microsoft's evergreen runtime distribution model.

By combining the capabilities of the Edge rendering engine with a simplified native API and ActiveX interface, the WebView components make it easier to build modern Windows applications that integrate web-based content, user interfaces, online services, and interactive documentation while maintaining the performance and flexibility of native applications.

HTTP/3 Support

SocketTools 12 adds support for HTTP/3, the latest version of the Hypertext Transfer Protocol used by modern websites and web services. Unlike previous versions of HTTP that rely on TCP, HTTP/3 is built on the QUIC transport protocol, which uses UDP as its underlying transport mechanism. This new architecture is designed to improve performance, reduce connection latency, and provide faster recovery from packet loss and changing network conditions.

For developers, HTTP/3 support enables applications to communicate with web servers and cloud services that have adopted the latest Internet standards. In many environments, HTTP/3 can improve responsiveness by reducing the time required to establish secure connections and by eliminating certain performance limitations associated with traditional TCP-based connections. These benefits can be particularly noticeable on mobile networks, wireless connections, and other high-latency environments.

As adoption of HTTP/3 continues to grow across web servers, content delivery networks, cloud platforms, and public Internet services, support for the protocol helps ensure applications remain compatible with current and future web infrastructure. By adding HTTP/3 support alongside existing HTTP/1.1 and HTTP/2 capabilities, SocketTools enables developers to take advantage of evolving Internet technologies while maintaining compatibility with existing services and applications.

Security and Protocol Updates

Updated TLS Defaults

SocketTools components now default to using TLS 1.3 when establishing secure connections, automatically falling back to TLS 1.2 when required by the remote server. TLS 1.3 provides improved security, reduced connection latency, and simplified protocol negotiation compared to earlier versions of TLS, while TLS 1.2 remains widely supported across existing servers and services.

This change requires no modifications to existing applications. Secure client and server components will automatically negotiate the highest TLS version supported by both endpoints, allowing applications to benefit from modern security standards while maintaining compatibility with current Internet infrastructure.

Legacy SSL Support Removed

Support for the legacy Secure Sockets Layer (SSL) protocols has been completely removed from SocketTools 12. SSL 2.0 and SSL 3.0 have long been considered obsolete due to known security vulnerabilities and have been disabled by default on modern operating systems, servers, and network infrastructure for many years.

This change is not expected to affect existing applications. Most Internet services have required TLS in place of SSL for more than a decade, and applications that use the default security settings have typically negotiated TLS connections automatically. Removing support for obsolete SSL protocols simplifies configuration, reduces the risk of unintended use of insecure protocols, and aligns SocketTools with current industry security practices.

Although SSL support has been removed, SocketTools continues to support TLS 1.0 and TLS 1.1 for applications that must communicate with legacy systems. These older TLS versions are disabled by default and are only used when explicitly requested, ensuring that applications use modern security standards whenever possible while still providing compatibility options for specialized deployment environments.

Security Zone Support

SocketTools 12 adds support for working with Windows security zone information through the FTP and HTTP APIs. Security zones are implemented using NTFS alternate data streams and are commonly used by Windows to identify files that have been downloaded from the Internet or other external sources. This information can influence how files are handled by the operating system and other applications, including whether users are prompted before opening potentially unsafe content.

Applications can now examine, create, modify, and remove security zone information associated with downloaded files. This provides developers with greater control over how downloaded content is managed, enabling applications to preserve source information for auditing and security purposes or remove zone information when appropriate as part of an automated workflow. Support for security zones helps applications integrate more effectively with modern Windows security features while giving developers flexibility in how downloaded files are handled.

Additional API Enhancements

Encoding, Filtering, and Normalization

The general-purpose encoding and compression library has been expanded with additional filtering and Unicode normalization functions. MIME-related functionality has also been enhanced with options for filtering message content, normalizing text, removing HTML markup, and identifying potentially unsafe links or Unicode content within email messages and other text-based data.

These features can be useful when processing content obtained from external or untrusted sources. Applications can normalize text from different languages and platforms into a consistent representation, improving text comparison, searching, indexing, and display. Content filtering options can also simplify the extraction of plain text from HTML messages and assist with the detection of potentially suspicious or misleading content.

The growing use of Unicode has introduced new security challenges, including the use of visually similar characters from different writing systems. For example, characters from the Latin, Cyrillic, and Greek alphabets can appear nearly identical while representing different underlying text. This technique, sometimes referred to as a homoglyph attack, can be used to create deceptive links, domain names, or message content that appears legitimate to users. The new filtering and normalization functions help applications identify and manage these situations, making it easier to process international text safely and consistently.

Network Time Improvements

The Network Time components have been updated to support 64-bit time values and include several enhancements to improve compatibility with modern Network Time Protocol (NTP) infrastructure. These changes help ensure accurate time synchronization across a wider range of systems and future-proof applications that work with dates and times beyond the limits of traditional 32-bit time representations.

Internal improvements have also been made to the selection and management of NTP servers, including updated support for the public NTP pool infrastructure commonly used by modern time services. These changes improve reliability and help ensure applications can obtain accurate time information from currently maintained and recommended time sources.

Compatibility Notes

.NET Enumeration Naming

The SocketTools .NET classes have been updated to use standard .NET naming conventions for enumeration values. Enumeration constants that previously used legacy naming styles, such as ErrorCode.errorNotConnected, are now exposed using the preferred Pascal case format, such as ErrorCode.NotConnected. This change improves consistency with Microsoft's .NET Framework design guidelines and helps SocketTools APIs better match the conventions used by modern .NET libraries.

To maintain compatibility with existing applications, the legacy enumeration values have been retained and marked as obsolete. Existing code will continue to compile and function normally; however, developers are encouraged to update their applications to use the new enumeration names. Adopting the updated names will eliminate obsolete warnings, improve code readability, and help ensure compatibility with future versions of the SocketTools .NET libraries where the legacy names may eventually be removed.

Improved Unicode Support

The SocketTools .NET classes have been updated to use Unicode strings internally throughout the library. Previous versions maintained compatibility with underlying ANSI-based interfaces in some areas, which could require additional string conversions when exchanging data between managed and native code.

This internal modernization improves consistency when working with international text, reduces unnecessary string conversions, and more closely aligns the implementation with the .NET Framework, where strings are represented internally using Unicode. Existing applications do not require any code changes, but developers may benefit from improved handling of non-English text, international domain names, file names, email content, and other Unicode data.

API Changes

The legacy INITDATA structure has been removed from the SocketTools C API. Initialization functions such as FtpInitialize, HttpInitialize, and related APIs now define their second parameter as a reserved LPVOID value that must always be specified as NULL.

The INITDATA structure was originally introduced to support configuration options related to Windows Sockets implementations and version selection. These options have not been required on modern versions of Windows for many years, and the structure has remained unused in recent releases. Replacing the structure with a reserved parameter simplifies the API and more accurately reflects the current behavior of the initialization functions.

Most applications will not require any modifications because the reserved parameter has typically been specified as NULL. Applications that explicitly declare or reference the INITDATA structure should be updated to remove those references and pass NULL for the reserved parameter. This change reduces legacy API complexity while preserving compatibility with existing initialization code.

RSH Deprecation

Support for the Remote Shell (RSH) protocol has been deprecated in SocketTools 12 and is planned for removal in a future release. RSH is a legacy remote command execution protocol that was designed for trusted network environments and does not provide encryption or modern authentication mechanisms. As a result, its use has largely been replaced by more secure alternatives.

Applications that currently use RSH should begin planning a migration to Secure Shell (SSH). SSH provides encrypted communications, strong authentication methods, support for public and private key authentication, and is widely supported across modern operating systems and network infrastructure. The SSH client components included with SocketTools offer a secure replacement for most RSH-based functionality while providing significantly improved security and compatibility.

RSH support remains available in SocketTools 12 to provide existing applications with time to transition; however, developers are encouraged to update their applications as soon as practical in preparation for its removal in a future version of the library.