OSDev.org

Not sure if this is supposed to be in OS Design & Theory or General Programming forum, but I try here first.

I often find that operating system programming is quite a lot different from normal application programming. It can be summed up as follows.

OS programming vs normal programming:

• Much more often chicken and egg problems
• Much more pointer arithmetics vs applications almost never
• More often have to go outside type safety
• Order of initialization much more important
• Often simpler primitives (in case of C++)
• Static allocation a virtue, application programming using "new" or "malloc" not really more common.

Often with application programming you can program much without paying much attention. Your C++ course will work here. OS programming on the other hand you are outside the normal and you have to break the law, figuratively speaking.

What do you think? Do think that OS programming feels similar to application programming? Anything else that you can think about that I haven't brought up?

for me, modern os programming is perfectly similar to 3d computer game programming.

1. i used the slightly modified software renderer with sprite handler to do the gui engine in the OS
2. the challenges were very similar:
3. you have to call some very obsolote and yet simultanously ultramodern hybrid hardware through obscure protocols and get it working in the way they complitely unfit for your high-level goal
4. you are on your own, you walking in the joungle without any guidence
5. testing smaller chunks and smaller units alone will not help you to find the bugs
6. very hard to predict what the users actually want
7. hard to predict what configurations the users will run it
8. hard to predict what bugs will occur on various systems
9. general community members falling into the same traps: for example, too much focusing on something alone, or trying to enforce some modern and complex conceptions just based on they personal ideology instead of focusing something to be finished
10. results very big code that is very hardly to modularize or separate
11. a lot of challenges every day, where you have to invent all solutions within minutes. you dont have to time to think on them properly, so sometimes you can end up using non-optimal and buggy solutions infesting your work
12. general people and programmers with lower knowledge usually think that writing a 3d renderer or an operating system is something holy grail, which is undoable, meanwhile its not so hard, just the masses are dumb
13. there are millions of people who have no clue, but they are agressively expertising them both, and they think if the heard from ,,antialiasing'' or ,,protected mode'' actually makes them some kind of skillfull expert in anything
14. when the whole thing becomes real, the theocretical speed falls down brutally
15. you need to support very similar tasks: for example, bmp loader for image display, wav loader for sound, panels to display messages
16. both a game and an os sits on an inifine loop, and it is very hard to idle them
17. no matter how hard you try, there will be still plenty of devices left with no proper support
18. you may need somekind of programming language or scripting language inside your system
19. you cant generally ask people if you are in trouble - nobody will have a clue what are you talking about
20. for a complicated os or game, you can simply end up with 50-60k lines, or even more. does not matter how hardly you are trying to keep the code simple.
21. if you want proper results, you can do it only in REAL programming languages, like C. this makes the scriptkiddos frustrated and jealous on you.
22. bugs are usually not trivial to bait, even if you have the conditions to trigger it
23. simplier solution is best solution
24. you will be never satisfyed with the results
25. everybody think he could write better, if he groups up with 30 friends with world-beater ideas (and suddenly no one in the team is an actual programmer with any skills)

OSwhatever wrote: OS programming vs normal programming:

• Much more often chicken and egg problems
• Much more pointer arithmetics vs applications almost never
• More often have to go outside type safety
• Order of initialization much more important
• Often simpler primitives (in case of C++)
• Static allocation a virtue, application programming using "new" or "malloc" not really more common.

those problems are heavily fought in programs that :
* have complex functional modelisation. You dont know where to start.
* Pointer arithmetic is a core problem of memory allocators. It is encountered also in lock free structures. Or i-starve-memory things like Xor linked lists
* Order of initialization matters everywhere. Especially in huge systems with big inertial state. Try game mods for example.
* simpler primitives are meant to standardize stuff. Yoh will see them around each norm

IMHO Os deving big "problem " is, an OS does not solve one problem. Allow software to solve problems. That problem is also a turing general purpose language compiler problem.

[*]Much more pointer arithmetics vs applications almost never

In C++, it's often preferred to generalize pointers to iterators and think of terms of ranges. It cuts down on the amount of casting and arithmetic that needs to be done. Example:
compared to:
There's nothing preventing this approach being used in C although I don't see it too often.

remyabel wrote:compared to:

Code: Select all

auto begin = reinterpret_cast<multiboot_tag_mmap*>(tag);
auto end = begin->entries + (tag->size / begin->entry_size);

for (auto it = begin->entries; it != end; ++it) {
    auto entry = reinterpret_cast<multiboot_memory_map_t*>(it);

Compared to