The question was, "Can XyWrite read a Long File Name-styled directory,
and in particular, can it read the C:\Program Files directory on
Windows-based PCs?" The claim was that C\Program Files was somehow special,
andthe implicit notion was that this somehow left XyWrite... hmm...
sabotaged.
It turns out, somewhat to my surprise, that this is a real phenomenon. But
it is not an insoluble problem.
-------------------------------------------------------------------------
On my home machine, I have XyWrite III (v3.51 and v3.58) on what Windows
thinks is Drive I (It's /dev/hda1 for Un*x speakers, and C:\ when I boot
up in DR-DOS). I also have XyWrite 4.17 for DOS, on the same partition, and
XyWin on "Drive F" (/dev/hda6). And just in case, I have XyWrite II v1.10
and v2.00 dev/hda1 as well. (For the curious, I've also got an early
version of Nota Bene, but unfortunately that's on a 286 system sitting
somewhere in storage and not quickly available.)
I suppose this seems a little.... I think of it as Being Thorough.
Anyhow, the Windows C:\ drive is partition 3, /dev/hda3. /dev/hda1 on my
system is a half-gig FAT-16 partition, which is fine for DOS, but the
Windows partitions are 4-8 gigabyte VFAT partitions; I can't see them while
running DOS. So I had to start everything by clicking on them from Windows.
No problem, everything starts up fine.
I attempted to read the directory "C:\My Documents\My eBooks\". No version
of XyWrite had any luck with the command
dir "c:\My Documents"
or
dir "C:\My Documents\My eBooks"
Which struck me as bit odd, since most versions of DOS can translate these
into appropriate 8.3 form, so one would normally expect DOS applications to
show the same cleverness. Evidentally not.
But, moving on, both varieties of XyWrite III and IV read the directory with
dir C:\MYDOCU~1\MYEBOO~1
XyWrite II, however choked. With both versions, from outside the
directory, the command
DIR C:\MYDOCU~1
simply produced a line stating that C:\MYDOCU1 was a directory with no
files and zero length. If I CD-ed into that directory, and gave a DIR
command, it told me MYEBOO~1 was a zero-length directory. Evidently XyW II
predates the notion of hierarchial directories in DOS. Which probably
limits its usefulness on modern systems. Too bad-- it was a real screamer
back in the days when PCs came with 2 floppies and hard disks were an
expensive option; I'd love to use it for serious work on a modern system.
Anyhow, again. I ran the same experiment on "E:\Software\File Managers"
and got the same kind of results. XyII choked, everything else worked,
as long as I requested
DIR E:\SOFTWARE\FILEMA~1.
Ditto for "C:\Windows\System". So far, so good.
And then I tried "C:\Program Files" And Son of a Cur.... XyWrite III (both
versions) treated this as just another LFN directory; XyWrite IV (both
versions) reacted like XyWrite II -- they saw only a single zero-length
directory. Just as was reported, really and truly.
----------------------------------------------------------------------------
I spent about five minutes being really perplexed, and then hauled out the
DISKEDIT program in the Norton Utilities (well, I double clicked on it, to
be accurate). It turns out, "C:\Program Files" and some number of the
subdirectories under this -- Common Files, Accessories, Outlook Express, Net
Meeting,Web Publisher, and Windows Media Player -- are write-protected.
When you look at their entries in a top-level directory, you'll see that the
R (for Read-Only) and D (Directory) attribute bits are set. Most other
directories simply have the D bit set.
(Interestingly, these are all Microsoft-supplied programs. Should we read
something into it? Probably not. Internet Explorer is NOT write protected,
not is Visual Studio, nor are half a dozen other MS addons. Some things are
protected, probably as a safeguard during installation, but it doesn't seem
to be a consistant policy, and I seriously doubt that Microsoft intended to
inconvenience anyone.)
Anyhow, again again. What's also of interest in a high level directory is
that these things show up TWICE. One entry always has the form
Long File Name (LFN) RSH V
in Mr. Norton's view of directory and immediately below, is
LONGFI~1 D
That second entry is the classical 8.3 DOS filename that XyWrite wants to
deal with. The first is, of course, a Long File Name, and it discloses the
fact to us (and the operating system, and properly clued-in applications) by
all those attribute bits. Which is kind of a
kludge, but face it, with current operating systems we aren't
exactly building for the the ages.
So anyway once more, what shows up for "C:\Program Files" is
Program Files (LFN) RSH V
PROGRA~1 R D
Most Windows programs and old DOS programs ignore the read-only attribute,
and see this simply as a run-of-the-mill directory. XyWrite IV
bounces,evidently seeing PROGRA~1 as another (illegible) Long File Name
because of that set R bit. I suspect it reflects the state of technology at
the time XyWrite IV was hitting the market-- the developers knew of LFNs,
knew something about how they would be recognized, and also knew they didn't
want to touch such files and possibly screw up the names and attributes, so
they made the program err on the side of caution. Whereas the older, less
sophisticated XyWrite III.... Well, there's a Cost To Be Paid For Progress.
Of course, the "solution" to the tilde problem is now obvious: In Windows,
Right Click on the offending directories in Win Explorer, select Properties
(the last entry on the menu), and turn off the Read-Only check. Press Apply
and you/re set-- you can read the directory. In DOS, use the "attribute
-r" command. Believe me, it works.
-------------------------------------------------------------------------
So. A nice puzzle, but not a Three Pipe Problem.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.