OSDev.org

Hello,
I have worked on many OSes this year. I started off with a microkernel based OS, and then after a short time realized that it was poorly designed and relied on tutorials to much. I started making another OS after that, and wanted it to be Unix like. That was not a good decision, as I had little Unix experience and had been a Windows person up to that point. So when I realized it was not Unix by a long shot, I started making a DOS OS, followed by a Windows clone, followed by another microkernel OS where I came close to getting it right, then when I realized that I needed to understand multitasking more, I started working on another OS. Then I realized that one was poorly designed, so I started working on a Unix clone. Luckily, I am much more seasoned in Unix now. I hope this project works out! Anyone else keep recoding there OS? Anyone know why it happens?

For a long time, I couldn't even start coding because I couldn't stop redesigning! Right now, I'd like to be gaining experience with Plain English Programming, but it's Windows-only and my desk is so bad, I've taken to coding on my tablet where I have multiple versions of Forth. I keep telling myself to get back to PEP but it's got to the point where I have a nice lot of 'userspace' code on the tablet and I almost have a BIOS-based 16-bit Forth on a laptop. (It'll run under DOS initially, but even under DOS it'll use a partition for blocks.) But... again... I'm starting to think about design details such as the format of string references. Forth's native string reference is start address; length, but I'm seeing the benefits of start address; end address[+1]. It's easy to convert between them so I shouldn't worry.

As with any project, you need to have a very clear goal in mind, if you don’t have that then everything you do will just be academic.

That is not to downplay the importance of academic research, you probably learnt far more from writing all these than you ever could with just a single project

bloodline wrote:That is not to downplay the importance of academic research, you probably learnt far more from writing all these than you ever could with just a single project

This is true. From Plain English Programming I learned about riders and later applied them to parsing Forth. They seem to be simultaneously simpler than the usual Forth input parsing and overkill for Forth. I also picked up ideas about data structures in text editing from various places, and I'm finally using them in my 3rd or 4th text editor. Can't forget experience with different interfaces in text editors, command lines, or everything, really.

bloodline wrote:As with any project, you need to have a very clear goal in mind, if you don’t have that then everything you do will just be academic.

That is not to downplay the importance of academic research, you probably learnt far more from writing all these than you ever could with just a single project

That is very true, I learned quite a bit with all those projects! I think I have a clear goal now, however. That goal is to take GNU, and all its functionality, just make it much less bloated. For now, I will just make the bootloader and kernel for that project .

Ditch UNIX. It stinks.
Go custom all the way. Reimagine everything.
No point in doing what has been done.

Octacone wrote:Ditch UNIX. It stinks.

Unix is actually quite brilliant. The “everything is a file” abstraction is still a very powerful model.

Go custom all the way. Reimagine everything.
No point in doing what has been done.

And yet I do agree with you, no point doing yet another Unix.

But that’s our choice, if someone wants to make another UNIX then
I say all power to them! Making an OS is a thankless, soul destroying, task... whatever it takes to keep motivated is a good thing.

I am not just reinventing Unix, but re imagining it. The ideas for the kernel somewhat resemble Unix. If I was making a stereotypical Unix, that would be boring . I guess it is whatever you enjoy most!

bloodline wrote:

Octacone wrote:Ditch UNIX. It stinks.

Unix is actually quite brilliant. The “everything is a file” abstraction is still a very powerful model.

Both of these statements are correct. Particularly, reimagining Unix can have good results. I've seen this with Plan 9. Interestingly, as the Plan 9 project was just starting in 1989, one of the team members publically stated, "Unix is not only dead, it has started to smell really bad." However, I think there's room for improvement over Plan 9 too. This is the root of some of my ideas.

