Subj : Re: Reply Splitting
To   : Ken Hrynchuk
From : William McBrine
Date : Sun Oct 28 2001 02:17 am

-=> Ken Hrynchuk wrote to William McBrine <=-

 KH> I've noticed, in this version, that there's a limit to the size of the
 KH> reply that's being split, after which truncation will take place. The
 KH> limit appears to be a little over 80K (QWK mode, MaxLines: 200). Do
 KH> you know if the limit's a product of the 16-bit code, or if it's also 
 KH> present in other versions?

When splitting a reply, MultiMail first reads the entire thing into memory,
so that it can format it with MakeChain() (the same routine used to break
it up into lines for display purposes) to calculate the number of lines.  
So, it's limited by available memory. I wouldn't be surprised if that came
to around 80K in a particular situation, but it will vary.

Technically this limit (available memory) applies to all versions, but
you'd only notice it in the XT version, since that's the only one that
experiences significant memory constraints. I've used the Linux version of
MultiMail to enter and split replies that were over 40 megs long.

Strictly speaking, the problem is real-mode addressing (limited to 640K)  
vs. protected-mode (16M+), rather than 16-bit code vs. 32-bit. A
hypothetical 16-bit protected-mode version of MultiMail (e.g., for 16-bit
DPMI or OS/2 1.x) could still handle very long replies (up to 16 megs,
minus the size of the program and other data). Even more strictly speaking,
the problem _is_ the number of bits, but it's 20 (the number of address
bits in real mode) rather than 16. (16-bit protected mode gets you 24
address bits; 32 has 32. Confused yet?)

Of course, it should be possible to redesign the split function so that it
doesn't require the message to be in memory, but I'm not sure that would be
worth the trouble.

I must say, I'm surprised to hear of someone trying to post multi-thousand-
line replies with the XT version. What the heck are these things?

 KH> Also, it's no biggie, but I must admit that I do miss the ability to
 KH> 'prompt to save read pointers'; I found it quite handy for testing.
 KH> <g>

Heh. I didn't think anyone had ever used that but me, and I gave i up some
time ago. (Now I habitually press 'U' after reading something that I want
to save.)

.... Predestination was doomed from the beginning.
--- MultiMail/Linux v0.41
 * Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

.