OSDev.org

Hooray! I have released the first version of Triodium OS, v0.1 ALPHA! This version only does a few things:

• 1: It loads the IDT at 0x10000FF
  2: It remaps the PIC to 0x20-0x27
  3: Enables interrupts

Here is a screenshot of Triodium OS v0.1 ALPHA running:

Your code base is a mess. You include .c files left and right, your headers have no include guards, you don't use abstractions, most of it is copied verbatim from the tutorials on the wiki, you use inconsistent styles (especially for the things you copied over), your build script makes no sense, and the code code is of very low quality. People on this forum have been recommending that you take the time to learn C. You may think you are making progress but you aren't and will get stuck very soon. I really recommend you follow their advice and then get back to your project.

Why do you upload files via GitHub's web interface instead of uploading them by syncing your git repo?

Love4Boobies wrote:Your code base is a mess. You include .c files left and right, your headers have no include guards, you don't use abstractions, most of it is copied verbatim from the tutorials on the wiki, you use inconsistent styles (especially for the things you copied over), your build script makes no sense, and the code code is of very low quality. People on this forum have been recommending that you take the time to learn C. You may think you are making progress but you aren't and will get stuck very soon. I really recommend you follow their advice and then get back to your project.

"your build file doesn't make sense"

It's for Windows, and assumes qemu is in your path. It's not a .sh or a makefile.

Roman wrote:Why do you upload files via GitHub's web interface instead of uploading them by syncing your git repo?

beacuse my git doesn't show you how to connect to your repo after the first time. and now i have to use the web interface.

I'm working on a new version (i realized the loading IDT thing is not even valid, sorry, also adding more features, obviously.).

I think that you will do everyone a favour if you were to stop posting every silly mistake that you make. It would also help with any ambitions that you might have to get a job working with computers one day.

Try learning C programming, learning some debugging techniques, reading the documentation, and working at a simple keyboard handler that uses hardware interrupts. Don't post here when you get it wrong but work out what you are doing wrong by yourself. Keep at it until your keyboard handler works without asking others to do the work for you and you may, just may, be on your way to writing a simple operating system. You could even start by just implementing a simple timer-tick routine. Use it to print characters to the screen, something like that. Make sure that you understand first what you want to do and what every line of code that you write does.

Printing messages to the screen saying that you have enabled interrupts, when you haven't, is not an operating system.

NunoLava1998 wrote:It's for Windows, and assumes qemu is in your path. It's not a .sh or a makefile.

You can use actual build systems (makefile-based or not) in Windows as well. Even if your project is small enough that you don't care about rebuilding modules that haven't changed since the last build, why does your batch script do both building and emulation? I won't even get into implementation issues like the path hack.

NunoLava1998 wrote:

Roman wrote:Why do you upload files via GitHub's web interface instead of uploading them by syncing your git repo?

beacuse my git doesn't show you how to connect to your repo after the first time. and now i have to use the web interface.

Here's a good (free) introduction to version control. It covers several tools, including git, for some of the more common tasks. More advanced topics like submodules, resetting, rebasing, etc. are not covered but it's still a good starting point.

NunoLava1998 wrote:I'm working on a new version (i realized the loading IDT thing is not even valid, sorry, also adding more features, obviously.).

My point wasn't that you did a bad job and should try harder. My point was that you would do a better job effortlessly if just you took the time to find out the things you don't know: a few things about upstream prerequisites, design patterns, and the tools you're using and you'd be ready to actually work on your projects.

As iansjack suggests, being self-reliant is one of the more important things about being an engineer. A little literacy and willingness is the difference between a script kiddie and a software engineer.

Love4Boobies wrote:most of it is copied verbatim from the tutorials on the wiki

I'm especially a fan of this comment in defs.h

The way i could determine interrupts weren't working were by doing a int $0. Which didn't work, as it kept triple faulting.

I just watched "The Giver" the other day. I think you got their use of the word release correctly.

alexfru wrote:I just watched "The Giver" the other day. I think you got their use of the word release correctly.

I never watched that movie.

A tip with your build file, you don't have to change directory all the way to qemu's install location to run it, you can just run qemu from the current directory. It'll save you having to copy over your kernel into a system folder every time you build as well. And it means you don't need admin access to test out your kernel. As others have mentioned, you may want to split your build file into at least dedicated scripts for dedicated actions, even at this early stage, since it makes it's a little misleading to anybody reading your code that "build.bat" does more than just build. (Although the most sensible option would be to adopt a proper build system as soon as you have more than few object files being compiled. Or, you could make your own build system if you feel like it's something you want to do.)

On a related note, please at least make some kind of effort to show you didn't directly copy almost everything from the wiki, your "build script" still makes a kernel called "myos.bin". You've even come up with a name (2 in fact!) for your kernel / project, why not make use of that shiny new name and hide the fact that you blatantly copied that part out of bare bones without any thought to what it did. Showing people what you've done is often rewarding, especially if you're proud of reaching a personal milestone, but it paints a bad image when your big achievement is "I pasted in some faulty IDT/GDT stuff and maybe managed to make it compile." A little bit of effort and patience goes a long way. And even if you feel like "Ignoring the Haterz" (I'm not saying you are, but you might be giving off that impression with the way you respond), people will become less likely to help and more likely to insult and jest you in the future if you make yourself look a fool.

In any case, good luck with getting your GDT and IDT to work, and congrats on figuring out how to properly process newlines on your terminal code. A little more self problem-solving and you'll soon be on your way.

- Mikumiku747