Continuing the discussion from Consider Switching from Creative Cloud to Affinity V2:
Ashton Tate committed corporate suicide. dBase III was incredibly popular, used and beloved by everybody.
But they took forever to develop version 4, and when it shipped, dBase IV was a resource-hog, slow and crashed all the time. I remember trying to use it and recommended going back to dBase III (and Nantucket’s Clipper compiler for making native executables from dBase applications). Which we did.
This catastrophic failure (and taking 2 years to put out a bug-fix release) killed the company. And then the Borland merger ended up killing Borland too. (See also Wikipedia).
Ironically, this is not a problem with DOS, but with sloppy programming on the part of the utility/app writers (more specifically, the development tools used at the time).
On UNIX-like systems (including Mac OS X), even in the 1980’s, the shell (sh, csh, etc.) would parse the command line, including a robust mechanism of quoting and substitution to support wildcards, environment variables and other such things. It would then pass the list of parameters to the launched app via the exec
family of system calls. The app receives the list as an array when it starts.
MS-DOS was much more primitive. When launching a DOS app, the 256 byte structure containing various process-specific information includes a 128-byte block of text containing its command-line parameters (up to 128 characters, of course). It is the application’s responsibility to parse this text into a sequence of parameters, including quoting parameters with spaces and expanding wildcard characters into lists of filenames.
Apps written in a high-level language like Pascal or C would get an array of parameters (like on UNIX), only because the language’s startup code would parse the DOS-provided parameter string. This parsing was typically very primitive, blindly using space characters as delimiters and doing very little else. Hence the inability to use filenames with spaces - not because of a DOS problem, but because of a Pascal or C library limitation.
An application could choose to manually parse these parameters on its own in order to (for example) allow the use of quotes to allow parameters with spaces (I have sample code in a book showing one way to do this), but very few applications actually did this.
Ironically, applications (even using the old GW-BASIC interpreter) have no problems using filenames with spaces. Within an application, you could easily include a space in the string used to represent a filename. DOS wouldn’t have a problem with such strings and would dutifully create, open and use such files. But you wouldn’t be able to pass those filenames to most commands, due to the primitive argument-parsing logic used.