DosLynx Quick Start Home Page

DosLynx v0.41b boasts a new File|Clip View (Alt-V) menu entry or command. It also includes several important bug fixes.

The new File|Clip View (Alt-V) menu entry or command provides for clipping or extracting URL(s) or other relatively short citations from rendered document(s). You express each clipping's content by means of a Turbo Vision TMemo (editor) dialog that the new command provides. This dialog gets primed with a copy of the presently viewable document screen's text.

Clipping(s) may be pasted into the File|Open URL... (F3) menu entry or command dialog's history list, for use. Or, saved in a local (clip board) file. In turn, saved clipping file(s) may be pasted into the e-mail client's TMemo dialog. Or, into the HTML Form Text Area Input control's TMemo dialog. To facilitate these pastings, full paths to saved local file(s) will now get copied into the Open Local (file) dialog's history list. This saves you from having to enter a clip board file's name more than once in a DosLynx session. URL(s) to be pasted may flow over several lines, if necessary. However, they are limited to a maximum length of 250 octets. Clippings to be saved are limited to a maximum length of about 4000 octets.

The TMemo editor provides a text selection feature to facilitate clipping away large text areas: Text may be selected by moving the cursor, with arrow key(s), while holding a Shift key down. Or, by moving the mouse while holding either of its buttons down. Then, a Backspace or Del(ete) key will delete all of the selected text. If a mistake is made while selecting text, an un-shifted arrow key may be used to remove any selection present. Also, Shift and Ctrl-Shift combinations with the Page Up, Page Down, PgUp, and PgDn keys provide special selections. Shift-Page Up and Shift-PgUp select all of the text from the top of the screen to the character ahead of the cursor. While, Ctrl-Shift-Page Up and Ctrl-Shift-PgUp select all of the text from the very beginning of the edited data to the character ahead of the cursor. Similarly, Shift-Page Down and Shift-PgDn select all of the text from the cursor to the bottom of the screen. While, Ctrl-Shift-Page Down and Ctrl-Shift-PgDn select all of the text from the cursor to the very end of the edited data.

Here is a detailed recipe for accessing an undistinguished URL found in a displayed document:

 1.  Bring the full URL into view on the screen.
 2.  Start the File|Clip View (Alt-V) dialog.
 3.  Move the cursor to the first character of the URL.
 4.  Press Ctrl-Shift-Page Up or Ctrl-Shift-PgUp.
     (This selects all of the text ahead of the cursor.)
 5.  Press Backspace or Del(ete) to delete the selected text.
 6.  Move the cursor to the first character following the URL.
 7.  Press Ctrl-Shift-Page Down or Ctrl-Shift-PgDn.
 8.  Press Backspace or Del(ete) to delete the selected text.
 9.  "Push" the Paste push button.
10.  Start the File|Open URL... (F3) dialog.
11.  Press the down arrow key to open the dialog's history list.
12.  Press Enter to retrieve the URL pasted in step 9.
13.  "Push" the Open or Download push button, for access.

LarryL wrote to report that the DosLynx e-mail client quit working for him after his ISP became usfamily.net . He had/has b64usrid= and b64passw= values configured so as to specify SMTP AUTH LOGIN operation. As it turned out, DosLynx wasn't finding usfamily.net's AUTH LOGIN PLAIN "advertisement" in their response to an EHLO command from DosLynx.

DosLynx has had a provision for finding all the lines of that likely multi-line response. However, that didn't provide for finding those lines spread over multiple packets. Apparently, all the SMTP servers we've tested up to this point confine their multi-line responses to a single packet. While usfamily.net's SMTP server doesn't do that. We've resolved this issue by extending DosLynx to seek the lines of a response to its EHLO command(s) in as many packets as necessary to find them all.

