HISTORY.TXT
                      (for DosLynx v0.33b, November 2006)
                               by Fred C. Macall

Introduction

This is for my twelfth release of DosLynx.

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.
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 most of that history from:
http://users.ohiohills.com/fmacall/dlx2xdoc.zip .
This archive collects the info.htm and history.txt documents for all eight
of my DosLynx v0.2xb releases.  For the rest, the documents for
DosLynx v0.30b, v0.31b, and v0.32b are available at:
http://users.ohiohills.com/fmacall/dlx30/info.htm
http://users.ohiohills.com/fmacall/dlx30/history.txt
http://users.ohiohills.com/fmacall/dlx31/info.htm
http://users.ohiohills.com/fmacall/dlx31/history.txt
http://users.ohiohills.com/fmacall/dlx32/info.htm
and
http://users.ohiohills.com/fmacall/dlx32/history.txt .

Protected Mode Version breakout( ) Call Upon Showing a Long URL

MYALLOC.CPP, introduced in the history.txt for DosLynx v0.31b, contains a
realloc( ) function consisting of only a wrapper for a breakout( ) call.
It is included in the DosLynx Protected Mode version, but not in the
Real Mode version.  The idea is that all the realloc( ) calls in DosLynx
should have been replaced with caprealloc( ) calls.  Well, when I worked on
MYALLOC.CPP, I had already forgotten a realloc( ) call I added to
TURLView::handleEvent( )'s case cmShowDestination, in TURLVIE9.CPP.
I think that addition came in the course of implementing the
Navigate|Show Destination URL (Alt-U) dialog's Paste button.  That work was
reported under the heading:  A Second Paste Button, in the history.txt for
DosLynx v0.29b.

The troublesome realloc( ) call was intended to resize a memory allocation 
containing a copy of the URL string being reported.  After truncating a long
URL string, to 250 octets.  This wasn't a significant issue with the DosLynx
Real Mode version, because it contains the realloc( ) function supplied by
the Borland C/C++ compiler's runtime library.  I've replaced that overlooked
realloc( ) call with the caprealloc( ) call that I should have used in the
first place.

Bad /P Command Line Parameter Value Triggered a Protection Violation

When given a bad /P command line parameter value, the DosLynx Protected Mode
version sometimes tried to use an invalid selector number, in tcp_config( )
in WATTCP module PCCONFIG.C.  This occurred because tcp_config( )'s
(auto) char * temp variable would get used without having been set, in that
case.  The same problem probably occurred, but tended to go unnoticed, in the
DosLynx Real Mode version.  I've resolved this issue by moving the setup, for
tcp_config( )'s temp variable, to follow the else clause that previously
contained it.

HTTP Location: Header Field Recognition Failure

HTLoadHTTP( ), in HTTP.C, wasn't case insensitive when it looked through
received Headers for a Location: field, after receiving a 3xx (redirect)
response.  This caused it to fail to find the location: field that at least
one Web server likes to use.  I've extended HTLoadHTTP( ) to make it
completely case insensitive in its search for a Location: Header field.

Missing HTML </SELECT> Tag Caused Unexpected Error in Formatting

HText_beginAnchor( ), HText_beginSelect( ), and HText_endForm( ) all contain
precautionary calls to HText_endSelect( ), for dealing with missing HTML
</SELECT> tags.  These functions are all defined in GRIDTEXT.CPP.
However, these precautionary calls aren't sufficient to take care of the
exception(s) they were intended to handle.  Because, a call to
HText_endSelect( ), by itself, is no longer sufficient to signal the end of a
<SELECT . . . block's processing, to TURLView::FormatHTML( ) in TURLVIEW.CPP.
This is the result of work done to resolve an earlier exposure in
<SELECT . . . block processing.  That was described under the heading:
More Forms Support, in the history.txt for DosLynx v0.27b.

