Getting a Web Server running on my hobby OS on OSHub

OSHub.org 1.3.7ImportExploreProjectsPostsNewsHomeAll UsersSign InSign Up

Info:
Check out our new News page! Ranked stories, points, comments, and more.
×

Send FeedbackYour Feedback
Email (optional)CancelYour feedback helps us improve.Or email us directly
On this pageReading Time3 min read • 591 words/joexbayer/RetrOS-32/Getting a Web Server...ShareGetting a Web Server running on my hobby OSNovember 27, 2025joexbayerkernel, networking, tcp, http, web
DemoAfter a long break from working on my hobby operating system, I finally got back into it and finished a very important milestone: a working web server.Full Github repo: https://github.com/joexbayer/RetrOS-32

Serving a real page

Networking was always integral to my hobby project. The first goal was getting the basic networking stack working: Ethernet, IP, ARP, UDP, TCP, DHCP and DNS. Besides TCP this was rather straightforward, but when moving onto HTTP things broke.

First time getting TCP to work.

Networking stack codeThis led to my first break from the project, but also left a nagging thought in my mind, wanting to make it work. I finally sat down and started debugging. I eventually found the culprit after hours of dissecting my own code, the problem was a broken implementation of the terminal buffer, overwriting a lock in another process… fun. Additionally, the E1000 network driver did not correctly handle incoming packets, which I finally got working by handling bursts of packets.Performance and hardeningAfter getting an HTML page returned from the web engine I started noticing lots of performance errors and hangs from TCP, mainly because quickly refreshing the browser led to a spam of RST packets which were not handled correctly.After a few hours of tinkering I finally got the RST packets working and the network stack is now able to handle a packet spam from the browser.The HTTP EngineNext step was actually implementing a HTTP engine, parsing the requests from the user. Before this engine I simply returned a static HTTP response no matter the actual request.Keeping with the spirit of this hobby OS I want to write everything from scratch, luckily I already had implemented a pretty complete HTTP parser for my other project c-web-modules. So I extracted the HTTP parser as a standalone library and ported it to my OS.The Web Engine.After the HTTP engine was done I moved onto the web engine, focusing on something small, rather than big and fancy. Mainly routing was important and adding route handlers. Allowing the user to specify a route, method and lambda function handler./* Simple routing */
engine.get("/", [](const http::Request& req, http::Response& res) {
(void)req;
res.setBody("hello world!");
....
});It’s a tiny example, but it mirrors how a lot of modern C++ and web frameworks think about routing: match a path + method, call a handler, build a response.#lang:plaintext
[ Browser ]
|
v
[ Web Server (userspace):
WebEngine | HTTPEngine | FileRepository ]
|
v
[ Network stack:
TCP/UDP | IP | ARP | DHCP | DNS | Ethernet(E1000) ]The Web Server. The last step was updating the userspace program with the new HTTP and Web engine. Finally I added a way to serve files using a FileRepository which supports caching. Now I can edit the files inside the operating system and then serve them with the web server.#lang:cpp
WebEngine webEngine(80, 16);
web::FileRepository fileRepo;

/* Simple static pages */
webEngine.get("/home", [&fileRepo](const http::Request& req, http::Response& res) {
(void)req;
res.sendFile(fileRepo, "/web/index.htm");
});

webEngine.get("/about", [&fileRepo](const http::Request& req, http::Response& res) {
(void)req;
res.sendFile(fileRepo, "/web/about.htm");
});

webEngine.get("/status", [&fileRepo](const http::Request& req, http::Response& res) {
(void)req;
res.sendFile(fileRepo, "/web/status.htm");
});

webEngine.run();https://github.com/joexbayer/RetrOS-32/tree/development/apps/webserverNext stepsThe next thing on the TODO list will be to add a more fancy UI for the webserver and a way to close it gracefully.(Graceful shutdown is one of those “boring” features you don’t miss… until the first time you corrupt something on exit.)When this is finished, the biggest task so far will begin… the web browser.

