>    Somehowtt i doub it. From what I've heard of EMX, it's libraries try  to
> make sockets and file handles look the same, as they are under Unix. Under
> OS/2, they're not, so the socket libraries for EMX have an interface that's
> slightly different from IBM's. IBM's X Client kit is of course written for

You can still use OS/2 API's directly under EMX.  Most of them anyway, I
don't know about the networking ones.

> their own socket interface. If you're trying to port a genuine Unix X Client
> library, I suppose you'd have an easier time with EMX if the bugs don't get
> you (I'm not trying to imply that EMX has too many bugs - I don't know - but
> it wouldn't suprise me if EMX were less robust). Academic interest aside,

EMX is amazingly robust.  I've only encountered one bug in it so far (very
minor, which I reported to the author and he went "oh yeah" and
fixed it.  If you give it a source code file with a relative path from
where you ran the compiler, like "gcc ../file.cc" it'll look for
#include "file.h" header files in the current directory, not the
one the file is in.  But it works for absolute paths just fine.  Only
relative ones confuse it, and it should be fixed next release.  I found
that out while writing "bake".)

I haven't actually encountered a bug in gcc itself yet.  Gcc is the most
thoroughly tested compiler in existence, that I know of.  It's been spread
across the face of unix for years and years.

> it wouldn't suprise me if EMX were less robust). Academic interest aside,
> for me it's not worth the effort to reproduce what IBM's already done.

If IBM includes the product and instructions on how to program for it in
"warp connect", then you're right.  If they don't, then it's
needed.

Rob
 
--- Xblat