Re: Subject: Re: XYWRITE digest 2483

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Patricia M. Godfrey"  on Fri, 20
Jan 2006 09:48:19 -0500


> I'm using Clip to copy and past blocks of text between Tbird and Xy.

Not really. You're using CLIP to copy from XyWrite to the Windows Clipboard
(no connection with Tbird). Then you're using Windows system services to paste
from the Windows Clipboard to T-bird.

Anyway, FireFox has changed a lot since March 2005 -- I'd grab the newest
installation EXEcutable at work (DSL, right?), put it on your memory key, take
it home and install.

Try this: take that very same text that you XPLeNCODEd in your last msg, and
try to Clip it again and again, with and without Tbird running. Is a crash
repeatable? Is there some particular character in that text that is triggering
this? Check your memory situation next time Clip crashes: VA/NV $ME and also
take a look at the allocation of overflow files, with func SW.

> On this
> particular occasion, I had XYWWEB.REG and my January posts file up in Xy
> (06jan.txt was 378,261 bytes at that time) plus a third, untitled file
> into which I had copied the Not found lines, then run encode on them.

Just guessing, but it *may* be related to not having enough leftover memory
available to fully run CLIP.EXE when you shell from XyWrite, within its own
session, to DOS. This would be related to not having substantial parts of your
several open documents offloaded into temporary "overflow" files (which
liberates main memory == DOS memory). And AFAIK, there's no way to _force_
that offloading to overflow to occur, or rather (more precisely) to calibrate
it exactly -- XyWrite just does it internally, as and how it sees fit, in
proportions/amounts that it determines. The consequence would (could) be that
CLIP launches but then runs out of memory midstream. NT seems to be MUCH more
forgiving about this than 9x. You might try this: about 11 lines down into U2
frame ClipW*, you'll see this SUbroutine:
\CLIP.EXE  Q2 >
 Change it as follows:
\CLIP.EXE  Q2 >
That would do three things: 1) if memory shortage is the problem, it will
crash KMD.EXE instead of CLIP.EXE, which will be diagnostic; 2) it will push
CLIP into a separate session, with full memory; 3) it *may* slow Clipping down,
because the CPU will be paying more attention to XyWrite (especially under 9x!)
than to CLIP.EXE -- because focus will have returned to XyWrite, which will
have the CPU's priority. Now, that's OK for Clipping (which doesn't have any
further interaction with XyWrite anyway), but not so cool for Pasting, where
XyWrite is sitting around waiting for file CLIP.TXT to show up in the directory
so it can MErge it into the present window. Hmmm. Since (I gather) you have
this problem only with Clipping, never with Pasting, let's do this: let's
change the instance of SU11 on the eleventh (or whatever) line per the
modification above, but let's _first_ copy the original version of SU11 and
insert it waaay down in the frame, right here:
 ...right_here...
Insert it just BEFORE the . This way, you shove CLIP out of Xy's memory
space for Clipping, but not for Pasting. (Now, *why* Clipping crashes CLIP and
Pasting doesn't is a mystery to me, given that the environmental conditions are
the same, but... whatever.)

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------