osdev hasn't gotten harder

[kzinti]

Then again, the world wasn't and isn't uniform in terms of internet access, book availability and foreign language skills. It was quite hard to find the necessary info in the early nineties in Russia. No internet, few home computers, few books translated into Russian from English, etc. In the late nineties the situation improved but you still had to know enough English 'cause the Russian segment of the Internet wasn't too rich yet.

I didn't know English then either. I learned it by reading computer magazines and books with an English-French dictionary and no understanding of the grammar. In the beginning, it would take me days to read a 3-4 pages article.

But I do understand English was/is more accessible to a Canadian than for someone in Russia.

[nexos]

It was quite hard to find the necessary info in the early nineties in Russia.

That was probably more or less because of the political crisis / economic downturn (to put it lightly) in Russia at that time. Linus Torvalds and ast lived in Europe, yet they had access to everything needed to build OSes.

As for the topic itself, I most certainly wasn't OSDev'ing then, hence it's hard for me to say. But I personally think that OSDev itself is significantly more difficult now than it was then. Torvalds developed Linux initially in a few months, try developing an OS that runs GCC and Bash in that timeframe these days. Of course, I've seen his code at the time, it was mediocre (to say the least), but still, it was a lot easier to get something decent running then.

Nonetheless, one thing is easier about now than then: it's easier to find information. True, in those days, you could order books, or order manuals and so on, but today, you can find pretty much all the HW docs / specs (at least for PC) you need on the internet. The only real stumbling blocks are PCI, SATA, and the various non-standardized host controllers (NICs, sound cards, graphics cards, WiFi cards, Bluetooth cards, SCSI HBAs, and so on). Also, in those days, if you weren't professionally trained and encountered something in a spec such as, "this checksum is computed using CRC32", then chances are, you were toast. You couldn't pull out Google and search for "crc32 algorithm", you had to either a) have attended university or b) know someone who did or c) were lucky and had read a book such as "Algorithms in C" and learned about CRC32.

Finally, in those days it was more likely people would build better OSes. This is because of the lack of tutorials. One may argue that the widespread tutorials make OSDev easier, I disagree. I think they make it easier to print "Hello world" to the screen, but make it harder to do anything useful. I used to just follow tutorials; I'd say that the bad "knowledge" I got from them set me back about a year with my OSDev'ing. At a point I can't quite remember, I committed to doing things the right way. I ordered several of the classics on OS design (namely "Unix Internals" by Uresh Vahalia, which I truly consider the turning point for me in OSDev, "Inside Windows 2000" by Microsoft Press, and of course ast's classic "Operating Systems: Design and Implementation". I have a couple others, I just haven't really read them yet). It sure is more difficult, but I've gained good knowledge that is beneficial to OS design, not bad knowledge that will get me to write something, but not write something that works. Of course, there are disadvantages; the last time I wrote kernel code was January 2021 . But that's partially due to other projects that distracted me for a while.

[thewrongchristian]

Finally, in those days it was more likely people would build better OSes. This is because of the lack of tutorials. One may argue that the widespread tutorials make OSDev easier, I disagree. I think they make it easier to print "Hello world" to the screen, but make it harder to do anything useful.

"In those days"? You've used anything by Microsoft prior to Windows NT, right?

And the resource constraints made the OSes pretty ropey. Lots of hacks and short cuts to make the code and data fit. 4mb was a luxury when Linux was written, for a student. It's hard work to write a good OS in 4mb.

What the tutorials do do, is make kernel development more accessible. I started in earnest in OS dev in about 2015, when I started playing with Xv6. It's with this that I discovered that stepping OS code can be done easily using QEMU and gdb, and I'd run out of excuses not to have a play.

From there, I played with the Bare_Bones, and started building on that. I couldn't have imagined doing that on bare hardware, just the thought brings me out in a cold sweat, I think the likes of qemu make OS dev much easier to get started with.

Of course, now my kernel is more mature, I could contemplate doing bare hardware based development, but I'm pretty sure I'd never have managed to bring it up using bare hardware.

