Re: generalized startup.int

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from cld@xxxxxxxx (Carl Distefano) on Sat, 2 Nov 2002
00:19:56 -0500

May I offer an alternative approach to a "portable" XyWrite?

This may appeal to someone who doesn't want to change the
way XyWrite loads, and/or finds that s/he wants to set a
large number of variables. The basic idea is to make all
your configuration file (DFL, INT, PRN, REG, etc) settings
point at an unused drive like Z:, and then use DOS's SUBST
command to redirect the XyWrite's d:\path (and subdir
tree) to the root directory of Z:. There are advantages
compared to Carl's method, and also disadvantages, but in
general I find it easier. All my installations point at Z:,
which means that I can take any file from one machine and
put it on any other machine, transparently.

I also have a second kind of installation, pointing at Z:,
which I burn to CDs. I can carry the CD into an Internet
Cafe, or to anybody's machine, and presto I have my own
Editor, with all my personal configurations, looking just
like it does at home, instantly available. You can
read/write/edit files anywhere on the host machine. It even
AutoRuns when I put the CD in the drive, on machines that
haven't disabled that. But this is a trickier thing to set
up, because normally XyWrite wants to write Temp files in
the current directory, or in the same directory as Editor,
and of course a CD is Read-Only (so the configuration can't
be altered). Overcoming that requires editing a few files,
like changing many U2 VA$ED specs to VADR, and being careful
that files that use indexes (DLG, U2) have an index written
after the EOF character before you put them on CD;
still, when you get it all adjusted, it works. If you travel
a lot, it's mighty handy; you can also stick all your favorite
utilities on the CD, and simply temporarily add Z:\ to the
DOS PATH.

The disadavantages are, generally, that Z: might already be
in use (mapped to a network drive, etc), or that access to
C:\ (where I write my Temp files, on the theory that it must
exist) might be restricted to guest users on a public
machine (e.g. at Kinkos) because they don't want you mucking
with the operating system files, or that access to DOS might
be disallowed to your class of user on a public machine.
But restrictions like that are rare on personal machines.

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