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