Introduction

Welcome!

We are very happy to announce that we have made the decision to offer our commercial lineup of MFC libraries, including Ultimate Toolbox, Ultimate Grid, and Ultimate TCP/IP to the CodeProject.com community free of charge.

These are the full and complete libraries including source code, documentation, samples and examples.

Ultimate Toolbox, Ultimate Grid and Ultimate TCP/IP come with full source code, and are compatible with Microsoft Visual Studio versions 6.0 through 2005.

The Ultimate Toolbox and line of related MFC libraries products have been powering professional MFC applications for more than 10 years. We realize that there is a very large number of users who are still coding new applications in Visual C++ and MFC and who are looking for effective and proven libraries to enhance their applications, as well as those with legacy code to maintain and update.

By releasing these long standing MFC libraries to the CodeProject.com community we hope that the libraries will continue to grow, evolve and provide a library of useful controls to the development community through the auspices of The Code Project and its members.

Includes Servers For The Most Popular Protocols

The Server edition of Ultimate TCP/IP includes the server-side implementations for the following protocols:

Web Server (HTTP protocol).

Finger server.

Fully functional Email and relay server (SMTP, POP3, DNS)

File transfer server (FTP)

Echo server.

*full source for each of the protocols is included

Design Your Own Custom Protocol

Create modified protocols by deriving from our base protocol classes.

Create entirely new protocols by deriving from our client and server framework classes. This is very easy since the product comes with complete source code for all of the included protocols, which you can then use as a guideline.

Our customers have found that source code availability drastically cuts down on time spent debugging .

Maximum Access Control

The framework includes functionality that lets you grant, suspend and/or deny user access based on their IP address or network range.

The server framework also monitors every single command sent from the server.

Allows you to grant, deny and modify client requests based on your own custom protocol logic.

In conjunction with the secure version you can make sure that both the server and the client use a certificate for authentication.

Programmatic And Interactive Certificate Management

Unlike other products the certificate management wizard can be integrated with your own application, without having to run as a separate application.

You can search, view, select, install, and/or delete a certificate programmatically or interactively.

Generating a certificate-signing request (CSR) can be done with a single function call (programmatic mode). You can also do this in interactive mode by integrating the ready-to-use certificate management wizard into your application.

Security Features

Fully Supports PCT, SSL v2.0, SSL v3.0, and TLS v1.0.

The certificate validation process is fully automated, and you can configure this process to: deny access for all errors; allow access regardless of an error (ideal for testing); or build your own authentication logic based on the occurrence of certain errors.

When used in conjunction with the enterprise edition you can ensure that both the server and the client use a certificate for authentication.

Included SSL/TLS Servers

Secure Web Server (HTTPS): can be used by all browsers that support SSL/TLS (e.g. Netscape and Internet Explorer).

Secure Mail server: can be used by all clients that support SSL/TLS (e.g. Outlook Express and MS Outlook).

Secure FTP Server: can be used by all clients that support SSL/TLS (e.g. WS_FTP and Cute FTP).

Secure Echo: can be used as the basis for building a secure custom protocol that takes advantage of the well-known, secure SSL/TLS protocol.

Layout

We've split up the components of the Ultimate TCP-IP into separate source code, samples and documentation files for the initial deployment.

In general, for a code library such as the Ultimate TCP-IP, installation files are a cumbersome nuisance. While they do allow the formality of license agreement acceptance, and are expected of a commercial offering, for our purposes it would be too much trouble to update an entire install in order to accommodate a small update to a core source file or sample, and if the CP community finds this offering useful (and we hope they do) we expect that there will be updates and patches in various forms - for now, we'll keep it simple and see how it evolves.

The samples and library projects all reference relative paths with respect to source and include files, and should compile 'out of the box' if the ZIP files are extracted to a common directory - your installation should look more or less like this:

Support for the products will be community based, and will include participation from core developers of the products, long standing and informed users of the products, and other members of the CodeProject.com community.

It is our intention that you be able to use the libraries in any manner you wish however specific details of licensing rights, limitation of liability, and other details are included both here, and in a license.txt file included with the downloadable packages

The main focus of Ultimate TCP/IP Version 4.2 has been to update the source code for use with Microsoft Visual Studio 2005, while maintaining compatibility with Visual Studio 6.0. This section contains an overview of the various impacts of the version 4.2 revisions:

Unicode builds:

New Visual C++ 8.0 projects now default to Unicode compilation.

