Introduction to SerenityOS Programming | Hacker News Reader

Introduction to SerenityOS Programming

awesomekling.github.io

159 pointsrogerclark43 comments

Hello friends! Author here. Happy to answer any questions about SerenityOS and its programming environment. :)

Do you have any ready to use development environments? If not, do you have a detailed doc around setting my local dev env? Thank you!

Hi pryelluw! There's no ready to use development environment. There are scripts to build a toolchain, and scripts to build the system, but beyond those things, everyone sets up their own environment they way they like. :)

It usually takes less than 30 minutes to have everything set up if you're on a modern Linux system. Build instructions can be found here: https://github.com/SerenityOS/serenity/blob/master/Documenta...

Thank you for the quick response.

The LibGUI you've created looks to be a really nice and capable widget toolkit :)

Any plans to port it to other platforms (eg OpenGL so it becomes very cross platform) so it can be used outside Serenity?

Hi JoeG2040! I don't really make plans for this project, I just follow my nose and work on what's the most interesting at the moment.

That said, jcs@ from the OpenBSD project has been working on a port of the entire Serenity desktop environment to OpenBSD: https://twitter.com/jcs/status/1224205573656322048

I usually make a little round-up video at the end of each month and I invited jcs to show off his port in my last video[1] a couple days ago.

It would definitely be feasible to port it to other platforms. The original prototype for the Serenity GUI was built inside an SDL framebuffer on Linux, and it would be kind of fun to bring it back there someday. :)

[1] https://www.youtube.com/watch?v=m5JD5JCe1wY (jcs's segment starts at ~15:30)

> That said, jcs@ from the OpenBSD project has been working on a port of the entire Serenity desktop environment to OpenBSD: https://twitter.com/jcs/status/1224205573656322048

Wow. That looks pretty awesome. Your gui aesthetic is pretty 90s in the best way possible, and combined with OpenBSD underneath this looks like it has potential to be a seriously no nonsense system.

Hi asveikau! Yeah, it's a nice glimpse of one possible future. :)

I'm gonna keep building the custom SerenityOS kernel of course, since it offers extreme productivity and integration opportunities that would be a lot harder to explore with a foreign kernel at the moment.

At a time when I had more spare time vs. today I was also hacking on my own kernel, so I definitely understand the drive to do that. (And congratulate you for pulling it off.)

But OpenBSD is a great kernel and user mode, all around. For context on my own biases, usually when discussions of desktop environments occur around here I am defending X, because it isn't as bad as people say. But seeing the combination of OBSD and your UI I am like... Yes, that looks like a feasible system that is not X.

This is amazing! I love it! I have a couple of random questions. What video mode does the GUI environment run in? Does it boot directly into the GUI or can it run headless as well? Do you have a more detailed overview of the different parts of the OS and its current capabilities?

Disclaimer: I am not the author, just spent a little time with the system. You can totally boot without the GUI by passing the "text_debug" option to the kernel command line. If you have Serenity built on your system you can try this out really easily by running: SERENITY_KERNEL_CMDLINE=text_debug ./run in the Kernel/ directory.

Hi bananaboy! The system currently boots into 1024x768x32 by default. It uses the Multiboot protocol to request that the bootloader sets a video mode before passing control to the kernel. That allows the system to work in tons of places where we don't have a proper video card driver yet :)

As DAlperin mentioned, it's possible to boot it headless although it's not something that gets a lot of focus since this is primarily intended as a GUI system.

I have some presentation and "code tour" videos[1] on my YouTube channel where I go into great detail about how some parts of the system work. If you would like to know about the SerenityOS internals in-depth, it's a pretty good place to start. :)

[1] https://www.youtube.com/playlist?list=PLMOpZvQB55be9pGeYypHg...

Thank you! I’ll have a look at your videos!

After a few pull requests I can definitely say that LibGUI is the most fun c++ GUI framework I have ever seen (not that it's my usual wheelhouse.) After a few minutes of looking around and reading the source, LibGUI quickly became something I look forward to working with every time I do. Thank you for all of your work on Serenity!

Hi DAlperin! I'm really glad you've found it fun to work with so far. :)

Have you considered adopting GRSec's kernel patches to make it a serious security force to be reckoned with?

Also do you have a serious key-management plan in place to signing and distributing your builds and packages?

Grsec is Linux. Serenity OS isn't.

SerenityOS did recently add an implementation of OpenBSD's pledge() and unveil() API calls¹; seems like - if SerenityOS does continue to pursue OS-level exploit mitigations - it'd make sense to continue down that path of referencing how OpenBSD does it. Andreas Kling's blog also describes some programming conventions for internal code, a lot of which seems geared toward avoiding potentially-security-compromising memory access bugs in C++.

----

¹: https://awesomekling.github.io/pledge-and-unveil-in-Serenity...

Hi yellowapple! Yes indeed, the pledge() and unveil() mechanisms are still spreading throughout the SerenityOS userspace. I'm happy to borrow smart mitigation techniques from anywhere, as long as they make sense and don't have unreasonable performance cost :)

Since you mention memory access bugs, I should mention that the number of regular "C-style" memory access bugs I've had to debug in all of the system so far is in the single digits.

I've heard over and over that C++ is unsuitable for operating systems (and kernels, especially) but so far it seems extremely suitable. To each their own, of course :)

