PM>> You don't need to do anything quite so drastic! I've released the

 PM>> program as public domain, and it includes all the source code. You can

 PM>> use any or all of it in what ever way you like.



 RM> Got it, ta. Compiles as is without error under BC4 (doesn't run

 RM> properly, of course). Got 94 "declared but not used" warnings,

 RM> though, good thing they can be turned off .



Ah, I see what the problem is. I hadn't turned on all warnings. The
warnings are easy to fix by making all the messages #defines. Actually, you
could probably descrease the exe size by moving all the messages out of the
headers and into the C++ source files. I only had them in the headers in
case someone wanted to look for a specific message.



 RM> Nice little bunch of classes, btw, just right for "why doesn't this

 RM> sodding thing work this time?" problems.



Yeah, trying to debug some of this stuff can provide hours of amusment :-)



 RM> And I *love* the RE: remover....



Caused me lots of grief until I realised that some messages actually had
*two* RE: prefixes! Aaarrrggghhhh!



 PM>> The code is C and C++. It was written with the OS/2 version of BC++.

 PM>> I've compiled it under the MS-DOS version, but it has a hard time

 PM>> running due to the limitation of only being able to allocate 64K of

 PM>> memory at a time.



 RM> I've noticed that. Probably the line that asks for a chunk of

 RM> memory equal in size to the combined size of all the packets is the

 RM> main killer....



Unless you have less than 64k worth of packets of course :-)



 RM> Is "int" a 32 bit thing under BCOS/2, btw? The program certainly

 RM> seems to expect it.



Yes, it is 32 bits. I tried to use longs where I really needed large
numbers, but obviusly I missed a few places. I found one place yesterday
and fixed it.



 RM> I can see how to alter the mem requirements to suit dos, mainly by

 RM> storing only IDinfo and subject for the sort, not sorting on date,

 RM> and sorting on only the first 25 odd subject chars (the chance of

 RM> the subject lines differing after 25 is low, and I think I can

 RM> tolerate the oddities). Without using kludges, I'll still be

 RM> restricted to being able to sort 1500 odd msgs, though.



My original code did pretty much this sort of thing. I changed it to read
the packets into memory to speed it up. I just had a look and unfortunately
I haven't kept a backup of my program as it was then.



If you have a 25 byte subject and the info needed to find the message on
disk (2 byte index into the packet table + 4 byte offset into the file) you
end up with 31 bytes per record. This will allow you to sort about 2,100
messages.



The other approach is to allocate a table of pointers to sortItems. Then,
each time you need to add another record, allocate memory for the sortItem
and add it to the table. You'll need to changed the qsort compare routine a
little as well if you do this.



 RM> If I get really short of mem, I can start using overlays for the

 RM> code, too (thinks: 50k core code, two or three 20k overlays, would

 RM> have to be pretty desperate)



Jeeze! Are you trying to get this to run on a C64 or something? :-)



 PM>> You'll also need to increase the stack size, as it

 PM>> allocates some large structures as local variables.



 RM> Haven't struck that problem yet. Is it likely to be something that

 RM> the compiler will spot?



You'd probably need to turn on stack checking for it to pick it up. If you
don't, and you overflow the stack, weird things could happen.



The biggest culprit is the pktCollection class, as it declares a table of
packets, each a few hundred bytes long. I've changed it so it now allocates
memory as it's required, which means stack size won't be a problem. It'll
also help with the memory situation as it will only allocate what it really
needs. I'll netmail the updated source to you.



 PM>> Good luck! 



 RM> psychic, he's gotta be psychic



:-)





Paul



--- GoldED/2 2.42.G1114