Dec 052017
 
Version 2.24 of MR/2, the OS/2 off-line mail reader. Text mode.

Full Description of File


MR/2 - A QWK compatible mail reader for
OS/2 text-mode. Menu/picklist driven,
mouse support, thread summary, multi-
threaded searching, virtual conferences,
address book, internal editor, speller,
thesaurus. Reply templates, clipboard
access, BBS specific INI's. Message
deferring, reply logging, long file
name support. Much more ... Many
SLMR/OLX compatible keystrokes.


File MR2_224.ZIP from The Programmer’s Corner in
Category Recently Uploaded Files
Version 2.24 of MR/2, the OS/2 off-line mail reader. Text mode.
File Name File Size Zip Size Zip Type
EMAIL.ICO 3192 370 deflated
EXAMPLE.ADR 1274 608 deflated
EXAMPLE.TF 4121 1141 deflated
FILE_ID.DIZ 386 266 deflated
MISC2.TAG 4955 2699 deflated
MQWK.CMD 7060 2099 deflated
MR2.DOC 231884 57841 deflated
MR2.EXE 281058 141784 deflated
MR2.HLP 27525 8799 deflated
MR2.ICO 888 183 deflated
MR2INI.ORG 28975 10219 deflated
MSG2REP.CMD 3198 1158 deflated
NEWMR2.ICO 888 238 deflated
OS2.TAG 3360 1662 deflated
READ.ME 104767 36785 deflated
REGISTER.DOC 1995 796 deflated
SAVEVCS.CMD 6146 2345 deflated
SEARCH.INI 5620 1596 deflated
UNQWK.CMD 6025 2215 deflated
WELCOME.QWK 2416 2071 deflated

Download File MR2_224.ZIP Here

Contents of the READ.ME file


MR/2 - A QWK compatible mail reader for
OS/2 text-mode. Menu/picklist driven,
mouse support, thread summary, multi-
threaded searching, virtual conferences,
address book, internal editor, speller,
thesaurus. Reply templates, clipboard
access, BBS specific INI's. Message
deferring, reply logging, long file
name support. Much more ... Many
SLMR/OLX compatible keystrokes.
MR/2 - A QWK Compatible Mail Reader for OS/2. 07/08/95

Copyright (c) 1994, Knight Writer Software Company.
All rights reserved.

===================================================================
N O T I C E
===================================================================
This IS a shareware package, and does require a registration fee if
you choose to continue using it after 30 days. The registration
fee is currently $25 US. Eventually, the product MAY have a
"begging" screen with a key-file that will register the software
and suppress it. The more interest I get, the more likely I am to
continue with improvements.
------------------------------------------------------------------

CONTACTING THE AUTHOR
=====================

You can contact me in a number of ways. Unfortunately, I can't
provide a phone number at this time.

US Mail: Nick Knight
1823 David Ave.
Parma, Ohio 44134

Fido netmail: 1:157/2 to "Nick Knight"

Internet: [email protected]

This is a BBS service, so mail is not "instant".
I can usually be reached during the week more quickly
by emailing me at [email protected] Better yet, mail
the message to BOTH addresses, just to be safe ๐Ÿ™‚

Fido Echomail: Find the Fidonet OS2PRODSUPPORT conference. I'm there.

Echomail messages to me in more general conferences are
discouraged, as keeping them "on topic" and
interesting to the masses would be difficult. I do
read OS2, OS2PROG, C_PLUSPLUS and DR DEBUG daily,
though. OFFLINE echo also (deals with mail readers),
this might be THE place to ask public questions, eh?

I recently have acquired access to a host of other
networks with OS/2 conferences. These include RIME,
SmartNet, Uninet, Intelec, Nanonet, Racenet and some
others I can't remember.

Direct BBS: Leave a message on the Nerd's Nook BBS (1:157/2) at (216)
356-1772, 356-1872 or 356-1431. I check in here multiple
times a day. I will also keep the most recent copy of
MR/2 posted here. Other boards (non-local) will get
updates at my convenience.

****** INTERNET ADDRESS CHANGE!!! PLEASE READ IF FTP'ING **********

Internet FTP: My work machine is now on the internet "full time". For
those of you used to the difficulties accessing the the
"old" site, this *should* be a relief. Only time will
tell! I have an anonymous FTP "site" setup as a
directory on my machine. THE ADDRESS HAS CHANGED FROM
WHAT WAS PREVIOUSLY PUBLISHED! Ftp to nick.secant.com.
You can upload bugs, packets, notes, whatever.


**************************************************************************
**************************************************************************
** NOTE: Nerd's now supports an MR/2 conference **
** and file area. Conference #208 is dedicated to **
** MR/2 support and files. File area #45 contains **
** MR/2-related files. Any file uploaded into **
** conference 208 will be placed in file area 45. **
**************************************************************************
**************************************************************************

Nerd's does support file requests (157/2 or 157/3)

Compuserve: I check only once a week or thereabouts. Try mail to my
user ID - 76066,1240, although internet mail has proven
to be a faster approach.


Changes included in v2.24
-------------------------
CALL FOR BETA TESTERS: Internet email now, newsgroups later. A direct
connection is required (SLIP, PPP, LAN, whatever). Let me know if you
want to preview this PM-based product and provide feedback. Email me.

o The "J" - jump to original/source message was broken when I added
the new folder stuff. Fixed.

o INTERNET ftp site has been changed. Use nick.secant.com instead
I've also registered and upgraded the ftp daemon, and the new
version is supposed to relieve some of the access problems users
have had in the past. Secant Technologies is my "new" employer
although, in reality, this is just a spin off from my old company,
Raleigh Systems. This means the same basic SLIP connection, but
much less traffic over this line. In theory, it will work much
better. Whatever the case, I have much more control over how this
domain is managed :).

EVEN BETTER ... I wrote a "connection watchdog" utility that checks
the SLIP connection every 5 minutes and attempts to re-establish it
if pinging our provider fails. I've seen this work nicely a couple
of times, which means nights and weekends ought to provide an
excellent chance to connect.

Email can be directed more directly to me at [email protected] I ONLY
SEE THIS ADDRESS DURING THE WEEK, though. As mentioned above, the
best approach is to send message to me at both addresses:
[email protected] AND [email protected]

o Fixed a minor template problem where "new" internet email would not
copy in the TO: address supplied in the header edit form. If no
message (i.e., a new message) or address-book entry was selected,
the "from" user was checked for an "@" sign. In the case of a new
message, the "to" user needs to be checked. Fixed.

o Somewhere along the line, I fixed the 'O' command. This again
loads a command shell (cmd.exe) directly from MR/2. Apparently,
Mike uses this, so I'll make sure I quit tinkering with it :).

o Ooops. If the new VCPriority was not specified in the INI file,
then it would default to "Normal". Fine. However, the "delta"
value was never initialized, causing it to be set (by default) to
zero. This is "full normal priority". It had too much priority;
the "old" default called for Normal, -31. I now initialize the
delta to -31 at program startup.

o I started playing more seriously with UQWK and how MR/2 interfaces
with it. I've been reading Internet news for a long time using
UQWK to create the packets. Worked great, but I never looked into
replying. If I wanted to reply, I'd usually see the message in
my PC-Ohio packet. BUT, I started getting newsgroups that aren't
carried by PC-Ohio, and I found a message I *had* to reply to ...

o Modified the way articles from USENET-declared conferences are
quoted. Headers are now stripped from quotes. I can make this
optional, if desired. Just yell.

o I modified the way initials for quoting are generated for Usenet
areas. If I find an internet header, and the QWK from field has
an internet address in it ("@" found), I try and extract valid,
usable initials from the Internet header.

o The example template in this release includes the code necessary
to create a COMPLETE and CORRECT Usenet news header. This will
only work if the target system (UQWK, for example), supports the
uploading of articles with headers. I have one little problem with
lines wrapping, but other than that, it seems to work great.

o I modified ZTC's runtime library. Again. Support for the %Z
timezone variable was missing from there date/time formatting.
It isn't any more :). I added support for %Z, which will extract
the timezone from the environment variable TZ (for example, Set
TZ=EST5EDT for eastern US'ers). The default (if TZ isn't set)
is the eastern time zone. I kludged in %z, and that will be
replaced by -0500 (the 5 in the TZ spec), which represents the
difference between the current time zone and GMT.

o Ah, now the fun stuff. I added new template variables:
@[email protected], @[email protected] and @[email protected]

IHeaderInfo must have a "parameter" passed with it. The parameter
string will specify an Internet message header value to find and
insert. For example, @IHeaderInfo:[email protected] will insert the list
of newsgroups found in the source message's header. Any string may
me used ... if not found, a zero length string is returned.

SystemDate is as flexible as you can get when it comes to formatting
the current system date and time. You have access to ALL the
variables a programmer has when calling the runtime library function
strftime(). For example, the variable expression (as used in the new
Usenet template section) "@SystemDate:%a, %d %b %Y %H:%M:%S %[email protected]" is
replaced with the current date/time formatted similarly to "Sun, 01
Jul 1995 17:20:12 EDT". I offer the following as a quick reference
to the % values available. Mix and match as desired:

Weekday name: %a or %A (Mon or Monday)
Current Week day #: %w (0-6, Sunday = 0)
Month: %b or %B (Jul or July)
%m (2 digits, e.g., 07)
Year: %y or %Y (95 or 1995)
Default display: %c (02-Jul-1995 17:30:12)
Default date display: %x (02-Jul-1995)
Default time display: %X (17:30:12)
Day of the month: %d (On July 2nd, this equals 02)
Current hour: %H or %I %p (18 or 06 pm)
Current minute: %M (Minute as a 2 digit number)
Current second: %S (Second as a 2 digit number)
Julian Date: %j (Julian date, e.g., 183)
Current Week number: %U or %W (Sunday or Monday starts week)
Time zone: %Z or %z (EST/EDT or -0500 (diff GMT))


Environment also must be complimented by a parameter. The string
parameter will specify the environment variable to lookup up, and
whose data will be inserted. For example, "@Environment:[email protected]"
will be replaced (on my system, at least) with "C:\os2\cmd.exe".

o OK, I added some "pre wrapping" to the template logic. This to
correctly format a Usenet message header before the internal
editor decides to word-wrap it incorrectly. This logic will
actually pre-word-wrap ALL template lines. Shouldn't (??) make
a difference. I'll add more code if someone informs me otherwise.

