During the time DOS 2.0 was in development, I visited Microsoft with a group of colleagues. (We were touring computer manufactures both in Seattle and in Silic

During the time DOS 2.0 was in development, I visited Microsoft with a group of colleagues. (We were touring computer manufactures both in Seattle and in Silicon Valley (where we visited Digital Research, Intel and many others—in those days it was comparatively easy to visit these enterprises for a tour.) We were at Microsoft quite some hours (and we seemed important enough to be fed lunch which consisted of very good sandwiches). One of the people who toured us around was a DOS developer (who in his 'spare' time also contributed to the Flight Simulator development). He spent considerable time discussing the new DOS subdirectory matter as it was a hot topic back then. Anyway, he received somewhat of a tongue-lashing from us about the backslash 'problem' and it was very clear to us that he too was not in favor of it although for obvious reasons he chose his words carefully. This brings me to more ergonomic problems that Microsoft has never bothered to solve with its operating systems—DOS or Windows. The first I'll mention is the annoying reserved character problem, specifically: < > : " / \ | ? * cannot be used in a filename. I'm aware these characters are also deemed illegal in the filenames of other operating systems but I fail to see why after about 30 years that we still have to worry about avoiding them. If Microsoft had fixed the problem back then, then there would have been pressure for other operating system developers to also fix the problem. Just because other operating systems were behind the times, it didn't mean Microsoft had to be—after all, in the early days, Microsoft went to considerable trouble to please users in the useability stakes, even to the extent that it put security severely at risk in the process. I fail to see why Microsoft couldn't have coded around this problem and allowed the use of these characters. It went part of the way by allowing spaces within filenames in Windows and it also allowed spaces to be entered into the command line filenames with quotes "My first Name.doc". The fact that these characters cannot be used has caused considerable trouble for IT staff over the years. It'd hate to think how many thousands of hours have been wasted by both users and IT staff over the past three decades or so on what ought to have been a trivial matter to fix. Similarly, I hate to think how many times I've had to enter a ¿ into a filename just because the damn operating system will not let me enter normal question mark: ?. Another major stuff-up is the maximum filename length/max path length of 254/255 - 260 when the path length could be potentially 32,767 characters—as it already calculates the path to this length internally (the exact length varies between O/S versions). These days, this limit is ridiculous. If, say, you have a file with a filename of say 245 characters long in directory \MyFiles then move the directory way down deep into nested directories then one automatically has a problem that one's not necessarily aware of until a cannot-continue crash occurs during a backup. Having to regularly run a Max-Path-Length utility across the disk to search for potential problems is a damn nuisance and it ought to be completely unnecessary. Same problem occurs when saving web pages with long names, these often exceed the maximum filename length and the page cannot be saved without manual intervention. To say ≈255 characters for a filename is long enough is just not being realistic these days. Here's another instance: say one wants to save a book with a long title from the Internet Archive and to avoid confusion later over having a cryptic filename one adds the book's title to the already-cryptic IA filename, i.e.: Books.<…>.with_very_long_names_are_common_on_the_IA_+_the_Internet_Archive_filename_abcxzy123.pdf Many a time I've had the title combined with the IA O/S filename exceeds 255 characters, and sometimes it's by a large margin. Shortening the filename at this juncture wastes considerable time, especially if there are many files involved. Oh, and there's another PIA worth mentioning: .MSI files cannot be loaded from a directory when the directory has a leading blank (space) in its filename whereas an .EXE file can. Now how did that come about (and it's never been fixed)? [Leading spaces in directories are useful as directories and files are automatically sent to the top of the file manager tree—which is a very useful technique I've adopted for years to highlight temporary work files or sorting directories, etc. Again, this is necessary due another operating system limitation, which is that neither DOS nor Windows has any way of allowing a user to order the file/directory structure to meet his or her needs.] Other obvious limitations are that we cannot highlight filenames or directories in that we cannot make them different colors or even have filenames with different typefaces. Why not? As I've said for years, operating system developers don't care much about user ergonomics. If they did then by now we'd even have a new file system to replace the existing one which is truly antiquated. A new file system would include metadata extension(s) within files that OSes and programs would both understand (but that's a far too big a matter to discuss here). When one thinks about it, we users really have been shortchanged by the likes of Microsoft and others over the years.