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.

Maybe I'm missing something so obvious I just cannot see it. In trying to create a simple ftp dialog application, I'm going round and round with errors.

Basic Questions

#1 - is the TCP/IP package independent of the main Ultimate package?
#2 - does the current download link for Ultimate TCP/IP contain all of the user contributions?
#3 - I've managed to build all of the activeX controls. When I try to drop a control onto my dialog, it reports I don't have a design time license.

So, it seems that no matter what I do, I run into issues, and based on what I read here, it should not be this hard. What am I missing? Punting on this for now, I'll just do the ftp operations manually.

Charlie GilleyStuck in a dysfunctional matrix from which I must escape...

Yes. Some samples might use a file or two like the history control, but there should be a UT copy.

charlieg wrote:

#2 - does the current download link for Ultimate TCP/IP contain all of the user contributions?

No, I don't think so - but haven't checked since it was put in the workspace. But note the AX controls are not core - this is legacy stuff that has probably not been looked at since the turn of the century.

charlieg wrote:

#3 - I've managed to build all of the activeX controls. When I try to drop a control onto my dialog, it reports I don't have a design time license.

Check the licence.cpp and licence.h files - should be straight forward to disable.

I think there is an error in the function CUT_MimeEncode::GetMultiPartBoundryString(), line 3044.
If the boundary-string has an semicolon (';') at the end (some mail-systems append one), then the string isn't read exactly, and no message-body will be loaded. I have it patched as follows:

I have trouble to use CUT_SMTPClient in Unicode dialog MFC application. I've tried in VS 2013 and also VS 2008, new simple solution. In both I've just created the CUT_SMTPClient object in button handler like this:

void Cmfc_app2008Dlg::OnBnClickedOk()
{
CUT_SMTPClient c;
}

In VS2013 it crashes in runtime after click with stack corrupted around c variable, in 2008 it crashes in

Thank you, I had the same problem I've already found out I have different sizes of the classes and shifted layout of member variables by 4 bytes when I've checked your post which showed me it is not Unicode related. Thank you again!

I am having issues getting the library to work. I need to use SSL to communicate with a server over a SSL connection - not HHTP, FTP or any other protocol. Just open a socket and communicate using SSL. Cleary, this library should be able to help me, but I can't figure out how to do it.

1. I can't get the help file to work. Problems.txt isn't the problem.
2. I've looked through the samples and they are a help, but not enough.

I think it shouldn't be such a chore. Can someone give me some direction? Sample source code would be a life saver. Please help!!

From what I can tell I need to derive a class from CUT_SecureSocketClient and write the needed virtual functions, though I'm not sure what needs to go into them. That's why anyone with sample code of connecting to a secure server would be a godsend.

OK. I can build and run the test programs. However, when I try to create a project that is NOT within the "MasterS" project, i.e. my own project, it fails.

I have a simple project with a main that does nothing. It includes the same .h files and .cpp files into the project as EchoClientS project. When I compile I get the following errors - cannot figure it out:

Looks like you need to tell the linker to use the appropriate UTSecureLayer.lib - in the project Properties | Linker | Input | Additional Dependencies you'll need the path and file name of the appropriate one - e.g. for a Debug build Security\Lib\UTSecureLayerD.lib.

Assume you already have the CUT_SECURE_SOCKET defined in the preprocessor defs.

It's windows 7 64 bit. The file opens but if I click on anything in the index - or do a search for something - the pane on the right is never populated. I can click away on the list on the left, everything is there. Just that nothing is ever displayed.

First, thank you so much for your assistance. Something you said in your last post was the answer.

I was building Debug and Release. I didn't know there was a UNICODE version of both as well. As soon as I built those, the linker errors went away. Unbelievable. Documentation would be nice. I've been poking around blind trying to figure out why I'm linking with a library with the defined routines but the linker didn't see them. Ugh...

hi,
dunno if you still have that problem (one year), but, the only difference between a ssl (https) and not ssl (http) if the flag pass to HttpOpenRequest Wininet API function.
it has INTERNET_FLAG_SECURE set on (and optionnaly INTERNET_FLAG_IGNORE_CERT_CN_INVALID to avoid problems with old IE and XP).

as i dont know how the ultimate tcp/ip stuff is done, it might not be relevant with your problem though...

A quick question from someone more experienced than me (which wouldn't be hard to be )

I'm trying to make an application that will have multiple TCP/IP servers running at the same time, only at different ports. As I understand the code, OnConnect() will be called whenever a client connects, and it'll handle the communications between the server and that client.
But, with multiple servers running, how will OnConnect() "know" which server it's operating from? Each of my servers will have to accept/reply information specific to that server's instance, and right now, I don't see how OnConnect() can differentiate which Server it's working with?

What I've tried to do (and it isn't working is to call ConnectToPort() multiple times for each of the different ports. Then inside my OnConnect(), I try and retrieve the Port# from the server to decide which server called OnConnect()--like I said, I'm not having much luck.

Is there some 'cleaner' way to set up a server to listen at multiple ports and 'report' which port a request came from?

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!