Anyway, I am now satisfied that I can correctly generate RFC-821
and RFC-1036 compliant message headers. With this, I will quickly
throw together docs on how to use MR/2 with a direct internet
connection. I will first support UQWK, then add SOUPER later
(still planning to support SOUP, although I don't know why).

o Yet another template variable. This one is @IHINDENT:[email protected], and was
added mostly to aid in my formatting of Internet headers (Internet
Header INDENT). I don't like the way this works; it's bound to
change. Mentioned only because it's visible in the new Usenet
template sections. It's really a Second Line indent spec, and
perhaps that's what I'll rename it to ๐Ÿ™‚ Later: added INDENT:n and
RIGHTINDENT:n. These can be used to increase the margins on both
sides of quoted text, for example. IHINDENT is a specialized
"second line" indent and has NO USE outside of the internet header
area.

o I've been adjusting the internal editor, again. I got mad when
it crashed on me, trying to import a 100K file :(. I'm
determined to make it successfully import huge UUEncoded files.
I also want to fix the problem with marking super-long blocks
of existing text. All of this requires reworking the internals,
with which I am now unfondly familiar. I did improve things a bit,
but the job is not done.

o Modified the spelling checker to recognize words with embedded
apostophies as single words instead of two pieces-parts. I'll
adjust this code, over time, if necessary.


Changes included in v2.23
-------------------------

o Fix for new folders logic where folder save/selects would use the
"default" folder path and ignore any FoldePath statement in the INI.
This now uses the FolderPath setting when listing folder for import
and for saving messages.

NOTE: I tried to allow for the importing of folders by exact file
name, in effect allowing you to list/pick folders in a different
path. Well, the picking part went just fine, but there was a big
problem. MR/2's internal engine simply says "if they pick a
folder conference, go to the FolderPath and open this file for
reading". There is currently no provision for remembering folders
outside this path. Not too difficult a fix, but not one I can
address at this moment.

If you wish to "archive" a message and use it as the source for a
reply targetted for a different BBS, you'll have to SAVE the message
to a folder in the target BBS's folderpath. Only folders in the BBS's
FolderPath can be imported, but a message can be saved to a new or
existing folder anywhere on your PC.


Changes included in v2.22
-------------------------

o I found the beep-on-personals problem. It was an interesting mistake
that would definitely cause it to work "sometimes". Fixed.

o Finally, I've added some control over the priority of the background
thread that creates virtual conferences (VC's). I once tried to
make this an "Idle time" thread, but it often locked up the session
on exit. This turned out to be a conflict with pulse and other
CPU/resource monitors. So, since day #2, this thread has run at
"regular" priority, with a -31 delta* (the lowest "regular" setting
there is). It was often still too resource-hungry.

So, for the folks that like to keep things simple, I'll tell you
that you can now use the INI parameter VCPriority to set the thread
priority to either NORMAL or LOW. Low results in an "idle time"
setting, with a +2 delta. A default idle time setting with a delta
of zero still locks the session on exit.

*DELTA's are merely "fine tuning" adjustments. They're provided to
give you a way to adjust thread priorities in finer increments.

NOTE: I changed the default to now be LOW. This seems to be about
the same speed with no other activity, but the system is more snappy
when you need it to be. Don't like it? Add the line:

VCPriority = Normal

to your INI and you're back to the old setting. This results in
normal/regular priority with a -31 delta.

OK. For those that like to twiddle more (others, skip to the next
dot-item :). You can supplement the Low/Normal settings (again, for
you programmers out there, that's Idle Time/Regular, respectively)
with specific deltas. Simple give the delta numerically, after the
category specifier, separated by a comma. For example:

VCPriority = Low,1

will slow the VC thread down even more. All settings searched a
simple packet on my system in 22-25 seconds, except for this one.
This one stretched the search out to 40 seconds. Oh, sure, a value
of ZERO will not even search, and will lock the session on exit.
For Low priority, don't use any delta lower than 1. For Normal
priority, valid values are between -31 and +31, including 0.

o Yet another VC-thing, related to the above but actually resulting
in a new VC "subfeature" ๐Ÿ™‚ You can now TURN OFF all virtual
conferences defined. Actually, you're clearing them out of
memory. Where this comes in handy is in local INI's, where your
packets don't benefit from you "global" INI's. You can have
a specific local INI that first declares VC's "off", then defines
some specific VC's just for that BBS/INI combination. So, for
example, with a little UQWK trickery and creative-INIizing,
I don't have to search the binaries and non-computer related Usenet
newsgroups for keywords that, if they are found, aren't in the
context I was looking for, anyway. Do you know how often strings
like "MR2" and "BMR" turn up in UUEncoded binaries? ๐Ÿ™‚

o "Subject" lines in the body of a message will no longer highlight
automatically. I did this for myself, and liked it. So, if you
also prefered this, simply modify your Color INI parameter. The
5th pair of HEX numbers, if provided, will set a color for the
SUBJECT lines. To recreate the previous release's colors, simply
tack on the 4th (usually the last) pair of hex numbers again, to the
end of the string. For example, my old Colors strings said:

Colors=0F0E0AE1

and I changed it now to:

Colors=0F0E0AE1E1

o MR/2 will now prompt you for confirmation when you exit. Previously,
pressing ESCAPE on the packet select screen will cause an exit from
MR/2. Now you are prompted to confirm exiting.

NOTE: this is a bit of a worry for me, as I kind of like exiting
quickly. I will admit, I sometimes exit "by accident", but I also
like the fact that I can press ESCAPE 6-7 times from anywhere and
be assured I'm out of MR/2 withou waiting to make sure it happens.
I made prompting the new default. If you don't like this, and
prefer the old way (no confirmation prompt), simply modify your
MR2.INI file and add the line "ExitPrompt = No".

o MR/2 now works better when using an external editor and NOT SAVING
your reply. This has great benefits for those whose settings say
to edit the header ONLY BEFORE, and some benefit to the others.
MR/2 now can tell if the reply file has been changed during the
editing process. If it hasn't, MR/2 will not save the reply, and
will not prompt for a disposition when in AFTER mode. Basically,
MR/2 sees no-change in the reply file as being a "cancel reply".

PREVIOUSLY: If the settings called for not prompting for header
info "after", MR/2 would save the reply automatically, even if the
file reflected no editing by the user. If AFTER mode prompting was
on, MR/2 would prompt for a disposition, again, even if the reply file
was not changed. I don't see any problems with changing this ... I'm
sure someone will let me know if they see otherwise :).

o I added a new "feature" in response to some problems with performance
involving large reply logs. This change can speed things up, and
if you look hard enough (with a little imagination :), you'll see
lots of potential for expanding on this. This is a move towards an
(optional) database-type add-on.

Anyway, you now can IMPORT replylog-type files into your list of
"Conferences w/Mail". The InBasket and ReplyLog are both QWK-based
"folders", and you can now create your own. This allows you to,
for example, rename a bulging ReplyLog to another name. The
result is that you start with an empty reply log. However, you
can still "import" and access the older reply log when/if needed.

When you press ALT-I from the Conferences w/mail pick list, you are
presented with a list of all *.DAT files in your BBS specific folder
directory (note that the Inbasket and ReplyLog are suppressed from
this list). If you select a folder, it is added to the conference
list after the two system/automatic folders.

Ok, so you can manually copy reply logs and InBaskets around to
create importable folders. This has some usefulness, but only to
a limited extent, right? You can also "file" individual messages
into an existing, or new, folder. The '/' key now functions
as the save-to-folder command, at least until I think some more.
When you press '/' while viewing a message, you will be allowed
to select from a list of existing folders. Pressing ESCAPE from
this list will allow for entry of a "new" folder name. These
messages are stored in QWK format, as opposed to TEXT format used
by the 'S' key. That means that these messages may later be
"imported" and read as another form of "virtual" conference.

PLEASE consider this "beta"-type code. It's new, and shouldn't
effect anything else, but it underwent very limitted testing.
I'm sure I'll improve on it greatly over the next couple of months.

Note that you can import the same folder dozens of time. It does
you nothing for you, though :). There are dozens of helpers and
lots of error checking I will add. Later.

---- Complex Tutorial on how to waste much of an evening ๐Ÿ™‚ -----

What I did was copied my reply log (ReplyLog.Dat in my BBS specific
sub directory off of MR/2's home path) to a "save" file. I then went
through and marked all of my 1995 replies as "killed" (remember, I
saved the original file). I followed up my exiting MR/2, which then
repacked my ReplyLog, removing all killed messages. This file now
contained only pre-1995 replies. I copied this file to a file named
"ReplyLog-1994.Dat" (I work off of an HPFS drive), then copied the
save file back to ReplyLog.Dat. I then manually marked all of the
pre-1995 replies in the "current" reply log as Killed and repacked
(Actually, I first set my PurgeAfter setting to a safe number of
days greater than the julian date, that made things quicker). I let
MR/2 repack the log, removing all old replies. I now have two reply
logs, a current/active version for 1995, and an importable file
containing all older replies.

I know, this begs for some automation, batch killing and even an
external packer. As I mentioned, lots of room for expansion!

SUPPLEMENT: This is also great for me now, as I read/reply from
both work and home. I was always wanting to access replies from the
"other" system, but had no sane way to do it, even if I happened to
have the "other" reply log accessable. Now, it's a simple matter of
copying the other log to another name and updating it periodically.
I now have a "Work's ReplyLog" at home, and visa versa.

----- End of tutorial!! -----------------------------------------


Changes included in v2.21
-------------------------
So much for not working on the text mode version. I knew it would
happen this way - the bugs wouldn't come out until I said it was done.
I probably have one more very minor update in a week or two, but I *do*
plan to revist PM work starting NOW.

o I broke RIME routed auto-addressing when I installed the Usenet
conference INI parameter. Fixed.

o Minor things for myself; may not be permanent. Subject: lines in
Internet message headers are not highlighted with the "search hit"
color. Only if *not* reading a virtual conference.

o Modified SAVE function slightly. If you're saving a file that starts
a UUEncoded "binary" message (or series of messages), the SAVE file
default is derived from the UUEncoded banner. This will need to be
made optional and/or easily reversable.

o I added code a while back to attempt to always fill the "To:" field
with something for Internet-type replies. This has proven to be
too aggressive and has been "calmed down" a bit.

o Just for general information: Someone hit me with a packet that
crashed. It contained about 9 message, but the control.dat file
described almost 6000 conferences. I couldn't see this as a problem,
as I read a BBS with 4000+ now, with no problem at all. Well, it
turns out to be a "sort" problem. I currently use a binary tree
sort. These are great for "randomly distributed" list of conference
names (a list in no particular alphabetical order), but absolutely
atrocious for pre-sorted lists. And that's exactly what was wrong.
The conference list was, for the most part, pre-sorted. This causes
the sort to slow to a crawl AND, with a large enough list, can
cause a stack overflow. (The binary tree "inorder" is recursive).

My suggestion to this user was to set SortMasterConferences=NO. That
solved the problem on my system, and caused no real loss of
functionality, as the list was mostly sorted, anyway. Until I go to
32-bit and switch to a "new" hi-tech sorting algorithm.

o I needed a new function on the packet select screen - so I added it.
ALT-T now allows you to change the date/time stamp of a packet. it
defaults to 01-01-80 12:00, so as to move the packet to the bottom
of the list (descending date sorts only). This will keep me from
inadvertently deleting sample packets that I want to keep for
awhile.

o FolderOrder would not be allowed to work correctly if used in
conjunction with the AutoFirstKey option. Fixed so that the
AutoFirstKey is ignored is a FolderOrder has been specified and
in fact, you are reading a folder.

o Small fix for editor open-file error - better error handling.

o Alt-U from the packet selection screen. "Un Saves" virtual conferences.
Simply marks the packet with an EA that tells MR/2 to rerun VC's
next time the packet is open. I plan on "auto detecting" the
modification of any VC definitions, and performing this automatically.
Until then, at least it's available as a manual method.

o Ctrl-C handler. This was a toughy. I had the editor crap out on me
a couple of times. Other users complained, also. I've been trying
FRANTICALLY to figure this out. Any and every time I went to find it,
the internal editor work flawlessly. It got me again tonight, and
I finally figured out why. I started with a fresh, previously unopened
packet. The Save VC's process, once it started, reset my CTRL-C
handler to the system default, which is to "break" when pressed. I
now save/restore the CTRL-C state before and after. Solved. Sorry ๐Ÿ™

o Minor help file additions.


Changes included in v2.2
------------------------
I'll be in PM mode for a while now. I'll address any bugs that pop up,
but enhancements and additions will have to originate from the new
MR/2 PM side, if they happen. When I get back into text mode, I've
got some big plans :). Again, if you're interested in testing my
SOUP packet support module, please contact me.

o '/' now defers to ReplyLog. It used to work as a synonym for the 'D'
key (Defer message to the inbasket). It was brought to my attention
that a user might want to save the "last" message of a reply thread
into the reply log, even though he wishes not to continue the thread
with a reply. This made almost TOO much sense, so I added this
ability. Simply find a message you wish to include in the replylog
and press '/'. Now, it copies it in there, and it obviously *isn't*
from you ... so it's now more than a ReplyLog, I guess.

o Edit Header: I modified the fields for From, To and Conference
so that they now use "autoclear" editing mode. Upon entering one of
these fields, if you press ANY alphanumeric key without moving the
cursor first, MR/2 will clear the field entirely before registering
your keystroke. We'll see how folks like this ...

o Entry fields in general: Well, there have been a couple of handy
"special" keys available within all entry fields (as in the
Message Header Edit screen) since day one ... it just seems I've
never documented them! I've added a couple more and modified some:

Home, End, Cursor Left/Right - these are obvious and "known".
Ctrl-Y or Ctrl-X - Clear the ENTIRE field's contents (delete all).
Ctrl-D or Ctrl-Z - Clear from cursor to end-of-field.
Ctrl-F or Ctrl-RightArrow - move forward to start of next word.
Ctrl-R or Ctrl-LeftArrow - move backwards to start of previous word.

o Template variables @[email protected] and @[email protected] now accept a numeric
parameter, if needed. Some gateway addressing schemes (like the one
at OS/2 Shareware) provide an internet email message via netmail.
With this comes a "double FROM" line, the first being a netmail
address, the second is the real internet address. When MR/2 would
go to resolve the internet address, it would see the first From and
select this as the reply's To: target. Wrong. The NEXT From line
would be the correct one to parse, but MR/2 would not look further.

For these case, you may now plug into your template something like
@Internet:[email protected], where the 3 tells MR/2 to START looking at line 3 and
on. This will solve the OS/2 Shareware problem, I think.

o Modified the template variable resolution logic a bit. Often MR/2
would search an entire message to resolve a variable. I shortened
this for some variables, particularly Internet header vars. The
search STOPS at the first blank line.

o Bug I introduced with the Usenet template section. If reply was to
a "Usenet" conference, it would be switched to PRIVATE by default.
fixed.

o Internal editor: Problem when CTRL-O was used to open a secondary
file, and then ESCAPE was pressed with that file "current". If the
file was not changed, the editor would EXIT, no matter what the state
of the other open file was (usually your reply, in progress). The
reply would actually get saved to the defined ReplyFile name, but
MR/2 would not save it as a reply. Now, ESCAPE from the "other"
buffer handles the "other" file properly, then returns to the
original file for further editing.

- Last minute changes - reworked this even more. In testing, I found

all sorts of little gotcha's involving the extensive editing of two
files at the same time. I'm happy with the changes I made; it will
solve most of my own personal "lost text" situations. I use the
internal editor myself and I do *tons* of multiple buffer functions
and cross pasting. I'm sure I'll tweak this a bit more over time,
but it looks good now. For example, if you save or exit one file,
and the "other" file has been changed, the editor switches to that
window and awaits a disposition keystroke. Previously, MR/2
"guessed" as to what you wanted to do, usually guessing to save it.

o By request, and another good one. I've added the key functions
ALT-I and ALT-N to stand for the Internet and Netmail Conferences,
respectively, on both the Edit Header screen and the Master
Conference Selection screen. So, if your INTERNET and/or NETMAIL
INI parameters are set, instead of having to remember and type in
these number, of find the conferences in the pick-list, simply press
ALT-I or ALT-N.


Changes included in v2.19
-------------------------
Folks! I've seen quite a few of you mention MR/2 in public echos,
pointing out its features and "sticking up" for it. I appreciate the
support! You have no idea how good it makes me feel to see someone ask
for feature in "some other reader", only to have 2 or 3 of you respond,
"oh, you mean like MR/2 already has?". Again, thanks!

Yes another beta. Next week this goes out as v2.2, no matter what. I
just had too many unconfirmed "fixed" bugs to let v2.2 out. I'll let it
ride one more week, then let it out. Once it's widely available, I'll
see who reports what.

o A couple of more changes fixing message >32k and <64k. Searching was
disrupted by any message approaching 64K. Fixed. Ditto with saving
them to a file.

o Using Conferences = and text wildcards would not work correctly unless
supplied string(s) were all upper case. MR/2 would upper case the
message's conference name for the compare, but test against the
string you supplied, in a case-sensitive manor, without adjusting the
case. Also fixed.

o I chased the "tagline disappears when reply is modified" problem. I
*know* it was there, as I saw it myself. When I tried to *make* it
happen, I couldn't. I'll keep watching ...

o I have preliminary SOUP format support in an "external" form. Write to
me if interested. It's currently read-only (no support for replies,
yet). This won't be actually released for awhile. I assume a long
development process to "get it right". It will be dependable
and productive very soon, tho, for those that want to help "test".
I may also need sample packets created by utilities other than the
one's I am using.

- Interesting "discussion" I've been involved with on the internet.
Specifically in news.software.readers. The regulars in this
newsgroup have determined that QWK readers can not and will never be
able to post "correctly" to the Internet. I've been disagreeing,
often "violently" :). Their solution? Throw out your QWK readers
and QWK BBS software - switch to SOUP format. My opinion? QWK is
easily fixed and/or extended to work. It's a much more practical
solution than asking millions of PC-based users to switch to stuff
that, for the most part, doesn't exist, or is still new and hard to
find, if it does.