Much of the Ultimate TCP/IP code is char based, having its origins in the implementation of several DOD RFCs dealing primarily with transmission protocols using 7 and 8 bit ASCII based command sets and data formats. For this reason updating the code to support compilation under unicode constitutes a special case, in that unlike most Windows libraries it is desirable to maintain the core code as char based while providing a unicode interface where necessary for ease of use within a wide char build.

In some cases, it made sense to rework the classes for full unicode compatibility substituting _TCHAR for char and using the generic text mappings. Other classes (especially those encapsulating ANSI based internet protocols) were modified to provide the user with wide char overloads when used in a unicode build. This was especially important for those classes where a wide char version of a function might be convenient for the user, but the char equivalent will still be called from char based internal code.

Some functions (overrides) that act as notification callbacks concerning events where protocol data is returned will still return ANSI text.

Warnings:

A primary goal of the Ultimate TCP/IP 4.2 release was clean compilation at Warning Level 4 in both VS2005 and VS6.0.

There were several issues to be addressed here. It was found that many areas of the code files evoked warnings at level 3 in VS8 that are either new to VS7/8 or VC6 level 4 warnings re-classified as level 3. Also, there are new warnings dealing with 64 bit portability (on by default in new VS2005 projects).

Level 4 warnings invoked by the STL code that were present in VC6 builds have been addressed.

With regard to 64 bit portability, Ultimate TCP/IP 4.2 is not intended to provide full 64 bit compilation, though some changes were made to suppress these warnings. In some cases functions taking integer parameters to designate buffer sizes have been updated to take size_t, which should help users of the class using values returned from strlen etc. to avoid warnings when calling the UT code. Future releases may address this issue more fully.

Note: Some portions of the code using static functions may give rise to warning C4710 (function not inlined). This warning occurs after the compiler has read the last line of code in the compiland, and can only be discarded on a per-project basis.

Updates to the C Run Time:

With the introduction of VC8, many CRT string handling functions are deprecated in favor of their safe equivalents.

Version 4.2 only partially addresses this issue, preferring to retain (for now) the non-safe string functions. Pragmas are provided to disable this warning in the core Ultimate TCP/IP code on a per file basis - these pragmas should not affect warning settings beyond the scope of each compiland. Future versions of Ultimate TCP/IP should address this issue more fully, as do Ultimate Toolbox and Ultimate Grid.

We have tried to limit the use of pragmas in disabling warnings for the Ultimate TCP/IP code. Beyond the safe string warnings, most pragmas dealing with warnings should be disabling warnings arising from the STL or SDK.

Several POSIX function names were deprecated in favor of their ISO equivalents.

All functions generating warning C4996 related to their POSIX name declarations were changed to use their ISO name declaration. This change is backward compatible to VC6. Some of these functions remain deprecated in favor of their safe counterparts.

Files referencing headers no longer included in VC8 were updated (e.g. iostream vs iostream.h). This is change does not break VC6.0 compatibility.

Changes to the Platform SDK

There have been changes to the Platfom SDK with the release of Visual Studio 2005 and the Platform SDK 2003.

If you are using the Ultimate TCP/IP secure client and server classes with 2005 it is no longer necessary to install a separate version of the Platform SDK to compile the UTSecureLayer.DLL. However, some key headers and lib files required by Visual Studio 6.0 are no longer contained in the revised Platform SDK 2003. VC6.0 users compiling the secure code will need to access a previous version of the Platform SDK. (PSDK from February 2003 recommended)

UTSecureLayer.DLL builds:

With version 4.2, the UTSecureLayer builds have been renamed based on character set and release/debug version.

Where previously code built against the secure DLL had to assume that the build was compatible with the current settings, we've separated it into UTSecureLayer.DLL, UTSecureLayerU.DLL, UTSecureLayerD.DLL, UTSecureLayerUD.DLL based on Unicode / Debug settings. Some project settings may need to be reset to reflect this.

Breaking Changes:

CUT_DataSource and derived classes

In preparing the Ultimate TCP/IP for wide char compilation, most file names and paths were changed to use _TCHAR strings, and this is reflected in the interfaces to the datasouces which take file names.

The interfaces that were specifying buffer or data lengths as unsigned int now take size_t, which may require changes to existing derived classes.

The datasource classes themselves remain primarily char based, as they are mostly used internally by ANSI based protocol classes. In future we may provide wide char or _TCHAR based classes.

The strings returned in the UT_ARTICLEINFO structure will be wide char for _UNICODE builds. This may break code that was attempting to decode strings with calls to CUT_HeaderEncoding methods, which take only char. For this reason, and added convenience, the strings returned in this structure will have been decoded if necessary, and the structure now contains a text representation of the associated character set for the applicable fields. Note that only Author and Subject are routinely encoded in an NNTP header.

