mjhjmtu

From The OS/2 Museum page about DOS3: "The new ATTRIB.EXE utility allowed the user to manipulate file attributes (Read-only, Hidden, System, etc.). It is notable for being the first DOS utility written in C (up to that point, all components in DOS were written in assembly language) and contains the string “Zbikowski C startup Copyright 1983 (C) Microsoft Corp”, clearly identifying Mark Zbikowski’s handiwork."

I realise that this doesn't really answer the question, but gives an idea of how DOS was implemented. Also remember that the operating system had to be as small as possible so as to leave room for user programs, so the resident part of COMMAND.COM would have stayed written in Assembly.

Low Memory ==> Assembly Language

In the early days every byte mattered. MS-DOS was, in many ways, an outgrowth of CP/M. CP/M had a fairly hard limit of 64K. Yes, there were some bank switching in later versions, but for practical purposes for most its popular lifetime it was a 64K O/S. That included O/S resident portion + Application + User Data.

MS-DOS quickly increased that to 1 Meg. (but 640K in practical terms due to IBM's design decisions) and it was relatively easy to use the 8086 segmented architecture to make use of more than 64K memory, as long as you worked in 64K chunks.

Despite the 1 Meg./640K limit, plenty of machines started out with a lot less RAM. 256K was typical. The original IBM PC motherboard could hold from 16K to 64K, though most (and all the ones I ever worked with myself) could hold from 64K - 256K. Any more RAM went on expansion cards. RAM was still rather expensive in the early days - plenty of machines did plenty of useful work with 256K (or less!), so keeping the resident O/S components to a minimum was very important to allow for larger applications and more user data.

Can an optimizing C compiler get really close to hand-coded assembly language in memory usage? Absolutely. But they weren't there in the early days. Plus, compilers (in my mind, until Turbo Pascal came along) were big & clunky - i.e., needed plenty of RAM and disk space and took a long time to compile/link/etc. which would make developing the core of an O/S even harder to do. MS-DOS wasn't like a strip of paper tape loaded in via a TTY to an Altair (the first Microsoft Basic) but it was small and efficient for what was needed at the time, leaving room for applications on a bootable floppy and in RAM.

MS-DOS (by which I mean the underlying IO.SYS and MSDOS.SYS files) was written in assembly through the first half of the 1990s.

In 1995 for Windows 95, which was bootstrapped by what you would call MS-DOS 7.0 (although nobody ran DOS 7.0 as a stand-alone OS), I did write a small piece of code in C and included it in the project. As far as I know, it was the first time C code appeared in either of those .SYS files (yes I know one of those SYS files became a text file and all the OS code ended up in the other one).

I remember sneaking a look at the Windows NT source code at the time to see how they had solved some issue, and I was impressed at how even their low level drivers were all written in C. For instance they used the _inp() function to read I/O ports on the ISA bus.

C would have been really inefficient to write the operating system for a number of reasons:

First, initial compilers for high level language used 16-bit pointers on MS-DOS, only later adding support for 32-bit pointers.  Since much of the work done in the operating system needed to manage and work with a 1MB address space, this would have been impractical without larger pointers.  Programs that took advantage of compiler-support for larger pointers suffered significantly on 8086 since the hardware doesn't actually support 32-bit pointers nicely!

So second, code generation quality was poor on 8086, in part because compilers were less mature back then, in part because of the irregular instruction set of the 8086 (re: many things, including the above mentioned 32-bit pointer handling), and in part because in assembly language a human programmer can so simply use all the features of the processor (e.g. return value in CF flags (Z-bit) along with return value in AX, as is done with the int 21h system calls).  The small register set also makes the compiler's job harder, which means it would tend to use stack memory for local variables when a programmer would have used registers.

Compilers only use a subset of a processor's instruction set, and accessing those other features would have required an extensive library or compiler options and language extensions that were yet to come (e.g. __stdcall, others).

As hardware has evolved it has become more friendly to compilers; while also, compilers have improved dramatically.

Aside from the historical answer, which is just "yes", you also have to keep in mind that DOS is magnitudes smaller than what we'd call an "OS" today.

What is odd in my opinion is the use of x86 assembly language for everything.

On the contrary; using anything else would have been odd back then.

DOS had very few responsibilities - it handled several low level components in a more or less static way. There was no multi-user/-tasking/-processing. No scheduler. No forking, no subprocesses, no "exec"; no virtualization of memory or processes; no concept of drivers; no modules, no extensability. No USB, no PCI, no video functionality to speak of, no networking, no audio. Really, there was very little going on.

See the source code - the whole thing (including command line tools, "kernel"...) fits into a handful of assembler files; they aren't even sorted into subdirectories (as Michael Kjörling pointed out, DOS 1.0 didn't have subdirectories, but they didn't bother adding a hierarchy in later versions either).

If you count the DOS API calls, you end up at roughly 100 services for the 0x21 call, which is... not much, compared to today.

Finally, the CPUs were much simpler; there was only one mode (at least DOS ignored the rest, if we ignore EMM386 and such).

Suffice it to say, the programmers back then were quite used to assembler; more complex software was written in assembler on a regular basis. It probably did not even occur to them to rewrite DOS in C. There simply would have been little benefit.

High level languages are generally easier to work with. However, depending on what one is programming, and one's experience, programming in assembler is not necessarily all that complex. Remove the hurdles of graphics, sound, inter-process communication, and just a keyboard and text shell for user interaction -- it's pretty straight-forward. Especially with a well-documented BIOS to handle the low level text in / text out / disk stuff, building a well-functioning program in assembler was straight-forward and not all that slow to accomplish.

Looking backward with a 2018 mindset, yeah it might seem strange to stick with assembler even in the later versions of DOS. It was not, though. Others have mentioned that some tools were eventually written in C. Still most of it was already written and known to operate well. Why bother rewriting everything? Do you think any users would have cared if a box containing the newest DOS had a blurb stating, "Now fully implemented in the C language!"?

You need to understand that C wasn't a good compromise between low-level and "high-level". The abstractions it offered were tiny, and the cost of them was more important on the PC than on machines where Unix originated (even the original PDP-11/20 had more memory and faster storage than the original IBM PC). The main reason why you'd choose C wasn't to get useful abstraction, but rather to improve portability (this in a time where differences between CPUs and memory models were still huge). Since the IBM PC didn't need portability, there was little benefit to using C.

Today, people tend to look at assembly programming as some stone-age level technology (especially if you've never worked with modern assembly). But keep in mind that the high-level alternatives to assembly were languages like LISP - languages that didn't even pretend to have any relation to the hardware. C and assembly were extremely close in their capabilities, and the benefits C gave you were often outweighed by the costs. People had large amounts of experience and knowledge of the hardware and assembly, and lots of experience designing software in assembly. Moving to C didn't save as much effort as much as you'd think.

Additionally, when MS-DOS was being developed, there was no C compiler for the PC (or the x86 CPUs). Writing a compiler wasn't easy (and I'm not even talking about optimizing compilers). Most of the people involved didn't have a great insight into state-of-the-art computer science (which, while of great theoretical value, was pretty academical in relation to desktop computers at the time; CS tended to shun the "just get it working, somehow" mentality of commercial software). On the other hand, creating an assembler is pretty trivial - and already gives you lots of capabilities that early compilers for languages like C did. Do you really want to spend the effort to make a high-level compiler when what you're actually trying to do is write an OS? By the time tools like Turbo Pascal came to be, they might have been a good choice - but that was much later, and there'd be little point in rewriting the code already written.

Even with a compiler, don't forget how crappy those computers were. Compilers were bulky and slow, and using a compiler involved flipping floppies all the time. That's one of the reasons why at those times, languages like C usually didn't improve productivity unless your software got really big - you needed just as much careful design as with assembly, and rely on your own verification of the code long before it got compiled and executed. The first compiler to really break that trend was Turbo Pascal, which took very little memory and was blazing fast (while including a full-blown IDE with a debugger!) - in 1983. That's about in time for MS DOS 3 - and indeed, around that time, some of the new tools were already written in C; but that's still no reason to rewrite the whole OS. If it works, why break it? And worse, risk breaking all of the applications that already run just fine on MS-DOS?

The API of DOS was mostly about invoking interrupts and passing arguments (or pointers) through registers. That's an extremely simple interface that's pretty much just as easy to implement in assembly as in C (or depending on your C compiler, much easier). Developing applications for MS DOS required pretty much no investment beyond the computer itself, and a lot of development tools sprung up pretty quickly from other vendors (though on launch, Microsoft was still the only company that provided an OS, a programming language and applications for the PC). All the way through the MS-DOS era, people used assembly whenever small or fast code was required - compilers only slowly caught up with what assembly was capable of, though it usually meant you used something like C or Pascal for most of the application, with custom assembly for the performance critical bits.

OSes for desktop computers had one main requirement - be small. They didn't have to do much stuff, but whatever they had to keep in memory was memory that couldn't be used by applications. MS-DOS targeted machines with 16 kiB RAM - that didn't leave a lot of room for the OS. Diminishing that further by using code that wasn't hand optimized would have been a pointless waste. Even later, as memory started expanding towards the 640 kiB barrier, every kiB still counted - I remember tweaking memory for days to get to run Doom with a mouse, network and sound at the same time (this was already with a 16 MiB PC, but lots of things still had to fit in those 640 kiB - including device drivers). This got even worse with CD-ROM games; one more driver to fit in. And throughout all this time, you wanted to avoid the OS as much as possible - direct memory access was the king if you could afford it. So there wasn't really much of a demand for complicated OS features - you mostly wanted the OS to stand aside while your applications were running (on the PC, the major exception would only come with Windows 3.0).

But programming in 100% assembly was nowhere near as tedious as people imagine today (one notable example being Roller Coaster Tycoon, a huge '99 game, 100% written in assembly by one guy). Most importantly, C wasn't significantly better, especially on the PC and with one-person "teams", and introduced a lot of design conflicts that people had to learn to deal with. People already had plenty of experience developing in assembly, and were very aware of the potential pitfalls and design challenges.

Yes - C has been around since 1972 but there were no MSDOS C compilers until the late 80s. To convert an entire OS from Assembler to C would be a mammoth task. Even though it might be easier to maintain, it could be a lot slower.

You can see the result of conversion when you compare Visual Studio 2008 to VS2010. This was a full blown conversion from C to C#. OK - it is easier to maintain from the Vendor's point of view but the new product is 24 times slower: on a netbook, 2008 loads in 5s, 2010 takes almost 2 minutes.

Also, DOS was a 16-bit OS in a 20 bit address space. This meant that there was a lot of segmented addressing and a few memory models to choose from (Tiny, Compact, Medium, Large, Huge): not the flat addressing that you get in the 32-bit/64-bit compilers nowadays. The compilers didn't hide this from you: you had to make a conscious decision as to which memory model to use since changing from one model to another wasn't a trivial exercise (I've done this in a past life).

Answering the question - yes.

For the rationale: there's very little gain in rewriting functioning code (unless for example you have portability specifically in mind).

The "newest version" of any major program generally contains much of the code of the previous version, so again, why spend programmer time on rewriting existing features instead of adding new features?

It's interesting to note that the direct inspiration for the initial DOS API, namely CP/M was mostly written in PL/M rather than assembly language.

PL/M being a somewhat obscure language and the original Digital Research source code being unavailable due to copyright and licensing reasons anyway, writing in assembly language was the most straightforward course for direct binary compatibility. In particular since the machine-dependent part of the operating system, the BIOS, was already provided by Microsoft (it was very common to write the BIOS in assembly language anyway, even for CP/M, for similar reasons).

The original CP/M structure consisted of BIOS, BDOS, and CCP (basically what COMMAND.COM does) with BIOS implementing the system-dependent parts, BDOS implementing the available system calls on top of that, and the CCP (typically reloaded after each program run) providing a basic command line interface.

Much of the BDOS layer was just glue code, with the most important part that was more complex being the file system code and implementation. There were no file ids indexing kernel internal structures: instead the application program had to provide the room for the respective data structures. Consequently there was no limitation on concurrently open files. Also there was no file abstraction across devices: disk files used different system calls than console I/O or printers.

Since the core of MS-DOS corresponds just to what was the BDOS in CP/M, reimplementing it in assembly language was not that much of a chore. Later versions of MS-DOS tried adding a file id layer and directories and pipes to the mix to look more like Unix, but partly due to the unwieldy implementation language and partly due to a lack of technical excellence, the results were far from convincing. Other things that were a mess were end-of-file handling (since CP/M only had file lengths in multiples of 128) and text line separators vs. terminal handling (CR/LF is around even to these days).

So doing the original implementation in assembly language was reasonable given the system call history of CP/M that DOS initially tried to emulate. However, it contributed to drawing the wrong project members for moving to a Unix-like approach of system responsibility and mechanisms. Microsoft never managed utilizing the x286 16-bit protected modes for creating a more modern Windows variant; instead both Windows 95 and Windows NT worked with the x386 32-bit protected modes, Windows 95 with DOS underpinnings and Windows NT with a kernel developed new. Eventually the NT approach replaced the old DOS-based one.

NT was renowned for being "enterprise-level" and resource consuming. Part of the reason certainly was that it had bulkier and slower code due to not being coded principally in assembly language like the DOS-based OS cores were. That led to a rather long parallel history of DOS- and NT-based Windows systems.

So to answer your question: later "versions of DOS" were written in higher languages, but it took them a long time to actually replace the assembly language based ones.