I intend to support SOUP as far as I can. I still have no intentions
of abandoning the QWK market. I intend to fight their plan, in as far
as it tries to condemn QWK. I'm not unaware of the problems with the
QWK format, and I know that the messages that *I* personally post do
not meet their RFC-1036 "standard". I *do not* agree with the severity
of the problem, nor with their suggested, must-do-it-our-way solution.

o Editor: Switched the meaning of CTRL-Y from "copy block" to the more
pseudo-standard meaning of "delete line". Hopefully this will not
confuse anyone.

o As what I'm hoping is the last effort I make to salvage long message
(greater than 64K) with this 16-bit code, I put in "overflow" logic.
What used to happen is that, when MR/2 encountered a message over
its limit, a blank screen would show, the message could not be saved
to a file ... nothing could be done with it. VC building would stop
dead in its tracks (and fail to find any hits past that point), and
often index building would, also. Now, I adjust messages >64K to
64K - 128 bytes, then "trash" the remainder, reading past it. Again,
not "the" solution, but a much more graceful work-around.

I've tested this with message approaching >64. They *still* work ๐Ÿ™‚
Since I have only heard reports of larger messages, I leave this to
those "reporting" to verify that it works. It's relatively simple;
it "should" (famous last words ...).

o A sample packet I was provided had a conference Personal (0). This
was a packet built by uqwk (Usenet->QWK utility). Since I remember
this reported as a problem, I suppress the listing if the size of
Personals is zero.

o Well, one more big-message problem handled. The viewer and searcher
work OK with these messages ... by ignoring anything > 64K. Saving
these messages in their entirety is important. The main reason, as
I see it, is that *most* message this size will probably be UUEncoded
binaries. It's not all that important to see and/or search these
messages to the end, but saving them completely *is* important. Hence,
I did just that.

The only remaining problem I see is *sending* a uuencoded binary >64K.
I'm sure you can't do it at this time. I'll see how hard this is to
address.

- NOTE that this version of MR/2 handled a QWK packet created from a
SOUP packet with HUGE messages. The packet contained 5 messages with
UUEncoded graphic images ranging in size from 133,201 to 179,907 bytes
each (message size as reported by the SOUP format; QWK size would be
a tad bigger). These messages could be viewed, although, only the
first 64K showed up. These messages *did not* disrupt searching, or
any other "normal" function. AND, I successfully converted ALL of
these UUEncoded images to their graphic form by saving them to a
text file and using a UUDecode utility on each. All messages saved
to text files completely and error free. This was not possible
before this release.

