HISTORY.TXT
                      (for DosLynx v0.30b, December 2005)
                               by Fred C. Macall
 
Introduction

This is for my ninth release of DosLynx.  This is a special release, not
only because it is the first of what I hope will be a fruitful series of
v0.3x releases.  But, of course, also because this is the first release of a
DosLynx Protected Mode version.

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 now get that history from:
http://users.ohiohills.com/fmacall/dlx2xdoc.zip .
This archive collects the info.htm and history.txt documents for all of my
DosLynx v0.2xb releases.

Although I haven't got it connected to my home network, yet, I again have a
'386 based PC for testing.  It is a big Zenith box, from 1990, that I call
Willy.  It is a cached 5 Bogo MIPS system with 4 MB of RAM, a 200 MB disk,
and a Numeric Processor.  So, it is well qualified for running Windows v3.x
and, perhaps, Windows 95.  This has proven to be a very comfortable minimum
system target for the DosLynx Protected Mode version.  What would make a
more rigorous target, of course, would be a '286 based system with 4 MB of
RAM.  I am still looking for one of these.

Old Business

Well, the work done to activate the Command Status Indicators, in the last
release, hasn't been entirely trouble free.  That can be pretty obvious when
a Command Status Indicator like Prior sits there with the wrong indication,
at times.  But, most bothersome was the arrangement made in
TURLView::draw( ), in TURLVIE6.CPP, for issuing a cmUpComs command upon
finding a change in its TURLView::TAp_selected's value.  The processing time
added to 'draw( ), when it did issue a cmUpComs command, seemed to aggravate
Turbo Vision's flakiness in interpreting the keyboard, on systems with a
slower processor.

In the interests of keeping TURLView::draw( )'s processing time from getting
much longer than it had been, I've revised it to only set a global indicator,
itapschd, when it finds 'TAp_selected changed.  itapschd is defined in
GLOBALS.H and instanciated in GLOBALS.CPP.  TDosLynx::idle( ), in
TDOSLYNX6.CPP, now checks itapschd and issues a cmUpComs command upon finding
it set.  This way, the time for processing that command doesn't get expended
unless or until the system is free enough to be running in its idle loop.
A small complication is that TURLWindow::URLoader( ), in TURLWIND.CPP, needs
to clear itapschd in order to keep a possibly pending cmUpComs command from
getting issued while loading a document.  Of course, I have also added some
more setComs(1) calls to TURLWindow::handleEvent( ), in TURLWIN4.CPP.
These plug loopholes I've found in the Command Status Indicators' updating.
However, I still haven't found a good solution for the unresolved issue with
the Command Status Indicators, acknowledged in the last history.txt.

I am still not sure where TURLWindow::handleEvent( )'s 'clearEvent( ) calls
should go.  I first acknowledged this under the heading:  Hangs Deep Into
DosLynx Sessions, in the history.txt for DosLynx v0.28b.  However, the
change reported there, for case cmLoadChild's 'clearEvent( ) call, has seemed
to have only helped.  So, I decided to move all the rest of the early
'clearEvent( ) calls to the ends of their containing cases.  I checked the
'clearEvent( ) calls in all of the DosLynx 'handleEvent( ) functions.
But, found them needing this movement only in TURLWindow::handleEvent( ).
I've moved several 'clearEvent( ) calls, there, and added a few more where
logic branching leads to one or more break(s).  I haven't seen any sign of
this hurting anything.

The Navigate|Go To (Alt-G) menu entry or command, also added in the last
release, seems to be working well.  However, I noticed that the new dialog's
initial cursor position was a little less than completely satisfactory, from
the user's standpoint.  That dialog's cursor should start at the end of the
list, shouldn't it?  To make it do that, I've added a
TLBHp->setFocus(nrurls - 1) call to TURLWindow::navGo( ), in TURLWI14.CPP.

Additional User Interface Touches

Even after having worked on HTHnSGut( ), in HTFWRITE.CPP, for many of my
previous releases, the local file name suggestion it offered still wasn't
right in some cases.  This problem came from URLs with names containing
multiple periods.  In those cases, the suggested name often wound up with
the wrong suffix.  I've added another small loop to HTHnSGut( ) to fix that.
It works through the suggested name and replaces all period(s), other than
the last one, with under bars.

I've occasionally had trouble understanding the error message(s) delivered
after trying to access a URL with a service type or protocol name that
DosLynx doesn't recognize.  For example:  https: , which DosLynx still
doesn't handle.  The message(s) seemed to say that the URL wasn't available,
i.e.:  didn't exist, when I sometimes knew that not to be the case.
I decided to add a new message making the trouble clear, when DosLynx can't
handle the service type given.

A URL's service type gets recognized in get_physical( ), in HTACCESS.C.
It returns the value:  HT_NO_ACCESS when it can't recognize the service type.
get_physical( ) gets called from HTLoad( ), also in HTACCESS.C.  It was 
checking get_physical( )'s return for the value:  HT_FORBIDDEN.  That's a
value that get_physical( ) doesn't return.  So, I've revised HTLoad( ), to
check get_physical( )'s return for the value:  HT_NO_ACCESS.  I've also
changed HTLoad( )'s previously unseen message, for this case, to something a
little more appropriate for the HT_NO_ACCESS case.

Character Entities in URLs

Character Entities, such as > and & , are sequences used to encode
special characters in HTML.  Character Entity sequences always start with
ampersand.  So, that makes ampersand a special character.  These commonly
appear in URLs because ampersand has an additional special meaning in URLs!
Ampersand(s) are used to separate name=value sequences in URLs developed to
express Form content.  When such a URL is included in an HTML document, it
is felt that its ampersand(s) must encoded in & Character Entity
sequences, to avoid any ambiguity.  However, most servers probably don't
expect to see those & Character Entity sequences in submitted URLs.
So, it is up to a browser to interpret any Character Entity sequence(s) in
an HTML document's URL(s) before submitting any of those URL(s) to a server.
DosLynx hasn't been doing this.

The natural place to take care of this omission was HTML_start_element( ), in
HTML.C.  HTML.C also contained an UnEscapeEntities( ) function, for
interpreting the Character Entity sequence(s) in a string.
But, HTML_start_element( ) was only calling HTSimplify( ) in the eight places
where it also should have been calling UnEscapeEntities( ).  To avoid having
to add eight UnEscapeEntities( ) calls to HTML_start_element( ), I added the
following short wrapper to HTML.C:

