ARACHNE TODOLIST - PROPOSED SOFTWARE CHANGE DETAILS ----------------------------------------------------------------------------------------------------- Item numbers refer to the 2DoList table. ITEM_2 Unwanted F4 dialling 1. The F4 autodial will occur when Autodial is Yes and when there is a line "Editor..." in ARACHNE.CFG, to call an external editor. I tried three different editors with the same result. 2. This occurs with both v1.71UE01 and 1.73GPL. 3. With 1.73GPL it occurs with the default CORE.EXE as well as with the 386CORE.EXE and CORE.EX0 that were sent to me by Ray and (Bob?) Update: > Since you have been working on config issues, do you still have > problems with "Unwanted F4 Dialling" ? I had to go back and check as I have AutoDial set to NO. So I changed it, and yes, it still happens if (a) AutoDial is set to YES and (b) I have anything selected for the external editor. Apparently with nothing selected for the external editor, F4 goes straight for the internal editor and there is no unwanted access of AutoDial. This occurs with two updated CORE.EXEs that I have been testing. Maybe the fault is somewhere else.... ITEM_6 Check connection pre email Once Arachne has connected to an ISP, it dosen't check to see if the connection is still active before trying to send or recieve mail. The result is that Arachne waits for perhaps 30 seconds while 'trying' to send or recieve, and then gives up with an error message to the effect that the opperation is aborted -- it looks like something is actualy wrong, but all that is amiss is that the program needs to redial. I'd say that this could be done automagicaly without too much trouble. ITEM_8 Frames corrupt arachne.cfg See http://www.cisnet.com/glennmcc/smiley.bug/ 01.txt through 13.txt Thought to have been fixed but: It's still with us, just not as bad as it used to be due only to the fact that we are now compiling for 386 CPUs This has changed the memory usage and has placed the bug into 'hiding'. It's still there and crops-up from time to time under conditions of high memory usage. ITEM_11 Online Timer fix for BOOTP dial-up An old bug that had eluded previous attempts by others to fix. Basically, with all versions of Core up to and including the standard 1.73;GPL release, if you selected the BOOTP method for configuring your IP Address, this prevented the Online Timer feature from working, even if you were using dial-up. Why was this important? Because you need to select the BOOTP method if you want automatic DNS configuration (which incidentally, is a feature supported by LSPPP:-). ITEM_14 8 bit encoding in e-mail headers Contemporary mail clients allow 8 bit input in headers (subject, from etc.). They usually encode those lines in this way: Subject: =?iso-8859-2?Q?COENAweb=3A=20Nov=FD=20=E8l=E1nek?= =?iso-8859-2? - indicates the codepage, Q? - probably means quoted-printable =XY - are replacements of 8bit character ?= - probably indicates end of encoding How can I (Arachne) filter these lines in order to get 8bit or at least 7bit pure text? This would be quite an improving when opening the inbox list (see http://www.volny.cz/cce.zizkov/download/page.zbm). ITEM_15 XSWAP crashes > "Memory allocation error - illegal xSwap operation at line 623 > of file HTMLSTAT.C" I get this error very often. It also seems to be line 623 most of the time, though it varies. I suspect that Arachne might run out of xSwap memory, whatever that might be. Very often, when displaying long and/or complex web pages, this or a similar error message is displayed. The symptoms are that just before the crash, Arachne will slow down to a crawl. If I click the X button just before the crash occurs, I notice that 'Free xSwap(KB) is very low or even displayed in red. Well, my question is now, is it possible to increase xSwap to something more suitable for surfing the 'net? I would also suggest to verify these findings, and if this is indeed a limiting factor in displaying web pages correctly, to make increasing the maximum xSwap memory usable by Arachne a high priority on the 2DoList. > 1. How does the XMS swap area work and how do I expand it? Good question, we're still figuring that out. Joe knows the most about it. This is the XSWAP system, and it's integral to the way Arachne works right now. A couple of the other causes....... - Many, many 'nested tables' on a page. - Lots of improperly commented JS within a page. "IgnoreJS Yes" fixes some of those cases while causing others to be even worse than with "IgnoreJS No" - Tons of very complex CSS within a page also causes the Xswap overflows. And those are just a few of the causes that I know of for sure. There are other Xswap overflow/crashes for which I have not been able to find the presice cause, but for which I was able to eliminate all of the above as being the cause. Some of them are reproducable on-demand... while others are not. ITEM_16 Reduce FP overheaad Softare Floating Point operations are very high in overhead. There may be a better solution (but it requires some work). As far as I remember, FP arithmetics is only used while rendering tables. For this purpose, it could be replaced by fixed point ("scaled" integer) arithmetics with much less overhead that the full x87 emulator.