
              Windows 95 and Long File Names . . . a Myth?
                            by Dale F. Ogden

In creating Windows 95, the successor to MS-DOS and Windows 3.1x,
Microsoft has performed what many, including this author, consider a
near technological miracle. The death of MS-DOS has been predicted since
the debut of the IBM PC-AT more than ten years ago. In Windows 95,
however, Microsoft has again demonstrated that MS-DOS is alive and well.
Windows 95, despite its name, is really version 7.0 of MS-DOS and
version 4.0 of Windows (those version numbers are actually coded in the
software). These very closely integrated versions of MS-DOS and Windows
provide significant evolutionary technological advances in Intel
x86-based operating systems and, with one significant and sometimes
painful exception, excellent backward compatibility.

The major improvements typically cited for Windows 95 are: 

  -  it's a 32-bit operating system (partly true);

  -  the dynamic allocation of physical and virtual memory between the
     cache (a smarter disk cache than SmartDrv) and applications;

  -  significantly increased availability of system resources (an order
     of magnitude better than the improvement between Windows 3.0 and
     Windows 3.1);

  -  the new user interface and TaskBar; and

  -  long file names.

Windows 95 is only partly a 32-bit operating system. This is not a
failure on the part of Microsoft, but rather part of the technical
near-miracle. The "compromise" was necessary to ensure backward
compatibility with "legacy" applications (particularly DOS-based
programs) and 16-bit drivers.

The dynamic allocation of memory and increase in system resources are
significant and long overdue improvements in Windows. For example, in
Windows for Work Groups, on a 90 MHz Pentium with 64 MB RAM, running
nothing but Program Manager, I have (had) approximately 80% of system
resources available after starting Windows. If I ran Excel 5.0 with a
couple of spreadsheets and Word 6.0 with a couple of documents, that
would drop to only 30% or 40%. Not only that, but closing an application
did not restore all of the resources that were used. As such, it was
typical that anyone using several Windows applications had to exit and
restart Windows at least a couple times daily (there are even shareware
programs that were created specifically to accelerate the Restart
Windows procedure). I have found that many problems in Windows could
solved by periodically exiting and restarting Windows.

In Windows 95, on the same machine, I start with 97% and 99%,
respectively, of User and GDI resources, while already running about a
half dozen utilities, like Norton System Doctor, at startup; I would
never have put anything in my Windows 3.x Startup group. On top of that,
I can run a half dozen applications, including the same 16-bit versions
of Excel and Word, along with, for example, PageMaker 5.0, ProComm Plus
for Windows 2.11 (both 16-bit applications), and two 32-bit
number-cruncher-type applications, MathCAD 6.0 Professional and APL*Plus
III for Windows, and still have about 65% of system resources available.

Whether or not the user interface is an improvement is highly subjective
and depends mostly upon personal preferences. As I've gotten used to it
and figured out how to customize it (with the Windows 95 Power Toys,
developed by the Windows 95 Development team, but not supported by
Microsoft), I generally like it. Nonetheless, I believe it is poorly
implemented, mostly because of its dependence on long file names for
menu items. And, as you might notice in the remainder of this essay, I
am not a fan of long file names on FAT partitions.

With the "_previous version[s] of MS-DOS" one was limited to an eleven
character filename, an 8-character name and a 3-letter extension.
Generally, the extension was used to identify the type of file and the
8-letter name was used to identify the particular file. This led to
complaints that people did not know what the files were. The lack of
support for long file names was often cited as a weakness in DOS and
Windows. The 8.3 filenames were considered limiting and required users
to create cryptic names that usually would be forgotten when and if they
went looking for their old data and reports.

