Tom Brown wrote in a message to Thomas Seeling:

 TB> I looked through the ftpd.exe file to see if I could find
 TB> any clues as to what the file would be.  telnetd uses
 TB> telnetd.cmd, so I thought that there might be an ftpd.cmd. 
 TB> Anyway, I noticed that these applications were all written
 TB> in what looks like 16 bit Microsoft C!  Does this mean that
 TB> the protocol support is all 16 bit as well?  I would imagine
 TB> that if UDP/TCP and under were all 32 bit, the thunking
 TB> overhead of a 16 bit app could be significant when traffic
 TB> is running at LAN speeds.  If UDP/TCP and under are all 16
 TB> bit, then this would explain the 16 bit applications.

The TCP/IP interfaces are all externalized, and are accessible both from
16-bit and 32-bit code.  IBM migrated the network stack itself from 16-bit
to 32-bit in the transition from TCP/IP v1.2 to v2.0; the stack in Warp
Connect is designated v3.0, and the stack in Warp Server is designated
v3.1.

The problem was that, until TCP/IP v2.0 was released, IBM had to make the
16-bit TCP/IP v1.2 run on both OS/2 1.3 and OS/2 2.0.  There was really no
compelling reason to migrate some of the minor applications, such as
FTPD.EXE, when the old 16-bit versions had been thoroughly tested.  With
text-mode Vio applications, they have to thunk in one direction or the
other to get to the 16-bit video API or the 32-bit network API, anyway. 
Where there is some reason to do it, such as where there is some code
sharing between the text-mode FTP.EXE and graphical FTPPM.EXE, there was a
reason to migrate.
 
-- Mike


---