CUT_Msg, CUT_HeaderEncoding - decoding functions that previously took a reference to an LPCTSTR to return the charset now take an LPSTR that should be declared/allocated with space to receive the charset.

Miscellaneous Fixes:

CUT_SMTPClient: Was failing to include Reply-To header if set in CUT_Msg when sending.

Share

About the Author

In January 2005, David Cunningham and Chris Maunder created TheUltimateToolbox.com, a new group dedicated to the continued development, support and growth of Dundas Software’s award winning line of MFC, C++ and ActiveX control products.

Ultimate Grid for MFC, Ultimate Toolbox for MFC, and Ultimate TCP/IP have been stalwarts of C++/MFC development for a decade. Thousands of developers have used these products to speed their time to market, improve the quality of their finished products, and enhance the reliability and flexibility of their software.

It works fine without SetSecurityEnabled.I use the latest Ultimate TCP-IP with its 3 latest updates.Compiling using Visual Studio 2008, Unicode settings.Running on Windows 7 64bit, tried also on Windows 7 32bit.The FTPS server I am trying to connect to is my FileZilla FTP server.Why does it say "Can't create security credentials." ?Thanks!!!

I have just discovered the hard way that CUT_BufferDataSource only handles character strings terminated with a NULL. It is not binary compatable. It uses strlen in the Open method.

The help file makes no mention of this limitation. The help file documentation needs tobe updated!

Fortunately CUT_FileDataSource has no such limitation. It is a reasonably straight forward replacement for CUT_BufferDataSource. The only gotcha is to create a temporary file name, I use for the filename s.Format("XX%ld.tmp", ::GetTickCount()).

The help file for this constructor suggests that if the file name is NULL then a local temp file will be created. It is not created. Again, the help file documentation needs tobe updated!

I tried to use CUT_FTPClient::ReceiveFile in a pure console application.I use VC2005 and in MBCS, not UNICODE.My main purpose is to write a simplest console applicatioin code to get a file from a remote ftp server.

However, I can not get out of compilation errors even after hundreds of trials.

I've run into an issue with my BC patch (you may remember that I'm trying to use Ultimate TCP/IP in a Borland C program). I've got most of my features running, but have run into a bit of a snag...

Our program allows the user to start up the server, stop the server at any time, and re-start the server. So far, I can start the server with no problem, and I think I can stop it (a connected client shows that it gets disconnected). However, when I try and re-start the server, I get a 'normal' 0 return, but clients can no longer connect to the server.

It looks to me like I'm not completely closing off everything that needs to be closed when shutting down the server...

In a nut shell, here's what I do:Start the Server: call ConnectToPort(uPortNumber); call StartAccept();

BTW, I'm using the 'plain' TCP/IP server functionality--no FTP, SMTP, HTTP, etc. Basically, it'a a custom server for an application that we have.

I don't know if I was stopping my server functions correctly, but after stepping through the code many many times, I finally found that after the server was started the first time and stopped, the m_bShutDown flag was still TRUE! So, naturally, the next time I tried to start the Server, it saw the flag being TRUE and immediately exited!

I've 'fixed' this by adding a GuydonServer.SetShutDownFlag(FALSE); at the end of my ShutDown function, after all the threads have exited, and I've called StopAccept(). This seems to be working much better for me.

I create an array of binary data that contains some NULL values that is &gt; 6000 bytes long. I use CBase64::EncodeData to create an encoded BYTE array. I create a message via the sequence CUT_Msg::SetMessage() using the encoded BYTE array as the source and then use CUT_SMTP::SendMail() to send the BYTE array into the either.

As an aside, I notice deep down in SendMail, the helper function ProcessMail breaks the BYTE array into meaningful chunks by inserting CR LF pairs into the outbound BYTE stream when sent to the server.

Sometime later I receive the BYTE stream from the server via the sequence: CUTPOP3Client::GetMsgSize() CUT_MapFileDataSourceCUT_POP3Client::SaveMsg() This sequence saves the message into a tmp file. This tmp file has embedded CR LF pairs in it already.

I then use the following sequence to acquire the BYTE stream itself:CUT_MapFileDataSourceCUT_Msg::LoadMessageCUT_Msg::GetMessageBody

I find the BYTE stream returned by GetMessageBody littered with these CR LF pairs. How do I rid myself of these offending characters? I would have thought there is a parameter I am not setting to prevent these extra characters appearing in my incoming BYTE stream. It seems strange to me that the BYTE array retrieved by GetMessageBody() is not identical to the BYTE array one sends out via SetMessage().