HISTORY.TXT
                        (for DosLynx v0.43b, June 2012)
                               by Fred C. Macall


Introduction

In this document, I'll try to take up where I left off in the last
history.txt and not rehash the history of the previous versions.
Also, I'll try not to repeat the issues discussion presented in the info.htm
(or, Quick Start) document included in this release.  However, there is a
cumulative list of unresolved bugs, issues, and To Do(s) at the end.
If you want to know everything else there is to know about my previous
releases of DosLynx, you can get that history from:

http://users.ohiohills.com/fmacall/dlx2xdoc.zip
http://users.ohiohills.com/fmacall/dlx3xdoc.zip
http://users.ohiohills.com/fmacall/dlx41/info.htm
and
http://users.ohiohills.com/fmacall/dlx41/history.txt

dlx2xdoc.zip collects the info.htm and history.txt documents for all eight
of my DosLynx v0.2xb releases.  dlx3xdoc.zip does likewise for all nine of
my DosLynx v0.3xb releases.


TURLView::setTApsx( ) Revisited

TURLView::setTApsx(const char * fragment), in TURLVI39.CPP, was introduced
in DosLynx in version 0.26b.  And, described in that release's history.txt
document.  It is where DosLynx goes to locate a #fragment-named label in the
TNSCollection of a document's anchors.  'setTApsx( ) expects its callers to
supply it with a pointer to the # delimited and null terminated tail of a
URL.  It assumed that always would suffice to define a fragment.
However, when a <form . . . tag's action= attribute ends in a # delimited
fragment, there is an opportunity for the appearance of URL(s) ending in:
#<fragment>?<form data element(s)><null> .  Of course, 'setTApsx( )
wasn't able to match this kind of a URL's tail with a document label.

We decided to fix this issue in 'setTApsx( ) by searching a copy of its
fragment parameter's data for a question mark.  Replacing any found with
a null.  And, searching the document's labels for the thereby possibly
shortened or clarified fragment copy.  While studying 'setTApsx( ), we also
noticed it relied on pointers being set, without checking them, in a couple
of places.  This explained crashes we had seen with the
DosLynx Protected Mode versions while processing certain Web pages!
Including a few from Google.

We've extended 'setTApsx( ) to verify that every pointer it needs to use is
non-null.  Upon finding a null pointer while looking for an anchor's label,
it immediately proceeds to considering any following anchor in the present
document's TNSCollection.


Document(s) Ending in an Anchor

If an HTML document can end in a label anchor, example(s) will be found that
do.  DosLynx ran into trouble with such an anchor when it included no
distinguished text.  Because that anchor's distinguished text pointers wound
up pointing to the memory location immediately following the end of the
document.  A trouble preempting anchor checking routine added to DosLynx in
version 0.22b detects such troublesome pointer(s) and removes the offending
anchor(s) from the document's TNSCollection of anchors.  As a result, that
anchor's label gets lost.  For more information on that anchor checking
routine, look for a paragraph beginning:  "The last category 2 issue . . .",
in the DosLynx v0.22b history.txt document.

We decided to fix this issue in TURLView::FormatHTML( ), in TURLVIEW.CPP.
We added an appendCharacter(HT_NON_BREAK_SPACE) call to 'FormatHTML( ), just
ahead of its final split_line( ) call.  The idea is to insure that the
document's text extends beyond any final anchor.  However, this addition
(alone) was not enough to fix the problem.  Because, that last split_line( )
call may eliminate trailing space(s), even "non-breakable" ones, from the
end of the document.  So, we took this Kludge a step further by defining a
-1 value for split_line( )'s ssi_split parameter.  We've extended
split_line( ) to omit its trailing space(s) elimination when ssi_split is
less than zero.  And, we've changed TURLView::FormatHTML( )'s final
split_line( ) call to read:  split_line(-1) .


E-Mail Client's Handling of Server's Response to the EHLO Command

An SMTP server's response to an e-mail client's EHLO command may consist
of a multi-line list of "advertisements" for the service(s) it then offers
and/or requires.  Work was done, for the release of DosLynx v0.41b, to
improve the handling provided for such a multi-line list.  However, even
with that, the e-mail client's provision for recognizing an AUTH LOGIN
advertisement, in these responses, didn't allow for the AUTH PLAIN LOGIN
variation of this advertisement.  SMTP servers, like
smtp-server.nyc.rr.com , now use this form in place of a pair of AUTH PLAIN
and AUTH LOGIN advertisements.

TDosLynx::mailDeveloper( ), in TDOSLY15.CPP, has been extended to find an
AUTH LOGIN advertisement even where other keyword(s) intervene to separate
the AUTH and LOGIN keywords.


Updated Score

As explained under the heading:  Keeping Score, in the history.txt for
DosLynx v0.20b, I am maintaining an informal written list of DosLynx issues
and their resolutions.  In addition to the issues it's always had, this list
now includes issues that have come along in connection with the DosLynx
Protected Mode versions.  At the time of this writing, for the release of
DosLynx v0.43b (early in May 2012), my list has about 658 issues.
Of these, about 459 (over two thirds) have been resolved or ameliorated.
This leaves a total of about 199 issues pending.

