KOS-MOS

1) Progressive installations

Thought Process

Shell commands were broken into stages of relevance, only being added when necessary. Most display-related commands were added immediately, with those relating to program execution being added as the project went on. Error handling also needed to be accounted for, as well as solutions to what could have went wrong.

Results

Breaking down the shell commands progressively helped me keep on task. Besides modifying existing commands as needed (say, load or run), I also wrote down exactly what each command needed to do and the syntax for input in the manual, which made debugging easier on the front-end.

2) Broke down into 3 steps

Thought Process

Technically, this is how parts 2 – 4 were structured. But the 1st task was to make sure at least 1 program could execute. Next, juggle 3 programs concurrently. Then lastly 4.

The 1st task had us write out all the necessary op codes to read the program and establish at least some sort of memory limit. Debugging was quite the hassle, since op codes aren’t the easiest thing to tell where something went wrong. To remedy this, we had a single step protocol to show where the program was in the PCB and CPU. This also meant that we needed to check the values by hand to see if they lined up as expected with the example programs our professor would run. If the output was correct, then it runs well; if not every value lines up, that might be a problem down the road.

The 2nd task had us build a scheduler to juggle the programs, with the ability to use Round Robin, First Come First Served, or Priority. Seeing as we now volley the programs back and forth, since true concurrency doesn’t exist, we had to determine how the programs would be ran. We also had to upgrade our memory, adding onto the limits, headers, and info needed to determine it’s current position, as well as go back and fix any errors that may have existed in the 1st iteration.

The last task had us throw an extra program into the mix, with the stipulation that our memory can only run 3 concurrently. We simulated a hard drive via HTML5’s local storage and swapped programs in-and-out of memory onto the hard drive, if the CPU was full. The hard drive was also capable of reading, writing, editing (via writing again), and deleting files. While no stage of our tasks was easy, this was the hardest, since swapping was the hardest concept to wrap my head around, in terms of the coding.

Results

The operating system is fully functional, able to juggle 4 programs at a time. However, there is a bug that requires a reset after every time all current programs are done running. This only popped up during the final task, and thus at the end of the semester.

3) Use Materialize.js

Thought Process

While looking for a UI framework that dealt with flexbox, I stumbled on Materialize.js. It allowed for cleaner divisions on the page and some responsiveness, as well as allotted me time to create some more intense looks, such as the background.

Results

Materialize.js saved me time from trying to write out and configure flexboxes.