o Moved the default MR2INI.ORG "ReplyFile" specification back to the
MR/2 "home" directory. I realized that just using "Reply.Msg" caused
MR/2 to see an open packet WITH replies, even if no reply had been
saved.

o I attempted to offer some "crash recovery" from within the internal
editor. I can't be the only person occasionally losing work because
of seemingly unrecreatable crashes :(. I discovered recently, after
ALMOST losing an hour or two of work, that much of the text exists
in either the REPLYFILE or a file called TEMP1.TXT in the work
directory. My first attempts to automatically salvage these files
is less than satisfactory. I do plan on bettering this, tho. I
may switch recovery efforts to keystroke recording, so that changes
can be "replayed" upon any kind of crash. We'll see. Perhaps a
periodic auto-save feature.


Changes included in v2.18
-------------------------

o Mostly unoptimization and squashed a couple of obscure bugs. I
turned off optimizations anywhere seemingly "critical" code was
being performed. I kept the generation of 286+ code on everywhere.
This in an attempt to squash the last of these incorrect highlighting
in virtual conference bugs. I have been unable to recreate these
at all. I have one user reporting this problem and have heard
nothing else about it from others ...

Question: Is anyone else experiencing the miss-highlighting of words
in virtual conferences? Ok, if you *were* having this problem, does
it still occur using this release? Please, if you feel up to it,
let me know EITHER way, via private mail only. Responding publicly
in echod conferences on a individual basis is discouraged.

- UPDATE: I may have found it. It turns out that there *is* a problem
when a user sets PositionOnMatch to NO. It was an easy one to fix,
once I saw it, and that one's gone. I'm not positive this was *the*
problem, but it was very similar to what was described. I'll wait
for confirmation ... ๐Ÿ™‚

o Wrote a message base reorganizer; this after a one user's reply log
became corrupt. Even though his reply log contained several hundred
messages, only 9 would show within MR/2. This was because there were
2048 bad "blocks" between the 9th message and the next good one.

While I can't explain what happened, this new utility reorganized the
corrupt file and allowed the rest of the messages to be accessed.
It is a relatively simple utility. It walks through the messages,
checking the header, then reading the defined number of message
blocks, copying these to a second file. If a header is read that is
determined to be invalid, the utility scans ahead until the next
valid header is found. It then continues to copy messages. There
is much information written to the screen, including a summary line
for each message, and statistics at the end of the run.

This utility can be used to repair QWK "message" type files such as
Messages.dat, BBsname.rep, InBasket.Dat and ReplyLog.Dat. The most
obvious use for it is in repairing the two MR/2 specific files.

This utility, while small, is not included in the distribution zip.
It will be posted locally (Nerd's Nook) and at my internet ftp site,
and will be available via uuencoded email "on request". It has just
too limited a use to be shipped everywhere, all the time. That's
my opinion, at least. I'm open for a discussion, if anyone sees fit.

FILE: FixDat.Zip, about 13k.

- Perhaps, when all is said and done, I'll separate out the little
utilities into a "MR2UTIL.ZIP" kit. Since they will rarely be updated
(or at least at a slower rate than the main program :), this might make
sense.


Changes included in v2.17b,c
----------------------------

o Backed out a large number of the compiler optimizations I had tried
since v2.12. As more and more of these little bugs were apparently
caused by faulty optimizations, I made the call that whatever very
minimal speed difference they make just wasn't worth the bugs.
I will be switching compilers very soon, anyway.

o Big boo-boo on my part. MR/2 can now read larger message, although
still limited to <64k. Due to some lousy integer-based math, reading
messages > 32K would fail (giving you the no-message, blank screen).
I've fixed the math, and found that "most" UUENCODED messages in my
test packets can now be read. It's isn't "the" answer, but it sure
will help. This has been unnecessarily limited since day one.


Changes included in v2.17a
--------------------------
A couple of quick bug fixes ...

o HideConferences once again works. It was a silly error on my part.

o Welcome screen backdrop was flackey. I don't know why, exactly, but
it had something to do, once again, with Zortech's optimizations.
I'm beginning to badly distrust the optimizer, and may undo some of
the remaining switches on critical modules.

o And MR/2 keeps getting smarter :). I had a brainstorm ... I can now
solve the problem with BBS's that have both Netmail and Internet
email going into the same directory. If Internet and Netmail are
defined as the same directory, and you switch a reply into this
directory, MR/2 will first check to see if it originated in a
defined Usenet conference. If it did, it gets an Internet section
from the template. If not, or the Usenet parameter has not been
set, then the source message is tested for the existence of an
Internet-style Message ID. Again, if there is one, the reply gets
created with an Internet template. Otherwise, a Netmail template is
used. I think this will be extremely accurate.

Ok, for the users that this may help: Does this solve the whole
problem? Do you need the ability to create a Fidonet netmail
address in Internet form? Please let me know. Maybe I'll create an
@[email protected] variable, and/or give you access to the pieces-parts
as individual variables. Heck, I'll do this anyway ๐Ÿ™‚

o Ok, I added another @variable: @[email protected] This is the internet
form of the current message's fidonet address. For example, if
replying to a message from me, @[email protected] would be replaced with
"f200.n157.z1". With this, it will be easy to set up a template
that will route fidonet mail through the internet. A template
section example will follow in the next release. My full Fidonet
address via the internet is "[email protected]".



Changes included in v2.17
-------------------------
Enough small problems still exist in the new search logic to keep
calling this a "beta". For those that have reported problems, please
make sure you report them again if they still occur (thanks!). Still
left to do for the v2.2 release: Folder packing - scan for, warn about
and remove malformed sections. Possibly expand maximum search string
and allow multi-line INI definitions. Small enhancements to MQWK,
including adding support for multiple archivers. Maybe a few others...

o Searching once again enhanced! Marc Bourassa came up with a great
idea that I had overlooked ... being able to actually include
conference selection criteria in a search string. This allows for a
VC that "includes all message from conferences that contain OS2 in
their name, and add all mention of OS/2 in conferences that don't."
Basically, conference specifications can be used just like any other
keyword in a criteria string and can be AND'd or OR'd as desired.
For example:

String = {C}"*OS2*"

This example (when found as part of a complete MakeConference set)
tells MR/2 to include all messages that are in conferences that
have the string "OS2" anywhere in their name.


String = {C}"*OS2*" | (!{C}"*OS2*" & OS/2)

This example tells MR/2 to include all messages that are in
conferences that have the string "OS2" anywhere in their name OR
if OS2 is NOT part of the conference name, include the
message if it contains the keyword "OS/2".


String = !{C}"*OS2*" & OS/2

This example tells MR/2 to include all messages that are NOT in
conferences that have the string "OS2" anywhere in their name AND
ALSO CONTAINS the keyword "OS/2".


String = !{C}"*OS2*" & !{C}"OS-*" & {SB}OS/2

This example tells MR/2 to first EXCLUDE all messages that are in
conferences where OS2 is anywhere in the name, and then also EXCLUDE
messages from conferences that START with "OS-" ("OS-DEBATE", for
example, would be excluded). All message NOT EXCLUDED will be checked
for the keyword "OS/2" in the SUBJECT or the BODY of the message
(simple tearline detection is applied, and if identified, the tearline
denotes the logical end of message).


String = !{C}"*OS2*,OS-*" & {SB}OS/2

Logically identical to the previous example, but in my opinion
a little less "intuitive", if any of this is at all :).

NOTES. The "Conferences" line is still fully functional, and in
fact, superceeds these "embedded" commands. If you specify an
old-style Conferences line, and the message doesn't fit into this
specification, the message will not even make it to the processing
of the search string. If you want to check ALL message and have
the search string dictate the full set of criteria, leave the
"Conferences=" line out completely, or manually specify the default
of "Conferences = *".

o I noticed that under NO-QWK message entry, portions of previously
opened packets still might linger. Now, work directory is scrubbed
before building message-entry environment.

o Removed compiler optimizations from template file appending code.
It was interferring somehow. If you would "write new" to an address
that used a tempalte section, then went in and wrote a second (even
to the same address), second message would start completely blank.
With optimizations turned off, this now works fine. Go figure.

o Editor bug: Ctrl-O to open a file, type in an illegal file name or
specify a directory that didn't exist, MR/2 would lock up. File
system errors caused an infinite loop when opening an file for
editing. Now it beeps and returns to the file name prompt. No
error message is provided yet, but I think it's pretty obvious, and
it's certainly better than locking up. I was bitten by this twice
just this week, losing parts of a reply ๐Ÿ™

o You may now use the UseNet INI parameter to identify a list of
conferences that are Internet-based "Usenet" newsgroups. The
benefit of this is that, when replying, MR/2 will now attempt to
access the new Usenet/NewUsenet template sections for the reply.
If not found, the default section is used. This allows for
Usenet-targetted replies to use their own unique boilerplate.
A couple of new reply-time variables have also been added ...

o The "Usenet" INI parameter follows the same rules as the old
HideConferences parameter, whose workings have changed just a little
:). HideConferences previously was able to handle ONLY a list of
simple numeric values delimitted by commas. It now uses the
"Conference matching" logic of searches. That is, you may specify
single conference numbers (old lines need not be changed, I've just
added additional possibilities), ranges and/or wildcard strings to
compare against conference names. For example:

HideConferences = 7,93,99,100-163,*forsale*

There can be multiple Usenet and HideConferences lines in any INI,
the lines are effectively accumulated so that MR/2 sees one line for
each INI keyword containing all data from each of the individual
corresponding lines.

For my setup, specifying Usenet conferences was easy ... they are the
ONLY conferences I read that contain a "." in the conference names as
supplied by my BBS, and I read no other conferences with a dot in
the conference name. Hence, my totally functional Usenet INI line
is:

Usenet = *.*

An alternative might be something line "Usenet=comp.*,alt.*,cle.*"

Remember, this isn't a file name match ... it's simply a pattern
matcher, so this matches any conference name with a dot anywhere
within its name. One day I'll fully document the wildcard pattern
matched and all of its supported features ๐Ÿ™‚

