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.

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.

For professional developers who need security, additional functionality and technical support, we have commercial versions of SocketWrench. Secure connections using SSL/TLS can be easily established, usually with just an extra line of code, and for projects where you need to create a server application, the commercial version also includes the Internet Server component which makes it easy to create custom TCP/IP servers.

For those programmers who are primarily working with native code, such as classic Visual Basic, PowerBasic, C++ and other similar languages, our SocketWrench Secure Edition includes both an ActiveX control and a standard dynamic link library (DLL) that provides an interface that’s similar to the standard Windows API. It can be used with virtually any programming language, and has a great degree of flexibility.

For Visual Basic .NET and C# developers, we’ve designed SocketWrench .NET to really simplify Internet programming beyond what’s included as part of the .NET Framework. Microsoft has a lot of interdependency in their classes where you end up creating a number of different class instances and writing a lot of “glue code” to tie them together. An example of this would be the TcpClient class which uses the NetworkStream class, and then to convert the data read to a string, you’d need to use the System.Text.Encoding class and so on. If you need SSL support, then you’d also need the SslStream class, and write the code to integrate that. All of this functionality is incorporated directly into SocketWrench, which significantly reduces the amount of code that needs to be written. And as every developer knows, the less code you have to write, fewer errors will be in that code. A simple, straight-forward design is one of the cornerstones of reliable software. Give it a try and let us know what you think.

With the SSH implementation in SocketTools, there is three basic functions that you can use within your applications to take advantage of the protocol:

1. Interactive terminal sessions. This is similar to how the current TELNET protocol component works, and in fact the interface to the SSH component was intentionally designed to be very similar. Our goal was to make it easy to integrate SSH support into an existing application that already used the TELNET protocol. The Terminal Emulation component can be used to provide a visual interface that supports the standard ANSI and DEC VT100/VT220 escape sequences. Alternatively, the SSH component can be used on the back-end to capture output from an interactive session and filter the data transparently.

2. Remote command execution. This is similar to how the Remote Command component works, in that a command is submitted to the remote host for execution, and the output is returned back to the caller. The SSH component makes this very easy to do, providing a single method that allows you to run a command on the server, and its output is returned in a string variable or byte array that you provide.

3. Secure file transfers. Support for secure file transfers using SFTP has been integrated into the current FTP API and components, making it extremely easy to upgrade existing applications to use SSH/SFTP. We decided to go with this approach, rather than implement SFTP support in a separate component, so that developers would be able to integrate the new protocol with minimal code changes. In most cases, all that’s required is specifying a few additional options.

For those developers who have been using SocketTools for a while, you may be wondering what the difference is between SSH and TLS; SocketTools has supported SSL/TLS for years, and that is still the most common method for securing connections to webservers. However, SSH has become popular for remote terminal sessions and secure file transfers because it’s generally less complex and has a lower cost to administrate. For example, SSH doesn’t use site certificates, so there’s no requirement to register with a certificate authority (such as VeriSign or Thawte), generate certificate signing requests and update certificates on a regular basis. Therefore one of the big differences is that SSH cannot provide information about the server itself in the same way that TLS can. For example, SSH doesn’t provide a way for you to determine what company or organization owns the server and where they are located.

However, it’s important to note that the SSH protocol uses standard public-key cryptography to authenticate the client session, and shares many of the same cryptographic algorithms used with TLS, ensuring that the data is secure. There are now millions of users that regularly depend on SSH for secure terminal sessions and file transfers, and SocketTools 6.0 will allow you to easily integrate support for the protocol in your own applications.

SocketTools is a fairly large collection of components and libraries. We support a number of different development tools and frameworks, and over the years the build process became fairly complex. When the first version of SocketTools was released in 1996, it consisted of Visual Basic components and the build process was comparatively simple. We used batch files to build the components, and manually built the help files and install package. Over the years, as development tools evolved and our product line grew, our build process really didn’t follow suit. We just kept on adding batch files, created some custom makefiles and wrote a few Perl scripts to manage the build process. At last count, we had about 18 batch files, three Perl scripts and custom makefiles for each product group. While the build process worked, it was difficult to manage and maintain.

During the development of SocketTools 5.0, we decided to review our build process and make some changes. The most important criteria for us were:

1. Fully automated process, requiring no manual intervention
2. Structure the build process based on product groups
3. Support for external command line utilities
4. Support for multiple build configurations and options
5. Complete logging of the build process.

The first criteria was pretty much a given, but the idea was that we wanted to fully automate absolutely every part of the build process. At the push of a button, we wanted to be able to go from project source and documentation to a finished product, down to the executable installation package which would be uploaded to our servers. We also needed to be able to structure the build process based on our different products, and support different build options.

After doing some research, and contemplating building our own in-house tools, we decided that the tool which best met our needs was Visual Build from Kinook Software. Using Visual Build, we were able to completely automate the build process from start to finish, and it supports a hierarchical build structure that we needed to manage the various product groups within SocketTools. It has the ability to run any external command, but goes beyond that with the ability to create macros, invoke scripts, transfer files and a lot more. The actual build process itself was extremely easy to setup, and the build configuration is stored as an XML file which was a significant plus for us because it allowed us to create a build framework, edit it manually in a text editor and tweak it outside of Visual Build itself.

It did take some time to convert everything from our mass of batch files and scripts, but the end result has been a build process that is infinitely easier to manage and one that feels much more solid and reliable. If you’re a Windows developer, I strongly recommend that you take a look at Visual Build, download the evaluation and give it a try. Once you start using it, you’ll never want to build your software any other way.