/*  Wrapper for a pair of UnEscapeEntities( ) and HTSimplify( ) calls.
*/
PUBLIC void uneensim ARGS1(char *, s)
{
HTSimplify(UnEscapeEntities(s)) ;
}

Then, I changed all eight of HTML_start_element( )'s HTSimplify( ) calls to
uneensim( ) calls.

This story might have ended here.  But, while testing, I came across an HTML
document containing a Character Entity sequence in a URL's #fragment part.
This is used to refer to a label in the URL's document.  Sure enough, the
label in question also contained a Character Entity sequence.  Once the URL's
Character Entity sequence had been interpreted, it no longer matched the
label!  To correct this, I've extended HTML_start_element( )'s case HTML_A
processing to give value[HTML_A_NAME] UnEscapeEntities( ) treatment.

TCP/IP Timeouts at Midnight

You may recall my eventual triumph over the heap corruption stemming from a
small omission in tcp_ProcessData( ), in PCTCP.C.  That was reported in the
history.txt for DosLynx v0.28b.  Well, that episode's result encouraged me to
tackle this issue, finally.  This one turned-out to be a lot easier for me to
figure out.  The bug found here amounted to another small omission.

cpublic functions set_timeout( ), set_ttimeout( ), and chk_timeout( ) are all
contained in TIMEOUT.ASM.  set_timeout( ) and set_ttimeout( ) were dependent
on chk_timeout( ), for handling the BIOSCLK's midnight rollover.  But, they
weren't calling chk_timeout( ), nor doing anything else, to get it called
when necessary.  They produced an incorrect result when run, without an
intervening chk_timeout( ) run, after the midnight BIOS Time-Of-Day Clock
rollover.  In that case, their result was way low and produced a time-out as
soon as it got checked.  As TCP/IP being done at midnight often may be part
of a long download, the occasional midnight time-outs that resulted were
usually quite frustrating and memorable.

I've fixed this issue by moving chk_timeout( )'s midnight rollover handling
sequence into a GETOD PROC NEAR that I've added to the beginning of
TIMEOUT.ASM.  Now, all three of TIMEOUT.ASM's cpublic functions are able to
call GETOD( ), to handle the midnight rollover possibility, for themselves.

Interrupts have to be masked and restored at the beginning and end of
GETOD( )'s processing.  And, TIMEOUT.ASM's functions kept their local data in
their Code Segment.  As a result, this module later came in for a little more
work, in support of the DosLynx Protected Mode version.  That is described
under the heading:  Protected Mode Packet Driver Interface, below.

Form Textarea Handling

The first time I ran into http://www.softhome.net/signup/signup.fcg
with Zeke, its behavior seemed pretty strange.  The document's loading went
very slowly and eventually timed-out.  I was able to make a Save Source type
copy of this document, however.  With the document in hand for study, I soon
recognized its distinguishing characteristic.  It contains a Form
<textarea . . . > tag with almost 20 KB of initial text.  The code I had
developed for accumulating a textarea's initial text, in
HTML_put_character( ) and HTML_put_string( ) both in HTML.C, was quite
inefficient and slow.

To speed that code up, I've revised HTML_put_character( )'s
case HTML_TEXTAREA to use an HTChunkPutc( ) call.  And, I've revised
HTML_put_string( )'s case HTML_TEXTAREA to use an HTChunkPuts( ) call.
These changes necessitated changes in HTML_start_element( ) and 
HTML_end_element( ), both in HTML.C as well.  These changes yielded a
textarea initial text handling speedup factor of about six.  That is, the
processing time needed to accumulate signup.fcg's textarea initial text has
been reduced to about a sixth of what it had been.

While doing this work, I also addressed limitations on a Form textarea's
size, imposed by TURLView::setTArea( ) in TURLVI42.CPP, and
TURLView::edTArea( ) in TURLVI43.CPP.  'edTArea( ) had limited a textarea's
text size to about 8192 octets.  It now chooses an edit buffer size from the
set of sizes:  4079, 8158, 16316, 32632, and 65264.  It trys to choose the
least one that is at least twice the textarea's initial or present size.
If the user fills this buffer while editing, the TMemo editor dialog stops
accepting further input.  At that point, the user may save the present
document and leave the dialog by pressing the dialog's OK button.
Then, if the user reenters the dialog, 'edTArea( ) will try to provide a
doubled buffer size by using the next buffer size entry, in the list, if any.
If a heap memory allocation for the selected buffer size isn't available,
breakout( ) will get called.

The method just described leads to the choice of an edit buffer size of
65,264 octets for signup.fcg's textarea.  And, for any textarea that has
become larger than 16,316 octets.  Unfortunately, finding a continuous
area of free heap memory 65,264 octets long becomes somewhat unlikely, once a
document or two has been presented and cached.  Even when there is a total of
150 KB, or more, of free heap memory still available.  Perhaps some graceful
way(s) should be sought, for limiting the user to a smaller buffer.
However, at this point, my thoughts again turned to seeking way(s) for
providing DosLynx with more heap memory.

Protected Mode Version

Staying within the 'x86 family's Real and Virtual '86 architectures means
that standard memory is limited to 1 MB.  Actually only 640 KB, or perhaps
705 KB, after superimposing IBM's PC architecture.  However many MB of RAM a
PC may be said to possess.  Even the so called "Big Real Mode", available on
the '386 and later processors, requires the use of Protected Mode for set up.

Without some use of Protected Mode, one has only EMS memory to turn-to for
more memory.  However, once the '286 with its then new Protected Mode became
available, the memory in most new large systems grew via the extended, or
XMS, memory route.  On '386 based and later systems, even "EMS memory" is
provided by a "driver" like EMM386.EXE or QEMM386.SYS, which runs the machine
in "Protection Enable(d)" state.  That enables remapping the physical XMS
memory into an EMS memory frame.  On top of everything else, DosLynx already
provides for using up to a total of about 1 MB of EMS for program overlays
and for swapping itself out of DOS memory.  Trying to use EMS for (also)
holding document data would entail sacrificing (or working around) those
existing arrangements.

So, rather than trying to resist a Protected Mode solution, why not embrace
that?  Unfortunately, a Protected Mode version won't be usable on '86/'88
based systems.  In September, I finally decided to bite the bullet and see
if I could find a way to develop a DosLynx Protected Mode version.