o @[email protected] and @[email protected] have been added to the reply-time
variable list. You may include these in any template section.
They will be resolved at reply-creation time to the source Usenet
"Message ID" and "References" line, respectively, as derived from
the source message's header area. This may help with the claim of
several Internet hard-heads that MR/2 is "breaking" threads.

o Usenet and NewUsenet template sections added to the default
"example.tf" file. Existing users that already have a working
template file can cut these files from the example file and paste
them into their working template file. The reply template for
Usenet will create a basic Usenet-style header area that includes
the "References:" line that some Internetters are complaining
is absent from most QWK messages. PC-Ohio seems to place these
in the message correcly, without any help from the mail reader.

ALSO, the `Forward` header section of the example template was
modified slightly. The "~" symbols meant to suppress word wrap on
short lines never really did serve the purpose well. What else
suppresses line rewrap? Blank spaces at the beginning of the next
line. So, each of the three lines in the Forward section have been
indented a single space. Users can make the same or a similar change
to their own template file, if desired.

I'd love to figure out what Fidonet is doing to rewrap messages so
horribly. Then I'd like to find a fix. Oh well, I guess we'll all
have to live with nasty-looking messages for awhile.

o John Bales reported a problem where certain NOT-type searches, were
causing trouble; usually reporting "first failed-0" errors. It
turns out that MR/2 was checking the very last sector of the packet
as a message. Usually this sector consists of all NULL characters,
and when comparing for the contents of a string, would always fail.
If you're checking for the ABSENCE of a strings, as is possible now,
it will always match. It was seen as a message header (with no
body) that matched any NOT comparison. This would always give you
one more NOT match than you really had, and trying to read that last
message would cause the error . Fixed.

o Reworked SaveVCs.CMD to work with multiple archivers. I will let
this out as-is, but there are some complications. I have tested it
with PKZip, InfoZip, Arj and LH/2. The problem is that ONLY PKZip
and Arj seem to have options that preserve the date/time stamp of
the original archive when updating. This means that InfoZip and
LH/2 actually set the date/time of the packet to the current
system time when repacking. Not good. I still have to test with
Zoo, DOS Arc and DOS LHA, but this is just busywork, and I believe
these are rarely used. This script also detects packets with
"long names" and applied logic that allows for DOS-based archivers
to access the file.

Using REXX, I see I can get a file's date/time stamp easily
enough ... I just don't see how to change it from within REXX.
If anyone knows how to do this, it might save me some grief.
Otherwise, I get to write this touch utility that will do
nothing but accept a lone file name and a REXX-format date/time
string and set the file's date/time to that.

o OK, I wrote an extremelly simple "touch" utility, which is included
in this zip. It has no features or options other than what I
needed, and totals 7k in size. No docs, as it is meant ONLY to
solve the problem of timestamps being changed by saveVCs.cmd.
"sfiledt.exe" will be in your MR/2 directory and SaveVCs.cmd will
now make use of it, when found.


Changes included in v2.16
-------------------------

o Internal: Repackaged the INI data and file loading routines into a
C++ class. Previously these were just a growing collection of
public/global variables and some odd-ball routines. I need the
ability to save a single packet's working "environment" as a unit
for MR/2 PM (to allow multiple working environments :), so this is
the ticket. No functionality added, but due to the large amounts of
code and macro-ugliness I created, bug-potential is above average.

o Further enhancements to the text-string search function. Support
for selecting message-specific areas to check within a search
specification. For example, you can now ask for all message that
have "OS/2" in the SUBJECT field, but not in the message itself.
You may tag any word, or set of words within matched parenthesis,
with a set of areas to test. The default is to test all parts of
the message. For example:

{S}OS/2 Matches "OS/2", only checking SUBJECT

{F}"Jim Gilliland" Finds ONLY message FROM Jim Gilliland

{M}"Tim McClanahan" & !{FT}"Tim McClanahan"

Finds references to Tim McClanahan
inside any message text, but excludes
messages FROM or TO him.

{S}(MR/2 | MR2 | MR-2) Matches any of these three strings when
they exist in the SUBJECT field.

{Conclusion} Probably won't find what you want ๐Ÿ™‚

"{Conclusion}" Probably is what you want. Finds any
occurence of the word "Conclusion" that
is enclosed between curly-brackets.

Valid areas are From, To, Subject, Message, Body and Origin,
represented by the letters F, T, S, M, B and O, respectively. The
Message section consists of the Body AND the Origin, which are
separated by the tearline (if MR/2 can find it :). When in doubt,
MR/2 calls all of the message "Body".

I think I'm done with the searching enhancements. The only thing I
can think to add is selection of conferences to search for the
ALL-CONFERENCES real-time searching. I rarely use this anymore, and
I think that this process belongs elsewhere. Maybe later, but I'm
putting this on the super-duper low priority list. I joked about
supporting proximity searches in the Fidonet OS/2 echo. Really, I
*was* just joking! ๐Ÿ™‚


Changes included in v2.15
-------------------------

Still a beta. I'll call v2.2 a "real" release. In the meantime, I'll
continue to poke with large, currently-working features ๐Ÿ™‚

o Had to modify the messaging-viewing support code to handle much longer
search strings. Most routines had support for 80-100 character match
strings, and MR/2's search engine now allows 255 characters. If you
used a longer string, many strange things would happen. Seems to
work now.

o I massively modified the VC file handling system. Again. I tested
fairly thoroughly, and my time trials showed an extremelly minimal
improvement. Considering all that I did, I'm pretty dissappointed
:(. BUT, my system is massively-double-cached ... meaning I have
large OS/2 disk caches, on top of a caching IDE controler with 4 MB
of cache RAM. Hopefully there are some *real* improvements resulting
from this, and my machine's just not the best for showing these.
Details follow.

o Modified the string matching logic added in v2.14 to be more efficient.
Some work on the conference matching parser also.

o Changed the VC process so that it opens a large-buffered FILE structure
instead of sharing the main process's open, raw file handle.

o Changed the way VC index files are opened and written too. Previously,
only one index file could be open at a time, and a process of closing
the current one and opening the "next" one in append mode was used.
I now open each index file once and it remains open until all VC's are
built. I then close ALL index files at this time. Index files were
converted to use raw file handle output as opposed to the previous
buffered-stream mode. I dynamically change the maximum allowed count
of file handles to facilitate this change. If this fails, the old
method is used as a backup.

o When building of virtual conferences is complete, MR/2 now invoked the
command file "SaveVCs.CMD", if it exists in the MR/2 home directory.
The current version of this cmd file pkzip's ALL modified NDX files
back into the original packet. This happens as a BACKGROUND process,
invoked using the "start /b /c" command. This has two benefits:

Virtual conference NDX files are saved with the packet, so that VC's
are built only once per the life of the packet. Any subsequent
opening of this packet will already have the VC structure intact and
available for instant reading.

Packets without NDX file altogether will now have ALL MR/2-created
NDX files saved for subsequent opens. For example, the QWK packets
produced by MR/2's MQWK packet merging utility do not include NDX
files. Each time you would open a packet created with this utility,
MR/2 would build the NDX files from scratch. This is now required
ONLY the very first time the packet is opened.

NOTES: If the command file processing fails, the only harm should be
that the NDX files are missing from the QWK packet. That's no
different than what happened previously; MR/2 will just try again the
next time the packet is opened.

If this new system is undesirable for any reason, simply remove (delete)
"SaveVCs.cmd" from the MR/2 directory.



Changes included in v2.14
-------------------------

BETA! Everything here is very new and, although, I've been using it every
day, is bound to have a problem or two.

NOTE: Old VC strings may not work as they used to. It's IMPORTANT and
very simple to fix this ... Make String = \word1\word2\word 3 into
String = "\word1\word2\word 3" and all will work as it did in the past.
Only strings containing embedded spaces need to be wrapped in quotes.

o I *think* I have a personal internet FTP site set up on my machine! ๐Ÿ™‚
See "Contacting the author", above.

o Previously, the bbsname.cfg file for a specific BBS was overwritten
with a packets control.dat file, regardless of the age of the
packet being opened. If the packet was a year old, that BBS would
then have a year old CFG file saved for it. MR/2 now copies only if
the "new" file has a newer date than the existing file.

o Modified the Virtual Confenence builder's "Conferences" command to
accept both ranges and text wild card strings. For example,
the following Conferences commands will now work:

(NULL) or * All conferences
1,2,3,4 1 2 3 or 4
1-4 1 through 4
1-4,100,200,1000- 1->4, 100, 200 or 1000 and greater
-1000 through 1000
alt*,comp* all named starting with alt or comp
!200,alt*,comp* all named starting with alt or comp
EXCEPT 200

!200-300,!17,alt*,comp* starting with alt or comp EXCEPT 200-300
and 17 EXCEPTIONS SHOULD COME FIRST as
first "match" terminates the check

*.* any confernce with a dot in its name
17,254,alt.*,comp.* all alt/comps and conferences 17 and 254
*-R, *-F All conferences ending in -R or -F. For
PC-Ohio, this would be all RIME or FIDONET
conferences, respectively.

"Negatives" are available to exclude certain conferences by number or
name. As the above states, negatives or excluded conferences should
be listed first, as the first criteria the conference fits in causes
the routine to cease checking. For example:

!100-150,1-1000

will include conferences 1 through 99 and 151 through 1000. Any
conference from 100 through 150 will fit the first catagory, which is
negated/excluded, so messages in these conferences will NOT be included.
However:

1-1000,!100-150

This will include all conferences 1 through 1000. Since any message
in the range 100-150 will first qualify as a match for the first range,
the second range will never cause a message to be excluded. The first
example is the correct way to exclude conferences.

NOTE: The support of ranges and wildcards has caused a slowdown in the
creation of VC's. While "minimal", I plan to add some code to support
original-style Conferences commands using the old method. The most
efficient commands will consist of singular numbers. Next in up in
efficiency would be numeric ranges. NOTE that, where large ranges are
concerned (more than 50 conferences?), this is more efficient than
individual listings. Finally, wildcard and/or text-strings matches
are CPU-intensive, and will cause slower VC building. Still, the
flexibility offered by wildcards and numeric ranges far outweigh
the "small" cost in performance. The decision is left to you.


o Boolean match logic is now available for both virtual conferences
and real-time (F, ALT-F) searching. The "old" method of or'ing
strings together is still supported, although I'm having some
problems with this. Perhaps an INI variable later ...

Keywords can be OR'd together, AND'd together and/or NOT'd. In
addition, parenthesis can be used to control the evaluations of
the test. There is also an operator that will match a word,
remaining sensitive to case. I've also added support for quoted
strings so that spaces and the special boolean operator symbols
can still be searched for. Some simple examples:

(OS/2 | OS2) & !WARP (OS/2 or OS2) and not warp
Windows & OS/2 Windows and OS/2
Windows | OS/2 Windows or OS/2
^warp warp, but ONLY if all lower case letters

The "operator" symbols follow the conventions used by C and C++ for
boolean operations:

& is the AND operator
| is the OR operator
! is the NOT operator
() cause the expression inside to be
evaluated as a single expression.

and one other that I added:

^ causes a case-sensitive match to be performed.
The word that follows must be found with
matching capitalization to be concidered a
"match".

The following will find all messages that contain one of two
different words referencing OS/2 that also mentions "bugs".
if the message doesn't match under this criteria, then it is
tested for the words "Windows" and "slow" in the same messages:

((OS/2 | OS2) & bugs) | (Windows & slow)

The following is somewhat similar. It will also find all messages
that contain one of two different words referencing OS/2 that also
mentions "bugs". If the message is found to match, then it is
tested for the words "Windows" and "slow" in the same messages.
If these words are both found, however, the message is eliminated
(compliments of the "!" NOT operator):

((OS/2 | OS2) & bugs) & !(Windows & slow)

When MR/2 displays a message that has bee "found", all words
contained in the match string will be highlighted.

A few more examples:

ObjectPM | "Object PM" spaces are ignored unless witin quotes

"R&D" operator characters must be in quotes
if part of a search string.

R&D finds the single letters R and D,
anywhere in the message. This *isn't*
what you want!

"(ch | 0xFF)" more special characters within quotes.
The operator characters will be treated
as any other characters.

"""Windows""" Looks funny? It will find the Windows
in message but only if between quote
marks. Two quotes together are treated
as a single " mark, but they must still
be part of an entire quoted string.
Tricky? Maybe. Just know that ...

""Windows"" WILL NOTE WORK, and that ...

"can you say ""neighbor""?" will find the prase 'can you say
"neighbor"?' The word neighbor mus be
within quotes to be concidered a match.

"&Windoze" Soundex search for anything sounding
similar to "Windows".

^warp | phasers Looks for the word "warp" in all lower
case ONLY, or the word "phasers"

^NT | ^Nick Looks for the capital letters "NT" or
the string "Nick" where only the N is
capitalized.

MAXIMUM seach criteria length for VC's is 256 bytes (after the "="
marker). All must be on a single line. Nesting is supported
further than anyone will need it (limitted only by stack space).
Other ideas are in head ... let me know if you come up with any
handy and/or clever ideas ๐Ÿ™‚

