4 ms·

I'd love to build a non-trivial operating system, but all I've made thus far has been written in assembler and extremely minimal. If one wanted to bootstrap an

by cmallen 17y ago

I'd love to build a non-trivial operating system, but all I've made thus far has been written in assembler and extremely minimal. If one wanted to bootstrap and get an OS running quickly, I wonder what the best approach or language would be? Renraku is interesting just for the sake of the horror of building something on Mono/.NET. I just wonder what kind of OS would result if you applied new-age MVC and rapid dev principles to the design of a new OS. Would the concept of a kernel even be totally relevant?

jacquesm 17y ago
I've built a small OS, multitasking, window manager, the works. It took me two years of my life but I learned more than I ever would have doing something else. It's good to have supportive people around you when you attempt something like this, and it also helps to have an old guitar push button wired up to your reset switch until you get it booting properly. You'll be resetting your machine lots of times. I used the minix filesystem because it was very simple and I could fit the code to load the configuration and boot files in to a small boot loader. I used an old 16 bit compiler for that part, PCs do not generally boot up in 'protected mode', so your first stage is spent on moving stuff from one side of the line to the other, then finally make the switch and continue from there. The stages, iirc were: - master boot loader - partition boot loader - file system boot loader (16 bit) - system tasks (fs, idle, task (the scheduler) and a console driver running a shell) Because the OS used message passing it was relatively easy to build and test the bits outside of the working os, after all as long as the messages were having the desired side-effects it was all good. I used borland turboc for the 16 bit file system aware boot loader, and DJGPP for the boot strapping to a self-contained os. As soon as that worked and I was able to get GCC running on the other side I focused on recompiling everything from scratch until the binaries matched exactly with the ones I had been making in cross development mode, after that things went a lot faster. That first stage took several months, I don't remember cursing so much in my whole life. I wouldn't trade that time for anything though, it was better than any other programming experience before or after. The OS I wrote was a functional equivalent of QnX, at the time only available for the 286, and I very much wanted a 386 version. Several others had a hand in there, Marcel Wouters completely re-wrote the console driver, and a large part of the window manager was based on a list package that was written by another friend. For networking I used the ne2000 driver from the freebsd project with a bunch of tweaks to get it to work as a user process. The hardest part of the whole thing was to get a hard-realtime response on interrupts in user processes.
- cmallen 17y ago
  It took me about ~2 months to get to an OS that could boot from an MBR, get into a raw kernel that only used memory space (no filesystem or persistence, this was intentional), and had a basic prompt running in kernel mode. What I really want to return to is what I call dual-mode programming. Taking the older Apple computers and the Commodore 64 as an example, they were comparatively speaking an absolutely joy to program on. You started with BASIC and then eventually progressed towards manipulating memory locations in asm to draw graphics and make whatever you wanted. Wasn't because the programming languages used were anymore powerful (asm and BASIC? Come on...), it was because they were frankly better designed as far as "whole systems" go. Functionality isn't exposed the way it used to be. It's difficult to put anything functional together on a computer these days if you're a rank beginner. Sure, I can slap something together in Python, but that's because they're walking right around the system's complexity by living in their own little world (the interpreter and the .py libraries). I guess I'm hoping for what no one really cares about anymore. They just want to add more layers of abstraction to compensate for their own short-sightedness and poor discipline.
  - jacquesm 17y ago
    I so agree with you, it's hard to put it in to better words so I'll leave it at that. thanks!
- kmavm 17y ago
  "have an old guitar push button wired up to your reset switch until you get it booting properly" Pro-tip: use a virtual machine.
  - cmallen 17y ago
    That's what I did, initially. I don't know how long ago he's talking though.
    - jacquesm 17y ago
      // UNITE jacques' operating system // (C) 1993 Mattheijs' Computer Services 17 Years ago.

by cmallen 17y ago

jacquesm 17y ago

I've built a small OS, multitasking, window manager, the works. It took me two years of my life but I learned more than I ever would have doing something else. It's good to have supportive people around you when you attempt something like this, and it also helps to have an old guitar push button wired up to your reset switch until you get it booting properly. You'll be resetting your machine lots of times. I used the minix filesystem because it was very simple and I could fit the code to load the configuration and boot files in to a small boot loader. I used an old 16 bit compiler for that part, PCs do not generally boot up in 'protected mode', so your first stage is spent on moving stuff from one side of the line to the other, then finally make the switch and continue from there. The stages, iirc were: - master boot loader - partition boot loader - file system boot loader (16 bit) - system tasks (fs, idle, task (the scheduler) and a console driver running a shell) Because the OS used message passing it was relatively easy to build and test the bits outside of the working os, after all as long as the messages were having the desired side-effects it was all good. I used borland turboc for the 16 bit file system aware boot loader, and DJGPP for the boot strapping to a self-contained os. As soon as that worked and I was able to get GCC running on the other side I focused on recompiling everything from scratch until the binaries matched exactly with the ones I had been making in cross development mode, after that things went a lot faster. That first stage took several months, I don't remember cursing so much in my whole life. I wouldn't trade that time for anything though, it was better than any other programming experience before or after. The OS I wrote was a functional equivalent of QnX, at the time only available for the 286, and I very much wanted a 386 version. Several others had a hand in there, Marcel Wouters completely re-wrote the console driver, and a large part of the window manager was based on a list package that was written by another friend. For networking I used the ne2000 driver from the freebsd project with a bunch of tweaks to get it to work as a user process. The hardest part of the whole thing was to get a hard-realtime response on interrupts in user processes.

cmallen 17y ago
It took me about ~2 months to get to an OS that could boot from an MBR, get into a raw kernel that only used memory space (no filesystem or persistence, this was intentional), and had a basic prompt running in kernel mode. What I really want to return to is what I call dual-mode programming. Taking the older Apple computers and the Commodore 64 as an example, they were comparatively speaking an absolutely joy to program on. You started with BASIC and then eventually progressed towards manipulating memory locations in asm to draw graphics and make whatever you wanted. Wasn't because the programming languages used were anymore powerful (asm and BASIC? Come on...), it was because they were frankly better designed as far as "whole systems" go. Functionality isn't exposed the way it used to be. It's difficult to put anything functional together on a computer these days if you're a rank beginner. Sure, I can slap something together in Python, but that's because they're walking right around the system's complexity by living in their own little world (the interpreter and the .py libraries). I guess I'm hoping for what no one really cares about anymore. They just want to add more layers of abstraction to compensate for their own short-sightedness and poor discipline.
- jacquesm 17y ago
  I so agree with you, it's hard to put it in to better words so I'll leave it at that. thanks!
kmavm 17y ago
"have an old guitar push button wired up to your reset switch until you get it booting properly" Pro-tip: use a virtual machine.
- cmallen 17y ago
  That's what I did, initially. I don't know how long ago he's talking though.
  - jacquesm 17y ago
    // UNITE jacques' operating system // (C) 1993 Mattheijs' Computer Services 17 Years ago.