If I ever put any effort into my Atari-inspired A8.86, (it's not the idea I like the most,) it'll be something like Unix because the ROM OS of the Ataris which inspired it was. "Everything" was not exactly a file, it was a file-like device. An example of the power of this approach is the Telnet client built in to the Gnu Atari800 emulator. Programs written by people who'd never heard of Telnet can communicate with Telnet servers. Also, the emulator's shared directory facility doesn't have to take over a disk device D1: to D4:, it serves H1: to H4: instead.

nexos wrote:Anyone else keep recoding there OS? Anyone know why it happens?

Not recoding, but I keep banging my head against the same obstacle again and again. I still don't get the basics of writing an UEFI application.

I have written some Asm code for booting Legacy PC. I know the BIOS interrupts well. I can "evacuate" my boot code, print to the VGA text screen, wait for keyboard input, program a timeout, switch to pmode, do simple FAT reads etc. All in BIOS interrupts or general 16bit Asm.

But UEFI is really new for me.

For example: Trying to use GNU-EFI leads to include errors etc. There's always a big "But it doesn't work".

Regarding your recoding: I think it's your personality which defines how you approach programming projects.

And I guess recoding isn't as bad as it sounds. Yes, it sounds like a waste of time, but in fact it's well-invested time IMHO.

Greetings
Peter

I read the title of the article first as "I keep recording my OS!". that would be way more interesting. why people over here, don't record their projects progress and show it on youtube, on a regular basis? at least those, having something to show and decent camera (if we are talking about running on real hw). of course, not all advances are this showable, but at least those that are, could be put there, something like the screenshot thread, but with video and comments by the author.

on topic, no, I do not swing/jump/oscillate between unix/windows or monolithic/micro/nano/exo kernel or something. my problem is allocating the time for making what I want, then get more knowledgeable to implement what I want an efficient way.

@PeterX: There's always something that doesn't work for me too, when using Gnu tools. To some extent, I even had that problem in Plan 9, which is far lighter. If asm is your forte, perhaps you could use asm to make PE format files with UEFI calls. It's probably easier if you have 64-bit Windows to practice on. I'll probably try this with Fasm or Nasm some day.

@zaval: I was just thinking I'd like to see short videos. They'd fit in the screenshot thread, IMO. Long descriptive videos tire me out and confuse me. I know lots of people get on with them, but I'm thinking it would probably be best if the average video is short. Oh and scrolling command prompts are not the easiest things to follow. I was really thinking I'd make video if I got a game working.

@zaval, I know the developer of SerenityOS makes YouTube videos
@PeterX, try foregoing GNU-EFI. Build with just MinGW on Linux, and then copy the headers from GNU-EFI and use those. It works for me.

I have the opposite problem; I keep changing direction before getting anywhere with my OS project, and thus have never really written any code for it at all. I think I need to just sit down and write a more conventional OS design (not necessarily a *nix type design, but one using C - or at least an existing language such as Rust or Go - and following a well-known design plan such as a microkernel rather than something which relies on elaborate language-specific models). I already have a repo set up for this 'Convos' (CONVentional OS) but have yet to do anything with it...

Schol-R-LEA wrote:I have the opposite problem; I keep changing direction before getting anywhere with my OS project, and thus have never really written any code for it at all.

I was doing this for a long time. A couple of features were unchanging, but I kept going off on wild tangents. Eventually I... limited my ambition... I stopped going off on wild tangents, but I kept my language specific model and 2 or 3 main goals. I had to shelve something I did really want: undo everywhere, but my UI and IPC ideas seem achievable enough, my array ideas may be helpful in the long term, and I'm sure I'll be able to work in something like file versioning later. Perhaps you could do the same with some variety of Lisp or another interesting language. I'd just recommend not choosing too pure a functional language or too pure a language of any other model. Some jobs are far easier if you can bend the language model or use another one entirely. These days, I put purity together with properness and elegance as things which look nice and help clarity a little, but I think they're more an indication of humans' limited capacity to understand than of any deep principles. I don't think any of them are worth trying too hard for. In a similar line, have you heard the quip that Common Lisp's loop is so powerful, they invented functional programming to get away from it? I'll never forget it because not too long before I heard it, I'd been trying very hard to choose the right loop for the job. Back then, structure was a big deal, the anti-goto jihad was in full swing and the Proper Way To Write Programs was to use the language's features, not ugly things like break or continue. I believed it all and I tried really hard, but had to give up and accept breaking out of loops; it's so much more practical. I'm amused to find Plain English Programming only has infinite loops with break. It implements counted loops with a "decider" (boolean function) which has a side effect of incrementing the counter, and a compile-time side effect of creating a counter variable if there wasn't one, and yet it's amazingly elegant and clear!