I've had a lot of people tell me that DOS is a bad OS. I've had a lot of people tell me that Unix is great.

OK. DOS is a single user OS. Unix is a multiple user OS. DOS does not multi-task. Unix does. DOS was never meant to be a multi-user, multitasking system so it's unfair to criticize it for that. If you need multi-user/multi-tasking, move on.

Except for these two differences DOS and Unix seem to work alike. A mathematician would say they are isomorphic, i.e., different words and symbols are sometimes used for the same thing. E.g., one uses \ where the other uses /. A trivial difference. They are both command line operating systems that store files in a hierarchy.

So why do people criticize DOS?

: I've had a lot of people tell me that DOS is a bad OS. I've had a
: lot of people tell me that Unix is great.
:
: OK. DOS is a single user OS. Unix is a multiple user OS. DOS does
: not multi-task. Unix does. DOS was never meant to be a multi-user,
: multitasking system so it's unfair to criticize it for that. If you
: need multi-user/multi-tasking, move on.
:
: Except for these two differences DOS and Unix seem to work alike. A
: mathematician would say they are isomorphic, i.e., different words
: and symbols are sometimes used for the same thing. E.g., one uses \
: where the other uses /. A trivial difference. They are both
: command line operating systems that store files in a hierarchy.
:
: So why do people criticize DOS?
:
:
:
People criticize DOS mostly because of its memory management. DOS is build with the idea that you'll never need more than 640kB of RAM. This means that no DOS program can be bigger than that amount. As a consequence of this, when PC's started getting more memory solutions needed to be found to access that additional memory (hence the EMS and XMS drivers).
Also DOS names have to be in the 8.3 format, which made naming documents often difficult.

: :
: People criticize DOS mostly because of its memory management. DOS is
: build with the idea that you'll never need more than 640kB of RAM.
: This means that no DOS program can be bigger than that amount. As a
: consequence of this, when PC's started getting more memory solutions
: needed to be found to access that additional memory (hence the EMS
: and XMS drivers).
: Also DOS names have to be in the 8.3 format, which made naming
: documents often difficult.
:
Good points. I find the 8.3 naming requirement particularly troublesome, however, I don't thing it bothered me until Windows began supporting long file names. In fact I came to DOS from a mainframe environment that allowed only 6 character names, so 8.3 was a great improvement. Meanwhile at home my Commodore 64 allowed 16 character names.

I don't remember how much memory the mainframe I was working on had but I do know that each individual user could access only 64k, so having access to 640k on my DOS machine put me in hog heaven. Even in those days, when Gates "640k is enough for anybody" statement was right on, people were bad mouthing DOS. I've never understood why.

Both the 640k limit and the lack of long file names is something that MicroSoft probably would have addressed had they continued to develop DOS but they didn't.

yea DOS really sucks.






: I've had a lot of people tell me that DOS is a bad OS. I've had a
: lot of people tell me that Unix is great.
:
: OK. DOS is a single user OS. Unix is a multiple user OS. DOS does
: not multi-task. Unix does. DOS was never meant to be a multi-user,
: multitasking system so it's unfair to criticize it for that. If you
: need multi-user/multi-tasking, move on.
:
: Except for these two differences DOS and Unix seem to work alike. A
: mathematician would say they are isomorphic, i.e., different words
: and symbols are sometimes used for the same thing. E.g., one uses \
: where the other uses /. A trivial difference. They are both
: command line operating systems that store files in a hierarchy.
:
: So why do people criticize DOS?
:
:
:

DOS is fine when it suits the need of a program.

1. 8.3 names? - So, separate your disk structure with sub-directories.
2. 640 Kb? - What about disk drive? In good days of DOS - huge systems were written, using this method. Now, of course, everyone does bloatware.

DOS is great for controlling other hardware, because ALL system resources are of the program - nothing spent on multi-tasking and such.

:
: DOS is fine when it suits the need of a program.
:
: 1. 8.3 names? - So, separate your disk structure with
: sub-directories.
: 2. 640 Kb? - What about disk drive? In good days of DOS - huge
: systems were written, using this method. Now, of course, everyone
: does bloatware.
:
: DOS is great for controlling other hardware, because ALL system
: resources are of the program - nothing spent on multi-tasking and
: such.
:
Separating disk structure with sub-directories is a good idea as far as organizing you data goes but does not address the issue that sometimes a natural file name just can't be used. Real world example: a procedure is named MustCreate. I want to put it in its own file so the software stores it as MUSTCREA.INC. It's a minor irritant.

Disk drive? Yes! Particularly a RAM DISK. I've used this to create really huge arrays and really fast sorts.

You can use long filenames in DOS 7+ as long as you run a TSR that provides the functionality. I have use LFNDOS in the past but there is also DOSLFN and others. In MS-DOS version 6.22 and below the commandline doesn't support long filenames even if a driver supporting the API is installed, but programs that take advantage of it will work as expected, e.g. an ACE archiver by Marcel Lemke IIRC. Programs that do not handle long filenames in Windows will not magically gain the ability since they will still use the older 8.3-style API. There are also non-TSR programs that are designed to replace the functionality of the internal DOS commands.

http://sta.c64.org/lfnemu.html
http://home.att.net/~short.stop/freesoft/windos.htm
http://www.geocities.com/jadoxa/ The fourth entry is DOSLFN.

DOS is most secure than UNIX in a
multiuser environment with lan drivers.
Good luck!
Hackman