When I configured
sockdelay=900
in order to improve the reliability of receiving long files over a marginal WiFi connection, I discovered an issue remaining in DosLynx Esc(ape) handling. After a transfer had stalled, with no packet(s) being received, DosLynx required a full sockdelay= elapse to respond to Esc! That wasn't much fun. Even with
sockdelay=30
configured. If I hadn't known what was going on, I might have thought DosLynx was "frozen" or "hung".

DosLynx has been extended to handle an Esc(ape) from a data transfer much more quickly. Without having to wait for a transfer timeout to expire.

DosLynx often wasn't able to accept cookies from the likes of tech.groups.yahoo.com . Because the domain= attribute value they carry often seems to specify a "domain" two levels of qualification above the "request host's" name. That is: .yahoo.com . The RFCs that pertain to cookies, RFC 2109 and RFC 2965, warn us to accept a domain= specification no more than one level of qualification above the request host's name. For the running example here, that would be: .groups.yahoo.com .

DosLynx has always marked all cookies it accepts and saves with a $domain= attribute identifying the request host's name. Now, we've extended DosLynx to provide the following accommodation for the issue described above: When a cooky's domain= attribute matches any "tail" of the request host's name, or is missing, DosLynx will save the cooky. When it is looking for cookies to send, DosLynx will recheck each candidate cooky's domain= attribute value against its $domain= attribute value. If there is no more than a one level of qualification difference, the cooky will qualify for possibly "domain matching" the then present request host. Otherwise, it only will be sent (back) to the request host that it came from.

In other words, DosLynx now will treat cookies with a troublesome domain= attribute as though that attribute has been omitted. If that troublesome attribute makes any sense at all. This accommodation seems to provide a real improvement in DosLynx' ability to work with request hosts such as tech.groups.yahoo.com .

The new feature, these fixes, and a few other fixes again make DosLynx v0.41b the strongest running version(s) of DosLynx, yet!

The Traditional DosLynx v0.41b Package contains DOSLYNX.EXE and all of its supporting files. This is the Real Mode version, recommended for all users. The DosLynx v0.41b Protected Mode Add-On Package contains DOSLYNXP.EXE (the 16-bit Protected Mode executable), DOSLYNXS.EXE (the 32-bit Protected Mode executable), my latest DPMIREVU.HTM document, and several other supporting files. It is recommended for users with systems that can provide DPMI service. That provision will be easy for DOSLYNXS.EXE, because those "supporting files" include CWSDPMI.EXE, an excellent 32-bit DPMI server. Both of these Packages consist of .ZIP files, which may be un-zipped into a single directory without conflict.

There are a couple other readme files for DosLynx. One is the again updated README.HTM which still tells about the original features, command line parameters, and other important stuff. There is also a history file which describes the major changes I've made in bringing DosLynx from v0.39b to v0.41b. The history file also lists some known bugs or missing features. If you find one that isn't there, please e-mail me at the address in this graphic. Finally, Wayne S. Buttles has provided a little cheat sheet listing the key commands to run DosLynx from the keyboard. It includes ones he added. I've brought it up to date and added a second page listing the "DosLynx Control, Movement, and Navigation Keys".

Remember that you can navigate with your numeric key pad by putting Num Lock ON.

DosLynx no longer contains a built-in graphics viewer. That has been replaced with a swap out and call to DLXVIEW with a parameter naming the .BMP, .GIF, .JPG, .PCX, .PNG, or .TIF file to be viewed. You may edit DLXVIEW.BAT to invoke your favorite viewer. The Traditional DosLynx v0.41b Package contains a sample DLXVIEW.BAT which invokes LXPIC (requires CGA+).

As Wayne said: "I have enhanced DosLynx for my own personal enjoyment. . . . I am just releasing my changes to the general public in hopes that it will help some other DOS User. I have made every attempt to keep it compatible with the lowest IBM-Compatible computer so that the greatest number of people can benefit and I will continue to do so as long as I play with the code."

Good luck, and happy browsing.

Fred C. Macall
4 November 2010