What's interesting about this is I feel I could write DOS from scratch with little effort these days. But it would have no value today.

The software I write today is far more complex than what was available in the early 80's.

I've had similar thoughts about this development. (Not about myself being able to rewrite DOS without much effort - but I don't doubt that you could!)

The sophistication of some individual projects today rivals major industry efforts back in the early 80s.

I think it boils down to mostly these things:

a) back then the number of software developers was perhaps 100x-500x smaller than today - so there was simply a much smaller pool of smart people. (But also: Today we have a much, much larger pool of kinda meh people.)

b) there was no widespread internet access, so developers learned new concepts very slowly, often re-inventing them on their own. also, smart people often gut stuck in places where they had no chance of excelling.

c) better tools now: much better screens, windowing systems, mice, better editors (edit: not necessarily IDEs), source code version control tools, SSDs instead of floppies, VMs, trivial networking, pdf readers, archive.org/etc, web browsers/services/sites, etc etc.

I don't understand it, myself. The small size of DOS and its utilities make it look, in a word, trivial to me. I've read about the early days of Microsoft and how they struggled to get DOS finished, and from the perspective of today am more or less baffled.

A part of the problem was they wrote in assembler. Today, I would not write it in assembler. I'd write it in C (or DasBetterC!) and get it all complete and debugged. Then, I'd hand translate it to asm. I expect this would go 10x faster.

I'd also develop it on a Unix computer, using an emulator to debug it, much like how Gates/Alan developed Basic. (That was a really smart move by those two.)

I don't use IDEs myself, but git is an absolute game changer.

You have the advantage, in this case, of knowing what the end result is. I can re-write any of my own existing applications in a fraction of the time it took to develop them initially.

But I agree that it all looks trivial. I'm developing an OS for a custom 8bit system and it's pretty slow going even though it's trivial. Of course, if I was cloning an existing OS it would go a lot faster but obsessing over the fine details is part of the fun.

Simply look at the size of the files. There just isn't much code there.

You're quite right about obsessing over the details. But the idea is to work out the details on a more powerful machine in a high level language. Only convert the final configuration in the target assembler.

For example, back in the 1970s (many years before DOS) I developed a handheld LED game for Mattel, it was Hockey. Handheld LED games were cutting edge at the time. The prototype was developed to run on a 6502 8 bit microprocessor. The dev tools for the 6502 were developed in a high level language and ran on a PDP-11, the resulting binaries were downloaded to an EPROM programmer, blown into an EPROM, then put on the 6502 for testing.

Once everything worked to Mattel's satisfaction, the code and the prototype was given to Mattel. Mattel took this, and gave it to their engineers to implement on a 4 bit microprocessor, to behave exactly the same way.

So this was 3 levels of development: PDP-11 => 6502 => 4 bit microprocessor.

Trying to prototype on a 4 bit machine would have been a horribly costly experience.

Remember that the DOS assembler at the time was terrible. Having a competent cross assembler on a mature machine like the -11 was the way to go.

(I also used a 6502 debugger that actually ran on the -11, again making life a lot easier to develop the code for the 6502 where only very primitive bug-ridden software was available.)

Using PDP-11 to build 6502 makes a lot of sense but using that 6502 to prototype for a even simpler processer is very clever. I'm just getting into electronics as something to do over COVID; I feel I'm re-visiting a bit of that era.

The 8-bit computer I'm working on 6502-based. One of the first things I did after "Hello World" on the hardware was write an emulator/debugger for the whole system in C#. I also get to use a pretty nice macro assembler compared to what you would have had back in the day.

You may have encouraged me to go back to a project I've put on hold: I started writing a high-level language that compiles to 6502 assembly. I could use C but it's not very 8-bit friendly and I want to go higher level than that but still keep the 8-bit-ness in mind. I've created a lot of macros but that only gets you so far.

If I had to do a lot of 6502 work today, I'd develop a custom language for it. Much like C is a custom language for the PDP-11 instruction set. C doesn't map very well onto the 6502, but customizing it would.

Good luck on your 6502 endeavor!