I want to make an operating system for modern x86/64 computer systems with a filesystem and shell, modern being backward-compatible at least back to 2005.
I am stuck in something: should I learn with bare-bones or babysteps assembly tutorial? I'm not perfect in C right now, and the reason why I started learning it is mainly to try to write an operating system; but assembly in a lot of ways feels and looks easier to write.
Would love to find coding mentors on here that can converse with me personally.
Bare-bones vs. Babysteps
Re: Bare-bones vs. Babysteps
I'm not sure if I understood correctly what you're stuck on, but I read it as you're just not confident enough about your programming skills or a specific programming language knowledge to get started.
If I interpret you correctly, then I suggest you just start doing: identify the very first problem you have to solve, and then solve it. You'll learn more as you stumble upon new problems.
I've been programming for years, but I only started my first "OS dev" project this summer. The way I approached this new domain was that I studied a specific physical computer I have available for playing around with: I figured out what exactly happens when I press the power button and then I've been slowly untangling all the side quests that emerge as I try to make something I believe would make the screen light up in some controlled way on real hardware. So far I have only run my code in an emulator because there are still known unknowns that I must resolve before even attempting booting on a real device.
Concretely, for any given intermediate goal, I try to first express its stages very clearly to myself, and then study how this particular thing is implemented in Linux kernel, and why (and why it probably doesn't make sense for me to re-create that implementation). Often the intermediate goal set by me is wrong and there turns out to be a lot other things I didn't even think of that I need to do first, and so I have to adjust my goal before I feel like I understand enough. Finally I understand enough to implement the immediate next step and then I move on to figuring out what would be the next step.
Which programming language to use is probably not that important. Use whatever you like. It's probably a good idea to know more than one language anyway in the long run, but to get started just pick one and start doing. You just need to be able to tell the CPU what to do. Typing out those instructions is usually easier than figuring out what the CPU should do. The former can also be automated nowadays, but a human programmer must be involved in the latter, at least for as long as a human wants to or needs to understand what the computer does.
If I interpret you correctly, then I suggest you just start doing: identify the very first problem you have to solve, and then solve it. You'll learn more as you stumble upon new problems.
I've been programming for years, but I only started my first "OS dev" project this summer. The way I approached this new domain was that I studied a specific physical computer I have available for playing around with: I figured out what exactly happens when I press the power button and then I've been slowly untangling all the side quests that emerge as I try to make something I believe would make the screen light up in some controlled way on real hardware. So far I have only run my code in an emulator because there are still known unknowns that I must resolve before even attempting booting on a real device.
Concretely, for any given intermediate goal, I try to first express its stages very clearly to myself, and then study how this particular thing is implemented in Linux kernel, and why (and why it probably doesn't make sense for me to re-create that implementation). Often the intermediate goal set by me is wrong and there turns out to be a lot other things I didn't even think of that I need to do first, and so I have to adjust my goal before I feel like I understand enough. Finally I understand enough to implement the immediate next step and then I move on to figuring out what would be the next step.
Which programming language to use is probably not that important. Use whatever you like. It's probably a good idea to know more than one language anyway in the long run, but to get started just pick one and start doing. You just need to be able to tell the CPU what to do. Typing out those instructions is usually easier than figuring out what the CPU should do. The former can also be automated nowadays, but a human programmer must be involved in the latter, at least for as long as a human wants to or needs to understand what the computer does.
Re: Bare-bones vs. Babysteps
Oh, assembler is very easy to write. However, also very easy to write wrong, very hard to read, and very hard to change. C gives you some error checking that is wholly absent from assembler. I would suggest, whatever language you end up choosing (you may want to give Rust a try) do get proficient in userspace programming first, and then try your hand at OSDev, because the latter is basically the former without safety nets.
Carpe diem!