This project started making the porting of an existing protocols analyzer (the analysis engine) for the MS-DOS platform towards the Microsoft Windows environment. Main addictions included a graphical interface and the adaptation of the software to the 32 bit memory model. The porting towards the Win32 platform was done in two steps. During the first step the sources were converted from the 16 bit memory model to the 32 bit one. The result was represented by a "console" version, executable from a command-prompt window. This program allowed to evaluate statistics on a capture file and to display packet satisfying a filter through the console. During the second step the graphical interface was developed and some improvements were applied to the application. The graphical interface is independent from the analysis engine; the communication between the two parts is implemented following a client/server scheme. The old analysis engine had a lot of limitations about the definition of the supported protocols so because of this problem a big part of the analysis engine code was rewritten.
The final product was composed by the following modules:
The first Analyzer version used the OLE Automation in the communication between the interface and the analysis engine.
The main peculiarity of the 32 bit memory model is represented by the "integer" data type that is made of 32 bit while in the DOS model it is made of 16 bit. This has some problems when, in the capture files, an integer (represented by 2 bytes) has to be read. In fact a capture file is a 'raw' file, so the access to it is like the access to text files. We will examine an example in order to understand this problem. For instance, we want to understand what happens if the following code fragment is executed in presence of the hexadecimal sequence 'EA-02-A6-03':
#include <stdio.h>
int i,j;
void main()
{
.....
fscanf(input_file,"%d%d",&i,&j);
.....
}
In the 16 bits model we obtain:
i=746 (0x02EA)j=934 (0x03A6)
N.B. in the x86 architectures the bytes of an integer are stored inverting the bits order while in the Motorola architecture they are stored keeping the original order.
In the 32 bits model the result is:
i=61211370 (0x 02EA03A6)j=????????? (0x???????? )
Then the solution adopted was represented by looking for all the code fragment like the previous one and by replacing the 'int' variables with 'short' ones (which are integer on two bytes on the Win 32 platforms).
N.B. We did not replaced all the 'int' variables of the code but only the variables which are used in capture file reading process; otherwise the efficiency of the program should have been decreased.
Because of the vision of the integer on 16 bit we had to make another correction to the code. We consider the following code fragment in order to explain this correction:
#include <stdio.h>
int i,j,t;
char c[100]
void main()
{
.....
j=0
fgets(c,100,Log_file);
t=*((int*)c);
j+=sizeof(int);
.....
}
In the DOS environment, at the end of the code execution, the j variable contains the value 2 while in Win32 it contains the value 4. We consider that, for instance, the j variable contains an offset relative to the 'raw' string; then, in Win32, the offset calculated is wrong. Besides the t initialization is wrong because of the previously described motive.
The mistake derives from the fact that the authors, thinking about making a portable code, did not consider that the Log file format is even the same, whatever is the environment; so in j we have to sum the value 2, in fact the integer in the log file are on 2 bytes.
The right code is:
#include <stdio.h>
int i,j,t;
char c[100]
void main()
{
.....
j=0
fgets(c,100,Log_file);
t=*((short*)c);
j+=2;
.....
}
Another problem derives from the fact that the library Turbo Vision, used to build the the previous Analyzer version, is replaced by the MFC (Microsoft Foundation Classes) used to build up Windows applications. MFC is very different from the Borland classes, so it was more easy to extract from Analyzer a version without any graphical objects and to build up, starting from scratch, the graphical interface using the MFC.
The version without graphical interface and based on a console approach is called "QUERY.EXE". It allows evaluating statistics on a capture file and extracting packets satisfying a filter. The original Analyzer version for MSDOS had only the first functionality.
Then, after the porting of the console version, the graphical interface was written. Two solutions could be used in order to develop this part:
The previous Analyzer version was also a text editor; this feature was kept in the Analyzer release for Windows.
The main limit of the first version was represented by the fact that the module that is used to print the protocols fields was implemented in C++; so adding a new supported protocol required rebuilding all the application. The capture files analysis was implemented through some files, called 'Statistics', which contained the definitions of some groups satisfying some conditions. Besides, in order to execute the file analysis, it was necessary creating the files which describe the protocols. These files had the extension PDF (Packet Definition Format) and they were written using a quite difficult language. So, as it is noticeable, there were two program parts which managed the same operation: the protocol definition. This redundancy forced the user to modify two parts (both the program source code and the PDF file) in order to add a new protocol to the supported ones.
The code which reads the capture file and the code which reads the 'Statistics' files were kept; the engine which executes the statistics was completely rewritten. Original parsers using a recursive descent were replaced by bottom-up parsers. The grammars were modified in order to create easily the parsed files.
In the first Analyzer version the interaction between the analysis engine and the graphical interface was implemented through the OLE Automation.
This solution was abandoned because of two reasons. First of all the OLE Automation does not give the possibility to manage, at a low level, the communications between the client and the server. Besides the server had some unpredictable behaviors; for instance, often, a dialog window compared saying that the server was blocked. Then the closing process of the server program was very slow and provoked unpredictable events. For instance in Win95 some 'beep' were generated in some particular occasions.