If you will look ahead to the next section for a moment, you may note that
several of the pending issues include the parenthetical observation:
"This is hardly an issue with the DosLynx Protected Mode versions."
For the most part, these are memory management issues that may be important
with the DosLynx Real Mode version.  However, since the DosLynx
Protected Mode versions have memory to spare, these aren't significant
issues with them.  As far as users of a DosLynx Protected Mode version are
concerned, the issues to which these observations apply have been resolved.
On the other hand, the DosLynx Protected Mode versions do have a few issues,
of their own, that don't apply to the Real Mode version.

A study identifying issues that don't apply to all three versions finds
about 157 pending issues that do apply to all three versions.  Or, about
42 issues that only apply to one or two version(s).  There are a total of
about 178 issues pending for the Real Mode version.  About 171 issues
pending for the 16-bit Protected Mode version.  And, about 178 issues
pending for the 32-bit Protected Mode version.  (These figures tend to be a
bit "noisy".  They depend on how we count issues that pertain to the OpenSSL
support that only the 32-bit Protected Mode version has.  Or, on how we
count issues that pertain to performance on slow systems.)  In the next
section, I'll list a few of the 199 pending issues that haven't been
mentioned above.

To Do

With both https/SSL support and secure e-mail support working in the
DosLynx 32-bit Protected Mode version, I feel that I have reached all of
my previous higher priority goals for DosLynxS.  Whether either of the
16-bit versions will ever be able to incorporate OpenSSL support still
remains to be seen.  As the previous section indicates, my informal DosLynx
issues list still has a lot of pending issues.  But, few of those seem to me
to be "burning" issues.  If DosLynx has a burning issue, I think it is to
find some way to give it some support for Java Scripts!  However, right now,
I still can't plan on having that ready in the next release.

So, for the immediate future, I am going to spend less time on DosLynx.
And focus on developing EHLO response handling fixes for PMSMTP and PMPULL.
If you use DosLynx at least occasionally, I hope you will write and tell me
what feature(s) or fix(es) would make it more useful for you.

Here is a summary of some of the pending DosLynx issues not discussed
anywhere above:

  -  Provide https/SSL/TLS support for the DosLynx 16-bit version(s).
     (This is expected by many Web servers that support data entry.)

  -  Provide Login (original AUTHINFO) support for the news client?

  -  Support the HTML Form <INPUT TYPE=file . . . variation.  (This is part
     of the so called "file upload" capability.)

  -  Find some way to guard against making duplicate Post requests.
     (Bypass:  Move the anchor cursor off the submit button after using it,
     if/when you resume, or first return to, a window containing a submitted
     Form!)

  -  Provide some way for retrying a temporarily failed e-mail send attempt?

  -  Support the HTML Form <BUTTON . . . tag
     (like <INPUT TYPE=submit . . . )?

  -  Automatically replace space(s) with %20 , in links being followed or
     other URLs requested.  (Bypass:  Use the Navigate|Show Destination URL
     (Alt-U) menu entry or command to paste a troublesome link's URL into
     the File|Open URL... (F3) dialog's history.  Then, edit it for use.)

  -  Provide a convenient Cookie(s) file viewing dialog or tool.

  -  How about a fast way to get to the directories, at the end of a long
     files list, in a local file dialog?  (Bypass:  After focusing on a
     list of local files, use Ctrl-PgDn to move to its end, quickly.
     Use Ctrl-PgUp to move back to its start, quickly.)

  -  Find a way for the 16-bit Protected Mode version to support the stock
     Microsoft mouse driver in Windows 2000 DOS windows, successfully.
     Find a way for the 32-bit Protected Mode version to support the stock
     Microsoft mouse driver in Windows NT DOS windows, successfully.
     (This isn't an issue with the DosLynx Real Mode version.
     Bypass:  Use mouse= configuration to disable support of the mouse,
     where necessary.)

  -  Find a graceful way for the FTP client to deal with directory reports
     that are too large to be memorized.  (This is hardly an issue with the
     DosLynx Protected Mode versions.)

  -  Find a way for the File|Save Source and Navigate|Download Selection
     menu entries to handle FTP directory reports that are too large to be
     memorized.  (This is hardly an issue with the DosLynx Protected Mode
     versions.)

  -  When your display is set in a VESA mode upon running DosLynx, its
     arrangement(s) for saving and restoring the screen mode may break down.
     (Bypass:  Set your display into a "legacy mode" before running
     DosLynx.  Or, (re)do the display set up you want afterward.)

  -  Provide for displaying directory entry details, beyond filename, from
     the WAR-FTP Daemon's DOS style directory reports.

  -  Provide a configurable "download directory".  (Bypass:  use the command
     line /P option (as demonstrated in DOSLYNX.BA_) and set your DOS
     default drive and path to specify the directory you want to download
     into.)

  -  Provide a "disk view" number at the bottom of the screen that isn't
     limited to the 2.1 GB maximum size of a DOS FAT16 partition.  So, the
     free space available for a DosLynx temporary directory in a large DOS
     FAT32 partition won't be under-reported.  (Presently, the disk view
     number stays at or about 2147418112 as long as the large partition has
     at least that much space free.)

I hope you will let me know what you think about the way the DosLynx
Protected Mode versions have turned out.  Or, if you have any comment(s) or
question(s) in any connection with DosLynx v0.43b!  As I don't have a
'286 based PC, presently, I am especially interested in hearing from anyone
who is able to try the DosLynx 16-bit Protected Mode version on such a
system.

fcm