The lineage that included Windows 3, Windows 95-ME all were MS-DOS based. The Windows NT lineage which became the default consumer version with Windows XP are not based on MS-DOS. There is an add-on command prompt that has MS-DOS like commands but the OS does not run on top of that component.
(Note that all major modern OSes and then some are all "DOS"es. They are Disk based Operating Systems. So MacOS is a DOS.)
The first DOS I recall was the 360 operating system. It was still in use when the PC debuted in 1981, though usually with upgraded functionality. I have no idea why the rebooted the name for the PC.
Someone upthread mentioned Clipper. I had forgotten that I used that on a project in my first job out of college. Unfortunately I don’t remember much about what we were doing with it.
One job I had early in my career was developing in an OS/2 environment. Besides Borland C++ for OS/2, we used a scripting language called REXX and a VB-style IDE called VX-REXX.
To nitpick further: I don’t think the name DOS was based on the OS being stored on disk. It was named for having the functions to utilize disk storage in applications and subsystems like a spooler. Considering the cost of disk space at the time an IBM360 might have loaded it’s OS image from a tape.
That’s how I learned. The LGP-21 in my high school did not have an assembler. It also did not use ASCII, so the binary assignments to letters matched the opcodes for that letter. A “B” was 000101, and the opcode for the Bring instruction (loading from memory to the Accumulator, the only register) was 0001.
I wrote an assembler for it since I was fed up with having to redo jump instructions if I added code somewhere.
My first thesis adviser told me he wrote an assembler for the IAS machine when he was a student of von Neumann’s. Von Neumann thought assemblers were a waste of time.
I’ll pile on to the 6502 discussion by adding it was the 8502 and 8510 for me. No need to program assembly anymore, but I definitely still use C and C++.
Anyone who worked with older computers like the DEC PDP-8 had to know the machine language pretty well. In order to use the machine at all in its basic configuration, you had to enter the binary code for the “read-in mode” (RIM) loader through the console switches, a short program whose only job was to read in the paper tape of the more efficient but much larger main binary loader. Also, tracking down and fixing bugs was frequently done by halting the program and patching in new instructions, again through the console switches. The “James” instruction was very handy for that purpose “JMS I xxx” meant Jump to Subroutine with “I” meaning indirect through location “xxx”, and then you could patch in debugging code somewhere far away and return to the main program.
It was easier than one might think to know the PDP-8 machine language because it was a 12-bit word machine with only 8 instructions. But due to brilliant design, those instructions packed quite a punch. Only 6 were memory reference instructions, the other two were the I/O instruction and something called the microprogrammed instruction. The latter devoted all 12 bits to a wide variety of functions performed on the accumulator register and could be specified simultaneously; for instance, “CLA CLL CML RTR” could be coded as a single instruction (“clear accumulator, clear link, complement link, rotate two right”).
Back in the IBM System/360 days they had two different OS’s for it. One was DOS/360 and the other was OS/360. And the D did stand for “Disk”.
The DOS/360 product was the less-capable operating system. It included the functionality to communicate with disks, tape drives, card readers, etc. The DOS abstracted the IO devices but did nothing else. Only one program ran at a time, and that program “owned the machine”, calling into the DOS to perform IO. IOW, it was like the BIOS API of early PCs.
The OS/360 product was a true operating system. It did all the IO abstraction, but also memory management, timeslice multitasking, preemptive multitasking, program startup & shutdown, and all the rest of what we now think of as OS kernel ops.
The DOS/360 was essentially an up-port of the “monitors” that were available for earlier gen IBM processors. It did not exist for very far into the 360 family’s life and IIRC there never was a DOS/370.
I did actually once work with a guy who knew Z80 instructions so well that he could write programs in raw hex. Talk about specialization!
I never worked on IBM mainframes, but my wife used to. The OSs she remembers are VM and MVS. (Virtual Machine, and Multiple Virtual Storage, respectively). This may have been a slightly later era? Not sure how those map to the ‘360’ branded systems… I’m not a mainframe guy.
IIRC, VM was actually an early instance of a true virtual machine, which presented a more or less complete machine image to the layers above it. Don’t remember much about MVS other than my wife swearing about its command language (JCL, Job Control Language) which was universally hated.
That’s not as hard as you might think. I had the decimal op codes for the 6502 mostly memorized for my C64 when I was writing in assembly. You input them enough and you learn them. (I didn’t have an assembly monitor, so I had to write out my routines on paper, look up opcodes and memory locations, translate them into decimal, and then input them into BASIC with a POKE and a bunch of DATA statements. )
Not all OS/360 versions did all of that, and none of them did it particularly well. Only later releases of OS/360 had features like MFT (multiprogramming with a fixed number of tasks) and MVT (multiprogramming with a variable number of tasks) but only for the larger models, and essentially all of it operated in a batch-processing context. Meanwhile, DEC released the PDP-10 (later renamed DECsystem10) a 36-bit mainframe that provided true general-purpose multiprogramming in an interactive timesharing environment, with a batch subsystem as well, and a far more elegant hardware and software architecture.
IBM did try to venture into the true timesharing space with the System/360 Model 67 and TSS/360, but after several false starts the whole project was abandoned. Customers who wanted timesharing had to settle for something like TSO, the “time sharing option” for OS/360. As I said earlier I never had much to do with IBM professionally, but as a PDP-10 user I did once sit down at a TSO terminal out of curiosity. When I typed something wrong and got the message “Control card error” it was clear that this attempt to do timesharing on System/360 was an embarrassment.
I almost got to that point when I was writing a lot of 6809 code.
Maybe one of the most elegant 8-bit machines ever made: a very regular instruction set!
Still, “Those days are over, a long time ago”, to quote Steely Dan.
Nowadays it takes a city to create a program, and the linker brings in a vast amount of overhead.
And it appears that there are about 300 processes scheduled on my current Win 11 system!?
I blame the BSD Unix system distribution. They made two horrible mistakes.
They introduced a completely different network interface (sockets) which was not properly integrated into the namespace,
And they introduced the concept of userlevel ‘daemons’ for tasks that should probably have been done in the kernel. Which has metastased into an incredible amount of cruft.
I can see why they did it: userlevel programming is so much easier than kernel work, and they had to teach undergraduates. It was still a horrible mistake.
Very likely. My knowledge of IBM systems is totally second-hand.
What was the system that Brooks was working on which inspired the ‘Mythical Man Month’?
I used SAS for years. I’d moved from the IT dept to an IT-adjacent group in HR. At the time, we did a lot of the quick-and-dirty reporting that IT couldn’t handle (because they – and I – all used COBOL) within less than six months of leadtime. Also, due to the sensitivity of the data, they wanted to restrict access to a small core group. I loved SAS after using COBOL. It was so much faster, plus it was very flexible and powerful.
I used a lot of reporting tools that had their own “language” and rules, but didn’t really qualify as actual languages – Intellect, GIS (Get Information Switfly) … damn! several others I can’t even remember the names of.
I used MS/Access to extract data and do some reportng, but it wasn’t really a language either.
ETA: I took an Assembler class through UCLA extension, but I never used it. A friend who took the class with me had just taken a job at Security Pacific NB and had to support programs that ran in production written in Assembler. At least I learned what IEFBR14 stood for!
JCL! Ha. I knew a guy who wrote a proc to run a job in production (!) that was run monthly, quarterly, and annually which were controlled by COND options!!! Insane.
Oddly, I had a lot of JCL experience, got really good at it, and enjoyed writing it. I once told a co-worker that I found JCL intuitive (I must have been high), and he rightly looked at me like I was off my nut.
We used TSO for years. I don’t even remember any “control card error” messages. It worked fine. Of course, when we went to one of our favorite Chinese restaurants for lunch we always ordered General TSO Chicken (not General Tso’s Chicken).