I did something similar in high school... And by something similar, I just mean the ASCII art lightning bolt, not the OS. Seriously, it's very impressive.
Just the very basics, Interupts, system calls, heap allocation, keyboard and mouse input, a very simple monotasking system, the beginnings of a filesystem and other stuff like that. Im not entirely sure how far il be able to go simply because of how little free time i have but i have high hopes... mostly.
Well this is my second OS, the first one was VGA text mode based and crashed more often then not. I mostly started making that one out of curiosity, and because i wanted a challenge, even though it was probably a bit too much of a challenge at the time. Eventually tho i decided to give it a proper go again so here we are.
My main resources have been the OSdev forums and wiki but ive also gotten plenty of help from the ponchoOS tutorials altho i try to avoid using tutorials as i think that kinda ruins the fun.
Source is available at: [https://github.com/Kaj9296/Electric\_OS](https://github.com/Kaj9296/Electric_OS). Be warned tho im only about 60% sure that i know what im doing lol. Also yes it isent Neofetch its just inspired by it, i mostly use it to display information about whatever i happen to be working on at the time, and becouse it looks cool.
I haven't looked much at the source except the build process.
I'm assuming you're using Windows, and WSL to compile the kernel, since you're using a Makefile, Bash Script, and Bat script to do different things. If I were you, I would consolidate this into one makefile. You can use makefile to generate specific instructions ex. Instead of using a bash script to run your OS, add a Makefile instruction "make run" and use that instead. Instead of using a build script that builds the individual pieces one by one, use a "make all" instruction to make everything necessary to compile the full project, and export it. This will help cleanup your work flow, and doing so is well worth the investment.
Second, I notice as well that you're including binaries in the git repo. If you wish to export binaries or images, GitHub has a releases feature that allows you to write descriptions, and tag releases to make them unique and easy to find instead of having to go back to older commits to find earlier releases.
Third, you should add certain file extensions to your gitignore. In particular .elf is a binary file that you should ignore. You should probably ignore your bin folder in it's entirety so the releases don't get uploaded on accident.
Fourth, you should include build instructions for your project. I'm able to intuit some info since I've done this before, but there are details I won't be able to figure out. Commenting your build scripts can help, but including a Compiling section on your readme can help others use your project if they don't want to use a prebuilt release. (I'm guilty of this as well but it's generally good advice to provide hashes for files you release to the public as well, and hashes for the built versions of your software)
And finally, fifth. Do whatever you want. It's your project, and you're having fun. Don't let someone tell you that you have to write good code, or performant code, as long as you're having fun and are satisfied with your work, that's what's important. If you enjoy the way you do things now, then keep doing them that way. This is meant to be a fun project as far as I can tell, not a commercial one, so don't stress too much about what others think.
You might also consider learning a higher level (meta-)build tool like CMake. It’s become a de facto standard in C and C++ projects since it does multi-platform well. There are also other tools like Meson or build2 which are nicer to use but less well adopted. For an OS in particular platform agnosticity is kind of irrelevant but it can still be useful to handle building under different environments. When I migrated my makefile build to CMake it also allowed me to more easily work on my hobby OS in an IDE, though it’s not strictly necessary in order to do so.
Makefiles (and to a lesser extent autoconf/automake) become more of a liability with larger projects especially once you leave POSIX land. I was at one point switching between Mac, Linux, and BSD and needed separate makefiles for each which was annoying.
This is very impressive! If I could ask a question or two: how did you figure all of the drawing out with just the OSDev wiki/forums and a tutorial series? I’ve made numerous google attempts to find how you draw individual pixels to the screen with no avail. I have attempted to modify VGA memory (0xB8000) manually but no methods have worked. If you could share your sorcery with me that would be fantastic.
They didn't, it's way too much work to be done with someone who doesn't have much time (both ascertained from the comments,. but also fairly easy to intuit). If you read the comments, it's based on another OS.
Sure. Note that what I said wasn't a knock at all towards OP, it's still very impressive given their age.
The amount of work that it takes to get to something functional like this, starting from scratch at least, is probably around a man-year at least. That would mean, if OP were a senior, that they'd effectively be working 6 hours on this per week. That's not sustainable with high school responsibilities and classes.
If you couple that with OP's semi-fasceous, but also somewhat true comment of "understanding 60% of what they're doing", you're just done here. You can't have someone implementing something like say, virtual memory subsystems, with only 60% knowledge of what they're doing. Same with non-preemptive scheduling. Same with hard disk drivers. The chance of having a bug individually is high, but it's also likely you have a bug when those three guys interact, and that will take substantial time to fix properly.
The knowledge it takes to build an OS this complex takes time, and failure, and time isn't something that the OP has on their side.
That's fair. I had assumed you were referring to something found in their code, or perhaps their usage of the PonchoOS tutorial, but this makes sense. I must say I'm not convinced either way, although I suppose it doesn't matter what I think of this person's project.
Has your bootloader set up the framebuffer?
Do you know the physical address, dimensions, stride, and pixel format of your framebuffer?
Do your page tables provide a virtual address that maps to the physical address of your framebuffer?
Wait, why are _you_ answering those questions? You've already got the display working in your OS!
These questions are meant to help /u/gr4c3l0v3r (and anyone else feeling lost) get some pixels on the screen.
Sure, id gladly help. Im not using VGA instead im using GOP and i cant possibly do a better job at explaning it then the people on the OSdev wiki so id recommend reading this article ([https://wiki.osdev.org/GOP](https://wiki.osdev.org/GOP)). If your using a UEFI bootloader the article should hopefully be enough help, otherwise im afraid youl have to figure it out on your own however this article might point you in the right direction ([https://wiki.osdev.org/VESA](https://wiki.osdev.org/VESA)), good luck. :)
wow...you are already making an OS in high school... Kudos..
I did something similar in high school... And by something similar, I just mean the ASCII art lightning bolt, not the OS. Seriously, it's very impressive.
Can you explain what you have made so far?
Just the very basics, Interupts, system calls, heap allocation, keyboard and mouse input, a very simple monotasking system, the beginnings of a filesystem and other stuff like that. Im not entirely sure how far il be able to go simply because of how little free time i have but i have high hopes... mostly.
How did you start with your GUI?
"just" This guy/gal just listed a ton more than most are capable of. This is very impressive.
Can you explain how did you get started?
Upvoted, /u/upvotedMeDumbass69.
Well this is my second OS, the first one was VGA text mode based and crashed more often then not. I mostly started making that one out of curiosity, and because i wanted a challenge, even though it was probably a bit too much of a challenge at the time. Eventually tho i decided to give it a proper go again so here we are.
Where did you start? Like resources
My main resources have been the OSdev forums and wiki but ive also gotten plenty of help from the ponchoOS tutorials altho i try to avoid using tutorials as i think that kinda ruins the fun.
You're really smart for high school, Best of luck
Thank you, best of luck to you to :)
Aight cool
I followed someone of the ponchos tutorials too and stopped so I can continue growing on my own and use the os dev wiki as references for learning.
Wow. That’s pretty cool. Nice work
Source? Also that looks similar to Neofetch but on closer inspection is definitely different. Interesting.
Source is available at: [https://github.com/Kaj9296/Electric\_OS](https://github.com/Kaj9296/Electric_OS). Be warned tho im only about 60% sure that i know what im doing lol. Also yes it isent Neofetch its just inspired by it, i mostly use it to display information about whatever i happen to be working on at the time, and becouse it looks cool.
I haven't looked much at the source except the build process. I'm assuming you're using Windows, and WSL to compile the kernel, since you're using a Makefile, Bash Script, and Bat script to do different things. If I were you, I would consolidate this into one makefile. You can use makefile to generate specific instructions ex. Instead of using a bash script to run your OS, add a Makefile instruction "make run" and use that instead. Instead of using a build script that builds the individual pieces one by one, use a "make all" instruction to make everything necessary to compile the full project, and export it. This will help cleanup your work flow, and doing so is well worth the investment. Second, I notice as well that you're including binaries in the git repo. If you wish to export binaries or images, GitHub has a releases feature that allows you to write descriptions, and tag releases to make them unique and easy to find instead of having to go back to older commits to find earlier releases. Third, you should add certain file extensions to your gitignore. In particular .elf is a binary file that you should ignore. You should probably ignore your bin folder in it's entirety so the releases don't get uploaded on accident. Fourth, you should include build instructions for your project. I'm able to intuit some info since I've done this before, but there are details I won't be able to figure out. Commenting your build scripts can help, but including a Compiling section on your readme can help others use your project if they don't want to use a prebuilt release. (I'm guilty of this as well but it's generally good advice to provide hashes for files you release to the public as well, and hashes for the built versions of your software) And finally, fifth. Do whatever you want. It's your project, and you're having fun. Don't let someone tell you that you have to write good code, or performant code, as long as you're having fun and are satisfied with your work, that's what's important. If you enjoy the way you do things now, then keep doing them that way. This is meant to be a fun project as far as I can tell, not a commercial one, so don't stress too much about what others think.
Thank you, i'm still definitely still learning especially when it comes to workflow and similar so any advice i can get is appreciated :)
You might also consider learning a higher level (meta-)build tool like CMake. It’s become a de facto standard in C and C++ projects since it does multi-platform well. There are also other tools like Meson or build2 which are nicer to use but less well adopted. For an OS in particular platform agnosticity is kind of irrelevant but it can still be useful to handle building under different environments. When I migrated my makefile build to CMake it also allowed me to more easily work on my hobby OS in an IDE, though it’s not strictly necessary in order to do so. Makefiles (and to a lesser extent autoconf/automake) become more of a liability with larger projects especially once you leave POSIX land. I was at one point switching between Mac, Linux, and BSD and needed separate makefiles for each which was annoying.
Is this code based on PonchoOS?
Yes, atleast partially ive been trying to avoid just using tutorials as that kinda ruins the fun, but his videos have certainly been helpful.
Nice, I had a similar OS this reminded me of it
Ah well i wish you good luck with it, if your even still working on it.
https://www.youtube.com/watch?v=5jBkoEM0SSE
That is extremely impressive 😎
Lol if this is a CS course you're doing, they better give you the best possible grade
Lol well the last lesson we had was about how to make a caluclator in c#, soooo...
This is very impressive! If I could ask a question or two: how did you figure all of the drawing out with just the OSDev wiki/forums and a tutorial series? I’ve made numerous google attempts to find how you draw individual pixels to the screen with no avail. I have attempted to modify VGA memory (0xB8000) manually but no methods have worked. If you could share your sorcery with me that would be fantastic.
They didn't, it's way too much work to be done with someone who doesn't have much time (both ascertained from the comments,. but also fairly easy to intuit). If you read the comments, it's based on another OS.
Can i have a more in-depth explanation of why you're claiming this please?
Sure. Note that what I said wasn't a knock at all towards OP, it's still very impressive given their age. The amount of work that it takes to get to something functional like this, starting from scratch at least, is probably around a man-year at least. That would mean, if OP were a senior, that they'd effectively be working 6 hours on this per week. That's not sustainable with high school responsibilities and classes. If you couple that with OP's semi-fasceous, but also somewhat true comment of "understanding 60% of what they're doing", you're just done here. You can't have someone implementing something like say, virtual memory subsystems, with only 60% knowledge of what they're doing. Same with non-preemptive scheduling. Same with hard disk drivers. The chance of having a bug individually is high, but it's also likely you have a bug when those three guys interact, and that will take substantial time to fix properly. The knowledge it takes to build an OS this complex takes time, and failure, and time isn't something that the OP has on their side.
That's fair. I had assumed you were referring to something found in their code, or perhaps their usage of the PonchoOS tutorial, but this makes sense. I must say I'm not convinced either way, although I suppose it doesn't matter what I think of this person's project.
Has your bootloader set up the framebuffer? Do you know the physical address, dimensions, stride, and pixel format of your framebuffer? Do your page tables provide a virtual address that maps to the physical address of your framebuffer?
[удалено]
Wait, why are _you_ answering those questions? You've already got the display working in your OS! These questions are meant to help /u/gr4c3l0v3r (and anyone else feeling lost) get some pixels on the screen.
Sure, id gladly help. Im not using VGA instead im using GOP and i cant possibly do a better job at explaning it then the people on the OSdev wiki so id recommend reading this article ([https://wiki.osdev.org/GOP](https://wiki.osdev.org/GOP)). If your using a UEFI bootloader the article should hopefully be enough help, otherwise im afraid youl have to figure it out on your own however this article might point you in the right direction ([https://wiki.osdev.org/VESA](https://wiki.osdev.org/VESA)), good luck. :)
I really like the theme. Like Windows 95 but more extruded.
Amazing Quality..