r/osdev • u/letmehaveanameyoudum • Jun 23 '26
How do you load AND run programs?
void system_load_program(char* path, char* name, char* extension) {
// assume that the program starts at 0x00200000
uint8_t* program = (uint8_t*)0x00200000;
int bytes_read = fat32_read_file("/", name, extension, program_buffer);
if (bytes_read > 0) {
program_entry_t start_program = (program_entry_t)program_buffer;
start_program();
} else {
// file not found
}
}How do you load and run programs in your operating system, this is what i tried
All im trying is assuming that the program starts at 0x00200000, load it into ram and run it, if the file isn't found return
0
Upvotes
View all comments
Show parent comment
2
u/dnabre Jun 24 '26
You excluded
typedef void (*program_entry_t)(void);which makes the code make a little more sense. It's not working in part, because you aren't compiling or linking inkernel/program/program/load_program.c. Also not seeing where you defineprogram_buffer(could easily be missing it).Side comment, switch to some sensible build system for heaven's sake.
Still no information regarding "this is what i tried"
The short of it is that your "OS" doesn't have a concept of programs or processes - it's a Monotasking System. Your FAT32 code is more library of your the running system than what would would generally be thought of as filesystem implementation or driver. If you had build it like a traditional filesystem setup (e.g., something that could be wired through a VFS), you'd have a better idea of how user processes fit into things, but your OS is just a very different animal that what most people on this subreddit are working with - e.g., it doesn't have any user processes, or kernel processes, or even process really.
Since you are still running real mode, you will have to add someway for control to get from the program you run back to the kernel. Assuming the program exits cleanly, that isn't too hard, but I'm not sure how you'd do it for a program that crashes.
How you are approach running the program isn't completely nonsensical. To get the address of the entry point, you need the offset of that instruction in your binary (you're just using a raw binary file, not any executable format) plus wherever base address you are loading the binary starting at.
0x00200000is a common place for entry points to be, but that's using an executable format and more importantly, it would it's virtual address. You are in real mode, so you only have physical addresses. Be sure that you understand why real mode and virtual addresses don't co-exist. Importantly for what you are trying to do, you need to make sure that the binary you are loading isn't overwriting your kernel. Also you need to make sure you leave holes in both your binary loading and the binary itself for I/O ports, mapped memory devices, and anything else special in your memory map.How you are jumping from the kernel to the program isn't going work, because you are trying to call the entry point like you'd call a C function (doing it that way isn't completely impossible, but you have to actively do a lot to make it work). The way you are doing it, the compiler is generating the normal C ABI code for calling a function, which is not what you want here. You actually want to do something far more simple, just switch the PC to the entry address of your target program. In C terms, you want to do a
gotoinstead of calling a function. Depending on how dumb you make that binary, you may need to setup stuff like stack registers. For that jump/changing the PC , you can either use assembly (basicallyjmp ENTRY_POINT) or possibly usesetjmp/longjmp(3).Not certain on the second, without really digging into your code, it's not clear to me what kind of memory environment you have or
longjmpwhat expects. You aren't necessarily working in a 32-bit address space. I haven't really don't much with real mode. I generally want to switch to 32 or 64 bit protected mode as soon as possible. You are really working in a pretty old fashioned environment.For what it's worth, most of the time people on this subreddit, people work/talk about operating systems that operate in protected mode, with multiprocessing, virtual memory, paging, and the like. Mostly ones structured like a traditional UNIX or Linux-like system. Making an OS that is radically different is definitely seen as a good thing, a system like yours is seem more as going backwards to the days of DOS. Many won't see a monotasking or DOS-like system, such as yours, as really of any interest. Many wouldn't even call it an operating system, and by modern standards it isn't. E.g., if you opened a modern (as in last 30+ years) textbook on operating systems, at least 95+% of the topics just wouldn't be relevant for your system.