HISTORY.TXT (for DosLynx v0.41b, December 2010) 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 and http://users.ohiohills.com/fmacall/dlx3xdoc.zip . 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. Data Transfer State Esc(ape) Handling sock_wait_input( ) gets called when DosLynx wants to receive TCP/IP data. sock_wait_input( ) is #define(d) to an _ip_delay1( ) call, in WATTCP.H. _ip_delay1( ), in WATTCP module PCTCP.C, makes the tcp_tic( ) calls necessary for actually receiving TCP/IP data. And, _ip_delay1( ) checks for the arrival of received data, something gone wrong, or an elapse of the sockdelay= configured timeout value. Over and over, in a loop. In addition, that loop includes a call to (s->tcp.user_yield) ( ) , which has been assigned to be a yield( ) call. yield( ), in YIELD.CPP, is where DosLynx recognizes that Esc(ape) has been pressed. In that case, when ssi_sockfd designates an active sock_table entry, yield( ) sets sock_table[ssi_sockfd].usi_EOF . The trouble was that setting did nothing to break _ip_delay1( )'s loop. There still had to be received data, something gone wrong, or a sockdelay= timeout before that usi_EOF setting ended the transfer. To resolve this issue, I've added code to the end of yield( ) to "return" sock_table[ssi_sockfd].usi_EOF , when ssi_sockfd designates an active sock_table entry. Or, to return zero, otherwise. This return gets made via a new global, stableof, declared in UDP_DOM.C . I've extended _ip_delay1( ) to check stableof after calling (s->tcp.user_yield) ( ) . Finding stableof set, _ip_delay1( ) sets a "User Escaped" message and breaks its loop, with other indications like those set when it detects a sockdelay= configured time out. Cookies From the Likes of tech.groups.yahoo.com This issue and its amelioration are described, in some detail, in the info.htm document. It only remains to say: The change for saving some formerly rejected cookies was made in savecky( ), in CKIESRCV.CPP. Much of the cookie domain attribute checking that was removed from savecky( ) was replaced by similar checking added to getckies( ), also in CKIESRCV.CPP. Local (Output) File Paths Added to Open Local (Input) File Dialogs' History This is touted as a change made to go along with the new File|Clip View (Alt-V) menu entry or command's Save As button. But, actually, I had started this change before File|Clip View came along. Because, I found that I often want to save document(s) before viewing them. When I know I am going to want a local copy of a document's source, that saves a second TCP/IP fetch of it. Adding local (output) file paths to the Open Local (input) file dialogs' history then saves having to enter each saved file's name a second time. This feature began with the addition of a historyAdd(usi_OpenLocalHist, ca_buffer) ; call to the end of HTHnSGut( ), in HTFWRITE.CPP. This works for both of the Open Local (input) file dialogs because they share the history list that usi_OpenLocalHist designates. When File|Clip View (Alt-V) came along, I provided a similar historyAdd(usi_OpenLocalHist, cpb) ; call near the end of TURLView::clipview( ), in TURLVI44.CPP. TURLView::save( ), in TURLVI22.CPP, implements the File|Save Rendering... (F2) menu entry or command. I haven't provided it with a similar historyAdd( ) call. Should I? Please let me know if you miss having that. Additional Dividers for Several Menus I've added some dividers to the Options, Window, and Help menus. These are intended to improve readability for users in a hurry. newLine( ) calls added to TDosLynx::initMenuBar( ), in TDOSLYN9.CPP, provide the added dividers. E-Mail Client's Handling of Server's Response to the EHLO Commands 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. The DosLynx e-mail client's provisions for recognizing a STARTTLS or AUTH LOGIN advertisement, in these responses, took their multi-line nature into consideration. But, DosLynx did not go so far as to make a point of finding the last line of a response's possible multi-line list. Instead, it assumed each response would be completely contained within a single packet, and studied all of the response lines there. A packet as short as 512 octets can easily hold a dozen SMTP service "advertisements". So, it comes as no surprise that the DosLynx e-mail client works with all the SMTP servers that we've previously tested it with. But, usfamily.net's SMTP server, perhaps eccentrically, distributes its multi-line response to an EHLO command over multiple packets. So, of course, the DosLynx e-mail client couldn't get far with it. The fix for this issue comes in one or two places in TDosLynx::mailDeveloper( ), in TDOSLY15.CPP. When smtpsec=STARTTLS is configured, the DosLynx 32-bit Protected Mode version looks for a STARTTLS advertisement in the response to its first of two EHLO commands. Then, all DosLynx versions look for an AUTH LOGIN advertisement in the response to their only or second of two EHLO command(s). In both places, I've added a for loop enclosing the existing HTTP_NETREAD( ) call and subsequent response parsing. And, I've made small changes in these, to accommodate their changed environment. The loop continues until the last line of the multi-line response is found. Or, the loop's HTTP_NETREAD( ) call yields no additional response line. New File|Clip View (Alt-V) Menu Entry or Command The big decision for this new command was: Shall we provide a whole new editing or clipping tool that works on a whole document rendering. Or, shall we try to use the Turbo Vision TMemo editor, already included in DosLynx, for the new function. The first way was expected to take more new code. Or, at least, more development effort. While the second way, because of its need for a double text buffer, couldn't be expected to handle full documents. Well, we've taken the easier (second) way, with what I think is a pretty good result. We are applying the TMemo editor to the displayed document's present screen, which may be up to 50 lines long. If one needs to edit larger document chunk(s), they may as well save the document's source or rendering and use their favorite external editor on that. Here is the drill for adding this new DosLynx command: Add a menu entry for the new command to TDosLynx::initMenuBar( ), in TDOSLYN9.CPP. Add a new command number, cmClipView, to GLOBALS.H. Put a new class TURLView member function declaration, TURLView::clipview( ), into TURLVIEW.H. Add the new cmClipView command case to TURLView::handleEvent( ), in TURLVIE9.CPP. Define the new 'clipview( ) member function, in new module TURLVI44.CPP. Here is an outline of the new 'clipview( ) function: Construct a new TDialog( ) with: New vertical and horizontal TScrollBar( ) controls. A new TLabel( ) prompt. A new TMemo( ) (editor) control. And, three new TButton( ) controls. Read the present document screen's text, from the present formatted display file, into a memory buffer. Remove Line block(s) and add CR character(s), in place in the buffer. Set the TMemo control's initial data with this buffer. Draw and execute the dialog. If the user didn't cancel: Read back the TMemo control's (remaining) data. Destroy the dialog and its controls. If the user "pushed" the Paste push button: Eliminate any CR or NL character(s) from the data. Add upto 250 characters of the data to the File|Open URL... dialog's history list. If the user pushed the Save As push button: Construct a new TFileDialog( ) . Execute the dialog. If the user didn't cancel: Get the dialog's filename result. Destroy the dialog. If got a filename: See about opening the file named for binary output. If no open( ) error: Write the lines of the data read back from the TMemo control. Add a NL character following each CR character in the data. Close the file. If no write( ) nor close( ) error: Report on what was written. Copy the filename into the history list designated by usi_OpenLocalHist . Else: Report on the error. Else: Report on the error. Delete the memory data buffer. 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.41b (early in December 2010), my list has about 654 issues. Of these, about 454 (over two thirds) have been resolved or ameliorated. This leaves a total of about 200 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 158 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 177 issues pending for the Real Mode version. About 172 issues pending for the 16-bit Protected Mode version. And, about 177 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 200 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