In short, a somewhat more elaborate protocol was developed for signalling the
end of <SELECT . . . block processing, from HTML_end_element( )'s case
HTML_SELECT in HTML.C, to 'FormatHTML( ).  Since that work was done, for
DosLynx v0.27b, HTML_end_element( )'s case HTML_SELECT has been using both an
HText_endSelect( ) call and an HText_endAnchor( ) call to signal the normal
end of <SELECT . . . block processing.  'FormatHTML( ) produces a malformed
presentation file when an HText_sendSelect( ) call doesn't get followed up
by an HText_endAnchor( ) call.  A presentation file malformed in this way
gets detected and reported when the presented document gets scrolled to the
vicinity of the missing HText_endAnchor( ) call.

To resolve this issue, I've extended HText_beginAnchor( ) and
HText_endForm( ) to explicitly check for <SELECT . . . block processing in
progress.  (HText_beginSelect( ) already had this explicit check.)
And, I've added an HText_endAnchor( ) call to follow up the existing
HText_endSelect( ) call, in both those extended functions and in
HText_beginSelect( ).  This arrangement doesn't completely compensate for a
missing </SELECT> tag.  But, it avoids producing a malformed and disruptive
presentation file, in that case.

While studying the code in connection with this work, I also noticed that
HTML_end_element( )'s case HTML_SELECT wasn't verifying that a <SELECT . . .
block is actually in process.  I've given it a new HText_getselnam( ) call
for making the needed check.

Missing Short-Cut Keys Added

Encouragement from Robert Riebisch, http://www.bttr-software.de/ , helped me
see the need for filling the gaps in the Short-Cut keys provided in the
DosLynx File and Navigate menus.  New Short-Cut keys have been chosen for the
File|Open Local..., File|Dos Shell, and Navigate|Find... menu entries or
commands.  With the new Short-Cut keys determined, the rest of the work was
simply to add their definitions to TDosLynx::initMenuBar( ), in TDOSLYN9.CPP,
and TDosLynx::initStatusLine( ), in TDOSLY10.CPP.  I've also added the new
Short-Cut keys to the KEYS.TXT document.

More Configuration for the E-Mail From: Line

Robert Riebisch also helped me see the need for a better E-Mail From: line.
DosLynx was using its IP address, in quotes, followed by the configured
E-Mail address, on its From: line(s).  I've added a new fromname=
configuration item for providing one's "name in real life".  If it is
provided, this configuration value will replace the IP address, on From:
line(s).

Perhaps needless to say, the work for this addition consisted of:  Adding an
extern char * cp_frnam variable to GLOBALS.H.  Adding a char * cp_frnam = 0
instantiation to GLOBALS.CPP.  Adding a small section, to
TDosLynx::EvalConfigFile( ) in TDOSLY14.CPP, for extracting, copying, and
assigning a fromname= configuration string to cp_frnam.  And, adding a little
code to TDosLynx::mailDeveloper( ), in TDOSLY15.CPP, for composing the
revised From: line, when cp_frnam is non-zero.

Limited Support for Five More HTML Tags

Here, "Limited Support" implies the kind of support that DosLynx has already
been giving the HTML <IMG . . . and <FRAME . . . tags.  A place holder and/or
anchor or link are provided, to afford access to the tag's resource.
But, the IMG's resource isn't automatically displayed.  Nor is the FRAME's
resource automatically presented.

Since the HTML <BGSOUND . . . and <EMBED . . . tags have syntax like the
<IMG . . . tag, I decided to make them additional near synonyms for the
<IMG . . . tag.  (The apparently non-standard <IMAGE . . . tag is an existing
synonym for the <IMG . . . tag.  It was introduced in the history.txt for
DosLynx v0.24b.)  Here, "near synonyms" implies that the handling for these
tags isn't quite identical to the handling for <IMG . . . and <IMAGE . . . .
The difference is that, when showmetas=NO is configured, the near synonym
tags will be given a [BGSOUND] or [EMBED] place holder.  These take the place
of the [IMAGE] place holder provided for <IMG . . . and <IMAGE . . . tags.
When the configuration doesn't include showmetas=NO, the place holder for
all four of these tags will be [urlfilename].

