Re: Flash with Xy

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "J. R. Fox"  on Sat, 25 Dec 2004
08:56:06 -0800

Configuring XyWrite on Removable Drives (CD, USB)
--------------------

> I'm wondering if anyone has taken Xy -- the full program -- around
> with them on a Flash or "cigar" drive, and run it from there ? If so,
> wouldn't you need to do something moderately clever with Settings.DFL
> etc. (if it can be done), because the keychain drive could end up
> being anything from Drive D: to H:...

That's a really interesting problem, Jordan. I struggled with it for a long
time, not with a memory key but with self-booting "emergency repair" CDs. I
came up with two relatively solid techniques for a completely drive-blind
system, which I find transfer perfectly to USB memory sticks (I love them).
The first system I tried was SUBST (as Harry suggests); and that works -- but
the problem with it is that the Windows registry keeps a list of driveletters
that were formerly used by hot-swapped external storage, emulated CD/DVD
drives, etc. -- devices that I use a lot. Suppose Windows assigned one such
device to P:. When you unplug it, P: is free for your use. But if you SUBST
P: and use it for your memory key, next time you plug in the other external
storage device it will be Q: or W: or some damn thing, but not P: anymore.

You can prove that this happens by this experiment: Put a floppy in A:. Do a
DIR A: or any command. Then remove the floppy. Mount a boot image of a floppy
and use the SUBST command to assign that to A: Then put your *real* floppy
back in the drive. It will be B: Unload everything and cold boot the machine.
Put your floppy in the drive. It's *still* B: !! Fun fun fun...

So I dumped the SUBST command (I need predictable, unvarying driveletters for
my storage) and went for a programmatic XPL approach. Which is this, reduced
to essentials (I could post a sample STARTUP file I guess if anybody is
interested, with real code -- this is all pseudo-code):

The key principle here is to let Windows assign the driveletter, not humans.
Windows doesn't trample on the aforementioned semi-reserved driveletters (and
you also aren't chewing up *two* driveletters, as with SUBST). For ease of
discussion, let's say that Windows assigns your memory key to K:

I do all my processing in STARTUP.INT -- that's the logical place.

Find your current directory at the very top of STARTUP.INT:

>;*;
>++"\">{240}"\">>;*;
;*;==XyW Drive
;*;==d:\XyWpath\
;*;
BX :Q2 BX cd \XY4Q2 ;*; Locate in Editor's dir "[driveletter:]\XY4"
;*;

So now you just plug in your normal STARTUP.INT commands, but you fashion them
to refer to S/G 02, which contains "K:\XY4\", instead of a hard-coded d:\path\

There are a few snags. Two of them occur in SETTINGS.DFL. First, you need to
migrate to STARTUP all those "DF" (DeFault) settings in DFL which refer to a
specific *driveletter*, e.g. (note that the "G:" below appears because you took
DFL from your fixed harddrive installation somewhere else, where it was on G:):

df dr=G:\XY4\BTFONTS becomes BX d dr=BTFONTSQ2;*;
 and then *comment the spec out* in DFL:
;df dr=G:\XY4\BTFONTS
 gotta keep your head straight when you do this! Immaculate!

Second DFL snag: the PP: printer table. This has to be moved to STARTUP
altogether, so comment the whole thing out (prepend a ";" to each line, from
"PP:#" to the bottom). After doing these things, you just LOAD SETTINGS.DFL
via STARTUP, as you normally would.

So go ahead and LOAD all your main files, e.g.:
BX load settings.dflQ2;*;
BX load xywwweb.u2+xy4.mnu+xy4.dlgQ2;*;
etc. etc.

Now, obviously, there are a few things that I never do. Above all, I avoid
hardcoded d:\path assignments everywhere. For example, I don't RUN any
programs from the KBD file, where they would need hardcoded d:\paths. All
programs are in U2, where they are portable (and easily called by KBD). (There
is method to our U2 madness!)

To handle SETP, you want to create a temporary PRN file (SETTINGS.DFL is a
PRiNter file!), STore it, LOAD it, and then erase it. Here's the code, which
you put in STARTUP:

+"HPLJ-3.PRN	\\PSMAINE\P1
3	"++"HPLJ2FAX.PRN	HP LaserJet Series II for Fax
1	"++"TYF.PRN	TYF to a foreign printer (IMage printing)
1	"++"HPLJ-4.PRN	\\PSNYC\P1
1	"++"POSTGHST.PRN	PostScript Ghostscript
1	"++"STRIP.PRN	Strip formatting
1	"++"XYWBMAIL.PRN	Format for Email
1	"++"HPL3ANSI.PRN	ANSIfied LJ3
1	"++"GENERIC.PRN	Do nothing
">+"SETP.PRN">BX sa %01,Q2 )>BX waitQ2 JM
2.AwaitFileQ2 BX load Q2 BX waitQ2 BX ernv Q2 BX waitQ2 BX setp 5Q2
BX waitQ2 ;*;

The only other STARTUP snafu occurs in case you use an HP Laser that requires
one of the LJ*.BIN files. You might think you don't need to print when running
from a memory key; but if you want your docs to look as they customarily do,
you need to load a PRN. So if the BIN spec in PRN is:
 PR=G:\XY4\LJ4.BIN,L4
you can do the following to change it to the current driveletter:

>BX apfil/= ,PR=LJ4.BIN,L4Q2 ;*;

You need to do that *before* you SETP!

Finally: XyWWWeb.REG needs to be dealt with. Most of the published examples
of REG specs use hard code; but frame RegData, which fetches data from REG when
U2 frames need it, is also perfectly capable of interpreting XPL. So, instead
of
 Savesess_Data_Files=K:\XY4¯
you can say
 Savesess_Data_Files=+":\XY4">
and *that* is the reason that I keep the driveletter in permanent Save/Get 650
-- so that my REG data specs can be read. When data is fetched from
XyWWWeb.REG, it is always returned in S/G 99. So in the spec above, we just
put the correct data in S/G 99 outselves -- RegData doesn't need to do it.

When you're all done with this, you ask yourself, well, why not use this system
**all the time**? And that's a good question. I do. It allows me to ZIP up a
XyWrite installation and move it anywhere, to any machine -- and the whole
thing just works out of the box.

I hope I haven't forgotten anything, I'm doing this from memory. Better check
for typos...

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