o The old stuff. I've got all of my old w1\w2\w3 strings working
as-is, but there were problems with embedded spaces that used to
be seen as significant parts of the string. They aren't any more.
To get search strings that include spaces to work, simply wrap the
ENTIRE string inside quotes. For example:

String = "TekRam\DC-6\DC6\Promise\Caching IDE"

These will probably be "unsupported" quickly, as they're part of the
reason that performance is down (checking for or's in two places now).

o Expands the FIND criteria entry forms to hold much longer search-for
strings. I also saw that this was another case where light red on
white was being used. Changed to dark-red on white. Much easier to
see!

o The mouse, when set in single-click mode was totally unusable with
selection lists. Fixed.

o NOTE that my tests show that I've slowed down the creation of virtual
conferences by 10-20%. I have applied several optimizations and
rearranged, and this has helped. I see room for a couple of major
performance enhancements, and those will be applied next.


Changes included in v2.13
-------------------------

o Help screen for the editor was STILL missing the ALT-* (paste)
key combination. Added.

o Lots of questions about FolderOrder. Past Docs don't clearly state
all the possibilities. MessageOrder and SortOrder can have values
of: Subject, DateTime, From, To or MessageNumber.

o SplitLongReplies = YES would not work ... you would have to specify
a line count, otherwise the response was read as NO. Fixed.

o I spent quite awhile with a user, trying to figure out why his
internet replies weren't working correctly (they weren't using the
INTERNET template, although all appeared to be setup correctly).
Turns out he had HeaderEditing set to AFTER. This usually won't
work. I now check for this conflict and change HeaderEditing to
BOTH if either INTERNET or NETMAIL conferences have been specified.
I *do* post a warning on the first message of each session, and
explain how to remedy this. There is still a potential problem with
RIME routing (no way to specify PRIVATE before a reply to a public
message is created with HeaderEditing set to BEFORE), but this is
more difficult to detect. I will create and post on Nerd's a
"How to ..." document. This will save me a ton of time in the
future, as most of my support efforts have been in this area.
When questions arise, I'll simply send this boilerplate as a
message.

o More minor example template tweaks. Removed a couple of lingering
references to my last name, added another example of a netmail
routing line. There are now three routing lines for a netmail
message, *one* of them should be correct (most cases should be
covered).

o ADD/DROP was broken due to the change to 5-digit conference support.
Fixed this ... hopefully that's the last bug caused by this change.
I also cleaned up the ADD/DROP prompt (conference name was 1 char
off ... cosmetic, all related to the 5-digit change).


Changes included in v2.12
-------------------------

o Editing a reply and saving it would (sometimes) cause a crash
when the reply conference was exitted. This was non-destructive;
the reply would be OK, it was a function of the new sorting that
was slightly off. Fixed.


Changes included in v2.11
-------------------------
BETA as far as I'm concerned. Seems to work just fine for me, but I
changed lots of basic, its-been-working-forever code. Please do not
distribute widely ... and report any problems immediately. If all checks
out, I'll post it widely next weekend.

o MQWK.CMD - added and tested command lines for using zip/unzip
(InfoZip utilities). Tested with the DOS versions; assuming
command lines are the same. Comment out the first set of lines,
uncomment out the second. NOTE that zip failed when run with
the "start" command so as to run it in the background. It seems
zip wants to open the source file in a mode that conflicts with
the fact that MR/2 also has it open. Too bad; the PK utilities
work OK this way.

o More minor tweaks to the conference index builder. Someone
complained recently, so I thought I'd have a look. I see room for
some *big* improvements! ๐Ÿ™‚

o When modifying a reply, the fact that the NEW reply had a later date
than the OLDER version would case the message pointer to seem to
"shift" to another message. This was after you would save the reply
... the message viewer showed something different. This would only
happen if other replies had a matching subject. I now sort the
reply headers differently. I disregard date/time when sorting after
a reply-modify.

o Ooops. Forgot to list Ctrl-O on the Editor help screen. Fixed.

o I modified the conference header sort massively. It now uses a
btree sort with minimal data movement. This fix, in addition to
the other little tweaks a day or two ago, result in a great speed
boost. My informal testing (watching the MR/2 clock tick away)
involved loading one 800 message conference, and another with 402
messages. The larger conference took 15 seconds to load with the
old MR/2, it now takes about 5. The smaller conference's time
dropped from 6 seconds to about 2-3. The larger the conference,
the bigger the difference will be. Smaller conferences will show
smaller improvements. Overall, things are just *much* faster.

o Converted all internal storage and formats to support 5 digit
conference numbers, as long as these numbers remain in the
16-bit range (up to 65,635). A user reported a BBS system that
used thousands as a group identifier, and the remainder as the
sub-sconference number. This was a big change, and I'll test
thoroughly before releasing.

o Packet selection screen was expanded 2 characters and underlying
logic modified to support packets from BBS's with 8 characters
names, and with 2 digit TE/2-style collision suffixes. For example,
NERDNOOK.QWK;99 could not be opened, renamed or passed to MQWK.CMD
when merging packets. This appears to be working better.

o Another error dialog has been added. This one agains warns if the
working directory has been specified on a different-but-valid drive
(a potential problem). There's even one more problem to detect; as
MR/2 requires the work directory to be a subdirectory off of its
"base" location. This would occur rarely, and is not destructive,
whereas the one that are now detected and avoided were.

o Added a third level sort to the subject thread sort procedure.
Threads are now sorted by Subject, then date/time, then message
number. As reported, split message all may have the same date/time,
and this usually assures that they appear correctly.

o Editing a message header, then requesting to "pick a conference"
from the master list. Previously, typing letters did not jump to
the first prefix match. Fixed.

o Add in a new INI parameter for myself - FolderOrder. This has the
same parameters as MessageOrder, but allows a different sort to be
applied to the ReplyLog and Inbasket. I found myself constantly
converting these folders to date/time sort, so I decided to add
an option to default the sort for just these folders.

NOTE: By default, FolderOrder = -1, which means that the
MessageOrder is used. Sort orders will work the same for everyone
unless they specify this option specifically.

o Further modified the message sorting ... if DATE/TIME sort is active,
a secondary sort level of message number is activated. Same reasons
as it was added as the 3rd level on subject sorting.

o Revamped the INI parser once again. My while() loop kept growing,
and I kept breaking the compiler. It's now broken into two
separate routines, which gives me plenty of room for expansion, but
also increases the possibility that bugs have been introduced.


Changes included in v2.1
------------------------

o I found rather large memory leak when using the internal editor. It
seems that the cleanup routines ... something I've never looked at
before and always *assumed* were just fine (NOTE: the editor started
as a third party editor "toolkit", which I have modified extensively).
Well, the cleanup routine was empty; totally empty. I added about 8
free() calls to release committed but unneeded memory. I found this
when I went to add the "cleanup" counterpart for:

o The internal editor now has an undo capability ... unlimitted levels.
I keep a record of all block delete's and CTRL-X line deletes. You
can use CTRL-U to insert the text in reverse order of the deletes.
Inserts are always to the current cursor position. In a way, this can
be used as an intra-document cut/paste. Each of the two editor buffers
has its own undo-delete list.

Let me know if you can think of any other place to store text for
"undoing". I'll look through the code for more possibilities, too.
NOTE that I do *not* pay attention to presses of the delete key (for
removing a character at a time).

NOTE: CTRL-U previously would delete a marked block. There are
several other ways to do this, so I remapped this key. I hope
this won't confuse anybody ๐Ÿ™‚

