OSDev.org

Hey... I want to learn more about advanced OS development.

I currently know how to print strings, draw graphics to the screen, load sector into memory with INT 13h, wait until key press, reboot with 0xffff:0000, get key from keyboard and set cursor position.

Where would I learn things like push, pop, mov byte, in, out, loading sectors the proper way (like MikeOS), comparing strings and making drivers etc?

If I got a detailed guide, I would really like that.

OSDev.org, or alternatively manufacturer's documentation. Or other osdev sites

I mean advanced. I read most of the documentation on the OSDev Wiki. I'm talking about more with advanced OS development.

Define advanced. Most of what you're saying is very simple.


push and pop are x86 assembly language instructions for manipulating the stack. out sends data to an I/O port. The I/O port would most likely have a device listening to it for commands/data. in does the exact opposite reads from an I/O port.
There's no "proper" way to load sectors. MikeOS AFAIK uses BIOS to load sectors. It's not wrong considering it's a 16-bit OS, but in general you should write a real driver for the disk device you'd like to use. Comparing strings isn't related to OSDev at all. Making drivers is not of any importance if you're using the BIOS in your OS.

I think you should read up more OSDev theory first before trying to do anything in practice.

What you describe in your initial post has not much to do with operating systems. I would rather describe it as bare metal programming. Nothing wrong with that as that what you have to begin with anyway towards an operating system. The definition of an operating system is the handling of the resources in a computer system.

A usual book which commonly used in high schools and universities is "Modern Operating Systems" by Andrew S. Tanenbaum. It's usually a good start.

Using the BIOS to read / write sectors still requires a file system driver to handle files.
Using the BIOS to display characters on the screen still requires a screen device driver to handle formatted output.

Oops, I misread it as device drivers such as hard disk and keyboard.

Your point is valid.
It's just that many spend their time on the low level aspects (which the BIOS handles perfectly well for beginners and enthusiasts)
instead of OS development. It's only 16 bit real mode if you don't extend the BIOS to PM32 or LM64 (currently I'm satisfied with PM32).
The important thing is to actually get something working and have fun. For example I've written both a FAT32 and exFAT "load a short
long file name file from the root directory" of a formatted (either FAT32 or exFAT) floppy disk in real mode 8086 code both of which
fit entirely in a 512 byte boot sector.
Just for the H@CK of it.

Hi,



On a scale from 1 to 10 where 1 is very basic OS development and 10 is very advanced OS development; half of the things you've listed (push, pop, mov byte, comparing strings) are just "programming" and aren't even on that scale.

I'd say that the minimum needed to be on the scale is designing (possibly very crude/simple) functionality (memory management, scheduler, etc) and (possibly very crude/simple) device driver interfaces; and then implementing code (memory manager, scheduler, drivers, etc) that provides the functionality and interfaces you designed. The difference between basic OS development and advanced OS development (or, where you are on the scale from 1 to 10) is in how well designed your functionality and interfaces are.

If you're merely using functionality/interfaces someone else designed and provided (e.g. only using BIOS functions designed by IBM and implemented by firmware developers) then you are not developing an OS and you aren't an OS developer - you're only writing software/applications for an existing OS or environment.



There's:

• a "so basic that it doesn't even count as OS development" way to load sectors (e.g. using BIOS or UEFI services, or Linux or Windows services, or C library functions, to do it for you)
• a basic way to load sectors (e.g. using a simple "storage device driver" interface/abstraction and a simple driver designed to provide that interface/abstraction)
• a more advanced way to load sectors (e.g. an advanced "storage device driver" interface/abstraction, which includes things like device/media auto-detection, asynchronous requests, IO scheduling, fault detection and/or fault tolerance, features like "secure erase", device and/or media insertion and removal, etc)
• a very advanced way to load sectors (where the "storage device driver" interface/abstraction involves original research into new techniques that are not documented anywhere)

Cheers,

Brendan

Agreed!
But how is that different from sending messages to the operating system inside the USB controller or Network Interface Controller.

Hi,



Given that (as far as I know) there has never been an operating system in any USB controller or Network Interface Controller that has ever existed; I'm not sure how to answer your question.


Cheers,

Brendan

Exactly.
This is what I refer to as the "BIOS Operating System" and code written that utilizes the BIOS functionality as "BIOS based programming".
And while it is true that the BIOS by itself really doesn't do anything (other than provide default handlers for hardware events) it's simple
Basic eloquence is that it allows the beginner / enthusiast to "build" something that historically (in "ancient times") was an operating system.
This is the same as the enjoyment of accomplishment of a puzzle completed or a Meccano Set or similar, the user can "build" something
without having to manufacture (a very difficult and unnecessary task for most) the actual parts themselves.

Given that the question was rhetorical (notice the lack of the question mark) no answer is required.
Given that operating system is italicized so as to indicate that it doesn't refer to the formal definition of an Operating System,
but rather the "system which operates" inside the controllers which accepts and processes the supported message interface.
In other words, (actually your words slightly paraphrased) "you're merely using functionality/interfaces someone else designed and
provided (e.g. only using USB or NIC functions designed by engineers and implemented by firmware developers".

Personally, I think a large part of the fun in osdev is specifically learning the details of the pieces of hardware and writing drivers for them. Additionally, if one's goal is to learn, the BIOS approach is almost detrimental to things because it is almost completely obsolete. Plus, most people who come here expect to be able to make something a bit more modern than what the restrictions of the BIOS would allow.

To the OP:
Now that you have the basics down, you will want to step it up, virtual memory management, physical memory management and scheduling are good next steps and are rather well documented.

Hi,



Then it still doesn't make any sense. Obviously the hardware interface provided by any one device isn't comparable to the standardised "driver interface/s" the OS uses as an abstraction to hide the differences between different hardware interfaces.


Cheers,

Brendan