DosLynx version 0.36b features a new 32-bit Protected Mode version. A fix for a big bug in the 16-bit Protected Mode version. Improved downloading speed for both Protected Mode versions. And, some important user interface improvements. These, together with a few other bug fixes and user interface improvements, again make DosLynx v0.36b the most enjoyable to use and strongest running version(s) of DosLynx, ever!
The new 32-bit Protected Mode version is a step on the way toward https/SSL support in DosLynx. Though, there wasn't time for that to be included in the present release. The new 32-bit version is made using DJGPP v2.03 resources and tools, in DOS. These include an elegant 2 KB "stub loader", the GNU GCC v4.12 compiler, and the UPX v3.02 eXecutable Packer. I have supplemented these tools with the MASM v6.11d assembler. It is needed for a dozen and a half Borland/Microsoft dialect assembly language modules, which make up part of the program's source. I am using the old faithful Borland C/C++ v3.1 compiler and its companion TASM assembler to make the program's augmented "Real Mode stub."
The new 32-bit version's source comes from most of the same DosLynx, Turbo Vision v2.0, WATTCP, and WWW sources used for making the other DosLynx versions. All of these have been dragged into compliance with the GCC v4.12 compiler's and MASM v6.11d assembler's requirements. So, about 95 percent of the DosLynx source is shared in common among all three DosLynx versions.
The new 32-bit Protected Mode version requires a '386 or later based PC, equipped with at least 4 MB of RAM and a 32-bit DOS Protected Mode Interface (DPMI) service. These give it about eight times as much memory, as the traditional Real Mode version, to work with. (About 2.0 MB versus about 250 KB.) This extra memory will virtually eliminate the inability to completely present some very large documents, still present in the Real Mode version.
On PCs with more than 4 MB of RAM, other 32-bit software may be run while "shelled-out to DOS", from the 32-bit Protected Mode version. In particular, software such as multi-media viewer(s). This natural compatibility, which isn't available to the DosLynx 16-bit Protected Mode version, will likely make the 32-bit Protected Mode version a favorite. (Of course, the 16-bit Protected Mode version remains available for situations where 16-bit Protected Mode software is to be run while shelled-out to DOS.) At just over 300 KB, DOSLYNXS.EXE's size also will favor its use in environments limited to low capacity diskette program storage device(s). (The UPX packed DOSLYNXS.EXE expands itself to around 900 KB upon loading.)
An extended and updated DPMIREVU.HTM document reports on DPMI serving software which I've tested with one or the other or both DosLynx Protected Mode versions. I welcome contributions of additional review(s) for inclusion in this document.
I have always aimed to make the DosLynx 16-bit Protected Mode version support '286 (and later) based PCs, with at least 4 MB of RAM. However, I haven't had a '286 based system available for testing. In April, someone with a well endowed '286 based IBM PC/AT sent me a "registers snap" from a run of the 16-bit Protected Mode version on their machine. They had the Borland DPMI16BI.OVL DPMI service installed. That registers snap suggests that none of the previously released 16-bit Protected Mode versions of DosLynx has ever been able to complete its startup, on a '286 based PC! It really is a shame that this issue had to wait over two years to get reported!
With that registers snap, I've found and fixed a '286 specific bug in the DosLynx 16-bit version's Protected Mode memory management. So, I again hope that the DosLynx v0.36b 16-bit Protected Mode version will work on '286 based systems, as intended. Unfortunately, however, I haven't been able to get any feedback on this from my April informant. I hope other(s) will now step forward and give me some report(s). Whether favorable or unfavorable.
Until the present release, DosLynx has always written received TCP/IP download data to disk in essentially a packet-at-a-time fashion. I am using the term download to refer to all DosLynx operations that involve writing a received object to a local file, explicitly named in a local filename dialog. TCP/IP packets are limited to a maximum data length of 1500 octets. So, packet-at-a-time disk I/O is much less efficient than what is possible with longer buffer(s).
To improve on this situation, in DosLynx version 0.36b, I've extended the WWW htcopy( ) routine to accumulate multiple received packets in its input_buffer. I've also lengthened the input_buffer, instantiated in the WWW HTFORMAT.C module, in the DosLynx Protected Mode versions. And, I've extended htcopy( ) to augment that single static input_buffer with additional buffer(s) temporarily allocated in "heap memory". The lengthened input_buffer is 16 KB long. And, upto 250 KB of buffers space, for the Real Mode version, or over 1.5 MB of buffers space, for the Protected Mode versions, is now available from the heap. Even at high communication speeds, this extra buffering significantly extends the time between disk writes. And, thereby, insures lengthened stretches of TCP/IP reception free of any interference from disk I/O operations.
Unfortunately, since DosLynx only has a single processing thread, it is possible for there to be too much data transfer buffering. With too much buffering, the time needed for writing a full set of buffers to disk will force a TCP/IP timeout. I've tried to set a buffers space limit matched to the speed of fixed disks upto about fifteen years old. (Some of these are significantly slower than disks made since 2000.) So, this limit may not be optimum for those with only fairly new disk(s). Or, it may need to be reduced for receiving downloads to diskettes or other removable (read: slow) media.
A new dnldbufs= configuration option provides for those kinds of situations. By default, dnldbufs=100 (percent), which should be satisfactory for the majority of cases. However, it may need to be reduced, to as low as zero, if unexpected TCP/IP timeout(s) are experienced while download data is being written. Such a dnldbufs= reduction will have an effect with all three of the DosLynx versions. On the other hand, it will only be worth increasing your dnldbufs= configuration above 100 (percent) for the sake of the DosLynx 16-bit Protected Mode version. It may benefit from an increase to as much as 500 (percent). There will be little or no benefit from increasing your dnldbufs= configuration above 100 (percent) if you don't use the 16-bit Protected Mode version. This is because the Real Mode version doesn't have enough heap memory to warrant any buffers space limitation, at the dnldbufs=100 (percent) default setting. And, because the 32-bit Protected Mode version's disk I/O is faster or more efficient than the 16-bit Protected Mode version's disk I/O. As it turns-out, the 32-bit version's full heap is a good match for the default dnldbufs= setting. That is, the 32-bit version becomes heap memory space limited at dnldbufs= configuration settings just above 100 (percent). More information on dnldbufs= configuration is provided by comments in the sample DOSLYNX.CFG file included in the DosLynx Real Mode version package.
Experienced DosLynx users likely will appreciate the way some rough spots in the user interface have been smoothed, in version 0.36b. The Esc key will now be able to abort TCP/IP reception, from even its earliest phases. And, all history list Select Boxes, in URL and local filename dialogs, will now open with their "focus" on the most recent (bottom) entry.
The traditional DosLynx v0.36b Package contains DOSLYNX.EXE and all of its supporting files. This is the Real Mode version, recommended for all users. The DosLynx v0.36b 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 .ZIP files may be un-zipped into the same 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.35b to v0.36b. 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, or .TIF file to be viewed. You may edit DLXVIEW.BAT to invoke your favorite viewer. The DosLynx v0.36b 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
5 September 2008