That's all great to hear. SerenityOS looks awesome; keep up the great work!

> I've heard over and over that C++ is unsuitable for operating systems (and kernels, especially)

I think that myth's been dead for a long while (see also: Windows and Haiku, both of which - IIRC - have quite a bit of C++ in their kernels), but hey, one more nail in that coffin, right? ;)

I've heard about SerenityOS from the videos on YouTube and I'm impressed over its 90's GUI and some of the new OSes that have their own desktop environments and have the case for integration rather than a separate kernel + desktop environment, etc.

Are there any plans for 64 bit support? and in general about SerenityOS's internal GUI system, how does it compare to RedoxOS or more similarly Haiku which language and GUI development wise, it is almost exactly the same.

Hello highspeedmobile! I don't generally make plans one way or the other. However we do have https://github.com/SerenityOS/serenity/issues/1327 open about adding x86_64 support as of a few days ago. :)

I haven't looked at RedoxOS or Haiku enough to tell you how similar they are.

These blogposts are awesome, keep them coming Andreas!

Are programmers expected to always use this high-level OOP style of writing GUI programs? Or does Serenity expose a lower level API for manually creating windows, reading hardware input, writing pixels to framebuffer, etc, like Xlib for example?

Hey voldacar! Writing is hard, but I suspect it will get easier if I do it more often. Thank you for the encouragement :)

Indeed, this is the only native GUI programming interface available on the system. Outside of the standard C library (which includes an increasingly reasonable subset of POSIX), the whole OS is modern C++.

So glad this project is still going! I remember looking at the userspace code last time it was linked here and marveling at how clean and uncluterred it was.

Hi thom! I'm glad you remember it that way :) Hopefully the userspace code is still clean and uncluttered. The project keeps growing at a pretty high pace and I do sometimes worry that quality suffers. Nothing that a little "let's calm down and work on stability for a moment" can't fix yet though.

This is great! I found SerenityOS after it got posted here a few months ago and I've been keeping up with your videos. Unrelated note, how stable is SerenityOS on baremetal? Would love to have it up & running on a spare desktop in the near future.

Hi Aaronstotle! I don't run it on bare metal myself, but there are a couple of other developers who mess around with it somewhat regularly. You should have a fair chance of getting it running on hardware that's a decade old or so.

There are people actively working on various things like ACPI, AHCI and NVMe right now, but hardware support takes time. That said, things have been moving at a pretty decent pace :)

Yes, I've noticed things have definitely picked up steam in the last six months, especially considering all your security improvements. Is there an irc/chat you and other people hang out in?

Oh indeed, and it's been super fun learning about security!

The main community hub for the project is #serenityos on Freenode :)

This basically looks like a cleaned up Qt API. (Which is a good thing, the basic design works really well for applications, it only gets annoying if you want "apps" and fully customized look and feel, animating everything)

Hi blattimwind! Yes, it is heavily inspired by (the excellent) Qt. I worked on the Qt team in the past, so the influence is unavoidable :)

Wow, this is very cool. I am merely a BSD/Linux/UNIX hobbyist (I do not write code), but I love the concept and implementation of SerenityOS. Very clean and fast. The window manager reminds me of icewm, one of my favorites. And I love the global-style application menu on the top bar. I will be keeping an eye on your progress; I look forward to a bootable iso some day. Great work!

Please update the title to include GUI, i.e. "Introduction to SerenityOS GUI programming".

Is there some reason why an introduction to SerenityOS GUI programming cannot also be an introduction to SerenityOS programming as a whole? Especially considering that the graphical interface seems to be the focal point of SerenityOS (much like it is for Windows or BeOS/Haiku or classic Mac OS).

> Is there some reason why an introduction to SerenityOS GUI

> programming cannot also be an introduction to SerenityOS

> programming as a whole?

It could be, but it's vague. The original title was very much to the point, I don't understand why 'GUI' was dropped.

Very nice and clean GUI library.

Clean GUI C++ libraries like this always make me think that Microsoft deliberately chose to not implement such a nice C++ GUI API for Windows and instead gave us the horrible MFC in order to lock us in into Visual Basic and other proprietary projects.

If Microsoft had given us a clean C++ API for Windows, the world of programming would be very different today.

> If Microsoft had given us a clean C++ API for Windows, the world of programming would be very different today.

I mean, Win32 was a relatively clean C library. Not beautiful by any means, but it worked and was well documented. At the time it was huge, but it's pretty irrelevant today. If they did it in C++ instead of C, how could it have been different.

I wouldn't call the Win32 API clean. To me, it's one of the worst APIs I have ever encountered.

It worked and it was well documented, but that does not mean its design is very nice. To me, that is.

There would be no surprise to this since the Win32 GUI APIs were created at a time when C++0x was widely used compared to what you see with APIs created in C++11 and onwards.

I guess the latter is the case for SerenityOS and other OSes with integrated GUIs.

Indeed, SerenityOS has been using C++17 from the start, and will be using any helpful C++20 features as soon as they are available in compilers. We're already using templated lambdas in a couple of places :)

The Win32 API could have been much better designed even if done in plain C. The problems the Win32 API are basic, and can be solved in any language that provides minimal facilities.

Wow! Very nice

Reply on news.ycombinator.com