Can C be used for a raw beginner?

[mac]

I want to get to design my own hobby operating systems. How about C? I have fiddled around with other languages before but didn't get so much past the"Hello World"program. Am i still qualified to learn C programing before anything like Assembly?
And I also need brushing up on my technical English skills.

[SpyderTL]

That's a tough question to answer. But maybe I can help you decide which path to start with...

If you don't already have a preferred language, the choice comes down to what you want to accomplish, and where you want to focus your effort.

Assembly allows low-level access to the CPU, it's registers, and access to system memory and devices. You will be responsible for the state of the CPU, and making sure that the system remains stable as you add more and more complexity to your operating system. The larger your OS becomes, the more care you must take that all of the various aspects work together.

C provides an environment that manages the state of the CPU for you, so that you can focus your effort on creating functionality quickly. It allows you to write functions in seconds, where the same functionality may take minutes or even hours when using Assembly. It also allows you to include existing libraries and applications written by other people that you can incorporate into your system relatively easily. The only real disadvantages to using C are that a) most of the actual CPU details will be hidden from you, and b) there are a few things that cannot be done with C, which means that you will likely ultimately need to learn some Assembly anyway.

Writing code in Assembly and C are completely different experiences, so this decision is a big one. If possible, you should probably learn both, as each has its own merits, and learning one will help you understand the other from a different point of view. You can even mix and match Assembly and C code in the same OS, once you understand the relationship between them.