o Well, I finally had to fix the long-time Zortech file open bug,
instead of dodging it. ZTC's fopen(), the call used often to open a
file for reading and/or writing would NOT return NULL on error.
This is a C/C++ standard - to return NULL if an open fails. I
thought this was just a problem on open-for-reads, but I find that
opening a file for write that fails (a bad file name or path, for
example) STILL returns an "ok" value. This was masking the real
reason one user's VC's were crashing. Not that I know the real
reason, yet, but the diagnostics that have always been there can now
work. I cleaned them up further, and tested them using a hand-made
bad file name. In this example, instead of crashing whenever the VC
thread hits its first message, a polite failure message *should*
display on the screen. The VC process will terminate if ever an
open fails. Now, to see what file name this user's system is trying
to open ... ๐Ÿ™‚

o I love the Internet! ๐Ÿ™‚ In a single 24 hour period, I was able to
exchange private mail with the aforementioned user a couple of
times, actually upload a test MR2.EXE to his machine via ftp (I
don't yet have personal access like this - a friend "demoed" it to
me :). There was still enough time to get the tell-all error
message back from him!

If you specified a fully-qualified WorkPath, either in the INI file
OR on the command line (for example, WorkPath=C:\mr2\Work or
/WC:\mr2\Work, the VC index building process would crash. I now
handle this for both cases.

o In testing the above, I happened to try a drive/path that didn't exist
at all. I used /WJ:\mr2\tmp, where the J drive is non-existent on my
machine. I picked a packet (of pickled peppers? ... oh, sorry, long
day :), MR/2 pathed to the defined work dir, which of course failed,
and then proceeded to clean out the directory. The directory it
cleaned out happened to be my MR/2 home directory (source code and
all). Bummer! Good thing I keep great backups and hadn't done much
work since I backed up!

And I remember arguing with a user publicly that MR/2 wouldn't
delete files unless the chdir succeeded. Ooops.

NOW, if the change directory fails, a nice 10-12 line dialog box
pops up, explains the problem, shows you your workpath, then
promptly exits w/out deleting a single thing.

o Modified the edit header logic slightly. When editing a message
header where the original message's "from" field is blank, MR/2
now tries to use the @[email protected] value for the TO field. I've
received mail before this way, and when I replied, my message had
a blank TO field and was uploaded to the BBS this way. The message
made it to its destination, but since PCBoard views a blank TO as
being equivelant to "ALL", everyone else on my BBS could read it.
In other words, it was not PRIVATE on my home board. Since PCBoard
ignores the TO line if there's a TO: line in the message, I could
have put anything there, but the INTERNET address (truncated) seemed
appropriate.

o Minor internal editor fixups ... things like names on the top of both
editor windows are correct and stay that way, the search prompt
now stays at the title bar or the "owner" window.

o I modified the Editor=Internal INI options to accept another
parameter. Editor=Internal,FullScreen (or just the work "FULL")
puts the editor into full-screen mode. This uses ALL display lines
when editing a file instead of leaving the source message header
displayed.

o When switching the Editor specification in MR2.INI back and forth
between Internal, ME/2 and/or an external editor, MR/2 would
sometimes ignore the requested change until restarted from scratch.
This works much better now, except ME/2 still doesn't shut down
after it is no longer the requested editor. Minor nit - I'll fix
it eventually.

o When MR/2 packs the folders, a check is made to see if the folder
file is empty (size equal to 128 bytes). If it is, the file is
removed. Also, MR/2 will try to remove any BBS-specific folder
directory on packet exit. If the directory has *anything* in it,
the remove will fail (as it's supposed to). If empty, as is
sometimes the case, the directory will disappear. This will prevent
the system from collecting directories for BBS's for which no data
is stored in a folder.

o Subject sorting was modified to make DATE/TIME the secondary sort
field, rather than message number. I made a bold assumption that
the other way would never really give the desired affect and that
(as many have requested), DATE/TIME is indeed the proper second
sort option. If anyone disagrees, please speak up and I'll add
BOTH choices as options.

o When using the INI parameter SourceFile, MR/2 now starts in the
reply buffer with ALL of the text in the source file marked. A
simple ALT-C or ALT-M will copy/move the block into the reply.

o The default template file "Subject:" line for NewInternet was
changed from @[email protected] to @[email protected] This will keep MR/2 from
"inventing" long internet subjects and will instead insert the
SUBJECT value from the message header. You can modify the subject
in the message while editing, if desired.

o Another memory leak plugged - this time in deleting the list of
conference message headers. There was also an unneeded call to
lookup and format the Conference name in this loop. This was
removed (microscopic speed improvement).


Changes included in v2.09A
--------------------------
Another short-lived release; v2.09 had a serious bug. I offer this
release quicker-than-planned to ward off potential problems. I still
plan on a bunch more minor fixes, fixing anything else that turns up
wrong with the next internal editor changes, and releasing v2.1 in,
say, another week?

o Modified the folder-packing process. This procedure often left
unattached "source" messages in the log well after the parent
message was gone. I've written a little checker/diagnostic utility
to help me watch how well this works, so I'll be watching closely.

o Ooops! Ctrl-S from within the internal editor did nasty things. It
did save the work to disk, but then it closed the file and cleaned
up. This caused later saves to fail. Fixed.

o Initial MR/2 startup now uses the internal editor instead of E.
Don't know why I didn't switch to this before.

o MR/2 used the E editor as the default if not specified. Now it's
the internal editor.

o Modified the help subsystem slightly - HELP works when editing the
INI file with the internal editor.

o Modified the default colors specified in the default MR2.INI file.
Message text was in yellow, now it's in bright-white and the HEADER
data is in yellow. I like this better.

o Modified the default first-time startup code to copy example.tf to
template.tf, if template.tf is not found. Template.tf is the default
template file specified in MR2.INI. Previously, if a new user did not
put out the effort, templates would not be used ... the INI simply
specified a template file that did not exist. Now one *will* exist.

o Modified the example.tf file and removed all references to my name :).
In place of my name, I've inserted the string @[email protected]@[email protected] This
takes the user name from the QWK packet, mixes the case and signs
all message that way. For "Reply-To:" lines in internet templates,
I simply left this blank. If the user gets this far, he can edit the
template and fill this in himself.

o Another pathing patch so that, when using ME/2 as your editor, pressing
ALT-C to edit MR2.INI works ok.


Changes included in v2.09
-------------------------

o Better protection and diagnostics for read_line overflows. All of
my sequential file (text) access to read a "line" are now protected
by a "max" count value. If this value is met, a crude warning is
displayed, a keypress is requested, and the line is truncated. This
has been the suspected cause of a large number of unsolvable crashes
... any files that gets corrupted or modified when CR/LF's are
removed can cause this. Now, at least there is a warning, some
information, and no crash.

o Trying to solve an obscure VC crash for a user, I made minor changes
to the VC search process. Just for my information/reference later ๐Ÿ™‚

o Ooops. I temporarily saved the SplitLongReplies value in a character
variable. That caused overflow/rounding, so that specifying 300 line
messages resulted in 44 line messages (300-256=44). You could not
get messages longer than 256 lines. Fixed.

o When saving a message (or BBS file) to a save file, entering a bad or
invalid file name would show no error message or indication of a
problem, even though the save failed. This has been corrected to where
MR/2 will beep and stay at the file name prompt until a valid save file
name is specified, or ESCAPE is pressed.

o I somehow readded the problem where matching conference names failed to
insert the second name in the master conference list. This is, again,
fixed.

o If you opened a packet with existing replies, unpacked them, then killed
all replies (so no active replies remained), MR/2 would exit and leave
the original reply packet intact. It is now removed (renamed to a .old)
and none of the killed replies are registered in the reply log.

o Cosmetic: left over garbage in background when a "no packets exist"
box is displayed has been removed.

o If no BBS .cfg files existed, MR/2 would display a message about
not having any QWK packets available. Fixed.

o Internal editor work - LOTS of it :). I'm not telling yet! ๐Ÿ™‚
(Just in case bugs are found with what "used to work" ...)

o Ok, fine. I'll tell you about the editor. I'll put this out for
some user-testing, then issue v2.1 when it appears all the kinks are
out. I will add INI variables to specify full screen editing (all 25
lines) and initial split-window sizing.

- Optional 2-buffer, split window editing.

First, if you add the INI parameter SourceFile=somename.txt, MR/2
will automatically go into full screen, split window editing mode on
reply. If you don't do this, the editor starts off looking the
same, but new keys are enabled:

CTRL-O Open a new file (in the secondary buffer only)
prompts for file name, asks if save old one if modified
*This ALWAYS opens the file into the TOP, extra window/buffer*

CTRL-D Divide the editing screen into 2 equal parts
CTRL-C Close/Hide the current editor Window (if split only)
CTRL-G Grow the current window to full size (if split only)
CTRL-S Save the current file

CTRL-UP Move the divider bar up one line
CTRL-DOWN Move the divider bar down one line
CTRL-PAGEUP Expand the bottom window all the way
CTRL-PAGEDOWN Expand the top window all the way
ALT-N Give the NEXT editor buffer the focus
(split or two full screens - Shift F3 works, too)

ALT-C will now copy *across* windows. If nothing is marked in the
current window, the other window is checked for a mark. ALT-M will
do the same; if text is not highlighted in the current window, it
will check the "other" window, cut the marked text and paste it to
the current cursor position.

Sorry, I had to change some things:

FIND was remapped to CTRL-F (from CTRL-S)
FIND NEXT was remapped to CTRL-N (from CTRL-F)

And, for compatibility with ME/2:

ALT-X Save and exit whole editor.

If you don't do the SourceFile thing, then you can still open CTRL-O
a file or two for reference. For example, just today, I CTRL-O
opened MR2.DOC and cut a couple of lines from that. Same with a
snip from pmmle.h.

o Editor Help screen updated to show new key functions, also now includes
clipboard access keys.

o ME/2 USERS: I fixed it now so that ME/2 is initially loaded *after*
MR/2 switches the path to the working directory. This means that
the old ME/2 "erc 100 - reply.msg" error due to a pathing problem is
fixed by default. Your old INI ReplyFile specs will work. If you're
not using ME/2, this change *will not* effect you.


Changes included in v2.08
-------------------------

o By request, and it made sense, the conference name is displayed
at the top of the message index screen. I simply show the
"packet id" string that is optionally shown on the message viewing
screen.

o I noticed that the reply header editing screen still was using that
aweful light red color (on top of white) for the current field. I
changed this to normal red, and I think it's much easier to read.

