861.1
(Windows) Reintroduce version using standard file I/O API (as opposed to the WIN32 API which was introduced back in 4.6), in order to match non-LOKSER multi-user file read performance of earlier A-Shells. (It appears that the one disadvantage of the WIN32 API is that it always makes at least advisory locking calls, which can slow down multiuser read-only performance by a factor of 10 or more.) However, for programs which use LOKSER, the WIN32 API is just as fast and probably better in other ways. We will continue to look at this, but in the interim, we'll distinguish the between the version using the WIN32 API and the version using the standard C API by appending a "c" to the version of the latter. You can also tell by looking at the "License Options" field in the About box - the WIN32 version says "WIN32IO".
861.2
(UNIX) Support SBR=INFLD_KEEPALIVE to send a harmless byte sequence every 15 seconds while waiting for input within INFLD (which includes the dot prompt and BASIC INPUT statements). This serves two purposes. First, it will prevent connections from being dropped due to lack of activity while they are actually in a program waiting for input. Second (and perhaps more important), it provides a mechanism for UNIX/Linux servers to detect connections that have been dropped (without having to wait for the standard keepalive timers to expire, which by default may run to 2 hours). This way, within 15 seconds of the connection being dropped, the server will send a packet, which cannot be delivered. This should trigger a retry timer which will try to resend the packet some number of times before concluding that the connection is dead. This process is generally much quicker than the keepalive detections process.
Note that under Linux, the retry timers are controlled by two files in the /proc filesystem: /proc/sys/net/ipv4/tcp_retries1 and tcp_retries2. The default values of 3 and 15, respectively, may be large for your liking, possibly taking as long as 15-30 minutes to close the dropped connection. You can set them as low as 1 and 2 for nearly immediate detection, at the possible risk of prematurely judging a temporarily sluggish connection to be dead. Here is some good documentation with more information about the tcp variables in the /proc filesystem.
861.3
A ancient yet nasty bug in FLOCK has been fixed. The symptom was that the queue block representing permission for a particular file to be open could be overwritten by a record request for the same file, causing subsequent requests for that file to return status code 3 or 6 (permission to open file must first be granted). The chance of the error manifesting itself depended on many factors, and judging from the fact that it has never been reported (even though it affected versions going at least as far back as 4.4), probably didn't occur very often. (We discovered it in-house while testing the performance improvement of the QFLOCK MEM: option for Windows in the 4.9 development version.) Nevertheless an update is highly recommended.
861.4
(Windows) Improve raw disk read speed (of READ-intensive tasks) by about 15% by eliminating an unnecessary interruption to process Window events and check for Control-Cprior to each READ which was introduced in edit 816.
861.5
(Windows) MIAMEX,119 (Windows buttons) function supports a new type, 262144, to create a static text control. These are similar to buttons, except that they (currently) do not accept any mouse input, and thus really only serve as a means of displaying static text using a proportional font (same as the font used in buttons). Static controls also are erased (just like normal text) by TAB(-1,9) and TAB(-1,10) (unlike buttons).
861.6
(Windows) Fix 64K wraparound bug in size of QFLOCK.SYS. If file size was more than 64K, it acted as if it was only the modulo 64K size. Consequently, the maximum effective number of QUEUE blocks was about 1500. This problem was introduced in 4.9.
