This is a free update for customers using version 7.x, and is a complete package that replaces the previous version. Note that because of the version change, we recommend that you uninstall the previous version of SocketTools before installing 7.2. This update also applies to the related products such as SocketWrench, SocketTools File Transfer and SocketTools Internet Mail.

You can download it using the same link that you were provided with when you ordered the software. The release notes are available on our website.

You can download it using the same link that you were provided with when you ordered the software. The release notes are available on our website.

For those of you with an IPv6 connection, you can test that connection to us using ipv6.catalyst.com. If your IPv6 connectivity is limited to tunneling using Teredo, most browsers will not be able to connect to the site because they won’t resolve a host name to an IPv6 address if Teredo is the only IPv6 interface configured on the local system. Note that SocketTools works a bit differently. If a host name only has an IPv6 address associated with it, it will attempt to connect to the system, even if the only IPv6 interface is a Teredo tunnel.

News feeds can be accessed remotely from a web server, or locally as an XML formatted text file. The source of the feed is determined by the URI scheme that is specified. If the http or https scheme is specified, then the feed is retrieved from a web server. If the file scheme is used, the feed is considered to be local and is accessed from the disk or local network. The News Feed control provides an interface that enables you to open a feed by URL and iterate through each of the items in the feed or search for a specific feed item. The control also provides a method that can be used to parse a string that contains XML data in RSS format, where the feed may have been retrieved from other sources such as a database.

Each SocketTools Edition includes a news feed component. The Library Edition introduces a new API that can be used to access a feed with just a few function calls. The .NET Edition and ActiveX Edition include high-level components that make it simple to download a feed and enumerate each of the articles in the feed. You can download a free evaluation of SocketTools from go.catalyst.com/download

Download Product
Online Documentation
Order Upgrade

Originally we had planned to release each of the SocketTools 7 Editions in two different versions, one 32-bit and one for 64-bit development. Based on feedback from our customers and the recognition that 64-bit development is in a transition period, we’ve decided to include both 32-bit and 64-bit components in the same product. You will be able to choose the versions that you want to install, with the defaults selected based on the system that you’re installing SocketTools on.

For those who are using the SocketTools .NET Editions and the Visual Editions, there will be virtually no coding changes required; the components will work in the same way, regardless of which version is being used. Because they have a higher-level interface, you don’t need to worry about the core changes that were made to support 64-bit platforms. With .NET development, you’ll be able to build applications that explicitly target either the x86 or x64 platforms, or both. The most significant changes you’ll probably need to make are with how your installer deploys your application, since it will need to be aware of whether or not the installation is being performed on a 32-bit or 64-bit system.

For developers who are using the Library Edition, there will be more significant changes because of the lower-level interface presented by the SocketTools API. In particular, the size of pointers and handles are different based on whether you’re building your application for 32-bit or 64-bit systems. The signatures for some of the SocketTools functions have changed to accommodate this, and it may require that you modify your code. This is really a general programming issue, so it’s not something unique to SocketTools, but it is something to be aware of if you’re planning to port your software to 64-bit Windows.

By including both 32-bit and 64-bit components in each of the SocketTools 7 Editions, you’ll have the best of both worlds. You can continue to develop and maintain your existing 32-bit software, while planning your transition to native 64-bit support that is clearly the future direction for the Windows platform.

To become a member of the beta testing group, please use the following link (this will be removed when beta test concludes). Once your application is received, you’ll be emailed a PDF that contains the NDA. After you email or fax the signed NDA back to us, you’ll be sent the link to the private section of the forums for beta testers and download links for the current build of the software.

It is recommended that you don’t install the beta release on a production system. The libraries and components are also set to periodically expire, so they should not be used in release software. Updates to the beta builds are planned for approximately every two weeks, and you’ll receive an email notification when a new build is uploaded. For everyone who joins us, thank you for your interest in making SocketTools an even better product!

It’s predicted that the last of the large blocks of available IPv4 addresses will be allocated by the Internet Assigned Numbers Authority (IANA) early in 2011 and the regional registries will exhaust their pool of new addresses within a few years. The widespread adoption of classless routing (CIDR) and network address translation (NAT) delayed the inevitable exhaustion of IPv4 addresses, but we’re rapidly approaching the point where the transition to IPv6 will be required to accommodate the ever increasing number of devices connected to the Internet.

Fortunately, the transition for developers using SocketTools will be fairly simple. Most of the real complexity in dealing with both IPv4 and IPv6 is handled internally, although there are some important considerations when updating your software.

1. If your application stores IP addresses in a database, configuration file, etc. then you need to make sure that your program will recognize both IPv4 and IPv6 formatted addresses. If your program is written to only recognize IPv4 addresses in dotted notation, this will create problems for you with IPv6 because it uses a completely different format. Instead of a sequence of four numbers separated by periods, IPv6 consists of hexadecimal values separated by colons. So while an IPv4 address looks like 192.168.0.20, an IPv6 address will looks something like fd7c:2f6a:4f4f:ba34::a32 and can be much longer than an IPv4 address. You’ll want to allocate at least 46 characters to store a full IPv6 address.