(All that being said, I actually decided to use neither Assembly nor C, and wrote my own low-level "language" using XML. I wrote it specifically for people who didn't know Assembly, but still wanted to write low-level code. You can find more information here: http://forum.osdev.org/viewtopic.php?f=15&t=27971)

Regardless of which path you choose, this site is a great resource with a lot of information for both Assembly and C development for beginners. The wiki has plenty of articles on choosing a language, and lots of tutorials that you can follow once you've decided which language to use.

Feel free to post questions on the forums if you have specific questions about getting started.

Good luck!

[AndrewBuckley]

Most on this forum will tell you if you have not gotten past simple hello worlds then OS dev is a bit ambitious because everything you could have to handhold you to tell you where things went wrong simply don't exist "down here". Buzz kill out of the way.

C programming is somewhat easier to start with compared to assembly. If you are booting from whole cloth here you will be dropped in 16 real mode by the bios with all the limitations that entails. Using C here is tricky because of x86 segmentation, almost every compiler assumes a flat address space and will not work here. once you find yourself with a flat address space(your own bootloader or multiboot) you can link C code to your assembly, all it needs is a stack setup first before you call anything.

[embryo]

I want to get to design my own hobby operating systems. How about C?

You can ask yourself - how computer works? If you have no clear answer, then neither the C nor anything else will be of any help.

But if your answer is clear to you, then you can try to implement the first step - the bootloader. And again, first you should ask yourself - how bootloader works? If you have clear answer then there is no problem in using any language to implement your clear understanding in form of a code.

And if you have a bootloader, then there are no problems on the way to your OS.

[mac]

This is the best answer I got.
-Thanks

[Kevin]

An advisable shortcut is understanding what a bootloader would have to do, and then skipping it and using an existing one instead. A good bootloader is a project on its own and most people either end up never doing the actual kernel or using a bad hack that they call bootloader, but isn't really one that deserved its name. In the latter case, the lacking features and quality of the bootloader generally has negative effects on the development of the kernel.

[mac]

If it's also relevant, I also want to begin teaching myself electronics. I'm not sure what subfield yet, but I kinda have a burning interest in electronics, which hopefully will lead into some technical computer stuff. I think the OS can be just a dream at this stage.

And when I'm ready for the tough stuff, there is an OS design book lying around, but it's probably outdated from the 80s. My dad also went to electronics school.

I actually assume there are many people in their teens or 20s here correct?

[alexfru]

C can be learned as the first language. But because of its nature (origins + history) the learner must pay a lot of attention to things like:
- minimum and maximum values that every numeric type can represent (on this particular platform/compiler and in portable code)
- numeric overflows
- arithmetic peculiarities (in C, arithmetic doesn't work the way you learned in school, especially floating point, but integer arithmetic has its surprises as well)
- implicit/default type/argument conversions/promotions
- undefined behavior
- unspecified and implementation-defined behavior/result

That is important because it is very easy to make a mistake and write buggy code and it won't always be detected by the compiler or at runtime. C is not a forgiving language.

Because of optimizations that modern C compilers do, undefined behavior in your code can cause quite a havoc at runtime and if you don't know those several dozens of conditions causing undefined behavior, it'll be hard to figure out where exactly the problem lies, the source code will simply look "normal" to the eye. Undefined behavior can also be hiding from you and remain "dormant" until you move to a different platform or a different compiler or a different version of the same compiler or simply different optimization options. You may even get a feeling that either you're going crazy or your compiler is playing tricks on you. In extremely rare cases you can indeed uncover a compiler/library bug, but in most cases (99.9+%?) it'll be your code at fault and not something else.

Not all is lost, however. First, you need to befriend the compiler and use it to help you. The single most important thing to do is to make it a habit to always compile your code with all warnings enabled (there are compiler options for that) and to always properly rearrange or otherwise fix the code so it compiles without any warnings. If you ignore warnings or improperly fix the code, it's likely it'll break or continue to be broken. It is also true that not all warnings are caused by a real problem in the code. Sometimes the compiler is trying way too hard to find problematic code and gives false negatives on valid code. There are ways around that, but you should still avoid disabling warnings (you may be able to disable specific warnings on a section of code and that's better than disabling all or specific warnings on the entire source file or the entire project).

Secondly, you should get a good book on C. I hear K&R 2nd edition can be a good start, despite being old and covering ANSI C only.

I also strongly discourage you from programming an OS in C now. It'll likely be an extremely frustrating experience. OS stuff is hard to debug on its own. Doing that in a poorly understood language makes that much harder. Often things won't work and you won't have any idea why. It would be better to first learn enough C to write regular programs in it.

As for electronics, the simplest would be to stick with digital circuits operating with 0's and 1's. There would be less physics involved and the logic would be more apparent. There are textbooks that are called something like Digital Logic that start with simple inverter circuits, AND and OR gates and progress to parts of the ALU (e.g. binary integer adders, shifters and multipliers), flip-flops, static memory cells and finite state machines. They also cover de Morgan laws, base-2 (binary) arithmetic and some other math/logic things. All that is directly relevant to software and computers. Analog circuits and their parts (resistors, capacitors, coils, diodes, bi-polar transistors, RLC-circuits/filters, operational amplifiers, etc etc) are also relevant as they are basically at the core of all electronics, but as a programmer you are unlikely to be going that deep into things. In some fields you may actually be required to have some understanding of analog circuits, but that's not everywhere.

Oh, about the age. I'm 36.

[embryo]

An advisable shortcut is understanding what a bootloader would have to do, and then skipping it and using an existing one instead.

And what component should be the first? Here we have a lot of variants and all of them are just plain programs, that we can run under Windows or Linux. But bootloader is the part, which is hardly can be run under Windows or Linux (without emulation). So, when a programmer completes he's bootloader he has an empty field to fill with something useful and also he has the skill of developing and debugging on the lowest level possible. It is better to start to fulfill the emptiness while having really useful skill behind.

But if the skills are with a programmer, then, of course, it is possible to skip bootloader part.

[Kevin]

If my goal is writing an OS, then I would start with writing some part of the OS, not writing a separate project. Typically the kernel, but if you're aiming to be compatible to some existing kernel, you might as well start with userspace programs (that's how GNU worked).

Also, when you're talking about those dumb bootloaders that everyone seems to be hacking together, this is some work in real mode assembly and using BIOS interfaces - in other words, a really useless skill when you get to your actual OS.

[embryo]

when you're talking about those dumb bootloaders that everyone seems to be hacking together, this is some work in real mode assembly and using BIOS interfaces - in other words, a really useless skill when you get to your actual OS.

Is the skill of using assembly really useless? It is still useful even if it is a different platform dialect, but when it is the same platform with some minor modifications, then I bet there's no viable difference for a good programmer.

[Kevin]

I'm not saying that it's worthless to know how to deal with assembly. Just that doing a bootloader sidetracks you and teaches people to depend on the BIOS and that Protected/Long Mode are bad because the BIOS functions aren't accessible any more. And honestly, there are more than enough places in the OS to practice your assembly, for something a bit more modern than Real Mode.

[AndrewAPrice]

when you're talking about those dumb bootloaders that everyone seems to be hacking together, this is some work in real mode assembly and using BIOS interfaces - in other words, a really useless skill when you get to your actual OS.

Is the skill of using assembly really useless? It is still useful even if it is a different platform dialect, but when it is the same platform with some minor modifications, then I bet there's no viable difference for a good programmer.

It is still a good skill. Even if you're not fluent in it, it's good to just have a basic idea of what it is and what's going on in it. If your emulator crashes and gives you a disassembled dump of what it was executing, you can figure out a general idea of what happened. You may one day work on a project (maybe video/audio/image processing or a physics or graphics engine) that has some of its most intensive stuff written in hand-optimized assembly.

Assembly itself is very simple. Each instruction does one thing. If you know how to parse strings, you can write a basic assembler in one day. It might be good for a hobby project.

Trying to wrap your head around doing high level tasks in assembly language is the hardest part. It's not because the language is hard (".<label>" and "<instruction> <operand1> <operand2>" is very simple to pick up on) but because you're controlling the CPU by hand - you need to learn about registers, stacks, calling conventions - things higher level languages hide from you.

Learning assembly is mostly about memorizing - calling conventions, bios interrupts (in real mode), CPU instructions, bit tricks and common algorithms.

[embryo]

Just that doing a bootloader sidetracks you and teaches people to depend on the BIOS and that Protected/Long Mode are bad because the BIOS functions aren't accessible any more.

Yes, there are some side effects. But they are part of deeper understanding of the computer.

And honestly, there are more than enough places in the OS to practice your assembly, for something a bit more modern than Real Mode.

In my OS it is just compiler and a few small pieces of low level code. And the compiler again uses just small piece of assembly for each bytecode. The bootloader is much bigger part of my assembly experience.

The only way I see the assembly can be learned during osdeving without bootloader is an OS written in assembly language.

[Kevin]

Well, I never wrote any bootloader in assembly, let alone a whole OS, and I still think I have a good enough understanding of it. I did have a little contact with it in the form of inline assembly for doing some graphics on DOS, and I did write some Hello-World-level Linux userspace programs in assembly, but I would say that it was really the few assembly pieces of an OS that taught me most of it.