Subj : dosxnt
To   : Paul Williams
From : Jasen Betts
Date : Tue Sep 10 2002 10:09 pm

Hi Paul.

07-Sep-02 03:43:56, Paul Williams wrote to BEN RITCHEY


 PW> Hi BEN RITCHEY, hope you are having a nice day

PW>>> NP. It'd be nice if fixing the PKTFIX program Jesper Soerensen wrote
 PW> PW>>to handle msgs over 16k were that easy.
 PW> BR>I'd have to see the source. :)

 PW>  That's easy enough to solve. :>

 PW>  His comments were that it should be possible to get rid of the
 PW> MAX_MSG_SIZE

possible by rearranging it a bit.

 PW> so that it would process msgs larger than 16k w/o needing to be defined
 PW> to a larger number. I tried values up to 128k and compiled it w/ borland
 PW> turbo c++ 3.0 trying each memory model from tiny to huge but it didn't
 PW> seem to make any difference.

That won't work on a 16-bit compiler.
the lagrest you can go that way is 32767 bytes,  after that you start
running into integer overflow and all sorts of complicated mess.

 PW> Since c/c++ wasn't my thing I can't see what
 PW> would be limiting things when using a larger value.

TC3  uses 16 bit integers (usually signed)

You could re-write getCString (and other places that deal with the message
size) to use   "long int"   instead of  "int" and then compile with huge
model...

should get you more room for longer messages

But really the message size limit is a design flaw...
can we take this to C_ECHO?

with a little tweaking it could be fixed to deal with the long messaes in a
series of chunks, or even a single chunk and then and then remainder (that's
just copied a character at a time from file to the other....)

That way there's be no limit message size other file size limits and disk
space
---
 * Origin: nobody expects a fannish imposition (3:640/531.42)

.