Macintosh-envy is the source of much of this noise. However, I believe
that the Macintosh is a religion more than a computer. I used Macintosh
computers in a Macintosh-oriented "Big 6" accounting firm. I found
nothing particularly intuitive about the Macintosh; and given the
inability of many intelligent, highly educated accountants (most of
which are CPA's) I dealt with to do much with their Macs, they, too,
found very little intuitive about the Mac. Conversely, I believe that
almost nothing on a PC is more intuitive than the MS-DOS prompt. Maybe
this makes me a propeller head, but if I want to copy or move a file,
the commands in MS-DOS are "Copy" and "Move." I have no trouble
remembering them. Every time I use a Macintosh or a Windows-based file
management program, I have to test it first to figure out whether I want
"Drag & Drop" or "Ctrl + Drag & Drop" ("Cmd" instead of "Ctrl" for the
Mac). I am not 100% sure at this moment which it is.

I question whether the limitations of the 8.3 file naming system was or
is really a problem. I have worked on a couple thousand projects for
over two hundred fifty clients over the last thirteen years, and, with
only a handful of (intentional) exceptions, every proposal, every
analysis, every report, and every set of data provided to me is on my
hard drive and easily retrievable. They are efficiently stored in
cryptically-named PKZIP files within client specific and archive
directories. To accomplish this, one need only exercise a little effort
to be organized, as is at least as true with paper files.

However, even if the lack of long file names is a problem, Windows 95
does not solve that problem. Long file name support, as implemented in
Windows 95, does not really provide long file names; rather, it provides
an alias or a file description. Those file descriptions are, in my
opinion, poorly implemented by being stored in the disk directory
(Windows 95's implementation of long file names is the same as Windows
NT's long file names on FAT partitions; while I have much praise for
both operating systems -- I love Windows NT -- the same criticism
applies to both). A file with a long file name (and many with short file
names) now has two (or more, if the name is long enough) directory
entries rather than one. One directory entry is a short file name and
the other directory entries are the long file name. For example, if you
create the Excel file "Budget for Jan 1995.XLS" there will also be a
directory entry "BUDGET~1.XLS" an 8.3 alias for the long file name.
However, "BUDGET~1.XLS" is the "real" directory entry that points to the
actual file on the drive and the long file name is merely a pointer to
the short file name. If I create a separate budget file for each of
twelve months, I end up with the mess shown in Table 1.

                                Table 1
                       Windows 95 Long File Names
                       and Real (8.3) File Names

             Real File Name       Windows 95 Long File Name
             --------------       -------------------------
              BUDGET~1.XLS         Budget for Jan 1995.XLS
              BUDGET~2.XLS         Budget for Feb 1995.XLS
              BUDGET~3.XLS         Budget for Mar 1995.XLS
              BUDGET~4.XLS         Budget for Apr 1995.XLS
              BUDGET~5.XLS         Budget for May 1995.XLS
              BUDGET~6.XLS         Budget for Jun 1995.XLS
              BUDGET~7.XLS         Budget for Jul 1995.XLS
              BUDGET~8.XLS         Budget for Aug 1995.XLS
              BUDGET~9.XLS         Budget for Sep 1995.XLS
              BUDGE~10.XLS         Budget for Oct 1995.XLS
              BUDGE~11.XLS         Budget for Nov 1995.XLS
              BUDGE~12.XLS         Budget for Dec 1995.XLS

Furthermore, If I name a file with lowercase letters, it also creates a
long file name. For example, if I create the file "budg1295.xls" I end
up with the real filename of "BUDG12~1.XLS" and the long file name of
"budg1295.xls" -- I keep the CAPS LOCK key on much more than I used to.
I believe this creates the following paradox: In the interest of
backward compatibility, the implementation of long file names
compromises backward compatibility by unnecessarily rendering many
Windows and DOS-based programs (such as backup software) almost useless
and many DOS-based utilities dangerous (such as those that manipulate
directory entries). So- called "legacy" programs will only work on the
real 8.3 file name, so you'll see the file name as "BUDG12~1.XLS" rather
than "BUDG1295.XLS"

Some of that software will be upgraded or replaced (I hesitate using the
word "upgraded") at significant expense, but with little or no increase
(and many times a loss) in functionality. In other cases, there are
Windows-based replacements for older DOS-based shareware that have been
or will be revised to deal with long file names. However, in many
instances, the DOS-based utilities are far more useful. The best example
I can think of is WinZip by Nico Mak Computing; this is a terrific
program and I use it frequently. However, for someone like me who
downloads lots of files, SHEZ, an outstanding text-based DOS program is
far better at processing large quantities of [PK]ZIP (or ARJ, LHZ, etc.)
files.

Nonetheless, a better and simpler solution for long file names has
existed for several years in the simple form of file descriptions. All
of those PKZIP client files are described in hidden files named
"DESCRIPT.ION" that are located in the same directories as the file.
4DOS, a shareware replacement for COMMAND.COM, the limited functionality
"sample" command processor bundled with MS-DOS creates "DESCRIPT.ION"
files and displays them with directory listings. They are easy to edit
and 4DOS copies, moves, and deletes them along with the files
themselves. There are both Windows NT and OS/2 versions of 4DOS, and
Windows-based programs called Take Command, available in both 16-bit and
32-bit versions, with all the functionality of 4DOS and more. The
combination of 4DOS and Take Command is an unbeatable enhancement to
Windows 95, Windows NT, and to "_your previous version of MS-DOS" and
Windows.

With 4DOS, a partial listing of my client archive files looks like Table
2, below:

                                Table 2
                File Listing with 4DOS File Descriptions

AMER0694.ZIP    121740  7-25-94  12:38  American Insurance Company - Jun 1994
AMER1294.ZIP    161466  2-15-95  14:27  American Insurance Company - Dec 1994
AMER0695.ZIP    144721  8-07-95   9:25  American Insurance Company - Jun 1995
ISLAND92.ZIP    626407  4-27-93  16:02  Island Finance - 1992 Loan Reserves
ISLAND93.ZIP    683734  5-25-94  22:05  Island Finance - 1993 Loan Reserves
ISLAND94.ZIP    693612  3-15-95  17:12  Island Finance - 1994 Loan Reserves
PWIC0693.ZIP    140422  8-05-93  11:06  Pacific Western Insurance - Jun 1993
PWIC1293.ZIP    185816  2-25-94  17:43  Pacific Western Insurance - Dec 1993
PWIC0694.ZIP    160916  8-09-94  14:53  Pacific Western Insurance - Jun 1994
PWIC1294.ZIP    184728  2-28-95  16:25  Pacific Western Insurance - Dec 1994
PWIC0695.ZIP    165666  8-11-95  10:32  Pacific Western Insurance - Jun 1995

If file descriptions exceed 40 characters, they merely wrap to the next line 
(in contrast very long file names use additional directry entries). SHEZ, 
like many other shareware programs, including a number of Windows-based 
utilities like Canyon Software's Drag & File, is 4DOS aware and displays 
4DOS file descriptions.

How difficult would it have been for Microsoft to implement 4DOS-style
file descriptions? How difficult would it have been to make Windows 95's
new applications and utilities aware of file descriptions? I suspect it
would have been quite simple. I believe it would have been easier for
Microsoft to make its operating system aware of file descriptions than
for hundreds (perhaps thousands) of software developers to make their
software aware of long file names. 4DOS-style file descriptions would be
at least as easy to implement as long file names. Had Microsoft done so,
then DOS and Windows disk and file utilities, disk editors,
defragmenters, directory sorters, backup software, and other useful
utilities from PC Tools, the Norton Utilities and others still would
have worked. Instead, MS chose to "screw-up" the file system.

One final comment on the implementation of the Windows 95 user
interface. In Windows 3.1, Program Manager created Groups. The
information for each item in a group was stored in a "GRP" file such as
MAIN.GRP. Each entry in a group included a description, the command line
(typically the name of the executable file), a working directory, and
the icon for that entry. Each entry used about 1000 bytes; a group with
36 applications in it would therefore be about 36,000 bytes. Assuming
one has a 500 megabyte disk partition, that would use five 8 kilobyte
clusters or 40 kilobytes.

Under Windows 95, each entry in the Start Menu and each Desktop shortcut
(note "Start Menu" and "Desktop" are each long file name aliases for the
directories "STARTM~1" and "DESKTOP") is represented by a "LNK" file
that contains the same information as the Program Manager Group file,
except it does not contain the icon (the LNK files are too small); it
only contains a link to the icon (this causes much more disk activity
when booting Windows 95 and when cascading through menus). However, the
description is now the long file name (and subject to limits on the
characters that can be used to name files, a limitation that does not
exist in Program Manager, 4DOS file descriptions, or other shell
replacements). Therefore, each menu entry uses an entire 8 kilobyte
cluster. Ultimately, the Start Menu entries and Desktop shortcuts could
use up to eight times as much space as they do in Program Manager.

In Windows 3.1, I have 58 groups (45 of which are subgroups created by
Plannet Crafter's PlugIn, a Program Manager enhancement, with a total of
1,006,824 bytes; due to the FAT cluster size of 8 kilobytes, those 58
GRP files use 1,245,184 bytes, a storage efficiency of about 81%. There
are about 1,000 entries in those files. Under Windows 95, those 1,000
entries would use 1,058 8K clusters, one for each entry plus one
subdirectory (Oops! "folder") for each group, or 8,667,136 bytes, seven
times as much; storage efficiency would be only about 3.3% (the average
size of Windows 95's LNK files on my system is only 293 bytes). Each
sub-menu is a directory, using another 8 kilobytes.

I have avoided creating LNK files because it wastes space and clutters
my hard drive with long file names. Where possible, my menu items are
restricted  to eight or fewer CAPITAL letters; my Desktop shortcuts are
JOEY (for "My Computer"), XPLR, DF32, WZIP, TPRO, TC, 4DOS, EDIT, OZW,
AOL, CIM, PPW, VIEW, GWS, MOD, MIDI, and TRASH. I run most of my DOS and
Windows-based games from the 4DOS command line, and always delete links
to README files, WRI and HLP files, and uninstallers. On my system I
have 242 LNK files, the actual size of which is 70,907 bytes, but using
1,982,464 bytes. Add about 20 sub-directories (or sub-folders) and that
adds another 160 kilobytes. Instead of an improved menu system, I now
have reverted to running programs from the dreaded command line.

If either the long file names or wasted disk space were necessary to
gain the functionality of the Windows 95 user interface, it might be
worth it, but there is no reason why Microsoft could not have made each
"folder" in the Start Menu into one file; for that matter, the entire
Start Menu and all the Desktop shortcuts could be stored in one file.
Many other desktop enhancements for Windows 3.1, like PC Tools Desktop
for Windows, store all desktop items in one file. Metz Task Manager for
Windows has a customizable launch menu (much like the Start Menu without
the small and virtually useless icons) and includes twenty single click
buttons (with icons) to launch the most frequently used programs. It
uses only one file to store all this information. I could name at least
a half-dozen other Program Manager replacements (including Windows 95
style Desktops), enhancements, and program launchers that are more
elegantly and efficiently imple- mented than Windows 95's Desktop and
Start Menu. Maybe Microsoft should have looked at what already was
available (even if it was "not invented here" -- after all, Windows
wasn't invented by Microsoft either) before thrusting this abomination
on us. Such an approach would have allowed more flexibility in naming
menu items and would eliminate littering my directories with long file
names, a worthy goal by itself.

(c) Copyright 1995, by Dale F. Ogden - All rights reserved

This document may be freely distributed as long as it is reproduced in
its entirety and contains the above copyright notice.

	Dale F. Ogden
	76044.3556@compuserve.com
	DaleFOgden@aol.com