The Industry Standard Architecture for extending DOS software into
Protected Mode came about in the very late '80s.  It is known as the
DOS Protected Mode Interface (DPMI) specification.  This is virtually the
only game in town, for anyone who wants their application to be compatible
with DOS systems with memory managers like QEMM and with Windows DOS windows.
Fortunately, Borland was a fairly early DPMI adopter.  The 1992 vintage
Borland C/C++ v3.1 compiler and linker, already used to make DosLynx, is
close to being ready to make a Protected Mode application, in the form of a
DPMI client.

But, close only counts with a GUI, of course.  I needed to find some kind of
"DOS extender" software technology that would be compatible with my existing
tools and not cost an arm and a leg.  (Otherwise, I would be in for a few
more years of learning how to write a DPMI client from scratch!)
I also decided that I didn't want to try to make DosLynx into a 32 bit
application at this point.  (In addition to the extra work that might be
required, changing it to a 32 bit application would keep DosLynx from any
possibility for being usable on '286 based systems.)  That eliminated
possibilities such as the free Borland C/C++ v5, DJGPP, and WATCOM compilers
now available.  As I started my search, I wasn't too hopeful for finding
anything that would do.

I started my search with my usual Turbo Vision resources and ran right into
the Kevin Morgan Software Services Protected Mode APPlication construction
toolkit, which is offered at:
http://www.zeta.org.au/~grove/tvplus/memory/pmapp.zip .
Using Kevin's PMAPP toolkit hasn't always been smooth sailing.  But, PMAPP
has blazed the trail well enough to keep me from ever getting lost for more
than a few days at a time.  It turned out to be exactly what I had been
looking for!

Protected Mode, Getting Started

To make a DosLynx Protected Mode version for the first time, I needed to:

1.  Make a non-overlaying version of the Turbo Vision v2.0 library that
    DosLynx uses.  (The DosLynx Protected Mode version gets loaded into
    Extended Memory and doesn't need nor use overlays.)  I stayed with the
    overlaying version library's two part arrangement in order to avoid
    capacity problem(s) in TLINK.

2.  Relink DosLynx with the TLINK /Twe option, PMAPP's C0WL.OBJ, the DosLynx,
    WWW, and WATTCP .OBJs, PMAPP's CLIB.LIB, the two non-overlaying
    Turbo Vision .LIBs, the C/C++ compiler's CL.LIB, and PMAPP's RSTUB.EXE.
    As far as TLINK knows, that /Twe option declares that we're making a
    Windows program!  Here is where things started getting interesting.
    There were unresolved symbols, due to calls to _OvrInitEms( ) and
    _OvrInitExt( ), from TDosLynx::TDosLynx( ) in TDOSLYNX.CPP.  And, there
    were about a dozen other unresolved symbols, including __AHSHIFT,
    __C0argv, and __heapbase, due to?

    So, TDOSLYNX.CPP became the first DosLynx module to get #ifdef clause(s)
    for Protected Mode.  I have adopted the symbol:  __DPMI16__ to designate
    the DosLynx Protected Mode version.  In this case, I bracketed those
    unneeded (for Protected Mode) overlaying initialization calls with
    #ifndef __DPMI16__ clauses.

    After some study, I found that the remaining unresolved symbols defined
    in the C/C++ compiler's C0.ASM.  But, not in PMAPP's C0.ASM.  I suppose
    this was a plot hint for me.  But, I didn't get it until quite a bit
    later.  I stripped the needed symbol definitions from the compiler's
    C0.ASM and placed them in a new C0INC.ASM.  Then, I added an include
    for C0INC.ASM to PMAPP's C0.ASM.  And, remade C0WL.OBJ.  At this point,
    I was able to link the DosLynx Protected Mode version for the first time!

I have been using QEMM on my development system, Sailboard, for a long time.
So, all I had to do, to get a DPMI service, was add QDPMI.SYS to Sailboard's
CONFIG.SYS file.  Then, when I used PMAPP's DPMIRUN.EXE to run my new DosLynx
Protected Mode version, I immediately got a repeatable abort, with registers
snap.

Well, there isn't anything in the PMAPP package that tells how to interpret
its registers snap.  So, I started reading the DPMIRUN sources.  And, remade
it in a temporary debug version.  Eventually, I was able to determine that I
was getting a Protected Mode violation due to a
        MOV  CS:[someoffset],DS
instruction in what looked like a C library routine.  That instruction causes
a Protected Mode violation because writing to a Code Segment isn't allowed in
Protected Mode.  I looked through the rest of that Segment and found perhaps
half a dozen of those troublesome MOVs.  Am I going to have to be patching
a bunch of C library routines to make this thing work?  I wondered with
growing alarm.

Well, I'll have to admit that I did write a SAVEINCS.CPP module, containing
a saveinCS( ) function, and a PMPAT001.ASM glue module to be called from
patch(es) over the troublesome instruction(s)!  saveinCS( ) used a
Dpmi.createAlias( ) call to get an alias Data Segment Selector for the given
Code Segment.  This allowed it to perform the needed write.  I then patched
PMPAT001( ) into the first troublesome MOV instruction.  That simply got me
to the next Protected Mode violation in a C library routine!

So I went back to reading disassembled object and PMAPP's sources.

After quite a bit more reading, I came to realize that the troublesome
C library routine(s) I was running into are one(s) that should have been
replaced by PMAPP's C0WL.OBJ and CLIB.LIB!  Both the troublesome routine(s)
and PMAPP's replacements are included in the DosLynx Protected Mode version,
for some reason.  They are all included in a list of procedures to be run
at startup.  Perhaps this is due to a small naming mismatch somewhere?
I was able to remove SAVEINCS and PMPAT001 from my link.  And, simply patch
immediate returns over the beginnings of two troublesome but replaced
C library routines.  (After a somewhat later change, one of the two
troublesome routines quit appearing in the link.)

The next Protected Mode violation came from TDosLynx::TDosLynx( )'s call to
_ctruns( ), in CTRUNS.ASM.  I added _ctruns( ) to DosLynx in version 0.24b.
It looks through the DOS memory arenas for other copy(s) of DosLynx already
in process.  This check is needed for deciding if apparently abandoned
DosLynx temporary file(s) may be safely removed.  _ctruns( )' approach to
looking through the DOS memory arenas involves Segment Register manipulations
that are obviously inappropriate in Protected Mode.  To postpone this issue,
temporarily, I bracketed the call to _ctruns( ) with an #ifndef __DPMI16__
clause, too.  At this point, the DosLynx Protected Mode version started
displaying its old familiar "desktop".  Before hanging or running into
another Protected Mode violation!

PMAPP's IOCTL.CPP proved to contain the grossest bug I've found anywhere in
the toolkit.  It provides a Protected Mode compatible replacement for the
compiler's _ioctl( ) runtime routine.  At its heart there was a
    Dpmi.simulateRealInterrupt(0x10, iregp) ;
call.  Huh?  Shouldn't that 0x10 be 0x21?

Perhaps I should have tried to fix this one by patching.  Because, that
fairly simple correction took a fair amount of work.  The first complication
is that, lacking a CRTINIT.CAS module for my C/C++ compiler, I can't remake
PMAPP's CLIB.LIB, from sources.  So, the revised IOCTL.CPP needs to be
compiled for the large memory model and explicitly included in the DosLynx
Protected Mode version's link.  Next, in that context, I couldn't figure out
how to make the replacement _ioctl( )'s call to _IOERROR( ) be the "near"
type call that _IOERROR( ) expects.  So, I've introduced a FARIOERR.ASM
module that provides a small "far" wrapper for a call to _IOERROR( ).
(This might be something like the beginning of a "Thunk", I guess.)
Finally, the revised _ioctl( ) had to be enclosed in an extern "C" { }
clause, in order to make its decorated name actually match the name of the
replaced routine, in the link.

Next, there was trouble in Turbo Vision module HARDWARE.ASM.  It had a
runtime sequence for detecting Protected Mode.  That detection sequence was,
itself, developing a Protected Mode violation.  Well, I'm not trying to make
a DosLynx "dual mode" version at this point.  So, I simply added some IFDEFs
to omit that Protected Mode detection sequence and force the Protected Mode
target variation, when __DPMI16__ is defined.  This change necessitated
another make of Turbo Vision, of course.

Next, there was trouble in Turbo Vision module TGROUP.CPP.  TGroup::first( )
was getting called with this == 0.  That resulted in a Protected Mode
violation, there.  I deduced that the troublesome call must be coming from
either TView::makeFirst( ) or TView::prevView( ), both in TVIEW.CPP.  Due to
TGroup * TView::user being zero, there.  I fixed these possible trouble
sources by prefacing TView::makeFirst( )'s single statement with an if (user)
check.  And, by prefacing TView::prevView( )'s code with an
if (!user) return(0) ; statement.  After yet another make of Turbo Vision,
the module TGROUP.CPP trouble didn't reappear.  As the changes described here
don't include any #ifdef __DPMI16__ type conditioning, they apply to the
DosLynx Real Mode version, as well.

Next, HTANCHOR.C and SGML.C showed their heads in need of similar treatment.
equivalent( ) calls were sometimes being made with a null pointer parameter,
from HTAnchor_findChild( ) or HTAnchor_findAddress( ).  And, strcasecomp( )
calls, apparently from either of two places in SGML_character( )'s
case S_tag, were sometimes turning up with a null pointer parameter.
I've added checking for null pointers to the if logic already present just
ahead of each of these four calls.  Again, these changes apply to the
DosLynx Real Mode version, as well.

Protected Mode Hangs

At this point, the DosLynx Protected Mode version started working without
turning up any more Protected Mode violations!  (So long as I didn't try
to use TCP/IP or let DosLynx try to swap itself out of memory.)
However, it had a new hang that turned up every now and then.
For no apparent reason.  I was eager to see if the DosLynx Protected Mode
version could now live up to its promise of being able to have a lot more
memory to work with.  But, those hangs were keeping me from doing much with
large documents.

Then, I found a modestly sized HTML document that seemed to repeatedly
trigger a hang.  I tried to strip this and that out of it.  To find a shorter
triggering sequence.  Eventually, I got it down to a size of about 3 KB.
I couldn't seem to take anything more out of that without making the hang go
away.  But, there wasn't anything suspicious in that 3 KB fragment!
What could the matter be?

I started reading PMAPP's MALLOC.CPP and decided to remake it with its
//#define DEBUG
suggestion un-commented-out.  As with the remade IOCTL.OBJ, the remade
MALLOC.OBJ then had to be explicitly added to the DosLynx link.
At about this time, I also bracketed THeapView::GetHeapSize( )'s
case _HEAPOK heap walker, in THEAPVIE.CPP, in an #ifndef __DPMI16__ clause.
Heap walking isn't needed with PMAPP's farcoreleft( ), because that provides
the total free heap memory available figure, by itself.  And, I temprorarily
patched _protheaplen's initial value to 0x00440000 (about 4.25 MB).  This is
the amount of XMS heap memory that PMAPP's CreateHeap( ) requests, in
65,536 octet chunks, from the DPMI service.  (_protheaplen comes from PMAPP's
HEAPLEN.CPP, via PMAPP's CLIB.LIB.  Having said that, I now see that
_protheaplen's initial value should be easy enough to override in, say,
GLOBALS.CPP.) 

Well, #define(ing) DEBUG, in MALLOC.CPP, seemed to make the hangs go away!
I was finally able to start watching the DosLynx Protected Mode version
present documents far larger than the Real Mode version has ever been able
to present!

DEBUG provided a number of different additions to MALLOC.CPP.  I whittled
those away, to find one addition that prevented the hangs.  Here is what it
came down to:  Without DEBUG, PMAPP's malloc( ) would occasionally provide
an allocation whose pointer had the form:  selector: 0000.  (The Real Mode
version's Borland C/C++ v3.1 compiler supplied malloc( ) always provides
allocations whose pointers have the form:  segment: 0004.)  With DEBUG,
PMAPP's malloc( ) added 16 octets of debug information to the beginning of
its allocations.  I've whittled this down to 4 uninitialized octets.
So, the smallest pointer offset PMAPP's malloc( ) can now return is 0004.

With the above knowledge, I have found some code, which may be hanging, in
several places in HTPARSE.C.  These bad boys look something like this:

    char * cp, * string ;
    int enough, inaway ;
    <code establishing enough>
    string = (char *) malloc(enough) ;
    <code establishing inaway>
    for (cp = string + inaway ; cp >= string ; --cp)
        <nothing that would break this for loop> ;

I think (cp >= string) may always be true, in that kind of for loop, when the
string pointer has the form:  selector: 0000.  So, we may get a hang on any
loop like that one.  When the string pointer is of the form:  selector: 0004,
cp has four possible values that are < string, and a hang is avoided.

I've decided to leave PMAPP's malloc( ) returning pointers with a minimum
offset of 0004, for now.

Protected Mode Version's Real Mode Stub

With the Protected Mode violations and hangs gone and the theory proved,
I could see work remaining in (only) the following three areas:

1.  The Packet Driver interface, in ASMPKT.ASM and PCPKT.C. And, TIMEOUT.ASM.
    (Later, PCTCP.C also came in for a little attention.)

2.  The swap out (not overlay) stuff, in SWAP.ASM and TDOSLYN7.CPP.
    (Later, DPMISH.CPP and DPMISH.H also came in for extension.)

3.  Something still had to be done about _ctruns( ), in CTRUNS.ASM.

Also, I didn't appreciate PMAPP's RSTUB.EXE very much.  About all it did was
invoke DPMIRUN.EXE.  If DPMIRUN.EXE were a horribly big program and one had
several applications that invoked it, this arrangement might make sense.
But, as DPMIRUN.EXE is a modest 36 KB and as RSTUB.EXE, itself, is 13 KB, one
would have to have at least three DPMIRUN extended applications before this
approach would make much of a pay off.  However, there don't seem to be
(m)any DPMIRUN extended applications around.

So, why not simply replace RSTUB.EXE with DPMIRUN.EXE, in the DosLynx
Protected Mode version's .DEF file?  (The .DEF file is used for, among other
things, specifying a Windows program's "Real Mode Stub", to the linker.)
On top of everything else, incorporating DPMIRUN.EXE into DosLynx eliminates
compatibility constraints that might be felt to prevent customizing or
optimizing DPMIRUN for the DosLynx Protected Mode version's needs.
Only small revisions were required in callMain( ) and protectedMain( ), in
DPMIRUN.CPP, to accommodate this change.

As soon as I decided to make DPMIRUN.EXE the DosLynx Protected Mode version's
Real Mode Stub, I also realized it would make a perfect DOS memory perch for
ASMPKT.ASM and SWAP.ASM to cling-to.  Later, I realized that CTRUNS.ASM
should perch on DPMIRUN.EXE, as well.  All three have now been moved from the
DosLynx Protected Mode version's link to DPMIRUN's link.  This arrangement
allows the beginning of the DosLynx Protected Mode version's shadow, in DOS
memory, to look a lot like the beginning of the DosLynx Real Mode version.
That resemblance spares _ctruns( )' process, for identifying other instances
of DosLynx Real or Protected Mode version(s) already running, from any new
complication(s).

The DOS Program Segment Prefix (PSP), that the DPMIRUN and DosLynx links
share at runtime, provides a Real Mode base Segment Address landmark for
access to a few of DPMIRUN.EXE's new modules, from DosLynx.

The first thing that got changed, in the "embedded" DPMIRUN.EXE, was its use
of Interrupt 061h, for communication between some of its parts.
Interrupt 061h is smack in the heart of prime Packet Driver Interrupt number
territory.  I certainly don't want DosLynx to be kludging up a Packet Driver
Interrupt number!  I decided to change this Interrupt number to 04Ah.
I have changed the #define(s) for this, in DOSEXT.H, to read:

#define EXTENDER_VECT 0x4A
#define _EXTENDER_VECT 04Ah

So, why not simply replace RSTUB.EXE with DPMIRUN.EXE, in the DosLynx
Protected Mode version's .DEF file?  Above, I left that rhetorical question
without an affirmative answer.  Well, one affirmative answer did arise later.
This came when testing in a Windows NT v4.0, SP 6 DOS window, for the first
time.  Apparently, Windows NT decided that the DosLynx Protected Mode
version's .EXE file looked like a "Windows program"!  It tried to load and
run the DosLynx link part of the .EXE by itself.  Without bothering with the
DPMIRUN link, in the Real Mode Stub.  Well, I don't think even a "pure" PMAPP
application would have been able to survive Windows NT's treatment.
But, if I had known what was coming, I might have tried to make the DosLynx
Protected Mode version even purer.

As it is, my actual arrangements made the DosLynx Protected Mode version's
dependence on its Real Mode Stub a certainty.  So, I wanted to find some way
to improve on using Windows NT's FORCEDOS program to tell Windows to load and
run the DosLynx Protected Mode version's Real Mode Stub.  I am not sure if
the "New Executable" .EXE file format provides an "official" way to mandate
its Real Mode Stub's execution.  Lacking that, I've found what seems like a 
reasonable way to keep the DosLynx Protected Mode version from looking like
a Windows program.

Protected Mode Packet Driver Interface

The work on PCPKT.C started with transplanting pkt_init( )'s _pktasminit( )
call into main( ), in DPMIRUN.CPP.  In pkt_init( ), this involved enclosing
the _pktasminit( ) call in an #ifndef __DPMI16__ clause.  In DPMIRUN.CPP,
this involved adding #define(s) for BUFSIZE and MAXBUFS, together with the
following declarations:

extern "C"
{
extern unsigned char far pktbuf[MAXBUFS][BUFSIZE + 2] ;
extern void far _pktasminit(void far *, int, int) ;
}

PCPKT.C then needed replacements for pktbuf and _pktentry( ), which had
moved into the link for DPMIRUN.  I've added byte * ppktbuf, to provide for
Protected Mode access to pktbuf.  And, unsigned int(s) pktentryseg and
pktentryofs, to be given to the Real Mode Packet Driver for its calls back
to _pktentry( ).  ppktbuf's initialization brings us to a central
consideration in this.  PMAPP's DpmiApplication::makeDescriptor( ) is needed
for initializing ppktbuf.  class DpmiApplication members 'getRealVect( ) and
'simulateRealInterrupt( ) are also needed, elsewhere in PCPKT.C.
But, C++ class member functions aren't readily called from C.  I needed to
convert PCPKT.C to C++.  Or, copy these class DpmiApplication member
functions into C callable versions.  Or, provide C callable wrappers for
them.  I decided to go the C callable wrapper route.

I've stripped the definition of struct DPMI_Regs and a few other things,
appropriate for C modules, out of PMAPP's DPMISH.H, to make new header file
DPMIREGS.H.  To that, I've added prototypes for the new C callable wrappers,
for the functions listed above.  DPMIREGS.H is now #include(d) in PCPKT.C.
DPMIREGS.H's new prototypes read as follows:

extern void _FAR * cDPMImd(unsigned int segment) ;
extern DpmiInterruptVector cDPMIgrv(int intnmbr) ;
extern int cDPMIsri(unsigned int intnmbr, struct DPMI_Regs * pbigregs) ;

Much of the rest of the work in PCPKT.C involved developing Protected Mode
sequences to match the ten existing Real Mode sequences ending in intr( )
calls.  These intr( ) calls submit Software Interrupts to the Real Mode
Packet Driver TSR that DosLynx works with.  The new Protected Mode sequences
end in cDPMIsri( ) calls.  There also is a new Protected Mode sequence, using
cDPMIgrv( ) and cDPMImd( ) calls, to match a Real Mode sequence ending in a
getvect( ) call.  These intr( ) calls and getvect( ) call reside in
pkt_init( ), pkt_release( ), and pkt_send( ).  pkt_buf_wipe( ) and
pkt_received( ) also came in for small extensions due to the mismatch between
ppktbuf and pktbuf.  The new Protected Mode sequences and the existing
Real Mode sequences are bracketed as follows, in each case, of course:

#ifdef __DPMI16__
<New Protected Mode sequence.>

#else  /*  '__DPMI16__  */

<Existing Real Mode sequence.>
#endif  /*  '__DPMI16__  */

A final complication, in PCPKT.C, came from a few transfers of memory data,
to and from the Packet Driver.  These are accomplished by some of the
sequences enumerated just above.  The most notable of these is pkt_send( )'s
transfer of a transmit data packet, to the Packet Driver.  A DOS memory
buffer is needed for making these transfers.  My first approach was to use a
C callable wrapper, for a DpmiApplication::allocateDosMemory( ) call, for
allocating the needed memory buffer.

This proved to be problematic because of a problem found later, in connection
with swapping out of DOS memory.  The problem arises because
'allocateDosMemory( ) provides a DOS memory segment, or arena, that is
separate from the memory segment, or arena, containing the PSP and DPMIRUN.
It becomes very difficult for swap( ) to locate and identify the DOS memory
segments, or arenas, that it needs to swap.  And, to distinguish those from a
segment, or arena, that it needs to leave resident.  So, it is desirable to
get the needed DOS memory buffer(s) allocated from DPMIRUN.EXE's heap.
And, thereby, confined within its (the PSP's and DPMIRUN's) DOS memory
segment, or arena.

Well, it is easy enough to arrange to have main( ), in DPMIRUN.CPP, perform
the allocation needed for PCPKT.C.  However, some extra effort is required
for transfering the allocated buffer's address to where it is needed, in
PCPKT.C.  main( ) has to place the buffer's address in a global far pointer
variable in DPMIRUN.EXE's DOS memory.  Then, a Protected Mode pointer, to
that pointer variable, has to be used to get the Real Mode pointer data it
contains.  Finally, a Protected Mode replacement pointer has to be developed
from that Real Mode pointer data.  This is the method that is now being used.
 
With the work in PCPKT.C thought to be complete, I made a test run.
That forcefully reminded me that tcp_init_noexit( ), in PCTCP.C, still
develops and uses a pointer, called realclock, to the BIOS Time-Of-Day
clock's accumulator.  I've added the following #ifdef __DPMI16__ bracketed
Protected Mode initialization for realclock:

    realclock = (unsigned long far *) MK_FP(_40h, 0x006C) ;

_40h is an unsigned int containing the number of a Selector allocated for
accessing the BIOS data segment.  realclock had been declared static, in
PCTCP.C.  However, remembering that this pointer would also be needed in
TIMEOUT.ASM, I removed realclock's static declaration.  At that point, I also
added the following pair of declarations to replace TIMEOUT.ASM's
Code Segment data areas:

unsigned long int rcdate = 0 ;
int oldhr = 0 ;

In TIMEOUT.ASM, I've commented-out the existing Code Segment data areas
definitions and added EXTRNs for realclock, rcdate, and oldhr.  This approach
eliminated having to fuss with assembler incantations for suitably defining
these three areas, in TIMEOUT.ASM.  Having all the references to these three
areas confined to TIMEOUT.ASM's new GETOD( ) also simplified making the
remaining needed adjustments.  These changes apply to both the Real Mode and
the Protected Mode versions of TIMEOUT.ASM.

One other extension was needed in GETOD( ), for Protected Mode.
Its Real Mode sequence for saving the Interrupt Flag, disabling maskable
Interrupts, and later restoring the saved Interrupt Flag is as follows:

        PUSHF                   ;  Save Flags.
        CLI                     ;  Disable maskable Interrupts. 

<Code protected from interruption.>

        POPF                    ;  Restore given Flags.

This isn't appropriate for Protected Mode because the DPMI specification
allows an arrangement such that CLI is honored for disabling maskable
interrupts.  While POPF is not honored for restoring the Interrupt Flag!
If that were the case, this sequence would leave maskable Interrupts
disabled.  Here is the complete replacement, for that sequence, that I've
put into GETOD( ):

IFDEF   __DPMI16__              ;  If Protected Mode version:
        XCHG    AX,CX           ;  Save AX for:
        MOV     AX,00900h       ;  AX = Note Interrupt Flag and
;                                    disable maskable Interrupts
;                                      DPMI request.
        INT     031h            ;  Go disable maskable Interrupts
        PUSH    AX              ;    and get AX = 0090xh,
;                                      Stacked for return.
        XCHG    AX,CX           ;  Restore given AX.

ELSE                            ;  Else, Real Mode version:

        PUSHF                   ;  Stack Interrupt Flag.
        CLI                     ;  Disable maskable Interrupts.
ENDIF                           ;  Real Mode version.

<Code protected from interruption.>

IFDEF   __DPMI16__              ;  If Protected Mode version:
        XCHG    AX,CX           ;  Save AX for:
        POP     AX              ;  AX = Stacked DPMI request.
        INT     031h            ;  Go see about enabling all
;                                    Interrupts.
        XCHG    AX,CX           ;  Restore AX for return.

ELSE                            ;  Else, Real Mode version:

        POPF                    ;  Restore given Flags.
ENDIF                           ;  Real Mode version.

Notes:  The Protected Mode sequence scratches CX, in order to save and
        restore AX, while the Real Mode sequence leaves CX alone.

        The x in the 0090xh value passed from the first INT  031h
        instruction, to the second one, conveys the DPMI service's possibly
        "virtual" replacement for the processor's Interrupt Flag.

With this work completed, the DosLynx Protected Mode version's TCP/IP 
communication started working just as it does in the Real Mode version.
With one notable exception:  There may a very noticeable delay or pause upon
the Protected Mode version's first use of TCP/IP, in a DosLynx session.
Obviously, this delay or pause comes at about the point at which the
Packet Driver interface is initialized.  On my 16 Bogo MIPS '486 based
development machine, Sailboard, in a QEMM/QDPMI environment, this delay or
pause lasts for about 18 seconds!  With some other DPMI services, it has been
observed to last about either 5 or 9 seconds, on the same machine.  I suppose
this delay or pause is attributable to the run(s) of either pkt_init( )
and/or pkt_buf_wipe( ).  However, I haven't investigated it much further,
yet.  Investigating and reducing that delay will be a high priority for me as
I begin my next cycle of DosLynx development.

Protected Mode Swap Out

The DosLynx Protected Mode version's DOS memory "foot print" mainly consists
of DPMIRUN.EXE.  At runtime, its size is around 100 KB.  So, it is definitely
worth swapping out, when DosLynx "shells out to DOS".  To be clear, this
"swap out" will ordinarily be out of DOS memory and into XMS memory.
The swapmem= configuration option will remain available for limiting the
swap's destination to EMS memory and/or Disk.  However, that option won't
have any effect on the DosLynx Protected Mode version's occupation of XMS
memory, that will already be established at the time of the swap out.
Because, the DosLynx Protected Mode version's image in XMS memory won't go
anywhere during a swap out.  But, it may be lengthened by segment(s) swapped
from DOS memory.

After transplanting SWAP.ASM into DPMIRUN.EXE's link, accomplishing a swap
out was first thought to amount to invoking swap( ), in Real Mode.
The DPMI Call Real Mode Procedure function will handle doing that from
Protected Mode.  So, I added a member function:  'callRealProc( ), to the
definitions for class DpmiApplication, in DPMISH.CPP and DPMISH.H.
'callRealProc( ) follows closely along the lines of
DpmiApplication::simulateRealInterrupt( ).  DPMISH.OBJ has joined IOCTL.OBJ
and MALLOC.OBJ in being explicitly included in the DosLynx Protected Mode
version's link.

Well, the first complication is that swap( ) takes several possibly lengthy
string parameters, in memory.  These need a DOS memory buffer, which is
allocated from DPMIRUN.EXE's heap.  This is handled as already described
under the heading:  Protected Mode Packet Driver Interface, above.
Also, there is the matter of saving and restoring some Real Mode Interrupt
Vectors.  In the DosLynx Real Mode version, this is being done in
TDosLynx::b4swap( ) and TDosLynx::aftswap( ) routines that I added to
TDOSLYN7.CPP, in version 0.25b.

I decided to handle all these complications from a swapcall( ) routine added
to the DosLynx Protected Mode version's TDOSLYN7.CPP.  And, a SWAPWRAP( )
routine added to the DosLynx Protected Mode version's SWAP.ASM.
As usual, these conditional additions are bracketed in #ifdef __DPMI16__
and IFDEF __DPMI16__ clauses.  swapcall( ) is #define(d) to replace swap( ),
with its four parameters, in the Protected Mode version.  It's main duty is
to copy its (swap( )'s) arguments into the DOS memory buffer and prepare a
set of DPMI_Regs for its 'callRealProc( ) call.  SWAPWRAP( ) receives the
'callRealProc( ) call, does 'b4swap( ) type Interrupt Vector saving, and
Stacks pointers to swap( )'s parameters, in preparation for calling swap( ).
A struct swapargs, added to SWAP.H, helps coordinate swapcall( ) and
SWAPWRAP( ) in using their DOS memory buffer.  Upon swap( )'s return,
SWAPWRAP( ) does 'aftswap( ) type Interrupt Vector restoring.
Upon SWAPWRAP( )'s return, swapcall( ) retrieves swap( )'s return codes from
both the DPMI_Regs area and the DOS memory buffer.

Well, all those arrangements weren't quite enough!  A test disclosed that
swap( ) seemed to be working.  But, something was going wrong with the
Environment, provided by COMMAND.COM, for the DOS session ensuing from the
swap out.  This Environment gets copied from DPMIRUN.EXE's Environment, of
course.  Checking DPMIRUN.EXE's PSP, I found that its Environment's
Segment Address word, at offset 0002Ch, contained something in the sixties,
hex.  That is, a value way too low to be an Environment's Segment Address.
I realized that somewhere along the line, in the set up for Protected Mode,
that PSP word must have been changed from a Segment Address to a Selector
Number!

To fix this issue, I've added another little routine, SAVENVA( ), to the
Protected Mode version of SWAP.ASM.  It gets called from DPMIRUN.CPP's
main( ), before entering Protected Mode, to save a copy of the Environment's
Segment Address word from the PSP.  I also gave SWAPWRAP( ) some additional
work.  In its preparation for calling swap( ), SWAPWRAP( ) now copys the
Environment's Segment Address word, that it finds, and restores the value
saved by SAVENVA( ), back into the PSP.  Also, after swap( )'s return,
SWAPWRAP( ) now restores the Environment's Segment Address word to its
Protected Mode value, again.  This fix may be seen to do no harm if the
Environment's Segment Address word should actually be found unchanged, when
SWAPWRAP( ) gets invoked by 'callRealProc( ).

Well, these additional arrangements still weren't quite enough!
In my QEMM/QDPMI test environment, I might shell out to DOS and try, say, an
XDIR command.  That would usually hang or produce an exception caught by
QEMM.  Other commands often succeeded!

After about a day of hunting for the problem, I finally discovered that the
DosLynx Protected Mode version seemed to be hooking the Real Mode
Interrupt 021h Vector!  So, after shelling out to DOS, that DosLynx
Interrupt 021h handler was left sitting in freed memory where it was subject
to being overlayed by a command like XDIR, or not.  The whole thing was quite
a surprise because I didn't think there was anything in DosLynx or its
Protected Mode extension(s) that hooked the Interrupt 021h Vector!

Apparently, QEMM's QDPMI.SYS DPMI service is appending that Interrupt 021h
handler to the DosLynx Protected Mode version!  (Later, I found at least one
other DPMI service that seems to be doing something like this, too.)
The added handler is watching for a DOS Function 04Ch, End Program, call to
be issued.  Presumably, so it can free up the program's XMS memory
allocation(s) that, otherwise, might get lost to the system.  I think this is
the first time that I've ever encountered a DOS system program function that
augments my program for me!

Well, the DosLynx traditional (or, Real Mode) version already faces this kind
of issue when it swaps itself out to EMS or XMS memory.  Until the user EXITs
from the DOS shell, that EMS or XMS memory remains tied-up.  I can't think of
much else to do in that situation.

Since the appended Interrupt 021h handler is in a DosLynx memory arena, it
was getting swapped out of memory and then restored along with most of the
rest of DosLynx, or DPMIRUN.  So, the fix for the DosLynx Protected Mode
version seemed to be:  Note the Real Mode Interrupt 021h Vector before going
into Protected Mode.  Then, just before swapping-out, note the possibly new
Real Mode Interrupt 021h Vector and restore the originally noted Vector.
Finally, after swapping-out and getting the user's EXIT back, restore the
Vector noted the second time.  I added this Interrupt 021h Vector saving and
restoring to SAVENVA( ) and SWAPWRAP( ), just as explained above for the
Environment's Segment Address word.

Well, at first, that seemed to solve most of the problems with the DosLynx
Protected Mode version's swap out.  However, I found the DOS environment
ensuing from a swap out still unstable, in extended testing.
Especially when I tried to run another copy of the DosLynx Protected Mode
version!  Might there be a Protected Mode Interrupt Vector or something else
pointing into that memory segment appended to DosLynx?

Fortunately, the "appended" Interrupt 021h handler appears in a memory arena
that is separate from the one containing the DosLynx PSP and DPMIRUN.EXE.
That separation opens the door for leaving the appended memory arena resident
while the rest of DosLynx, or DPMIRUN.EXE, is swapped out of DOS memory.
However, I haven't found a good way to recognize such an appended memory
arena.  Nor, distinguish it from other memory arenas bearing a pointer to the
DosLynx PSP.  So, I've simply arranged the DosLynx Protected Mode version's
swap( ) to swap out only the DosLynx memory arena containing the PSP and
DPMIRUN.EXE.  This is why it is desirable to allocate the two DOS memory 
buffers discussed above from DPMIRUN.EXE's heap.  If they were separately
allocated, they would appear in additional memory arena(s) that would have to
be left behind, along with the troublesome one, when swapping out.

With the appended or troublesome memory arena being left resident, the
Interrupt Vector 021h saving and swapping could be removed from SAVENVA( )
and SWAPWRAP( ).  And, the DOS environment ensuing from a DosLynx
Protected Mode version swap out was stable, at last!

Protected Mode Version Finishing Touches

After the effort needed for the swap out, transplanting CTRUNS.ASM, from the
DosLynx link to the DPMIRUN link, was a piece of cake.
DPMIRUN's main( ) calls _ctruns( ) before going into Protected Mode.
And, saves its result in the DOS memory buffer allocated for struct swapargs.
Then, it remains for TDosLynx::TDosLynx( ), in TDOSLYNX.CPP, to use a
Dpmi.allocateDescriptor( ) call, to get a Selector for DPMIRUN.EXE's memory,
including the pointers to its two DOS memory buffers.
Next, 'TDosLynx( ) uses another 'allocateDescriptor( ) call to get a Selector
for the DOS memory buffer containing struct swapargs.  That enables it to
pick up _ctruns( )' result.

Most PCs with more than 1 or 2 MB of RAM probably have at least 4 MB of RAM.
Therefore, as suggested at the beginning, I decided to target the DosLynx
Protected Mode version on a machine with at least 4 MB of RAM.
Such a machine may be expected to have at least 3 MB of readily accessible
XMS memory.  64 KB of that might be taken for loading "DOS high".
The remaining (3 MB - 64 KB) of RAM seems like a perfect match for the
DosLynx Protected Mode version's requirements.  So, I've simply repatched
_protheaplen with a value of 0x00260000 (about 2.3 MB).  That leaves about
600 KB of XMS memory for the program, the DPMI service's table(s), and
malloc( )'s table(s).

As a result, the DosLynx Protected Mode version now has all of the Real Mode
version's capabilities coupled with about nine times as much working memory!
The extra memory virtually eliminates the inability to completely present
some very large documents, still present in the Real Mode version.
The Protected Mode version is a little sluggish at times.  In some cases,
this appears to be due to slowness in malloc( ).  In other cases, it may be
due to the time the 'x86 family processors need to update all their internal
tables when cross segment calls are made in Protected Mode.  I am looking
forward to making improvements in these areas in future DosLynx release(s).

When it handles documents way too large for the Real Mode version, the
Protected Mode version is bound to be extra slow.
However, the Protected Mode version won't be running on the slowest machines
that the Real Mode version runs on.  Because, they won't have any XMS memory
or won't be able to support DPMI service.  In spite of these issues, I am
really pleased with the way the DosLynx Protected Mode version has come out!

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.30b (in December 2005), my list has about 442 issues.  Of these,
about 314 (well over two thirds) have been resolved or ameliorated.  In the
next section, I'll list a few of the 128 pending issues that haven't been
mentioned above.

To Do

The DosLynx Protected Mode version is sluggish at times.  Trying to improve
that will probably be my next focus.  After that, the first five issues on
the following list probably represent DosLynx's other biggest shortcomings,
presently.  I hope to be able to do something about one or more of these
"big five" issues in the next year.

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

  -  Provide https/SSL 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?

  -  Provide SMTP AUTH LOGIN support for the e-mail client.  Or, simply
     provide for writing e-mail into a local mail directory?

  -  Add an HTTP-Referrer line to the HTTP GET command?

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

  -  Provide the e-mail and Form Textarea TMemo dialogs with an arrangement
     for reading or pasting input data from file(s).

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

  -  Find ways to speed up the DosLynx Protected Mode version.  And, reduce
     the size of its .EXE file.

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

  -  The handling of special characters seems to need work.

  -  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 2147418112 as long as the large partition has at least
     that much space free.)

Please, let me know what you think about the way the DosLynx Protected Mode
version has turned out.  Or, about any other issue(s) you notice with
DosLynx v0.30b!  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