Continuation of DremDOS Development

That Took Way Too Long


My laptop finally came in! Because of that, I can finally continue developing DremDOS. A few features and tweaks have already been implemented. For example, a better crash system has been developed. Details of the crash system can be found below, but in short, it basically allows DremDOS to be able to determine where the crash comes from and the type of crash that occurred. However, the crash handler is still only able to be called directly. I believe the only way I could change this is by modifying the crash handler in COSMOS itself. However, I don't have any experience working that close to the metal and don't know assembly.

The Crash Code System

The crash code system is fairly simple - an 8 character code (0-F) with certain characters allocated in sectors for specific purposes.
Crash code layout: [00][00][000][0]

First Sector

The first sector defines where the crash came from. As of the time of writing, there are two possibilities:
00: Kernel - A crash caused by the C# code itself. Because of this, this is fairly broad.
01: Setup - A crash caused by the setup program.

Second Sector

The second sector defines the type of error. For example, an error caused by a failure to write to a file is different than an error caused by a memory overflow. As of the time of writing, there are also two possibilities for this sector:
00: General - Another broad type of error used by normal things
01: Security - An error to, for example, prevent exploitation of a security hole.

Third Sector

The third sector is the actual error code that is defined by the program itself.

Fourth Sector

The fourth sector defines if the crash is fatal or not. Currently, if it is set to 0, it means it's fatal. However, if it's a 1, it's not fatal and DremDOS will continue running after the user presses a key. This functionality might be expanded on later, but for now this is it's only purpose.
Fatal Crash
Nonfatal Crash

Automatic Crash Code Definition System

Before the overhaul to the crash handler, crash codes were pretty much just some random letters and numbers dedicated specifically to one error. However, now there is the ability to tell the crash handler where the crash came from and the type of crash that occurred. As such, the crash handler automatically attempts to decode what the crash code means to help the user determine exactly what failed. This would be very helpful to a developer. As seen in the images above, the crash handler automatically tells you where the error came from, what type of error it is, the actual error code, and, if the error code is defined in the crash handler itself, the definition of the error.

Comments

Post a Comment

Popular posts from this blog

Hacking a SMART Response XE

The Tiny Computer of Your Dreams Note: I'm writing this on my phone so no headers and decent lists and stuff. I'll fix it later eventually probably. T oday I learned about a portable device called the SMART Response XE. Basically, it used to be an expensive unit to let teachers answer questions because it is too hard to raise hands (OK more for testing). Now that Chromebooks exist, they are basically useless, so you can get them for insanely cheap on eBay. This device, however, is basically an Arduino. Bundle it with a 2.4GHz transceiver, a screen, and a keyboard, and you have yourself one of the most amazing little bits of kit that are basically begging to be hacked. Anyway, I bought a lot of 5 functional units on eBay as well as 2 CP2102 serial adapters and 50 5x2 pin headers on Amazon (I only wanted a couple but whatever). It also has 128K of flash(?) so I have plenty of room to play with. Some madlad  wrote a support library for it  so I have almost all the previous functi...
Read more

Hacking a Smart Response XE (Pt.2)

Image
Updates I'm baaaaack! Let's Catch Up I finally decided to pick up this project yet again and, with some better soldering skills (and tools! Pinecil is great!) under my belt, I successfully flashed  Larry's SRXE Bootloader  to a board and fixed the UART connection, which means that I can now develop my very own firmware for the Smart Response XE! Well, by start, I really mean that I've already started, and it's really starting to take shape. Care For A Demo? By the way, if you're curious as to what Innonet is, I'll talk about it briefly in this blog post, and more information on it will come soon ™. The firmware will be uploaded to a  GitHub repository  in a preview state by the time this blog post releases. What Exactly is Done so Far? So far, the UI is about 70% done (most of it works, need to implement other dropdown menus and fix some bugs). If you have a keen eye, you will notice the header said DremXE, as opposed to the original name (which was Dremduin...
Read more

Changes to The Collective

The Collective is Moving The Collective has been moved to a private, self-hosted Pydio Cells server. If you would like access to The Collective, please leave a comment with a way to contact you (email, Discord username, Twitter handle, etc.) and I'll consider giving you a limited user account. A public access account is being considered. Related link: https://innovation-inc.org/services/thecollective/
Read more