Introduction to SerenityOS Programming • Hacker News Board

Re: Introduction to SerenityOS Programming

#21

Post by yellowapple » Wed, Mar 04, 2020, 6:41 AM UTC

dmix wrote: post #17

akling wrote: post #2

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

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?

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...

Re: Introduction to SerenityOS Programming

#22

Post by yellowapple » Wed, Mar 04, 2020, 6:44 AM UTC

bArray wrote: post #18

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).

Re: Introduction to SerenityOS Programming

#23

Post by akling » Wed, Mar 04, 2020, 7:41 AM UTC

DAlperin wrote: post #15

akling wrote: post #2

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

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. :)

Re: Introduction to SerenityOS Programming

#24

Post by akling » Wed, Mar 04, 2020, 7:48 AM UTC

thom wrote: post #13

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.

Re: Introduction to SerenityOS Programming

#25

Post by akling » Wed, Mar 04, 2020, 8:03 AM UTC

bananaboy wrote: post #14

akling wrote: post #2

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

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?

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...

Re: Introduction to SerenityOS Programming

#26

Post by akling » Wed, Mar 04, 2020, 8:07 AM UTC

asveikau wrote: post #19

akling wrote: post #12

Earlier quoted context omitted.

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 las…

> 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.

Re: Introduction to SerenityOS Programming

#27

Post by akling » Wed, Mar 04, 2020, 8:15 AM UTC

yellowapple wrote: post #21

dmix wrote: post #17

Earlier quoted context omitted.

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?

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 memo…

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 :)

Re: Introduction to SerenityOS Programming

#28

Post by highspeedmobile » Wed, Mar 04, 2020, 9:39 AM UTC

akling wrote: post #2

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

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.

Re: Introduction to SerenityOS Programming

#29

Post by axilmar » Wed, Mar 04, 2020, 9:58 AM UTC

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.

Re: Introduction to SerenityOS Programming

#30

Post by speedplane » Wed, Mar 04, 2020, 10:03 AM UTC

axilmar wrote: post #29

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.