I ordered several of the classics on OS design (namely "Unix Internals" by Uresh Vahalia, which I truly consider the turning point for me in OSDev

This book is fantastic, and I'd recommend it to anyone into osdev.

[nexos]

And the resource constraints made the OSes pretty ropey. Lots of hacks and short cuts to make the code and data fit. 4mb was a luxury when Linux was written, for a student. It's hard work to write a good OS in 4mb.

But there was a lot less complexity. For example, a good OS didn't necessarily need a full O(1) scheduler, these days, that would be treachery. No SMP was needed, you could get by with a trivial VMM, and so on. Yes, hacks were needed. But an OS with hacks then is simpler then a hack-free OS now.

What the tutorials do do, is make kernel development more accessible. I started in earnest in OS dev in about 2015, when I started playing with Xv6. It's with this that I discovered that stepping OS code can be done easily using QEMU and gdb, and I'd run out of excuses not to have a play.

From there, I played with the Bare_Bones, and started building on that. I couldn't have imagined doing that on bare hardware, just the thought brings me out in a cold sweat, I think the likes of qemu make OS dev much easier to get started with.

Fair enough, but that's not what I was thinking of particularly. Getting started with OSDev with no tutorial to figure out the basics would be very hard. What I'm saying is that beginner OSDev'ers (speaking from experience BTW) tend to follow the tutorials strictly, and can't figure out how to do anything outside of the tutorial. For example, I rarely have seen a tutorial point to the Intel or AMD manuals as the authoritative word, for me, it made them seem like mystical documents, hence me (and probably others) don't read them. Then they come here with issues, and don't have any real knowledge on how the GDT, IDT, paging and so on work. Why? They weren't pointed in the right direction. What's even more disturbing to me is the models of memory management and scheduling and other more or less creative parts of OSDev I see in tutorials. One well known tutorial I know of literally modified the paging structures using physical memory addresses! I fell victim to that tutorial; it took me a long time to recover from that one. Or some tutorials demonstrate multitasking in the worst possible manner. And non-suspecting OS developers fall victim to this, they begin to lose interest when they see problems. This is why hobby OSes have such a high morbidity rate.

So the problem isn't really the fact that tutorials exist, but rather, the fact they are poorly written. Some tutorials like Bare Bones, Brendan's Multitasking Tutorial, and a few others are good. They point OS developers in the right direction. Also xv6 is a great resource. Super simple codebase that is clean and correct still.

Since he was mentioned above, I think the renaissance I can observe that occurred in OSDev about 15 years ago was because of Brendan's teaching style on these forums. I wasn't here when before the infamous debacle, but I have seen in old posts how he quoted the manuals as authoritative, but still explained things to beginning OS developers. This is more helpful that saying "read the manual, what else do you think?" I think his departure a long with a lot of the older mod's departure has been the key reason to the "decline" in OSDev.

[nexos]

Oh, and also: I wouldn't take Windows 1 - 3.x and 9x as representative of the whole era. They were full of hacks for backwards compatibility. Resource constraints did play a role, but I think that also was more or less because of the 1M restriction of real mode that the DOS side had to work with. It was just one big hack.

I remember I wanted to make a Windows 9x clone. After reading a book on Windows 9x architecture, I decided against that .

I was thinking of pre-4.4 BSD and pre-SVR4 System V. Even 4.4BSD and SVR4 aren't all that complex by today's standards!

[iansjack]

OS development has got easier (obviously - there are so many more resources available nowadays).

However, OS development ambition has got greater.

[eekee]

I'd forgotten some of the problems of the 80s. There was a lot less understanding of how to design good interfaces, both APIs and user interfaces. The situation might have been different with mainframe/minicomputer OSs, (of which Unix was the cheapest by far, if I'm not mistaken,) but many OSs for microcomputers were terrible. No consistency, no orthogonality, and it was fashionable to try to constrain users (including programmers using APIs) so they "couldn't" do "stupid" things. This could make necessary and even quite ordinary tasks harder. "Unix does not prevent users from doing stupid things, because that would also prevent them from doing clever things." I forget the exact wording, but this was the original Unix developent team's policy. It was unusual to the point of being a distinctive feature of Unix.

As for actually writing an OS for micros, assembly language was your only choice. C was considered bloated and slow for good reasons: optimizing compilers were shockingly expensive and getting the most out of any hardware in that era required a lot of hardware-specific tricks. Instability and bugs were ever-present problems. I find it interesting that MS-DOS was very buggy until versions 5 & 6; these versions being rewritten in C in the 90s.

Still, some people did write operating systems and were happy with them, such as Dave Dunfield who built his own computer and wrote the VMS-inspired CUBIX OS for it.