2. If your application allows the user to input an IPv4 address, then you’ll need to change that code to accept both address formats. If you’re using some kind of masked input that expects four individual numbers that are in the range of 0-255, then that code will need to be rewritten because.

3. Your application uses the SocketTools Library Edition and stores addresses as 32-bit integer values, that code will need to be changed. There are several API functions in SocketTools 6.0 and earlier versions that expect an IP address to be stored in a DWORD (unsigned 32-bit integer) variable. In SocketTools 7, those functions have been changed to use a new type named INTERNET_ADDRESS that is capable of representing both IPv4 and IPv6 addresses.

If your software is designed to work with both host names and IP addresses, and you don’t make any assumptions about the format of the address, then there are few changes that you’d need to make. The SocketTools functions and methods that accept either host names or addresses will automatically recognize the difference in formats and act accordingly. Because a host name can resolve to either an IPv4 or IPv6 address, SocketTools will normally choose the IPv4 address whenever possible. For example, if host name www.company.com has both an IPv4 and IPv6 address assigned to it (which will be common, particularly during the transition period to IPv6) then SocketTools will prefer the IPv4 address for backwards compatibility. However, if that domain only has an IPv6 address, then SocketTools will use IPv6 to establish the connection. There’s also an option that you can specify which will force SocketTools to always use IPv6 if necessary.

Because it’s likely you’ll need to continue to support older Windows platforms, SocketTools will also automatically handle situations where an IPv6 stack is not installed, and it compensates for some internal differences between the various versions of Windows. The most complete support for IPv6 is available on Windows 7 and Windows Server 2008. You can install an IPv6 stack on Windows XP and Windows Server 2003, however it does not come pre-installed. There is also a preliminary version of an IPv6 stack that was made available for Windows 2000, however Microsoft never released it as an official update for the operating system.

We recommend that all developers begin looking into making the change to support IPv6, and you’re welcome to join the SocketTools 7 Beta Test that will be starting in January. If you have any questions about IPv6 support (or any of the other features in version 7) join us on our technical support forums.

We understand that most developers can’t immediately switch to the current release, and because SocketTools 7 introduces some very fundamental changes to the product, we need to continue to provide support for version 6.0. We’ve decided to extend the support period for version 6.0, with its end-of-life scheduled for December 31, 2012. Free support will continue to be available after that date, but that will mark the end of paid support and new or renewed support agreements will not be available for version 6.0 from that point forward. This should give everyone almost two years to migrate to the next release and prepare their applications for IPv6 support and/or native 64-bit builds of their software.

Once the SocketTools 7 beta starts in January, the version 6.0 codebase will be feature-locked from that point forward. The only code changes will be to address critical errors, such as bugs that would cause a component to crash (and fortunately those are extremely rare). Any new feature requests would be considered for version 7.0, but won’t be back-ported. At this time, because the current 6.0 release has been very stable, we don’t plan any future service pack releases. That may change if a new critical defect is found in one or more of the components, but right now version 6.0 build 6030 is considered to be the last stable release of the SocketTools 6 product line.

When we designed the API for SocketTools, we wanted to make it as similar to the Windows API, with similar function naming conventions and using only common data types and simple structures whenever possible. For example, instead of passing around pointers to complex context structures as some APIs do, all of the SocketTools functions using handles. We explicitly avoided using certain C/C++ constructs like unions, and use common scalar types (integers, characters, etc.) for most parameters and structure members. The goal was to make the API simple to use, reducing the overall learning curve and make it easy to use in other languages that may not have the same kind of language features that C/C++ does. For that same reason, the SocketTools Library Edition DLLs are not ActiveX DLLs that require the use of COM. However, we do include an embedded type library as a resource in the DLL that allows it to be directly referenced by Visual Basic (this makes things easier for VB6 developers who prefer to use DLLs rather than ActiveX controls).

If you’re interested in using SocketTools with a non-Microsoft C/C++ compiler, it should be fairly easy to use the libraries, particularly if the compiler supports the most common Microsoft extensions. The C++ classes do not require the use of MFC or ATL, however if exists, they will take advantage of it. We include import libraries in both COFF and OMF formats; while most compilers today use COFF, the Borland C++ compilers continue to use OMF, so you would need to link against those libraries.

For languages other than C/C++, we also provide constant and function declarations for Visual Basic 6.0, PowerBASIC, and Delphi. We also include P/Invoke declarations for Visual Basic .NET and C#. For languages that aren’t directly supported, usually the function declarations for one of these languages can get you started.

It definitely helps if you have at least a cursory understanding of ANSI C and the common data types that are used. If your programming language has documentation on how to call functions in the Windows API, you can also use that as a resource to learn what needs to be done for SocketTools. For example, if you need to know how your language handles passing a null-terminated string to a function, look at how you would call the GetFileAttributes function in your language. If you need to know how to pass a string buffer to a function that changes its value, check how you would call the GetCurrentDirectory function.

Of course, if you have any questions you can join our technical support forums and we’ll be happy to help. We may not have experience with the particular language that you’re using, but we can still provide guidance on what the SocketTools function expects and offer suggestions as to how you can get your program working.