In addition, the HTML <IFRAME . . . tag will now be supported as a synonym
for the <FRAME . . . tag.  And, the <LAYER . . . and <ILAYER . . . tags will
now be supported as near synonyms for the <FRAME . . . tag.  The difference
for these is that a Layer: place holder will be provided in place of the
existing Frame: place holder.

To support these five new HTML tags, I've added definitions for them 
paralleling the existing definitions for <IMG . . . and <FORMAT . . ., in
HTMLDTD.H and HTMLDTD.C.  Also, there are additional case labels for
cases HTML_IMG and HTML_FORMAT, in HTML_start_element( ) in HTML.C.
Finally, a little more new HTML_start_element( ) code provides the alternate
place holders.

Nested HTML <IMG . . . Tags Revisited

Here, I am also referring to the synonymous <IMAGE . . ., <BGSOUND . . ., and
<EMBED . . . tags discussed just above.  In DosLynx v0.27b, work was done to
give <IMG . . . tags, nested within anchors, their own place holders.
The approach taken is to defer a nested <IMG . . . tag's processing until the
containing anchor's </A> tag is reached.  This has worked out as well as I
imagined it would, with one big exception.  The work done for DosLynx v0.27b
only provided for deferring the processing of a single <IMG . . . tag per
containing anchor block.  But, HTML examples have now been found containing
as many as twenty <IMG . . . tags nested within a single anchor block!
In these cases, all but the last of the nested <IMG . . . tags got lost and
didn't appear in the DosLynx presentation.

The fix for this issue has been to provide for a more or less unlimited
number of <IMG . . . tags nested within a containing anchor block.
Two of the three HTML.C globals added for handling nested <IMG . . . tags,
in DosLynx v0.27b, have now been replaced.  That is:

    HTChildAnchor * HTCAp_img ;
    char * lastimg = 0 ;

have been replaced with:
 
    struct imglst
        {
        struct imglst * next ;
        char * cpimg ;
        HTChildAnchor * HTCApimg ;
        }
    struct imglst firstimg = { 0, 0, 0 } ;
    struct imglst * silp = & firstimg ;

Also, struct imglst * freeimglst(struct imglst * somelst) and
void HTML_endAnchor ARGS1(HTStructured *, me) have been added to HTML.C.

freeimglst( ) takes care of destroying or free(ing) any list of struct imglst
objects linked to a somelst object, which isn't free(d).
HTML_endAnchor( ), which isn't to be confused with HText_endAnchor( ) in
GRIDTEXT.CPP, also runs through any list of struct imglst objects found
linked to firstimg.  It does the deferred processing needed for the
<IMG . . . tag(s) that list of struct imglst objects represents.

Where case HTML_IMG, in HTML_start_element( ) in HTML.C, remembered an
<IMG . . . tag's components in lastimg and HTCAp_img, it now remembers the
same things in silp->cpimg and silp->HTCApimg.  It then uses a capcalloc( )
call to construct another empty struct imglst object and links it into
silp->next.  HTML_endAnchor( ) contains several HText_endAnchor( ) calls and
is designed to replace an HText_endAnchor( ) call, in the six places in
HTML.C, where that is appropriate.  Of course, case HTML_A in
HTML_end_element( ), in HTML.C, is one of those six places.
freeimglst( ) gets called from the two places, in HTML.C, where lastimg used
to get cleared.

Perfected Support for the ISO-8859-1 (8-bit) Character Set

I have been cataloging this issue as:
  -  The handling of special characters seems to need work.

There never seemed to be time for this issue until a Protection violation
arose, in the DosLynx Protected Mode version, from UnEscapeEntities( ) in
HTML.C.  This protection violation came as a result of nonsense being
performed in the name of processing numeric character entities.  Upon having
my attention so forcefully drawn to that nonsensical processing, I decided
that the time had come to tackle this issue.

Let me recount the ways I found that DosLynx was deficient in its handling of
special characters:  By "special characters", I mean the 96 characters that
ISO-8859-1 adds to the ASCII (7-bit) set.  The nonsensical handling of
numeric character entities, in UnEscapeEntities( ), was only the first of
these.  By "numeric character entities", I mean sequences like &#160;
By "character entity names", I mean sequences like &nbsp;
By "character entity", I mean either a numeric character entity or a
character entity name.  The provisions for handling character entity names,
in UnEscapeEntities( ) and in SGML_character( ) in SGML.C, made some sense.
But, these still had issues, too.

First, the translate tables:  static CONST char * entities[ ], in HTMLDTD.C,
and static char * ISO_Latin1[ ], in HTML.C, contained entries for only about
half of the one hundred plus entity names needed.  The entries in
ISO_Latin1[ ] generally provided a translation to the PC's Code Page 850
encoding.  However, no such translation was provided for any of an HTML
document's other characters.

The nonsense section for processing numeric character entities in
UnEscapeEntities( ) seemed to take a stab at checking for out of range
numeric values.  Meanwhile, the more reasonable counterpart code in
SGML_character( ) had no such check.  And, all four of the character entity
handling sections had their own individual ways for dealing with apparent
entity sequences ending in a character other than semi-colon!

I started work on this project by filling out entities[ ], with an additional
entry for each of the special characters that hadn't been represented before.
Since entities[ ]'s name entries are alphabetically ordered and have to be
matched by at least one other table, I also added a sequence number and
ISO-8859-1 encoding value to the comments for all entries.

Next, I needed to update ISO_Latin1[ ] to match the updated entities[ ].
Here, I also decided to remove the translation to PC code.  That translation
has been replaced as described below.  Without translation, ISO_Latin1[ ]
needs just a single character per entry.  So, I've replaced it with the new
array static unsigned char ISO8bit[ ], which has all new initialization.

Next, I took the nonsense out of the numeric character entity handling part
of UnEscapeEntities( ).  At this point, I also decided to pass all
unrecognized or out-of-range entity sequences through without change.
I also decided on a consistent handling for the last character of accepted
character entity sequences.  It won't be required to be a semi-colon.
It now may be any non-alphanumeric character.  Then, assuming an accepted
character entity value, if the last character isn't &, <, or >, it will be
consumed by entity processing.  If it is one of the three characters
mentioned, it will be left for reprocessing as the next input character.
I also revised both of SGML_character( )'s character entity handling
sections, to match these rules.

There are two notable results from all the changes discussed above.
First, one now observes a much lower rate of character entity name sequences
going unrecognized.  This, of course, is mostly attributable to having added
entries, for about fifty missing entity names, to the tables.
However, in a few documents, no longer requiring some character entity
sequences to end in a semi-colon is also a factor.  On the other hand, one
now observes a much higher rate of apparent numeric character entity
sequences going unaccepted or unrecognized.  This is because DosLynx is now
rejecting, and passing through, all apparent numeric character entity
sequences having values above 255.  This is something it did rarely, if ever,
before.  Many of the apparent numeric character entity sequences now being
rejected seem to represent a relatively small sample of defined Unicode
characters.  Characters like apostrophes, bars, dashes, and left and right
quotes.  DosLynx still has no way to handle Unicode characters.  But, I am
thinking of having it provide ISO-8859-1 approximations for the more
frequently seen numeric Unicode character entities.

At about here, translation from ISO-8859-1 encoding to PC code became the
last main issue to be treated, in this area.  I decided to include this
translation function in HText_appendCharacter( ), in GRIDTEXT.CPP.
This translation has to be to Code Page 850.  Because none of the other
Code Pages defined for DOS carry all of the ISO-8859-1 characters.
This is unfortunate because the DOS default or hardware Code Page in english
speaking countries tends to be Code Page 437.  To help a little with this,
I've added a section entitled:  Code Page 850 Cook Book, to the DosLynx
README document.  This new section provides a fairly simple recipe for
changing one's DOS set up, for the PC's console or display, to use the
Code Page 850 character set.

However corrections for the problems identified above might have been
structured, an additional translate table would need to be added to the
original entities[ ] and ISO_Latin1[ ] pair.  Given the choices I had already
made, neither entities[ ] nor ISO8bit[ ] are relevant to translation from
ISO-8859-1 encoding to PC Code Page 850.  So, I needed to introduce a new
translate table for HText_appendCharacter( )'s use.  This new table, which
doesn't need to correspond with entities[ ], is located in GRIDTEXT.CPP.

I had seen a surprisingly large reduction, in the size of DOSLYNX.EXE, result
from my replacement of static char * ISO_Latin1[ ] with
static unsigned char ISO8bit[ ].  (The .EXE size change was around eight to
ten octets per ISO_Latin1[ ] element.  Rather then the five octets per
element, for each element's pointer and string ending null, that I had
initially expected.  I now suppose that there must have been four additional
octets needed, per element, for initializing or relocating the pointers that
ISO_Latin1[ ] included.)  So, I was inclined not to make this new table
follow the example of ISO_Latin1[ ].  A study of ISO_Latin1[ ]'s entries made
this choice clear.  Only two or three of its entries were anything other than
single character strings.  Those few longer entries could be handled by
special casing in HText_appendCharacter( ).  So, the new translate table may
as well be a char array.  I've declared it const char ISO2pccp[ ].

ISO2pccp[ ] provides for translating only the 96 characters that ISO-8859-1
adds to ASCII.  That is, characters in the range of &#160; to &#255;
The ASCII (7-bit) characters are well matched by the PC's Code Pages,
including Code Page 850.  So, the ASCII characters don't need translation.
And, except in their most significant bit, the characters in the range of
&#128; to &#159; correspond to the ASCII control characters.  They have been
left undefined by the HTTP, HTML, and/or ISO-8859-1 specification(s).
So, except for &#151;, I've left them to be defined by the DOS Code Page in
use, as well.  Normally, that will be Code Page 850.  Right?  A special case
in HText_appendCharacter( ) grandfathers &#151;, as an EM Dash, and
translates it to &#196;  Fortunately, &#196; is also an EM Dash in
Code Page 437.

