shiva@well.sf.ca.us (Kenneth Porter) (05/20/91)
Has anyone used the PCTCP OS/2 Developer's Kit? What's included? Is it essentially documentation, an include file, and def files for the kernal DLL's? Or does it use Microsoft-compatible libraries? The latter has the disadvantage of being incompatible with other compilers, with the typical hard-wired library request records. Ken (shiva@well.sf.ca.us)
backman@FTP.COM (Larry Backman) (05/20/91)
>> >> Has anyone used the PCTCP OS/2 Developer's Kit? What's >> included? Is it essentially documentation, an include file, and >> def files for the kernal DLL's? >> The DevKit consists of an include tree, set of .LIB files,a set of DLL's, and a tree full of sample programs. All API's are in DLL's. The TCP kernel is not a DLL but a device driver. The DLL's are standalone, multi-threaded DLL's. >> Or does it use Microsoft-compatible libraries? The latter has >> the disadvantage of being incompatible with other compilers, >> with the typical hard-wired library request records. >> As just mentioned; the interface is via DLL's. The Socket API ( as well as the port of the Dos NetLib, FTP, & TN libraries as DLL's) are all _cdecl entry points to the DLL. We originally were trying for Pascal style enty points but the problems with MSC 6.0's errno variable forced us to use cdecl's instead. I'm interested in making sure that the DLL's work with environments other than MSC C6.0. What compiler are you using? Larry Backman backman@ftp.com
towfiq@FTP.COM (Mark Towfiq) (05/21/91)
In case this is of general interest, I am following-up, rather than
replying. Note that Followup-To: is set to the OS/2 group, since this
seems of more interest there.
>>>>> On 20 May 91 07:03:17 GMT, shiva@well.sf.ca.us (Kenneth Porter) said:
Ken> Has anyone used the PCTCP OS/2 Developer's Kit?
A little :-).
Ken> What's included? Is it essentially documentation, an include
Ken> file, and def files for the kernal DLL's?
There is extensive documentation (which I just finished reading for
our 1.1 release), many include files (think of all the include files
necessary for networking in sockets), LIBs (not DEFs) for using the
DLLs, and sample code (including the source to our GNU Finger client).
Ken> Or does it use Microsoft-compatible libraries? The latter has
Ken> the disadvantage of being incompatible with other compilers,
Ken> with the typical hard-wired library request records.
I am not sure what you are asking here, so I will explain what we did,
especially as it relates to OS/2. Many considerations went into our
devkit, but I would say the main one is ease of porting TCP/IP
programs from Unix and from applications written to our Dos interface.
To that end, in addition to 4.3BSD Sockets (calls like socket(),
bind(), gethostbyname(), etc.), we have two other DLLs that make this
process easier.
One is a Unix compatability DLL, which maps the whole multi-user-ness
of Unix into OS/2, and handles some BSD to the SysV-ish Microsoft C
run-time mappings. For the former task, we either emulate (or ignore)
calls which reference UIDs and GIDs, and add functions like alarm(),
the DBM/NDBM functions, opendir/readdir, etc. For the latter task,
many mappings are performed in header file #defines, or in short
functions written to the OS/2 API. In any case, the result is that
you can now port most BSD-type TCP/IP programs VERY quickly.
Another is a C run-time DLL, based on Microsoft's CRTLIB, but with
some functions modified for networking (like perror(), which needs to
also put out error messages like "Connection timed out" and such). We
also supply a UNIX-compatable signal() function, which handles SIGALRM
(unlike the MS C 6.0 signal).
Now, while it would be nice to have this independent of a specific
compiler (right now we require MS C 6.0), the work required to do this
would have greatly delayed the release of the product. You see,
because networking uses C run-time functions, especially ones which
manage file streams and handles, we have to make sure that we do The
Right Thing (tm) when someone calls a read() on either a socket or a
file, and the best way to do this at the time was by working closely
with the robust C 6.0 library.
With talk of Borland C++ being the thing for OS/2 2.0, perhaps our
scheme will have to change. However, OS/2 2.0 (and NT after that),
will probably make life easier in many of these regards anyway.
--
Mark Towfiq, FTP Software, Inc. towfiq@FTP.COM
Work No.: +1 617 246 0900 Home No.: +1 617 488 2818
"The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah