no-OS | Software drivers in C for systems

C is older than C++ but you are right that it is similar to C++ because it is compiled to binary code. When you write a C/C++ program you compile it to binary using a compiler.

Today, most desktop computers run on a variant of x86 architecture processor which started with Intel's 8086. The x86 processors are well documented. I never implemented an assembler so I can't tell exactly how to go from high level code (C/C++) to binary but I can link to the documentation which tells you how to do that. Here you have the download link for the Intel software developer manual: https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html. Appendix B of volume 2 of this download link has the instruction encoding explanations. Here's a picture of the format of an instruction:

On x86 (and all other architectures like ARM), the instructions have a certain conventional encoding that the compiler knows and that it will use to compile your high level code to binary code. Today, when you write an OS, you use a screen and a compiler and other tools readily available to compile to binary code. With gcc/g++ on Linux you have the freestanding and static flags which allow to include all the code in your final executable and to make sure the code is self-standing.

If you write code on Linux and want to develop an OS, you need to know C/C++ quite well because you cannot use anything which relies on the standard libraries like printf() or cout. This means that you are left with the basic C/C++ like pointers (which are very important) and function calls and other stuff. You need to know quite well how the language works to control memory properly and to be able to not use stuff of the language which depends on the presence of an OS.

The .exe file is a conventional format which contains binary code. The Linux equivalent of a .exe file is a .elf file. There's nothing wrong about compiling an OS to a .exe file (or a .elf file) and parsing that file from a bootloader to jump to its entry point. The difference is that you need to tell your compiler and you need to write a program which doesn't rely on the presence of an OS to work (because you are the one who writes the OS). You are thus left with the basic C/C++ like pointers and structs. With C++ you can use classes as well because they are compiled to function calls.

For freestanding C/C++ code to work, you need to set up a hardware stack with the RSP register of the CPU. This will allow your code to call functions (other than main()). Freestanding C/C++ code relies on the presence of a stack but nothing else to work properly because all high level lines of code that you write will be compiled to CPU instructions which don't rely on anything else. If you wanted, you could even forget the stack and do everything in the main function and forget about functions. You would thus be left with pointers and structs. I think a minimum is to have functions so that you can organize your code properly. Linux is really just a freestanding, statically linked C program compiled to a .elf file and compressed with gzip. Linux follows the multiboot specification which tells how to boot it. It means that, to write Linux, the developers used only pointers, structs and functions. Pointers are compiled to memory fetch code which is one instruction in itself. Structs are compiled to data. Functions are compiled to relative jumps (short jumps), pop and push instructions (using the stack for the arguments). This is pretty much it.

You can definitely write your own OS because otherwise how would Microsoft develop Windows. To write an OS, you need to use tools at your disposition and compile freestanding and static code. Then you need to write a custom bootloader like a legacy bootloader in assembly or a UEFI bootloader in C compiled with specialized tools like EDK2. EDK2 is a compiler for UEFI bootloaders. Once you have an EFI app, you can launch that app and parse a statically linked freestanding .elf file (or .exe file) from the app. Then you can jump to the entry point of that .elf file. You can use the UEFI environment to load the .elf file from the hard disk.

Remember when you last installed an OS. You basically use a tool like Media Creation Tool from microsoft to write a small OS on a USB stick. Then you choose that USB stick to boot from the BIOS and you install the OS to an hard disk. Developing and OS is the same. You use an existing compiler and existing OS to write custom OS code. Then you write that code to a USB stick (or an hard disk) and then you test the code. A better option is emulation. You do that using specialized virtualization software like QEMU or Virtual Box to test your custom OS.