Xref: utzoo comp.os.os2.programmer:738 comp.protocols.tcp-ip.ibmpc:5903 Newsgroups: comp.os.os2.programmer,comp.protocols.tcp-ip.ibmpc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!clarkson!grape.ecs.clarkson.edu!towfiq From: towfiq@FTP.COM (Mark Towfiq) Subject: Re: What's in FTP OS/2 Developer's Kit? Reply-To: towfiq@FTP.COM Organization: FTP Software, Inc., Wakefield, MA Distribution: comp Date: 21 May 91 10:56:00 Message-ID: Followup-To: comp.os.os2.programmer In-Reply-To: shiva@well.sf.ca.us's message of 20 May 91 07:03:17 GMT References: <24885@well.sf.ca.us> Sender: usenet@grape.ecs.clarkson.edu 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