> Since I plan to take the code forward with support 
 ac> for long file names, 
 > etc., would anyone object to removing the 16-bit (DOS and OS/2) 
 > compiled versions from future development?

 ac> FWIW, it is possible to have support for LFNs in 16-bit 
 ac> DOS programs.  I think you need to write wrappers 
 ac> around fopen(), FindFirst(), etc, though.  But you 
 ac> would need to do that for the 32-bit DOS Watcom build 
 ac> anyway.  I think it's just DJGPP that has C library 
 ac> support for LFNs in DOS, but I can't say for sure, 
 ac> because I'm only going by memory, and that feature 
 ac> doesn't seem to work in Windows 2000, so maybe I 
 ac> imagined it.

Interesting....  I don't intend to add such wrappers at this time....  I
would have expected the OS to handle more of the LFN issues.....  Any
way...  Dead subject for now....

 > The new future targets in this case would be Win32, OS/2 (32-bit),
 > Unix based (Linux, FreeBSD, maybe NeXT Step / Open Step / Mac OS/X),
 > and possibly a 32-bit DOS extender (if someone is willing to help in
 > this area).  

 ac> I hope you're used to dealing with byte ordering 
 ac> (endian) issues, for the non-i386 ports.  :-)

I have no intention of handling endian issues for now.  What does that
mean?  I expect if the code will compile and run on one Linux platform it
will on any other Linux platform.  The problem will be binary files (User
database, Squish areas, various maximus compiled control files, etc.) won't
be usable across different hardware platforms -- at least initially.  Long
term, assuming folks like you are around to step up and help with
development I would expect this to be fixed.  I would need to see what the
Husky project, Golded, the base Linux kernel and similar code uses for
this.  My background includes NextStep.  We had code compiled from a single
source that ran fine on the three different (of four available) hardware
platforms running NextStep -- transmitting binary data between platforms
without problems.  Once the the proper header files and library code is
setup, this could be a minor issue....  But agree that any code that assume
a given bit ordering can cause issues....  At least I'm not having to deal
with various word sizes (beyond the 16/32/64 bit issue), one's vs two's
compliment or other hardware basaed issues.  Take a look at the old TCP/IP
code -- they had Big and Little Endian options and then a third one for one
of the old DEC (PDP) systems.....

The joys of portability....

Thanks for your input.

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01