This contribution is a conversation between Samuel Liddicott
sam@campbellsci.co.uk and Bela Lubkin belal@sco.com

 Sam>> Am I right in understaning from your message that a program might
 Sam>> conceivably compile to COFF and fail to run on 3.2v4.2? Even if its all
 Sam>> staticly linked (however you do it [I'm a delphi man]). If so then 
 Sam>> I need lot of thought.

 Bela> Your understanding is correct.

 Bela> System calls are made by calling a generic kernel entry point with a
 Bela> system call number in a register.  Newer system call numbers will be
 Bela> rejected by the old kernel.  There is no compile-time protection against
 Bela> this.  If a program calls one of the newer system call numbers on an
 Bela> older kernel, it will get a signal (SIGSYS) and die, unless it's
 Bela> arranged to trap or ignore that signal.

 Bela> [about readv/writev]: the main place it's likely to matter is in network
 Bela> programs.  writev, in particular, helps ensure that data is sent as a
 Bela> single network packet instead of many smaller ones.  Could be a serious
 Bela> performance issue if the program thinks it's using a real writev and
 Bela> tries to take advantage of it.  A well-written program will probably
 Bela> have something like:

 Bela>   #ifdef HAVE_WRITEV
 Bela>   ... code that uses writev
 Bela>   #else
 Bela>   ... code that constructs a buffer and calls write() once
 Bela>   #endif

 Bela> So it would be better if they didn't find writev() at all.  But other
 Bela> programs may not have such ifdefs, or they may be using writev just for
 Bela> convenience and wouldn't be harmed by a multi-write implementation.
 Sam>> As far as fattach or fdir go, if a program "CAN" be compiled for 3.2v4.2
 is
 Sam>> it then presumed that there are compiled time #def's to stop it trying t
o
 Sam>> use those functions? Which I just set (perhaps by hand if a configure
 Sam>> script got it wrong?)

 Bela> No, that's the whole point of this discussion.  You can freely call
 Bela> these things and nothing will stop you, except the program will fall on
 Bela> its face on 3.2v4.2.

 Sam>> Otherwise, presumably I just wait for the errors to come up at compile
 Sam>> time, and see why, look for any compile time flags to choose the right
 Sam>> version, if not plug in my own and send in a patch?
 Sam>> Finally, have I missed any gotchas, in which it might seem to work, but
 Sam>> fail? [Presume I have done what you said and compiled a library that has
n't
 Sam>> IDEA: What can I do with the "best no-devsys devsys" as found in
 Sam>> kuso.shef.ac.uk? Maybe IT has the right libraries, which might WORK and
 Sam>> STOP a configure script detecting these dodgy calls?

 Bela> The SCO XENIX/DOS Cross Development Supplement will
 Bela> work in that respect.  It provides a compilation environment which uses
 Bela> its own libraries, which have none of the new functions.  Essentially
 Bela> the ODT 3.0 libraries, though perhaps some bugs were fixed.

 Bela> Meanwhile, as I said, here is a script which implements some form of
 Bela> back-portability ftp://ftp.armory.com/~filbo/makelibv42.