Up to TCP most protocols are very straight forward, atleast getting them to work semi reliable. But then TCP explodes in complexity with all the state management and possible paths a connection can take.
HTTP is mostly annoying because of all the text parsing :D
Yeah...HTTP/1 is one of those weird cases where the older protocol is considerably more difficult to implement correctly than the newer ""more complex"" standard. This is especially true if you want your server to work with they myriad of questionably compliant clients out in the world.
HTTP/3 might have been easier, and using QUIC+HTTP/3 in your hobby OS is a fun flex :)
I don’t think that http/3 is easier to implement than http/1.1 especially since h3 is stateful where http/1.1 is not. Especially not when everything should be working correctly and securely because the spec does not always tell about these things. Oh and multiplexing is quite a hard thing to do especially when you are also dealing with a state machine and each of your clients can be malicious.
I can't speak to http/3 (I haven't tried to impl it), but I can say that a bare-bones http/2 is very easy to implement because it doesn't try to pretend to be prose.
I’ve had a bunch of images of my OS lying around from over the years. Luckily, I started taking them early, all the way back to the textmode days. I thought I’d put together a small post series to look back on the different stages and how it’s evolved.
Been working on this site for a while after working on my own hobby OS for a few years. Idea is to have a central place to share and gather hobby operating systems.
Its possible to login with github and import projects from gitlab, codeberg and github. You can also import your projects without a user (although you wont be able to manage the project then).
Also allows posting "posts" on your project (devlogs, blogs, discussions, releases). Its all still in beta and got some future ideas that would be cool to implement. Would love any ideas or feedback.
An x86 disassembler is not that hard, as long as you stick to a single mode and ignore the SIMD alphabet soup.
You have a short loop that scans through the prefixes, checks for a REX prefix (if you handle 64-bit mode), reads the opcode (1-3 bytes), reads the MOD/RM byte if there is one (use a table lookup), reads the SIB byte if there is one (table), reads offset if there is one (table), reads immediate if there is one (table).
It's probably easiest if you use an "expanded/normalized" opcode internally so the 1-3 opcode bytes + the 3 extra bits from some MOD/RM bytes + prefix info (for certain SIMD instructions) map to a single 16-bit opcode (likely around a couple hundred to a thousand opcodes in total).
You have a table that maps those to mnemonics + operand info. You have some tables that map 0-7 (or 0-15) to AL/AH/... and AX/BX/CX/... and CS/DS/ES/... and various system registers.
Not that much code all in all. Several tables. You can squeeze them and bit pack them to your heart's content if you want.
Once you have that, a simple assembler isn't so hard.
HTTP is mostly annoying because of all the text parsing :D