Comments10.4k viewsAnonymous2 days agoI'm a hacker hahahahahahaah

I'm a hacker hahahahahahaah
Reply
CancelAnonymous2 days agoAnonymous2 days agoI'm a hacker hahahahahahaah
This dude clearly is a hacker, I don't know what you're on about.
This dude clearly is a hacker, I don't know what you're on about.Reply
CancelAnonymous2 days ago2.68k views
2.68k viewsReply
CancelAnonymous2 days agoIt makes me wonder why we still build http modules by hand, when we can just outsource that to a C++ library or even Codex.
It makes me wonder why we still build http modules by hand, when we can just outsource that to a C++ library or even Codex.Reply
CancelAnonymous2 days agoAnonymous2 days agoIt makes me wonder why we still build http modules by hand, when we can just outsource that to a ...Why not? Its a hobby project.
Why not? Its a hobby project.Reply
CancelAnonymous2 days agoHi!
Hi!Reply
Cancel
joexbayerMemberHobby operating system enthusiast.View Profile →StatsViews10.4kComments6PublishedNov 27, 2025Related ReadingRust Hobby OS projects worth exploringOSHub•1.14kMilestone 0.4: Kernel Mode Shellrickyadastra•117TagskernelnetworkingtcphttpwebShareTwitterCopy Link

© 2025 OSHub. Built for kernel devs. v1.3.7ChangelogsContact UsPrivacy PolicyShare

This document details the development of a web server as a significant milestone within the hobby operating system project, RetrOS-32, undertaken by joexbayer. The project’s core objective is to build a fully functional operating system from scratch, emphasizing a hands-on approach to developing various components. The development of the web server represents a crucial step, integrating networking, HTTP processing, and file serving capabilities.

The development process began with establishing a fundamental networking stack, incorporating key protocols like TCP, UDP, IP, ARP, DHCP, and DNS. Initial challenges arose due to a broken terminal buffer implementation, which inadvertently caused a lock contention issue impacting other processes. Furthermore, the E1000 network driver needed adjustments to correctly handle incoming packets, rectified by implementing burst packet handling. The initial focus was on achieving basic network connectivity rather than a sophisticated web server implementation.

Following the network stack’s stabilization, the subsequent development involved a HTTP engine, parsing incoming HTTP requests. Previously, the web server simply returned a static HTTP response regardless of the request. The author chose to leverage an existing HTTP parser—extracted from a previous ‘c-web-modules’ project—to streamline this process. The HTTP parser was then ported to the RetrOS-32 operating system.

The core of the web server architecture involved the WebEngine, responsible for handling HTTP requests and constructing responses. Routing was implemented using a lambda function approach, mapping URL paths to specific handlers. A simple example demonstrated this routing mechanism, illustrating the core principles of matching paths and methods to corresponding handlers. The web server architecture integrated the HTTP Engine, WebEngine, and a FileRepository enabling file caching and serving. The FileRepository was incorporated to serve static files, further enhancing the functionality.

The development culminated in integrating the new HTTP and Web engine components into the user-space program. The design emphasized a modular approach enabling the serving of static files, enhancing the operating system’s capabilities. The author planned future development steps including an enhanced user interface and a graceful shutdown mechanism. The significant remaining task was the creation of a web browser for the OS.

The document showcases a deliberate, incremental approach to development, prioritizing a hands-on understanding of the underlying technologies. The author's choice to reuse and adapt existing components, such as the HTTP parser, demonstrates an efficient strategy for tackling complex tasks within the constraints of a hobby project. The project’s timeline indicates a phased rollout of features, with a particular focus on building out the core functionality before adding refinements or more advanced features. The comments section reveals a community interested in the project, exhibiting a range of reactions, from enthusiastic support to skeptical observations regarding the feasibility of building a robust web server from scratch.