Re: How is U2 different from XyWrite?

["Patricia M. Godfrey" priscamg@xxxxxxxx]

I hope, for their sakes, that the lack of response from
the real gurus (Carl & Robert) means they're taking a
well-deserved vacation. Let me see if, in my inexpert
way, I can add to Jordan's very good answer.


The guts of XyWrite is editor.exe, and that, as Jordan
noted, is written in Assembler; the various "frills"
(menus, dialogues, etc.) are, I believe, written in
XPL. That gives the end user an enormous advantage in
making it work the way he or she wants: Ericsson and
Hild (the original XyQuestrians) were way ahead of
their time.


>>we are dealing with at least five entities: original
>>XyWrite 4.016, U2, Virtual Dos Machine, an
>>Operating System, and other applications that run
>>under that OS.


I would not call U2 a separate entity: it is another
add-on to the basic Xy engine: a set of macros, if you
will, but an enormously powerful, versatile, and useful
set. (By the bye, the general convention here--and I
sometimes forget, myself--is to use "Xy" for "XyWrite"
and "XyW" or "XyWin" for XyWrite for Windows.)


All applications (except for pre-opsys-loading BIOS
routines, and I don't think they're usually called
applications) run under some opsys; DOS apps run on
windows run under a VDM. There's nothing unique to Xy
about that. What complicates things is that when Xy was
running under DOS pure and simple, we were always told
that, because it is written in Assembler, it makes some
calls directly to the hardware, bypassing DOS. How much
that still happens under Windows, I'm not sure. I
suspect a certain amount of it goes on. (See an
exchange between Robert and me a few weeks back:
someone was complaining of not being able to get
graphic view in a Window; Robert said, "Of course not;
it won't work"; and then I found two--ancient and
underpowered--PCs of mine where, in violation of all
the principles of VDMs, I could do it. As one of those
boxes has recently been upgraded to Win2K, I must check
and see if it can still be done.)


>>But there has to be interaction between XyW and VDM,
  >>the OS, and any other applications involved. Does
U2 >>"translate" the XyW output so it can be understood
by >>the "external programs?" "Translate" commands from
 >>the "external" programs so XyW can respond to them?


Xy itself (i.e., Editor.exe, the compiled Assembler
program) translates all Xy commands, whether typed on
the keyboard or invoked by a macro (I'm using the term
loosely here, to include all user-created routines) if
they require interaction with the VDM/opsys. Thus, if I
type CA e:\xyinfo\2006\08aug.txt, Editor.exe. asks the
opsys to fetch that file and load it into memory. Then
editor.exe displays it on the screen for me to read or
edit. One reason I'm pretty sure that calls to disk
files are routed through the opsys (and certainly not
direct calls to the disk hardware--and maybe not even
to the VDM?) is that Xy can call files off all sorts of
"disks" that didn't exist when it was written: CR-RWs,
flash drives, not-mapped network drives...)


As for "external programs," there aren't that many
involved. Robert's clip permits Xy to copy and paste to
the Windows Clipboard; TYP and XYTOPDF interact with
GhostScript and GSView, but mostly (it appears: I've
looked at the code several times, but am far from fully
understanding it) by creating other command-line
sessions or batch files to pipe commands to the VDM.
(And plain-vanilla DOS lets you pipe data from one
command to another: witness this ancient DOS routine:

dir f:\xyarch\*.*>dirlist.txt
which writes a directory listing of the specified
folder to a text file.)


If you have the original Xy4 manuals, the place you
should look is in the Customization Guide under Menu,
Dialog Box, and Help File Frames. U2 is a set of type 5
frames: those that execute routines. (I believe Bry
Henderson has the Customization Guide as PDFs on his
site (http://www.xywrite.com/man/xy4/contents.htm) if
you don't have it.)


U2 differs from an ordinary program that you might
write in XPL in that instead of having one separate
routine for each task, which you then have to invoke
by, say, typing

Run xytowp.pgm
on the command line, or storing it as a save-get and
then loading it to a key (which means you can invoke it
by typing, say, CTRL-SHIFT-W, but that gobbles up
memory at a shocking rate) the whole megillah is stored
in some magically efficient way in memory (I think only
an index is actually in RAM, and then each routine gets
loaded and unloaded as it runs), so that you can invoke
each one by typing its name (without "run "--that's
four keystrokes saved) and hitting your dedicated helpkey.


This is a lot more than the one par John asked for, and
probably a lot of it is balderdash. Anyone who knows
better, please correct.

-
Patricia M. Godfrey
PriscaMG@xxxxxxxx