Putting translation into place, in HText_appendCharacter( ), broke the
Horizontal Rules.  To fix them, I replaced the '-' (&#196;) literal in case
HTML_HR, in HTML_start_element( ) in HTML.C, with '\227' (&#151;).
I wasn't able to find any other PC coded literal(s), like this one, in
HTML.C.

Finally, having seen the big reduction in the size of DOSLYNX.EXE that came
from replacing ISO_Latin1[ ] with ISO8bit[ ], I decided to change
static CONST char * entities[ ] to static CONST char entities[ ][8].
This did yield another reduction in the size of DOSLYNX.EXE.  But, not such
an impressive reduction.  Because, the average length of the entities strings
increased from about six to eight, in this change.  This change involved a
matching change, to the definition of entity_names, in
typdef struct { . . . } SGML_dtd in SGML.H.  entity_names is now declared as
CONST char (* entity_names) [8], there.  This is an instance of tricky C
parenthesization.  entity_names is now defined as a pointer to
char . . . [8], rather than as an array of pointers to char.
Next, the initial data value given for number_of_entities, in
PUBLIC CONST SGML_dtd HTML_dtd in HTMLDTD.C, needed restatement to
size(entities)/8.  And, of course, the actual users of entities[ ][8] needed
adjustments for this change.  These are UnEscapeEntities( ), in HTML.C,
handle_entity( ), in SGML.C, and HTMLGen_put_entity( ), in HTMLGEN.C.

DosLynx now consistently translates all of its input from ISO-8859-1 encoding
to DOS Code Page 850, in its document presentations.  (Meanwhile, its three
Save Source and Download type commands remain transparent.  They don't do any
translation on the data they process.)  So, one's viewpoint naturally adjusts
to expect the full 8-bit character set's handling to always make sense.
From this viewpoint, the File|Save Rendering... (F2) menu entry or command
now presents a dilemma.  Should this command write its file with ISO-8859-1
encoding or with Code Page 850 characters?  Or, optionally, either?
The trouble with writing using ISO-8859-1 encoding is that other PC
utilities, such as the TYPE or PRINT commands, may not have any way to
correctly handle that encoding.  On the other hand, writing using the
Code Page 850 character set yields a file that DosLynx can't correctly
read-back!

I've taken the course of least effort, for now.
The File|Save Rendering... (F2) menu entry or command will (continue to)
write its file with Code Page 850 characters.  That will preserve this file's
suitability for PC utilities that don't know ISO-8859-1 encoding.
However, as explained above, DosLynx doesn't have any way to correctly
read-back or import such a file, for now.  This arrangement adds another
reason for using one of the three DosLynx Save Source and Download type
commands.  When a file is desired for later viewing with DosLynx.
These commands are:  File|Open URL... (F3, with its Download button),
File|Save Source (Alt-S), and Navigate|Download Selection (Alt-D).
I welcome suggestions for resolving this issue.

Parting Shot

While testing HTML examples containing some of the five newly supported HTML
tags discussed above, the DosLynx Protected Mode version demonstrated another
Protection violation.  This one came from HTML_put_value( ), in HTML.C.
HTML_put_value( ) was introduced in the history.txt for DosLynx v0.26b.
The trouble was that HTML_put_value( ) was being called with zero for its
CONST char * cpstr parameter, from case HTML_AREA in HTML_start_element( )
in HTML.C.  The example being tested just then contained an HTML <AREA . . .
tag with no href= specification.  A review of all the calls to
HTML_put_value( ) disclosed that case HTML_FRAME, in HTML_start_element( )
was also exposed to this kind of a problem.  In that case, when the src=
specification wasn't provided.

To fix these problems, I've added checking to cases HTML_AREA and HTML_FRAME,
in HTML_start_element( ).  The added checking will keep those cases from
trying to develop their anchor, when the needed href= or src= value isn't
available.

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 version.  At the time of this writing, for the release of
DosLynx v0.33b (in the middle of November 2006), my list has about
497 issues.  Of these, about 368 (close to three quarters) have been resolved
or ameliorated.  This leaves a total of about 129 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 version."
As far as users of the DosLynx Protected Mode version are concerned, the
issue(s) to which this observation applies aren't really pending issues.
On the other hand, the DosLynx Protected Mode version does have a few issues,
of its own, that don't apply to the Real Mode version.  A study identifying
issues that don't apply to both versions finds about 123 issues pending for
the Real Mode version and about 119 issues pending for the Protected Mode
version.

In the next section, I'll list a few of the 129 pending issues that haven't
been mentioned above.

To Do

With the DosLynx Protected Mode version now well on its way, pressure is
building to implement some of the enhancements listed among the top five
entries in the following list.  I hope to be able to do something about one
or more of these "top five" issues in the next year.

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

  -  Provide https/SSL/TLS support.  (This is expected by many Web servers
     that support data entry.)

  -  Provide cookies support.  (This, too, may be expected for 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.)

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

  -  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 first return to a window containing a submitted Form!)

  -  Honor the HTTP Pragma: no-cache header field, the Cache-Control: . . .
     header field, and/or the HTML <META HTTP-EQUIV="Pragma"
     CONTENT="no cache"> directives.  And/or, provide a menu entry or command
     for designating all cached document(s) "stale".  (Bypass:  Use the
     Navigate|Reload Current menu entry or command, when necessary.)

  -  Find a way for the Protected Mode version to successfully support the
     stock Microsoft mouse driver in Windows 2000 windows.  (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 version.)

  -  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
     version.)

  -  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.)

  -  Provide for displaying directory entry details, beyond file name, 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'll let me know what you think about the way the DosLynx
Protected Mode version has turned out.  Or, if you have any comment(s) or
question(s) in any connection with DosLynx v0.33b!  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 Protected Mode version on such a system.

fcm