o Also by request, when MR/2 clears the screen to pack replies, a
simple message is posted informing you of this. On some system,
the delay was significant, and with the screen totally blank,
confusion resulted. The message is simple and modest; I depend on
the archiver to write to stdout, and pretty-stuff wouldn't scroll
off the screen nicely.

o MR/2 would sometimes "lock up" when moving backwards through message
by thread (using Ctrl-PageUp or backspace). This has been fixed.

o Importing text into the internal editor (Alt-R) would often result
in the cursor being shifted to the right one character from where
keypresses would insert characters. This has been fixed.


Changes included in v2.07
-------------------------

o Minor changes - mostly in the interface and communications between
my external PM editor, ME/2.


Changes included in v2.06
-------------------------

o Rime-routed messages that were long enough to be split missed the
auto-routing line placement logic on secondary parts. I was looking
for too exact a match on "RIME". Also, I keyed on "Postlink" within
the original message to tell if it was routed. Editing the header on
pass two, the original message was no longer available.
Anyway, fixed ๐Ÿ™‚

o Added support for ME/2, a PM-based editor I've been playing with.
ME/2 is an MDI-based editor with toolbar, statusbar, multiple
file windows, speller, thesaurus, simple printing ... tons of
features. I'm putting it out at the same time as this (ME2_099.zip).
If you use ME/2 as your editor, it is preloaded by MR/2 on startup.
MR/2 can control it using IPC tricks, so response is better than
you'd get with any normal PM editor. Session switching back and
forth is handled automatically. See the me2.doc file included with
the ME/2 distribution zip.

o INI parameter added - "SourceFile". If specified, a source message
that is being replied to will be quoted to this file, and the actual
reply file will contain no quoted text, just an empty template
read-to-complete. This is used by ME/2 as an option, and may be
useful for other setups.


Changes included in v2.05
-------------------------

o Resolution of the source Internet address enhanced slightly. I moved
the check for PC-Boards @From: specifier before some of the others, as
if this line is there, it's much more reliable than searching for the
tokens like "From: ". Some of my recent replies detected invalid
Internet addresses. This should help. (After a couple of replies,
it does! :).

o Setting extended attributes on packets stored on a LAN Server network
drive would actually modify the datestamp. I added code to query the
original date/time and then reset this *after* the EA's were applied.
Seems to behave properly now.

o I screwed up and overwrote a large, completely unread packet tonight.
I was bummed. But wait! I now save the PTR file and can reset my
pointers!! Only ... MR/2's saving mechanism seems to have been broken
and I uploaded a 3 month old file. Needless to say, I got more messages
than I needed! What a mess ... I had to reset all my pointers by hand
and I know I missed some mail. I then fixed the date compare of PTR
files. They should overwrite the existing one now, if newer, and do
it correctly. For whoever it was that reported this and that I
ignored ... you got your revenge!

o MR/2 would crash when you pressed escape from the "NO PACKETS FOUND"
message. Had something to do with the aggressive optimizations. I've
"unoptimized" a bit until I can figure this out.

o I made a slight goof when I fixed the recursive variable replacement
in the last release. I made it so any *real text* with an "@" in it
would get removed, whether it had a "\" proceeding it or not. You see,
the "\" would *not* be there the second pass, so the "@" was unprotected.
If there was a string between two @'s, this would be removed too, as
it was assumed it was an invalid variable name. I now leave unresolved
variables in the text as-is. This bug effected mostly fidonet
and internet addresses. Fixed.


Changes included in v2.04
-------------------------
NOTE: This version includes alot of optimization from compiler switches
and from some rearranging of localized code. I used it personally for
several weeks, and the only "problems" I saw were minor video (cosmetic)
issues ... like a "black hole" for a second or two when one of the "use
existing?" prompts comes down. I'll track this, but you may see it until
the next version. The fixes in this release are beneficial, and the
video problems just minor and cosmetic.

I've also traced some recent slow downs to the folder subsystem; packing
log files and building indices in particular. I do this way too often, and
it takes too long. I will spend some time on these shortly, attempting to
hit the disk far less than happens currently.

o New INI variable "ALIAS" allows you to set a user name for yourself
other than the one found in the BBS Control.dat file. This alias
name will be placed in the FROM field of all your replies. Best used
in a "local", BBS-specific INI file when accessing multiple BBS's.
For Example: Alias=Billy-Bob will override the settings in Control.dat
(say for this example the BBS name was "William B Gooden"). Replies
would come from Billy-Bob.

o Turns out that the @variable logic was not as recursive as I had
advertised. For example, inserting a "phrase file" line that
contained yet another variable to replace did not work. It does now ๐Ÿ™‚

o Fixed a crash when modifying replies (changing, killing ...). If the
subject happenned to end in column 25 with a number BUT not be a
"split reply", MR/2 would crash looking for the "/" in "x/n". For
example "OS/2 <...> 2.11" would cause this crash to occur.

o Reply log would not always be accessible without an existing packet.
If you had no messages in your inbasket or replies for a specific
BBS, ALT-E (No packet entry) would not allow access to the reply log.
Fixed.

o Some major under-the-hood work. I played around with some compiler
switches that have always been there, but have remained undiscovered
until now. it's 3 years late :>. I've compiled MR/2's code, including the
speller, thesaurus and editor, with 286-or-better code generation
turned on. The 386 code generator caused problems, and I still have
some v1.3/286 users. One day I'll go full 32-bit, but not yet ๐Ÿ™‚
Also, I turned on some aggressive optimizations. I also recompiled
the ZTC tools with these switches. I tried the C runtime library,
but it showed some bad signs, so I switched back.

All this does is provides a little more snap, and a 12k reduction
in EXE size. Nothing revolutionary, but every bit helps.


Changes included in v2.03
-------------------------

o ADD/DROP still had a problem whenever the DOOR and CONTROLNAME
specifiers did not match (in dorr.id). Fixed. Cammail-Gold door
configuration now works.

o Reply logging would work wonderfully ... until you started replying
to subsequent packets into the same REP file. In other words, if
you had a week's worth of packets (as I ended up having), and rifled
through ALL of them without uploading replies, only the replies from
the first packet would be logged. I fixed another bug after that
having to do with source messages, but this wasn't relevant until
the other bug was tackled.

o Killing replies with multiple parts: fixed the bug that killed the
WRONG messages. Big bug (sorry), but it works now.

o Fixed some problems and made some enhancements to the Fidonet node
detection logic (replacing @[email protected] with the source message's
fidonet address). Three digit zones are now supported where two
digits was the previous max (800:676/23). There was a problem with
"@" symbols as part of the Origin line text - fixed. I also now
attempt to extract the Fidonet address from a source message format
that I had never seen before. This format came from a source on
the NITELOG BBS, one which is home to many MR/2 users. I now
look for and use the "Reply:" line when found in a source netmail
message.

o When using U to UNMARK a message (to unkill a reply, for example),
the INDEX markings would not be removed. Fixed.

o Reports of sporadic crashing: some users have emailed me with
crash-reports and supplied debugging addresses. Often these
point me right to a problem. I have a couple of addresses that
are in general routines, and the information supplied is not
helping. I haven't forgotten you! I'm looking for these and
trying to come up with another way to find these. I am also
changing the way I archive older version so as not to "lose"
the chance of making sense out of info from these older version.


Changes included in v2.02
-------------------------

o Modified the after-packet-selection processing so that a local
INI might be loaded *before* the unzipper is called. I've always
held that MR/2 can't know the true BBS name until the packet is
unzipped and the control.dat file is parsed. What happens now is,
as soon as a packet is selected, a "base name" is derived from
the packet name. For example, "e:\dl\pc-ohio.qwk;12" would be
whittled down to "pc-ohio". If an INI file is found with this
base name, it is instantly loaded. Again, this is *before* the
packet is opened, so that BBS-specific unzippers can be identified.
If an INI cannot be found matching this derived name, then MR/2
tries again, the old-fashioned normal way, after the packet has been
opened. If one is found on the first try, no secondary loading is
performed. This *should* work in most cases, particularly when
OS/2 comm packages are used.

NOTE that this is *still* too late to identify a different "working"
directory. MR/2 has already changed the default path by this time.

o Mouse hot spots on message viewing screen changed a little. I made
clicking on the word "Subject:" equal to pressing the "Q" key and
anywhere after the ":" and up to the "Conf:" word is still the same
as pressing "H". This adds easier access to the Q key. Previously,
the entire area was mapped to the "H" key.

While I was at it, I added three more hotspots. The only correlation
between word and feature is that the word starts with the same letter
as the feature. That's how I picked the area :). Click on the "Ref#"
area to "R" Reply. Click on the "Date" area to "D" defer. Click on
the "Status" area to "S" Save.

o That pesky lockup that occured when marking and deleting a block
up to and including the EOF marker has been squashed. I could easily
recreate it here, now it seems to be handled. I simply make sure that
the end mark can't be placed on or after the EOF triangle.

o Bug: With PositionOnMatch set to NO, the key-word highlight would
also be suppressed for virtual conferences. Now the keywords hilite
regardless of the setting of this switch.

o By request ... remapped the numeric keyboard "5" key, when not in
numeric mode (arrows are active) to be equivelent to the ESCAPE key.
As was pointed on, one can now do most message selection and
reading/movement functions from just the numeric pad.


Changes included in v2.01
-------------------------

o Trying to open the WELCOME.QWK packet in the home MR/2 directory
caused a trap and terminated the program. This was caused because of
an error in the code that checks for the "\" character in the packet
file name. If one wasn't there, it would crash. Fixed.

o If a bad "working directory" was set in an icon, MR/2's background
searching virtual conference builder would crash. I've fixed this,
although some questions remain.



KNOWN BUGS AND STUFF
====================

The TEMPORARY directory MUST remain a subdirectory of the MR2 home dir.

You can't use "\" or "&" as part of any search text (since MR/2 uses them
as delimiters).

You can't cancel a search until the first "hit" is displayed. This is
particularly irritating when soundex searching, since soundexing is
noticably slower.

If you set "SkipReadMessages" to true, you cannot gain access to a
conferences where all messages have previously been read.

Other frills that have not yet been addressed: Bulk marking, twit filter.
There are probably others. Feel free to bombard me with requests.



 December 5, 2017  Add comments

Leave a Reply