>Technically, a program that runs without an OS, is an OS.<p>It is not. A program that runs without an OS just doesn't need the OS provided services but instead manages everything itself.<p>A perfectly valid program might be:<p><pre><code> #include <avr/io.h>
int main(void)
{
DDRB=255;
while(1)
{
PORTB++;
}
}</code></pre>
If you ever programmed a ROM for a Gameboy or something this should look familiar. The BIOS of those old systems just jumps right into a certain address and all you have to do is make sure your linker is setup properly to put crt0.s there.<p>The Gameboy Advance in particular is pretty fun and simple, I recommend it.
For any "How do I...X?" question involving connecting two pieces of software together in a different way, the first thing I try to do is look at the API(s) that connects them. In the case of a program and the OS, it's the system calls, device drivers, and standard libraries.<p>There have been efforts to provide the capability of running a program without an OS before, but any such effort is going to need to provide the system calls and standard libraries used by the program, and the infrastructure to support it (device drivers, management, etc.). That that point it becomes a mini-OS.<p>An example is Erlang on Xen. Xen is more often run with a guest OS running inside it, and then the program runs within that guest os. The <a href="http://erlangonxen.org/" rel="nofollow">http://erlangonxen.org/</a> folks made Ling (<a href="https://github.com/cloudozer/ling" rel="nofollow">https://github.com/cloudozer/ling</a>), software that enables an Erlang BEAM VM to be run directly on Xen, and thereby run a single Erlang program on Ling.
Saw a talk on Include OS that is a C++ library that allows one to do this
<a href="http://www.includeos.org" rel="nofollow">http://www.includeos.org</a>
For another take on the subject, see "This OS is a bootloader" in PoC||GTFO 0x4:<p><a href="https://www.alchemistowl.org/pocorgtfo/" rel="nofollow">https://www.alchemistowl.org/pocorgtfo/</a><p>There's a sequel in 0x5 that explains how to add a basic form of multiprocessing support.
The Osdev wiki is a great resource on this type of thing <a href="https://wiki.osdev.org/Expanded_Main_Page" rel="nofollow">https://wiki.osdev.org/Expanded_Main_Page</a>
Not directly related to the topic, but I wrote a simple puzzle game that emulates a computer which executes programs directly in the memory and you can modify memory to rewrite running programs. Here's a web-based demo if anyone wants to check it out:<p><a href="https://roguebit.bigosaur.com/" rel="nofollow">https://roguebit.bigosaur.com/</a>
A lot of people here seem to be questioning the usefulness of this, why someone would want to do this, et cetera.<p>Embedded systems are one of the most extremely relevant uses of this today.<p>However, historically, I think my first case of programming without an OS would be ASM development for the Sega Genesis?<p>Another addition is that I saw a comment ‘a program that runs an OS, is an OS.’<p>This is absolutely not true. An Operating System is a multi-faceted, complex piece of software, usually with the capacity to run other pieces of software within it, as well as usually offering high-level API’s to improve ease-of-use for developers to access common functionality, such as playing sound, or displaying images.<p>A ROM for the NES, while a program, is certainly not an OS, and to be very clear, the NES does not have an OS, like I believe the PS4 and XB1 have.<p>It contains a certain number of hardware features that can be accessed and manipulated by low-level software functions.
Would be interesting to hear discussion on why one might consider doing this.<p>My take is that it's most likely just being asked for the theoretical details, and few people would practically benefit, but does anyone think this would be practically useful?<p>Presumably you'd potentially cut overhead from anything you didn't explicitly want happening on the host, but as soon as I start to think about most of the uses typically have, the advantages quickly sink below the disadvantages of having to actually manage everything. It's reminiscent of that person who set out to build a toaster from scratch.
> printf '\364%509s\125\252' > main.img<p>It appears that bash `printf` wraps coreutils printf "with ARGUMENTs converted to proper type first," according to the manual. I guess that's how the "%509s" specifier is able to work without any args.<p>So how does bash `printf` actually determine the proper arg types? Is coreutils printf implemented with hooks that let wrappers fetch the proper arg types without generating an output string? Or does bash `printf` implement its own separate parser for the format specifier?
Very nice post. However I thought it would be about writing programs that could be executed from OS, but OS would be completely unaware that such a program is running. Not sure if that is even possible.<p>I know it’s possible to not use libc or similar, but os is aware of such a program.
Stack Overflow is for very specific questions with very specific answers.<p>You'll get better results for more general questions from a reddit forum.
i always feel these questions are answered to best effort of a person just starting out in the field of os / bare metal programming. there is a whole plethora of information missing in this post crucial to x86/64 early development which will get new programmers of this type into trouble if they don't become aware of it.<p>i'd be careful following such advices. for example this person isn't aware you really need to build a cross toolchain for your OS to compile to your target. on 64-bit there's some more things to take into account about compilers (red-zone?). even if you go all assembly your assembler will probably be an optimising one and shoot you in the back on more than one occasion! Thats just the tool-chain surface issues (deeper ones ignored... like file formats..? binary is fun, but good luck scaling that up to a complex project... bios can't load you up that high in memory and limited amounts...)<p>Next you get to things omitted which on baremetal would cause problems, like no mention of power management and such topics. or even assumptions that your code is loaded at 0x0000:0x7c00 while it could be loaded at that address but via a different CS value, completely screwing you over if you don't flush it immediately on your mbr...<p>Take an example of opengl tutorials. people tell you to write your first polygon because they just managed to do so. They forget to mention to throttle the loop, so you burn out your VGA card rendering 10000000000fps of 1 triangle.... good job!<p>this tutorials are kind of like that. fun to put into qemu which is sort of 'safe' learning and get acquainted but really doesn't do what it says on the box.<p>I'm not against these type of tutorials, i like that more people become interested in this, but really take some time and state the scope of the offered information properly. like this is a bit of clickbait / misinformation which is a shame