TRP vs TR

[Larry Tyree]

I have received some questions about TRP versus TR and thought I would
share the answers.

But first, if you are getting this message, then you are on the new
reflector at contesting.com.  There are a few people who have subscribed
to the old one at cmicro.com who aren't on this list.  I will update the
list with the additions sometime here soon, and then forward any 
messages sent to cmicro.com to contesting.com.

This change is being made as I am no longer an employee of Cascade Microtech.
My account there will last a few more months.  You can start sending me 
mail at tree@contesting.com in the future.  I will still get mail sent
to cmicro for a few months however.

Why TRP?  Well, some people have been running out of memory.  Generally
this is because they either don't have any extended memory to load 
other programs into (and even DOS), or they haven't run MEMMAKER to
free up enough memory in the lower 640K, or maybe they are trying to
make too many contacts or something like that.

TRP was intended to allow people to use extended memory with the program.
When compiling the program, I can tell the compiler if I want the program
to use extended memory or not.  There are no other differences between
the two programs.  They should operate exactly the same way.

I have had some comments that TRP runs slower than TR.  This is quite
possible as I am sure there is overhead associated with dealing with
extended memory.  The programs RTM.EXE and DPMI16BI.OVL support 
extended memory use.  Anytime you put a program between you and memory,
something is going to slow down.

I think the best plan is to continue using TR as the standard release,
and make TRP available as a special order.  

As I mentioned before, when the program was compiled as TRP, the memory
manager was more picky and I found some minor problems to fix which will
hopefully result in better reliability.  

73 Tree N6TR/7
tree@contesting.com