Subj : dosxnt To : Jasen Betts From : Paul Williams Date : Sun Sep 15 2002 03:22 am Hi Jasen Betts, hope you are having a nice day PW>> His comments were that it should be possible to get rid of the PW>>MAX_MSG_SIZE JB>possible by rearranging it a bit. Don't look at me. 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. JB>That won't work on a 16-bit compiler. JB>the lagrest you can go that way is 32767 bytes, after that you start JB>running into integer overflow and all sorts of complicated mess. Well seems like if you were to fix it to that point there shouldn't be that much of a problem compiling it w/ a dos extender of some kind. There are a couple of free ones like the causeway extender for watcom c/c++ and asm, and the dos32 which is free for n/c use, replaces the dos4g/dos4gw/causeway/pmode extenders and works under dos/w3.x/9x/nt/os2. I've got both of those here in the filebase infact. PW>>Since c/c++ wasn't my thing I can't see what PW>>would be limiting things when using a larger value. JB>TC3 uses 16 bit integers (usually signed) How abt MSC/C++ 7.0? I've got that one as well. JB>You could re-write getCString (and other places that deal with the message JB>size) to use "long int" instead of "int" and then compile with huge JB>model... JB>should get you more room for longer messages I think 32k would probably work most of the time, but since the pkt spec doesn't have a max msg size.. And I have had msgs that hit 128k go thru before. JB>But really the message size limit is a design flaw... Well as I understand it was a bit of quick&dirty programming based on a comment made in that echo abt systems that didn't add a msgid kludge to mail. I show Jesper in the current nodelist at 2:204/254 He might have an idea or two since when he originally wrote the program. JB>can we take this to C_ECHO? Don't have that one. Think I did abt 6yrs ago but.. you know.. :/ JB>with a little tweaking it could be fixed to deal with the long messaes in JB>a series of chunks, or even a single chunk and then and then remainder JB>(that's just copied a character at a time from file to the other....) Wouldn't that mess up w/ the crc calculations for the msgid though. As I understand it, the msgid value is based on not only the header info but the msg content as well. JB>That way there's be no limit message size other file size limits and disk JB>space And once you have fully functional code the whole thing can be converted over to assembly for a speed boost and shrinking in size. ];> (gotta drag it ontopic *somehow*) -=> Yours sincerely, Paul Williams <=- .... "It must be the elevated testosterone levels." -- Danny Davids --- Terminate 4.00/Pro * Origin: Insanity is a way of life and I've made it *MINE*!!! (1:387/710) .